Re: deploying a resource adapter (fwd)

[David Jencks]

<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. 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? thanks david jencks (looks like I confused the quoting in my mail program, sorry) <snip>