I was thinking last night about how crappy the whole archive thing that sun
started is with respect to changing the configuration easily. I was
thinking that it is a bitch to extract a .ear, edit the application.xml,
then re-jar it and copy it to change where my .war gets deployed too.
This whole archive concept is kinda quirky in my oppionon. I think it has
its merits, but the folks at sun who came up with this for EJB stuff (and
now J2EE stuff) really didn't think about the full implications of it.
I think that it is nice to have an archive which contains all the classes,
resources, native libraries, filesystems and whatever a given deployable
might need to run. I even think it makes sence to specify some
configuration aspects... but to force all configuratino to be in that file
is just stupid.
Take for example a simple MDB which implements the Command pattern. This is
trivial code, which you might want to use in several different parts of your
application. But lets also say that there is a LGPL version of this with
some extra bells and whistles available. The developer of such would
probably want to provide a single deployable which contains all of the
classes, support files and default configuration.
Currently for a user to make use of this, he/she would have a few options:
1) Create a seperate copy of the archive with the configuration for each
destination and operational parameters which the MDB will use.
2) Create a single copy of the archive which has each of the MDBs
configured in the single configuration.
The first means that you have more classloaders, more bytes loaded, and more
files to unjar/jar when changing things... but it means that you can easily
undeploy/redeploy them seperatly.
The second has less unjar/jar'ing when things change and you can't easily
undeploy/redeploy a single MDB.
So why not provide a seperate of the configuration from the support files
and make them both deployable? Well, I think that is what we are heading
twords... and actually that is kinda what the damn birds were trying to tell
me in the first place.
With this seperation, a vendor (or actually we could release optional
components like this) could supply an archive (classes, support files,
filesystems, native libs, default configuration) and an example deployment
configuration file.
The deployment configuration file would specify the deployment archives and
the deployment units which are to be constructed. The deployment unit
configuration would be the same for the actual component, but could be terse
and only provide those elements which are to be overriden from the default
configuration in the archive.
So back to the Command MDB, the vendor might provide a:
command-mdb.jar
command-example-deploy.xml
And the user would simply copy the command-mdb.jar to jboss/deploy,and
create a command-deploy.xml with the actual running configuration, then copy
that to jboss/deploy.
The deployer would only start doing any work when the .xml file is copied,
since it should not expect that the configuration of the .jar is what should
actually be deployed.
The command-deploy.xml might look something like this:
----8<----
<jboss:deploy>
<deployment>
<archive name="command-mdb.jar"/>
<ejb-jar>
<enterprise-beans>
<message-driven>
<ejb-name>WorkerInvoker</ejb-name>
<acknowledge-mode>Auto-acknowledge</acknowledge-mode>
<message-driven-destination>
<destination-type>javax.jms.Queue</destination-type>
<subscription-durability>NonDurable</subscription-durability>
</message-driven-destination>
</message-driven>
</enterprise-beans>
</ejb-jar>
<jboss>
<container-invoker-conf>
<MaximumSize>1</MaximumSize>
<MaxMessages>1</MaxMessages>
<Optimized>True</Optimized>
</container-invoker-conf>
</jboss>
</deployment>
</jboss:deploy>
---->8----
The point is to link up small snippiets of configuration overrides, which
are then used to build the actual configuration for the component when
deploying.
By doing this, a user (or admin) does not need to touch the deployable
archive. They only have to provide a configuration for the deployments,
which link to the archive (so we know how to load the classes) and specify
the deployment units and there configuration.
* * *
This configuration/deployment style would be very benificial for
distributing support components for JBoss too. We could provide the core
server in one .zip, then provide plugins in seperate .zip's each of which
contains an archive and example/default deployment configuration plus a
simple README to show the users the simple steps to deploying the
components.
Anyways, I think we are moving in this direction... but I thought I would
share my thoughts on the matter, as I watch the code roll by.
--jason
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
