geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sachin Patel <>
Subject Need patch review.. Builders to use DeployableModule Interface
Date Thu, 07 Dec 2006 23:50:42 GMT
I've attached a patch 
GERONIMO-2638 that provides the changes from our builders use of  
JarFile to a new interface DeployableModule.  Since 1.2 is currently  
less disruptive, I've created a patch that can be applied to 1.2 and  
eventually I'll port it to trunk.  I did the changes in a way so that  
all the builders don't have to change at once and the migration can  
be done incrementally.  Thus the use of the "temporary" classes,  
ModuleBuilder2, ConfigurationBuilder2, and their abstract impls.  The  
current patch only changes the EARConfigBuilder and the  
WebModuleBuilders (minus WebServices).  I want to go ahead and get  
this out so I can get input prior to migrating the rest of the  
builders.  So please provide your comments, concerns, feedback.

In a nutshell, the basic flow behind this change is the following..

(1) A deployableModuleType (gbean) can be set now in the  
DeploymentManager by the client (eclipse for example)
(2) Given the artifact to deploy, (previously a JarFile), a new  
DeployableModule instance will be created through the  
DeployableModuleFactory class, passing the the artifact, where its a  
JarFile or in the eclipse case, an xml file describing the  
application and where all of its resources, jars, classes reside.
(3) Now the builders will now be passed around this instance of  
DeployableModule, rather then the JarFile and the builders will  
process the artifact, when possible, using the DeployableModule  

And basically thats it.  This allows Geronimo to build the  
configuration from any directory structure, and no longer has to  
conform to a J2EE archive structure and the copy of a resource in an  
IDE is the copy that is running.  It is completley pluggable and you  
can easily provide support for an IDE or even a Maven project structure.

The only thing I don't like is when you're dealing with a JarFile  
(the primary case outside of an IDE).  I'm creating a wrapper around  
the Jar using the DeployableModule implementation JarDeployable.  The  
problem is that whenever you're processing the JarEntries, you can't  
use the interface and have to call..

if(deployable.isArchive()) {
	JarFile jar = deployable.getJarFile()
	//process the jar
} else {
	//use the interface

There are only a few cases where we're travesing through the entries  
of a Jar, so I'm not sure if people think this is a big deal or a  
huge annoyance having to deal with 2 cases.

Please review as it would be nice to get this into M1.  If you have  
any suggestions on how we can improve the interface, I would love to  
hear your input as I just threw this interface together a while ago  
and I'm sure we can improve on it.



View raw message