geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
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 17:41:39 GMT

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.

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.

david jencks

> -dain

View raw message