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
