On Mon, 9 Jan 2006, David Jencks wrote:
no, in fact right now you can't deploy a separate plan and rar using the hot
deployer, you would have to pack the plan into the rar. Personally I despise
the hot deployer :-) but I will try to consider this anyway :-)
<goes away and looks at the code>
After looking at the hot deployer, I think we can make it deploy a plan that
does not need to go with a j2ee artifact. There are 2 kinds of these, gbean
plans and "synthetic ears" that include one or more ext-modules and no normal
modules. If this works, you would be able to:
-put the appropriately versioned rar in the geronimo repository
-put your rar plan in a synthetic ear plan
-copy the synthetic ear plan to the hot deploy dir (hot deployer will deploy
it)
-modify the rar in the geronimo repo (nothing will happen)
-touch the synthetic ear plan in the hot deploy dir (hot deployer will
redeploy it)
Is this too much work?
Maybe not, but I want to deploy the resource adapter once as a standalone
module to
1. save memory,
2. save threads (each resource adapter instance creates a Timer instance
for administrative purposes).
Also, this is how I'm testing it on other app servers and I don't want to
maintain two deployment strategies.
So my wish is that, sometime in the future, geronimo supports
1. deployment and redeployment of a resource adapter as a standalone
module without any outbound connection factories defined,
2. the ability to deploy and undeploy outbound connection factories for a
deployed standalone resource adapter independently of each other.
If you agree that this is worthwhile functionality, I'd be interested in
helping flesh out the requirements, the design, and the implementation as
desired and as time permits.
I'll take back my request that geronimo be able to deploy any 1.5
compliant rar file without a deployment plan. In some cases this is an
unreasonable expectation. On deployment, the app server needs to
configure and start an instance of the resource adapter class, and it
can't do that if there are ra configuration properties with undefined
values. When default values are provided, I would suggest the app server
can and should use those. That's what JBoss does, and that's why I can
deploy my rar file to JBoss without a JBoss-specific descriptor. If I try
to deploy without default config property values, I get a deployment
error.
Now let me complain about the hot deployer :-) What I don't like about it is
that it doesn't integrate very will with automated builds. You can have your
automated build copy an artifact into the hot deploy dir, but there is no way
to determine that the deployment is complete or error-free, so effectively
your build script has to have the copy as its last step. I prefer solutions
where the build script does something that positively tells it whether the
deployment worked. At the moment we have 2 ways to do this easily with maven
1 and one way to do it with a command line tool.
command line: call the deployer java -jar bin/deployer.jar --user system
--password manager deploy myrar.rar myplan.xml
deploy to a running server using the maven deploy plugin, using something
like this:
<deploy:distribute
uri="deployer:geronimo:jmx"
username="system"
password="manager"
module="${maven.build.dir}/openejb-itests-$
{pom.currentVersion}.jar" />
<deploy:start
uri="deployer:geronimo:jmx"
username="system"
password="manager"
id="openejb/itests/${openejb_version}/car"/>
With this method, I usually have some other maven scripting that use the
deploy plugin to unpack and start a geronimo server in the same module. I
think this is the easiest way to set up integration tests.
build a server that includes your application: have one or more config
modules similar to the configs/ in the geronimo build, and assemble a server
with just the stuff you need, similar to an assembly/ in the geronimo build.
The last approach is not really as easy as it should be yet. We are working
on making it easier and more flexible.
What do you think?
I prefer a deployment directory because it's easy to manage, but I don't
mind using a command line tool or an ant task. I'm used to manually
deploying stuff anyway.
Michael
