Return-Path: 
 <user-return-1572-apmail-geronimo-user-archive=geronimo.apache.org@geronimo.apache.org>
Delivered-To: apmail-geronimo-user-archive@www.apache.org
Received: (qmail 2696 invoked from network); 9 Jan 2006 20:31:39 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 9 Jan 2006 20:31:39 -0000
Received: (qmail 58561 invoked by uid 500); 9 Jan 2006 20:31:32 -0000
Delivered-To: apmail-geronimo-user-archive@geronimo.apache.org
Received: (qmail 58499 invoked by uid 500); 9 Jan 2006 20:31:32 -0000
Mailing-List: contact user-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:user-help@geronimo.apache.org>
list-unsubscribe: <mailto:user-unsubscribe@geronimo.apache.org>
List-Post: <mailto:user@geronimo.apache.org>
Reply-To: user@geronimo.apache.org
List-Id: <user.geronimo.apache.org>
Delivered-To: mailing list user@geronimo.apache.org
Received: (qmail 58456 invoked by uid 99); 9 Jan 2006 20:31:32 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Jan 2006 12:31:32 -0800
X-ASF-Spam-Status: No, hits=0.5 required=10.0
	tests=DNS_FROM_RFC_ABUSE
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Received: from [216.136.174.140] (HELO smtp102.mail.sc5.yahoo.com)
 (216.136.174.140)
    by apache.org (qpsmtpd/0.29) with SMTP; Mon, 09 Jan 2006 12:31:31 -0800
Received: (qmail 18826 invoked from network); 9 Jan 2006 20:31:09 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Received:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer;
  b=NGev1QwIycH2T8uNczgautSbcpa0Ejy6CXWLxp7j0EmE8sFzegY/MlWqaaiRs1PNVjeNeeFSeSt1bKdrbk2spKmQkvQArMP/TrUDh/u7fYoNGxx78RAbbV3F0jXzq6xea4mvHHUxDXLyRH3Gshmq/9+HIhpebjfCFMSH0f4iHp4=
  ;
Received: from unknown (HELO ?192.168.1.5?) (david?jencks@66.93.38.137 with
 plain)
  by smtp102.mail.sc5.yahoo.com with SMTP; 9 Jan 2006 20:31:07 -0000
Mime-Version: 1.0 (Apple Message framework v746.2)
In-Reply-To: <D70CFE71-C6EA-484F-9E55-4F239B7BDC07@yahoo.com>
References: <20060108071904.T3755@yvyyl>
 <74e15baa0601080749n176db416ic7a75c70f78014eb@mail.gmail.com>
 <20060108222542.S94313@yvyyl>
 <B769A357-0017-4618-B1E2-CD51D3FC4742@yahoo.com>
 <20060108225953.X94313@yvyyl>
 <13BEDF10-8A61-4CC0-BC1D-6BEE8130D931@yahoo.com>
 <20060109000620.N94313@yvyyl>
 <9EACDEA7-16D7-4B33-AD28-CD707E760AC2@yahoo.com> <20060109010214.F5773@yvyyl>
 <EE84749A-0959-4197-B274-E98503BD09CC@yahoo.com>
 <20060109065853.A44460@yvyyl>
 <D70CFE71-C6EA-484F-9E55-4F239B7BDC07@yahoo.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <50FCE6A6-1009-40BE-A318-5F5C37F0991B@yahoo.com>
Content-Transfer-Encoding: 7bit
From: David Jencks <david_jencks@yahoo.com>
Subject: Re: deploying a resource adapter (fwd)
Date: Mon, 9 Jan 2006 12:31:01 -0800
To: user@geronimo.apache.org
X-Mailer: Apple Mail (2.746.2)
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N


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
>