geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <dsundst...@gluecode.com>
Subject Re: svn commit: rev 47239 - in geronimo/trunk/modules: client-builder/src/java/org/apache/geronimo/client/builder connector/src/java/org/apache/geronimo/connector/deployment connector/src/test/org/apache/geronimo/connector/deployment deployment/src/java/org/apache/geronimo/deployment deployment/src/java/org/apache/geronimo/deployment/plugin deployment/src/java/org/apache/geronimo/deployment/service deployment/src/java/org/apache/geronimo/deployment/util j2ee/src/java/org/apache/geronimo/j2ee j2ee/src/java/org/apache/geronimo/j2ee/deployment j2ee/src/test/org/apache/geronimo/j2ee/deployment jetty/src/java/org/apache/geronimo/jetty/deployment
Date Sun, 26 Sep 2004 21:31:30 GMT
On Sep 26, 2004, at 10:41 AM, David Jencks wrote:

>
> On Sep 26, 2004, at 10:27 AM, Dain Sundstrom wrote:
>
>> On Sep 26, 2004, at 3:55 AM, David Jencks wrote:
>>
>>> This might be moving in a good direction overall, but one aspect 
>>> totally sucks, namely that in the ModuleBuilder interface in the
>>>     Module createModule(String name, Object planFile, JarFile 
>>> moduleFile, URL specDDUrl, String targetPath) throws 
>>> DeploymentException;
>>> method the planFile can be either a File or an XmlObject from an 
>>> embedded plan.
>>>
>>> Personally I think at this point passing XmlObjects around rather 
>>> than file-like objects is a better idea.
>>
>> The planFile parameter can either be a File, XmlBean Object or null.  
>> I thought about parsing the file directly in the EarConfigBuilder, 
>> but that would require the builder to know about all the XmlBeans 
>> schemas used in module deployers (or XmlBeans parses it into a 
>> typeless thing that looks like a DOM).
>
> As the recent update to the geronimo-application.xsd shows, the module 
> builders all have to accept untyped XmlObjects anyway from embedded 
> vendor dds.  Forcing them to deal with Files as well is IMO a bad 
> idea.
>
>>  I prefer to simply pass the location through to the module builder 
>> so it can handle it like it does for a standalone module with an 
>> external plan (6 one way, half a dozen the other)....
>
> The EARConfigBuilder can and IMNSHO should be reading all external 
> plans into an untyped XmlObject first anyway.

IMNSHO I totally disagree.  If you ask me, if we have to pass a 
typeless xml representation through it should be DOM, since any xml 
marshaling framework can handle dom.  Frankly, XmlBeans sucks, I want 
to see less of it and absolutely don't want to force it on people 
trying to plug into geronimo.

> Anyway I'll have to look into the rest of these changes... any 
> simplification is good.  Maybe we could do something like wrapping the 
> plan in a somewhat typed object that gets the contents from variable 
> locations, somewhat like the xslt Source idea.

I'm not sure what you are getting at, but I can say one of the things I 
really dislike about our current code, is it is basically xslt written 
in java.  A descent xml marshaling framework would handle marshaling 
several representation into the same tree without lots of magic tree 
manipulation methods.

-dain


Mime
View raw message