On Jan 9, 2006, at 11:38 AM, David Jencks wrote:
On Jan 9, 2006, at 4:15 AM, Michael Allman wrote:
On Mon, 9 Jan 2006, David Jencks wrote:
<snip>
I started looking into the daytrader app you mentioned. I
think I found its deployed instance in config-store/28, but it
looks like it bundles the activemq and tranql resource
adapters under the TradeDataSource and TradeJMS
subdirectories, respectively. Are you saying they don't need
to be there, that they could be referenced from the daytrader
app somehow?
They are added by the configuration building process, the
simplification is that you don't need to include the rars in
your ear yourself. We are thinking about a way to make it so
deploying a j2ee artifact does not copy any of it into the
configuration but refers to it in some form in the repository,
but this will require at least a new classloader and perhaps
unpacking the nested jars into a flat structure.
I'm trying to get away from using JBoss because their software
is buggy and they're a pain in the ass, but their resource
adapter deployment and configuration is easier and more flexible
than what Geronimo currently offers. Aside from the issue of
being able to share a single rar among multiple applications, I
can also deploy a rar file to JBoss without any kind of JBoss-
specific configuration. (I understand said resource adapter is
useless without further configuration --- it's the principle
that I don't have to build multiple rar archives, one for each
app server implementation, that matters to me.)
I think there's a communication problem here, but I'm not sure
exactly what or where it is. I hope I can get you to explain
what you mean in a way I can understand more easily.
Unfortunately I don't remember all the details of how I wrote the
jboss connector stuff, and they might have changed it somewhat in
the last couple years, but... what do you mean by deploying a rar
file without a plan? it seems to me that all that is possible is
to get the classes into a classloader that can be referenced
somehow. If you want a usable instance, you need a vendor plan
and a reference to the ra.xml in the rar and some classloader
with the classes in it.
"A rar file without a plan" == a rar file packaged as required by
the J2EE connector spec and without any app server specific
configuration. I can take one of these and deploy it on a JBoss 4
instance by plopping it into one of the deploy directories. Like
I said, it needs further configuration to define actual connection
factory instances, but these can be added and modified ad hoc
without redeploying the rar file.
In geronimo, you do roughly the same thing. There are a couple
ways to make the deployment happen, and which you choose depends
a lot on whether you are trying to put together a special purpose
server for your app or viewing geronimo as something you can't
change and just want to deploy your app on. If you are trying to
build a server or want to be able to distribute your deployed
application, you should use the packaging plugin to build a
configuration from the rar and your plan. (soon there will be a
offline deployer to let you do this without needing maven). You
can then assemble a server including the .car file generated. If
you want to regard geronimo as immutable, you can use the online
deployer, again with the rar file and your plan. I don't see the
difference between putting the rar file in the maven repo or the
geronimo repo (geronimo) or "deploying" it without a plan on jboss.
If you build the car file, you will be able to include it in any
geronimo server you want: it includes all its classes and is
"predeployed". (the tool support for adding it to an existing
server is not too good yet).
I'm not familiar with Geronimo's deployment strategy, but it
sounds like each deployment module gets its own classloader.
Rather than copy dependencies, couldn't they be referenced via
classloader delegation or a similar mechanism?
We would like to come up with a way to avoid copying all the
classes into a car file, but as I mentioned this will take some
classloader tricks. However, I'm not sure how this affects a
user. The copying is done by geronimo during deployment. As
long as you only need to start with one copy of the rar, why do
you care how many times geronimo copies it?
Will the deployer transparently update all the copies if I
redeploy the rar file?
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?
I've implemented this in geronimo head. I don't know if there are
any working nightly builds so you would probably have to build a copy
of geronimo for yourself.
thanks
david jencks
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?
thanks
david jencks
Thanks.
Michael
