geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: deploying a resource adapter (fwd)
Date Mon, 09 Jan 2006 20:31:01 GMT

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.

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="${}/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

View raw message