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 AND gbeans in geronimo-application missing
Date Sun, 26 Sep 2004 18:43:11 GMT
After a very quick review of some of these changes...

This breaks a bunch of stuff.

Why isn't ApplicationInfo a subclass of Module?  I think this would be 
the quickest path to fixing the missing gbean handling and improve 

david jencks

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.
> 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.
> thanks
> david jencks
>> -dain

View raw message