Re: Geronimo JCA

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Geronimo JCA

Dmitriy Kopylenko
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 [hidden email] 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 <[hidden email]>
>>> To:     Dmitriy Kopylenko <[hidden email]>
>>> CC:     Juergen Hoeller <[hidden email]>, Thierry  TEMPLIER
>>> <[hidden email]>
>>> 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/
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Geronimo JCA

Jeremy Boynes
Dmitriy Kopylenko wrote:
 > 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?
 >

Cool stuff :-) Couple of thoughts...

The transaction and connector modules already create separate artifacts
(geronimo-transaction and geronimo-connector) that you can grab from a
Maven repo. All you would need to do is create a configuration plan for
your setup and build that (using the deployer) - you can create a
standalone executable, a bundle that can run in a Geronimo server, or a
hybrid where you control the Geronimo kernel and load in the
configuration bundle.

On the legal front, although the Geronimo codebase is Apache licensed,
the JCA specification itself is released under a license from Sun. You
should review the specification license if you are looking to call this
a JCA implementation.

--
Jeremy
Reply | Threaded
Open this post in threaded view
|

Re: Geronimo JCA

Dain Sundstrom
In reply to this post by Dmitriy Kopylenko
On May 22, 2005, at 4:05 PM, Dmitriy Kopylenko wrote:

> 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?

Absolutely.  David Jencks has written an fabulous piece of software  
here and I personally would love to see it become the implementation  
everyone uses.  I think that having a single jar along with some  
standalone how-to docs would help a ton.

BTW, I added a demonstration of using Spring in the core of geronimo  
to wire up beans and for configuration.  The spring.xml file I use  
for geronimo may help you get the configurations right:

http://svn.apache.org/viewcvs.cgi/geronimo/trunk/sandbox/spring- 
assembly/src/conf/server.xml?rev=170517&view=markup

-dain
Reply | Threaded
Open this post in threaded view
|

Re: Geronimo JCA

Dmitriy Kopylenko
Dain Sundstrom wrote:

> On May 22, 2005, at 4:05 PM, Dmitriy Kopylenko wrote:
>
>> 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?
>
>
> Absolutely.  David Jencks has written an fabulous piece of software  
> here and I personally would love to see it become the implementation  
> everyone uses.  I think that having a single jar along with some  
> standalone how-to docs would help a ton.
>
> BTW, I added a demonstration of using Spring in the core of geronimo  
> to wire up beans and for configuration.  The spring.xml file I use  
> for geronimo may help you get the configurations right:
>
> http://svn.apache.org/viewcvs.cgi/geronimo/trunk/sandbox/spring- 
> assembly/src/conf/server.xml?rev=170517&view=markup
>
> -dain

This is so cool! By looking at the app ctx for Geronimo server, gives
you an overall, clear picture of the server architecture!

Dmitriy.
Reply | Threaded
Open this post in threaded view
|

Re: Geronimo JCA

David Jencks
Basically I don't think you should have any problems running the jca
container and the tm in something other than the geronimo kernel.  The
only real geronimo dependency I can think of at the moment is that
connection factory serialization/deserialization currently relies on
looking up the actual connection manager instance in the geronimo
kernel.    If you don't need to support cf serialization (I think it's
pretty silly) you may be able to just ignore this :-).

Please let me know if you run into problems or need tweaks to the code.
  I would prefer if possible to support use in other containers without
making people copy and modify the code.

thanks
david jencks

On May 22, 2005, at 5:56 PM, Dmitriy Kopylenko wrote:

> Dain Sundstrom wrote:
>
>> On May 22, 2005, at 4:05 PM, Dmitriy Kopylenko wrote:
>>
>>> 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?
>>
>>
>> Absolutely.  David Jencks has written an fabulous piece of software  
>> here and I personally would love to see it become the implementation  
>> everyone uses.  I think that having a single jar along with some  
>> standalone how-to docs would help a ton.
>>
>> BTW, I added a demonstration of using Spring in the core of geronimo  
>> to wire up beans and for configuration.  The spring.xml file I use  
>> for geronimo may help you get the configurations right:
>>
>> http://svn.apache.org/viewcvs.cgi/geronimo/trunk/sandbox/spring- 
>> assembly/src/conf/server.xml?rev=170517&view=markup
>>
>> -dain
>
> This is so cool! By looking at the app ctx for Geronimo server, gives
> you an overall, clear picture of the server architecture!
>
> Dmitriy.
>

Reply | Threaded
Open this post in threaded view
|

RE: Geronimo JCA

Juergen Hoeller
In reply to this post by Dain Sundstrom
Hi Dain, everybody,

Great news :-)

Thierry, Dmitriy and me have essentially been toying with the idea of
creating a separate standalone project (SourceForge or Apache) for a
tx-aware JCA Connector, able to interact with JOTM (or the like) for 2PC
outside a J2EE server. This is not within Spring's own core competencies,
thus the idea of a separate project.

That's when the idea of checking out Geronimo came in: After all, it needs
to have exactly such a component as well. Reusing Geronimo's transaction
coordinator and Connector framework is - of course - a great solution. A
separate distribution of that part of Geronimo, clearly supporting
standalone usage, would be great!

How do you plan to handle that in general: Do you rather intend to have a
single Geronimo distribution where everyone can pick components, or release
the stuff with different packaging for different target scenarios? I'm
mainly wondering about Geronimo's own code here, not about integrated
components like JOTM.

Cheers,

Juergen


-----Original Message-----
From: Dain Sundstrom [mailto:[hidden email]]
Sent: Monday, May 23, 2005 2:13 AM
To: Dmitriy Kopylenko
Cc: Thierry TEMPLIER; Juergen Hoeller; [hidden email];
[hidden email]
Subject: Re: Geronimo JCA


On May 22, 2005, at 4:05 PM, Dmitriy Kopylenko wrote:

> 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?

Absolutely.  David Jencks has written an fabulous piece of software
here and I personally would love to see it become the implementation
everyone uses.  I think that having a single jar along with some
standalone how-to docs would help a ton.

BTW, I added a demonstration of using Spring in the core of geronimo
to wire up beans and for configuration.  The spring.xml file I use
for geronimo may help you get the configurations right:

http://svn.apache.org/viewcvs.cgi/geronimo/trunk/sandbox/spring-
assembly/src/conf/server.xml?rev=170517&view=markup

-dain

Reply | Threaded
Open this post in threaded view
|

RE: Geronimo JCA

Jeremy Boynes-2
In reply to this post by Dmitriy Kopylenko

>
>How do you plan to handle that in general: Do you rather intend to have a
>single Geronimo distribution where everyone can pick components, or release
>the stuff with different packaging for different target scenarios? I'm
>mainly wondering about Geronimo's own code here, not about integrated
>components like JOTM.
>

The intent behind Geronimo's design has always been to have a set of system service implementations that can be assembled as needed by different servers. Each of the modules should be reusable on its (provided its dependencies can be resolved).

We will formally be releasing an assembly of these as a certified J2EE server but others can easily but together either here or elsewhere.

A concrete example of this is Gluecode www.gluecode.com (which targeted the web container) - it would be great to have another targeting the connector framework.

--
Jeremy

Reply | Threaded
Open this post in threaded view
|

Re: Geronimo JCA

jstrachan-3
In reply to this post by Dain Sundstrom
Dain Sundstrom wrote:

> On May 22, 2005, at 4:05 PM, Dmitriy Kopylenko wrote:
>
>> 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?
>
>
> Absolutely.  David Jencks has written an fabulous piece of software  
> here and I personally would love to see it become the implementation  
> everyone uses.  I think that having a single jar along with some  
> standalone how-to docs would help a ton.

+1000!

I think we all would love an easy to use, single JAR JCA container we
can reuse inside Tomcat, Spring or Geronimo.

James