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 JaxB.
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 :)
Follow?
-dain
