geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Deployment Metadata [was: Deployment architecture]
Date Mon, 03 Jan 2005 22:27:19 GMT
I decided to split the discussion because it is getting too long to 
read :)

On Jan 3, 2005, at 1:30 PM, David Jencks wrote:

> On Jan 3, 2005, at 11:53 AM, Dain Sundstrom wrote:
>> IMNSHO this is caused by our usage of XML beans.  When I talked to 
>> the XML beans guys at ApacheCon they told me to put an abstraction 
>> layer between XML beans and our deployment code.  This allows them to 
>> innovate and us to have well defined objects with interfaces.  If we 
>> had interfaces (and normal objects) for our metadata, we would be 
>> able to create generic metadata processors.  I personally believe 
>> that the majority of the "ugliness" of our deployment code is the 
>> lack of abstraction (flexibility) of our metadata objects.
> Can you give me some more specific idea of what you are talking about 
> and how it might work?  I'm intrigued but really have no idea what you 
> mean.

I'm going to talk about implementations to make the discussion more 
concrete, but the implementation is not that important.  I think we 
should create a set of classes to represent a deployment unit.  This 
would mean we would have an EAR object which contained modules, which 
themselves are EJB, WEB, Connector or AppClient.  You get the idea.  
The important part is to use interface so a module build can create use 
it's own implementation.  As for how we get the data from XML to an 
Object graph and back, we either write some code that can take an XML 
Beans dom and turn it into a graph, or we use something like Castor or 

Once we have these objects, we can make them do work for us.  For 
example, the EAR object could resolve an ejb-link.  The connector 
module could contain a set of preformed activation spec (well maybe... 
I'm just making that up :)



View raw message