Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Date: Sun, 22 May 2005 19:05:30 -0400
From: Dmitriy Kopylenko <dkopylen@rutgers.edu>
Subject: Re: Geronimo JCA
In-reply-to: <4EF2691C-364A-4B95-9FDC-3B9DFE6D4BE5@iq80.com>
To: Dain Sundstrom <dain@iq80.com>
Cc: Thierry TEMPLIER <templth@yahoo.fr>,
	Juergen Hoeller <juergen@interface21.com>,
	rob.harrop@interface21.com, dev@geronimo.apache.org
Message-id: <4291103A.9060904@rutgers.edu>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 8BIT
References: <428C8BCD.1030208@rutgers.edu> <428F1C42.3010907@interface21.com>
 <4EF2691C-364A-4B95-9FDC-3B9DFE6D4BE5@iq80.com>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)

Hi Dain,

thanks for the reply. We'll post do the dev-list. One more thing. Would 
it be feasible to package TM and Connector (with pool impl) as as a 
separate, reusable modules, let's say geronimo-tx.jar and 
jeronimo-jca.jar or something to that effect?

Dmitriy.


Dain Sundstrom wrote:

> Hi all,
>
> This sounds like a good idea to me.  I personally have been wanting  
> spend some time to assure our TX manager and Connector implementation  
> were useable as standalone components, so I'm glad to hear that they  
> have been working.  As for the legal issues, Geronimo is apache  
> licensed, so you can do any of the stuff you mentioned below,  
> although I'd like to see improvements come back to the mail line.
>
> I suggest you post an email to the dev@geronimo.apache.org list  
> describing what you would like to do.
>
> -dain
>
> On May 21, 2005, at 4:32 AM, Rob Harrop wrote:
>
>> I can't see any problem with using any of the Geronimo components  
>> separately. I've CC'd Dain in on this mail to see what he thinks.
>>
>> Rob
>>
>> Dmitriy Kopylenko wrote:
>>
>>> Hello Rob, how are you? I have a question if I may :-)
>>> Here is the deal: for the past month or so, we (me, Thierry,  
>>> Juergen) have been chatting about introducing some kind of a  
>>> standalone JCA engine (implementing JCA system contracts e.g.  
>>> transactions, connection pooling, security, etc.) so one would be  
>>> able to deploy any JCA resource adapter in a "managed" mode  without 
>>> requiring a full-blown J2EE server. Without re-inventing  the wheel, 
>>> we've looked around but there was nothing really there  (as far as 
>>> standalone JCA implementation goes). So, we've looked  at the latest 
>>> Geronimo (M3 I think) code and noticed that they  have a JCA module 
>>> implemented as a part of their J2EE stack. Then  Thierry 
>>> experimented with it and made it work without the rest of  the 
>>> Geronimo server! Take a look at the attached code and readme  file.
>>> Now, here is the question - how would it be possible to reuse/ 
>>> modify/package Geronimo JCA module on its own, without the rest of  
>>> the Geronimo server? What the leagal implications might be? Do you  
>>> know any Geronimo folks, so you could forward it to them and  
>>> collaborate with them? Another thing we were thinking about is to  
>>> create a standalone project (code name Cancun) which would serve  as 
>>> a thing wrapper around such (pluggable?) JCA implementations.
>>> Did I miss anything?
>>> Thanks,
>>> Dmitriy.
>>> -------- Original Message --------
>>> Subject:     Re: JCA CCI documentation
>>> Date:     Wed, 11 May 2005 11:38:30 +0200 (CEST)
>>> From:     Thierry Templier <templth@yahoo.fr>
>>> To:     Dmitriy Kopylenko <dkopylen@rutgers.edu>
>>> CC:     Juergen Hoeller <juergen@interface21.com>, Thierry  TEMPLIER 
>>> <templth@yahoo.fr>
>>> Hi Dmitriy,
>>> Finally, I manage to make the application run ;-) I
>>> clean the code and make everything to done with ant
>>> tasks...
>>> In attachment, I have put a detailed readme file to
>>> explain how to use the application and which changes I
>>> made on both Geronimo transaction/connector modules
>>> and XAPool. I don't include the libraries in the zip
>>> file but you can see my classpath in the .classpath
>>> file...
>>> Cheers,
>>> Thierry
>>>
>>>> Thanks Thierry. Great job!
>>>>
>>> Take a look at my blog:
>>> http://templth.blogspot.com/
>>>
>>>
>>>
>>> _____________________________________________________________________ 
>>> ______________________________
>>> Le nouveau Yahoo! Messenger est arriv� ! D�couvrez toutes les  
>>> nouveaut�s pour dialoguer instantan�ment avec vos amis. A  
>>> t�l�charger gratuitement sur http://fr.messenger.yahoo.com  
>>> --------------------------------------------------------------------- 
>>> ---
>>> =========================================
>>> == Spring Geronimo  application        ==
>>> =========================================
>>> @author Thierry Templier
>>> 1. MOTIVATION
>>> The aim of this application is to make an application
>>> to show the feasibility of use global transactions in
>>> a non managed mode with different resources and and
>>> more particularly JCA resource adapters.
>>> The JCA resource will be configured with the JCA Spring
>>> support.
>>> The transaction manager will be the internal transaction
>>> manager of Geronimo and the JCA connection manager
>>> implementation will be provided too by Geronimo.
>>> These components will be configured in Spring using the
>>> facilities of this IoC framework (FactoryBean...).
>>> The transaction demarcation will be done with the Spring
>>> JTA transaction support.
>>> 2. CODE MODIFICATIONS
>>> This application contains four parts:
>>> - Spring integration of the Geronimo transaction   and JCA  
>>> connection managers.
>>> - The Geronimo transaction and JCA connection managers.
>>> - XAPool to to make take part simple datasources in global
>>>   transactions.
>>> - The application.
>>> To make the application work, we need to make some modifications
>>> in the second and third parts...
>>> -- Geronimo --
>>> When we try to use the Geronimo transaction manager, we have had
>>> a NullPointerException in the newTransaction method of the
>>> ConnectionTrackingCoordinator class. As a matter of fact, the
>>> oldInstanceContext instance is null whereas we do the following
>>> thing in the TransactionContextManagerFactoryBean class:
>>> this.transactionContextManager.newUnspecifiedTransactionContext();
>>> So we modify the newTransaction method as following:
>>> public void newTransaction() throws ResourceException {
>>>     InstanceContext oldInstanceContext = (InstanceContext)  
>>> currentInstanceContexts.get();
>>>     if( oldInstanceContext!=null ) {
>>>         notifyConnections(oldInstanceContext);
>>>     }
>>> }
>>> Important note: When you configure the transaction strategy with the
>>> XATransactionFactoryBean, you must imperatively set the  
>>> useTransactionCaching
>>> property to true. Otherwise, the transaction manager will try to  
>>> enlist
>>> two times the same XAResource...
>>> -- XAPool --
>>> As Geronimo transaction manager works only with NamedXAResource
>>> which extends the XAResource, we need to wrap every XAResource
>>> that XAPool tries to enlist in the current transaction...
>>> So we need to modify the prepareStatement of the  
>>> StandardXAConnectionHandle
>>> class:
>>> try {
>>>     tx.enlistResource(new WrapperNamedXAResource 
>>> (xacon.getXAResource(),"XAPool"));
>>>     // enlist the xaResource in the transaction
>>> } catch (RollbackException n) {
>>>     log.debug(
>>>         "StandardXAConnectionHandle:prepareStatemnet  enlistResource 
>>> exception : "
>>>             + n.toString());
>>> }
>>> and the preInvoke method of the StandardXACallableStatement class:
>>> try {
>>>     con.tx.enlistResource(new WrapperNamedXAResource 
>>> (con.xacon.getXAResource(),"XAPool"));
>>>     // enlist the xaResource in the transaction
>>>     if (cs != null) {
>>>         cs.close();
>>>         cs = null;
>>>     }
>>> } catch (RollbackException n) {
>>>     throw new SQLException(
>>>         "StandardXAStatement:preInvoke enlistResource exception: "
>>>             + n.toString());
>>> }
>>> Without these modifications, you will have some ClassCastException,
>>> when your application tries to enlist jdbc resources...
>>> 3. BUILD AND DEPLOYMENT
>>> To build the application, just make:
>>> "build build".
>>> This task compiles it, copies necessary files and packages
>>> all in a jar.
>>> As the application runs in a non-managed mode, there is
>>> no need of an application server so no deployment is
>>> mandatory!
>>> 4. START AND CONFIGURE THE JORAM SERVER
>>> Joram is the jms server of ObjectWeb (see the following url:
>>> http://joram.objectweb.org/).
>>> To start the Joram server, just make:
>>> "build startJoram".
>>> To configure the Joram server (creation of all needed resources),
>>> just make:
>>> "build configureJoram".
>>> 5. START THE HYPERSONIC DATABASES
>>> As we want to test global transactions on several resources, we
>>> will use to database servers. To start them, just make:
>>> "build startHsqldb1" for the first
>>> "build startHsqldb2" for the second
>>> To execute sql requests on these, you can use the Hypersonic
>>> console. To start it, just make:
>>> "build adminHsqldb".
>>> 6. RUN THE APPLICATION
>>> The application has three main features:
>>> - initialize the different resource (databases).
>>> - run the application in a global transaction. it can be
>>>   finished by a commit (everything is ok) or a rollback
>>>   (a RuntimeException occurs).
>>> - check if very happened as envisaged (in the cas of a
>>>   commit or a rollback).
>>> If you want to run the application and validate the
>>> global transaction, just make:
>>> "build launchCommit"
>>> If you want to run the application and force a RuntimeException
>>> to be thrown at the end (to make a rollback), just make:
>>> "build launchRollback"
>>> Note: These two ant tasks depend on the init task that
>>> initialize the resources...
>>> After running the application, we can check if every resource
>>> are in the expected state (row inserted in database and jms
>>> messages sent).
>>> When you launch the application, it try to make the following
>>> tasks:
>>> - insert a row in the database1
>>> - send a message to the jms queue Queue
>>> - insert a row in the database2
>>> - send a message to the jms queue Queue
>>> So, if the commit occurs, you will have the following with
>>> "build check":
>>> Buildfile: build.xml
>>> build:
>>> check:
>>>      [java] Table 1: 1
>>>      [java] Table 2: 1
>>>      [java] Requests to receive messages...
>>>      [java] Waiting for message...
>>>      [java] First message : msg1 = Hello World!
>>>      [java] Waiting for message...
>>>      [java] Second message : msg2 = Hello World!
>>> BUILD SUCCESSFUL
>>> and, if the rollback occurs:
>>> Buildfile: build.xml
>>> build:
>>> check:
>>>      [java] Table 1: 0
>>>      [java] Table 2: 0
>>>      [java] Requests to receive messages...
>>>      [java] Waiting for message...
>>> and the process will block on waiting of jms messages...
>>> Note: the numbers after "Table 1:" and "Table 2:" are respectively
>>> the number of rows for the database tables, country1 and country2.
>>>
>>
>> -- 
>> Rob Harrop
>> Interface21 - Spring Services from the Source
>> http://www.springframework.com
>>
>> Lead Developer - AOP & JMX, Spring Framework:
>> http://www.springframework.org
>>
>> Author, "Pro Spring"
>> (February 2005, with Jan Machacek).
>> http://www.amazon.com/exec/obidos/ASIN/1590594614/
>>
>> Author, "Pro Jakarta Velocity"
>> (August 2004).
>> http://www.amazon.com/exec/obidos/ASIN/159059410X/
>>
>> Author, "Pro Jakarta Struts"
>> (March 2004, with John Carnell).
>> http://www.amazon.com/exec/obidos/ASIN/159059228X/
>>
>