[PATCH] Tyrex 1.0 w/ Tomcat

[David Haraburda <da...@haraburda.com>]

Hi all,

I have written a patch to make Tomcat work with Tyrex 1.0.  Here's a
summary of the new classes/code and how it all works.  I apologize for
the length of this post, the explanation is necessary I feel...

New class org.apache.naming.factory.TyrexFactory:

Tyrex now has the idea of a TransactionDomain, which manages resources
and transactions and is configured through an XML config file.  In order
to instantiate a TransactionDomain instance, the class must know two
things: the location of the domain config file, and the name of the
domain to lookup in the file.  The way I've set it up, these two string
configuration parameters must be present in the java:comp/env
namespace.  The TyrexFactory is an abstract superclass that provides a
method to lookup these configuration parameters and create the
TransactionDomain.  The two subclasses of this abstract class are...

New/modified class: org.apache.naming.factory.TyrexTransactionFactory:

This factory simply uses the TransactionDomain to create a
javax.transaction.UserTransaction.

New class org.apache.naming.factory.TyrexResourceFactory:
(this replaces TyrexDataSourceFactory)

Tyrex now also has the idea of resources, of which now there are only
two "flavors" right now:  JDBC DataSources and JCA connectors.  Since
the configuration of these resources must be done in Tyrex's domain XML
config file, this factory simply returns the resource with the specified
name -- it is up to the user know what to do with the Object returned.

Here's an example of how Tyrex would be setup for a simple JDBC
datasource.  Let's say you have a domain-config.xml file, with a domain
named "my-domain", which has a resource named "my-db", which is a JDBC
datasource (see Tyrex docs for more info).  In the server.xml file, we
would need to specify two environment parameters:

<Environment name="tyrexDomainConfig" type="java.lang.String"
             value="domain-config.xml"/>
<Environment name="tyrexDomainName" type="java.lang.String"
             value="my-domain"/>

and a resource:

<Resource name="my-datasource" auth="Container"
          type="tyrex.resource.Resource"/>
<ResourceParams name="my-datasource">
  <parameter>
    <name>name</name>
    <value>my-db</value>
  </parameter>
</ResourceParams>

This would all need to go under a <Context> element (I made the two
config strings global environment elements, and created ResourceLinks
instead).

Now, the domain-config.xml file is placed where the classloader can use
getResource() to find it (so, WEB-INF/classes is a good place), and
everything should be ready to go.  You can now do:

InitialContext initCtx = new InitialContext();
DataSource ds = (DataSource) 
                 initCtx.lookup("java:comp/env/my-datasource");
Connection conn = ds.getConnection();
... etc

in your user-level code.  Tyrex is still the default factory for
UserTransaction, so lookups on java:comp/env/UserTransaction work.

There are a few caveats:

(1) This is kind of a pain, but it's the way Tyrex 1.0 works.  This way
provides a lot of flexibility, without too much extra hassle.  If these
changes are made, however, a HOWTO is probably needed.  I can put one
together.
(2) For this to work, Tomcat now needs to be able to load the Tyrex
classes, and any classes it uses.  This means the tyrex jar and all
other jars included in the Tyrex distribution need to go in common/lib
(that includes JTA, OTS-JTS, and Xerces).  Furthermore, Tyrex needs some
JARs that it doesn't include in its distribution: the Castor XML jar,
and the Log4J jar.  This is six jars that need to be in common/lib for
Tyrex to work.  This kind of stinks as well.

Obviously there are probably a few kinks that need to be worked out, but
I've tested what is attached and it seems to work pretty well.

I've attached a cvs diff, as well as the two new files that are needed. 
These two new classes both go in the org.apache.naming.factory package. 
(remember TyrexDataSourceFactory needs to be removed)

Feedback/suggestions on my code is appreciated.  I'd like to see Tyrex
1.0 integrated with Tomcat fairly soon, so I'm prepared to make whatever
changes I need to in order to get the patch committed.

Thanks,

David

Re: [PATCH] Tyrex 1.0 w/ Tomcat

[David Haraburda <da...@haraburda.com>]

Remy Maucherat wrote:

>
> For the transaction stuff to work properly, don't you need a valve also
> to bind/unbind the Tyrex context ?

Hmm, not sure exactly what you mean here (sorry :-).  I think you are referring
to the fact
that the transaction is bound to the current thread, and what if the transaction
is needed in
a different thread?

>
> Or is this only needed if you would want your transaction to last more
> than one request ?

Is this even something that should happen?  Beginning a transaction, and then
not closing
it until some other request happens, whenever that may be?  I don't see how this
could
ever be a good idea.

Any transaction "in the system" can be retrieved from the transaction manager,
by calling
getTransaction( xid ) -- but I'm still not sure you could retrieve the
transaction across requests --
since the only information available when looking up the UserTransaction is
whatever is passed
to getObjectInstance, I don't think this is possible, and a valve couldn't help
in this case.

Then again, maybe I totally misunderstood. :-)

>
>
> I'm +1 for the patch. We'll need to add detailed instructions on how to
> use it. Also, the JARs won't ship with Tomcat (it's just too much).

As soon as this gets finalized, then I can work up a short HOWTO or something.

David


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [PATCH] Tyrex 1.0 w/ Tomcat

[Remy Maucherat <re...@apache.org>]

David Haraburda wrote:
> Hi all,
> 
> I have written a patch to make Tomcat work with Tyrex 1.0.  Here's a
> summary of the new classes/code and how it all works.  I apologize for
> the length of this post, the explanation is necessary I feel...
> 
> New class org.apache.naming.factory.TyrexFactory:
> 
> Tyrex now has the idea of a TransactionDomain, which manages resources
> and transactions and is configured through an XML config file.  In order
> to instantiate a TransactionDomain instance, the class must know two
> things: the location of the domain config file, and the name of the
> domain to lookup in the file.  The way I've set it up, these two string
> configuration parameters must be present in the java:comp/env
> namespace.  The TyrexFactory is an abstract superclass that provides a
> method to lookup these configuration parameters and create the
> TransactionDomain.  The two subclasses of this abstract class are...
> 
> New/modified class: org.apache.naming.factory.TyrexTransactionFactory:
> 
> This factory simply uses the TransactionDomain to create a
> javax.transaction.UserTransaction.
> 
> New class org.apache.naming.factory.TyrexResourceFactory:
> (this replaces TyrexDataSourceFactory)
> 
> Tyrex now also has the idea of resources, of which now there are only
> two "flavors" right now:  JDBC DataSources and JCA connectors.  Since
> the configuration of these resources must be done in Tyrex's domain XML
> config file, this factory simply returns the resource with the specified
> name -- it is up to the user know what to do with the Object returned.
> 
> Here's an example of how Tyrex would be setup for a simple JDBC
> datasource.  Let's say you have a domain-config.xml file, with a domain
> named "my-domain", which has a resource named "my-db", which is a JDBC
> datasource (see Tyrex docs for more info).  In the server.xml file, we
> would need to specify two environment parameters:
> 
> <Environment name="tyrexDomainConfig" type="java.lang.String"
>              value="domain-config.xml"/>
> <Environment name="tyrexDomainName" type="java.lang.String"
>              value="my-domain"/>
> 
> and a resource:
> 
> <Resource name="my-datasource" auth="Container"
>           type="tyrex.resource.Resource"/>
> <ResourceParams name="my-datasource">
>   <parameter>
>     <name>name</name>
>     <value>my-db</value>
>   </parameter>
> </ResourceParams>
> 
> This would all need to go under a <Context> element (I made the two
> config strings global environment elements, and created ResourceLinks
> instead).
> 
> Now, the domain-config.xml file is placed where the classloader can use
> getResource() to find it (so, WEB-INF/classes is a good place), and
> everything should be ready to go.  You can now do:
> 
> InitialContext initCtx = new InitialContext();
> DataSource ds = (DataSource) 
>                  initCtx.lookup("java:comp/env/my-datasource");
> Connection conn = ds.getConnection();
> ... etc
> 
> in your user-level code.  Tyrex is still the default factory for
> UserTransaction, so lookups on java:comp/env/UserTransaction work.
> 
> There are a few caveats:
> 
> (1) This is kind of a pain, but it's the way Tyrex 1.0 works.  This way
> provides a lot of flexibility, without too much extra hassle.  If these
> changes are made, however, a HOWTO is probably needed.  I can put one
> together.
> (2) For this to work, Tomcat now needs to be able to load the Tyrex
> classes, and any classes it uses.  This means the tyrex jar and all
> other jars included in the Tyrex distribution need to go in common/lib
> (that includes JTA, OTS-JTS, and Xerces).  Furthermore, Tyrex needs some
> JARs that it doesn't include in its distribution: the Castor XML jar,
> and the Log4J jar.  This is six jars that need to be in common/lib for
> Tyrex to work.  This kind of stinks as well.
> 
> Obviously there are probably a few kinks that need to be worked out, but
> I've tested what is attached and it seems to work pretty well.
> 
> I've attached a cvs diff, as well as the two new files that are needed. 
> These two new classes both go in the org.apache.naming.factory package. 
> (remember TyrexDataSourceFactory needs to be removed)
> 
> Feedback/suggestions on my code is appreciated.  I'd like to see Tyrex
> 1.0 integrated with Tomcat fairly soon, so I'm prepared to make whatever
> changes I need to in order to get the patch committed.

For the transaction stuff to work properly, don't you need a valve also 
to bind/unbind the Tyrex context ?
Or is this only needed if you would want your transaction to last more 
than one request ?

I'm +1 for the patch. We'll need to add detailed instructions on how to 
use it. Also, the JARs won't ship with Tomcat (it's just too much).

Remy


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>