geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David E. Jones" <jone...@ofbiz.org>
Subject Re: Transaction Manager and Connection Manager usage outside Geronimo
Date Sun, 05 Feb 2006 10:48:14 GMT

Jacopo forwarded this message to me and I thought it would probably  
be easiest if I just joined in here... My name is David Jones and I'm  
one of the OFBiz developers and have worked quite a bit on this part  
of the project.


>> Hi all,
>>
>> my name is Jacopo Cappellato, I'm one of the developers of the  
>> OFBiz project (www.ofbiz.org), that will soon start the incubation  
>> process.
>>
>> We are evaluating the possibility to integrate into OFBiz two of  
>> the Geronimo's components: the Transaction Manager and the TX- 
>> aware Connection Pooling (right now we are using JOTM and Minerva).
>>
>> Can these components be used separately from the whole Geronimo  
>> thing?
>>
>> Any hints on dependencies (etc.) we should take care will be  
>> highly appreciated.
>
> You are not the first to want to do this :-).  The purpose of the  
> Jencks project is to run these components in Spring.  It should  
> also be pretty easy to set up the components you need in code.
>
> Does OFBiz use a component framework?  Does it run in a web  
> server?  If run in a j2ee app server, what happens to its own tm  
> and connection pooling?

We have various ways of doing this, and it is configurable through  
the database setup XML file. The Entity Engine is the part of OFBiz  
that handles all of this, so if it means anything to anyone this is  
setup in the entityengine.xml file.

Our preference is to just have the JTA interface (UserTransaction and  
TransactionManager) implementations in JNDI and use them from there.  
We prefer the same for the connection pool (data source), ie to have  
the XADataSource object available in JNDI. As an alternative to these  
we support (and have done this various times in the past) just  
writing code that uses the objects directly to get what we need.

For the TX manager side we have done custom code for both JOTM and  
Tyrex (a _long_ time ago). Right now we are putting the JOTM JTA  
interface impls in JNDI on startup and then using them from there.  
The issue with JOTM comes up because we are using Carol for the  
underlying stuff and that is LGPL licensed...

When running in an app server we just refer to the JNDI locations  
that the app server uses.

Our default running mode, however, is to run with embedded J2EE  
components, including the Servlet container (embedded Tomcat is the  
default, we also support Jetty embedded), transaction manager, and so  
on. The nice thing about doing it this way is that we have a  
container feature to load things on startup, and a component feature  
that allows us to drop in "component" directories that have an OFBiz- 
specific description to load various general (classpath, webapps) and  
OFBiz-specific (entity, service, etc) resources to make it easy to  
drop in applications and such and have then deployed.

For deploying OFBiz in an external (as opposed to embedded) app  
server we have a tool to turn templates into config files with the  
classpath and webapp settings from all of the OFBiz component  
descriptors. This is an extra step for deployment, but helps a lot  
when you have hundreds of classpath entries, and over a dozen webapps.

> The last time I looked the Jencks project was not setting up the  
> transaction log so recovery of in-doubt transactions would not be  
> possible.  I don't know why it wasn't set up, it is pretty easy to do.
>
> It's desirable for all calls into a web app or ejb to go through an  
> interceptor connected to the connection management framework.  This  
> is needed to support some required but bad-practice j2ee  
> requirements, but also has the very good effect of preventing  
> connection leaks if you use appropriate j2ca jdbc wrappers such as  
> the tranql connectors.  If you run in Geronimo these interceptors  
> are installed for you, but it is also possible to install them in  
> standalone jetty and (I think) tomcat and IIUC the Jencks project  
> has installed them in Spring.

Is there any sort of demo code you could recommend to see how to  
either initialize the JTA and JDBC DataSource objects to put into  
JNDI, or alternatively how to initialize and use the objects from TX  
operations and JDBC Connection factory types of things? I guess the  
Jencks project you mentioned is a good place to look, but it sounds  
like with a couple of exceptions where it could be improved...

> I am extremely geronimo-centric :-) but I will push one of our  
> capabilities anyway, feel free to ignore it.  If you are interested  
> in running OFBiz in geronimo, you can "predeploy" it into a  
> geronimo component, and then build a server that includes a web  
> server, the tm, connection  management, and OFBiz and pretty much  
> nothing else, and produce an "unzip and run" server.  This has  
> always been one of our goals and we are ironing out some details of  
> the "pretty much nothing else" part right now.

Deployment is an interesting issue with OFBiz... We have a few  
requirements that are difficult with some app servers. Well, we  
prefer to deploy using embedded components because of these, but some  
things are rather painful to use externally (like the good old Tomcat  
requirement when not running in an embedded mode to copy all  
classpath resources to its directories). Here are a couple of the  
major ones:

1. For out of the box running: Pull from SVN, build using "ant" (and  
we even include the jars to avoid requiring an installed Ant), and  
then run using the executable jar; alternatively download an archive  
with OFBiz already built, and just run the executable jar (directly,  
through a script, through ant, whatever)

2. For development purposes reload resources such as XML config  
files, scripts, templates, etc; these should be referred to "in  
place" so that they can be modified and picked up automatically; this  
includes classpath resources; for performance we manage the reloading  
through our central caching functionality (in development mode we  
just have timeouts for these resource caches, and in production the  
caches can be manually cleared or even individual cache lines can be  
cleared through the web-based UI)

For these we need/prefer to do things like mounting "exploded"  
webapps (as opposed to in a war file), and referring to classpath  
resources (jars, directories, etc) in place. This simplifies  
deployment for development and demonstration purposes and such. For  
deployment these are somewhat important, but for large deployments it  
doesn't matter so much because things don't change as much and the  
deployment process can (and sometimes needs to) be more involved, ie  
with more steps and building interim files like EAR files and what not.

So, yeah, an "unzip and run" deployment of some sort is just what we  
need. If we can do that by running inside Geronimo instead of putting  
Geronimo in OFBiz, that may be just fine. We would need some sort of  
JMX facility to load things on startup, and preferably to  
programatically change the classpath on startup, programatically  
mount webapps, and so on (to avoid having to generate deployment  
descriptions and such based on the OFBiz files).

For the classpath and webapp stuff part of the issue is that people  
like different app servers and we need to keep flexibility to at  
least somewhat easily deploy in various app servers. We use templates  
for startup scripts, deployment descriptors, and other configuration  
files because maintaining these without using a template is pretty  
tough (we did that for a while...).

> Thanks, feel free to ask more questions, what you want to do is  
> definitely possible and should not be difficult: the exact steps  
> may depend on how you are assembling everything.

I'm very interested in feedback on these questions... I hope the  
background on OFBiz is not too lengthy, but still sufficient to get  
an idea of what we're doing, and now moving toward the ASF where we  
are going.

It's really great, actually really really great, that Geronimo has  
progressed to where it is with the 1.0 release and what not. Default  
open-source infrastructure has always been a bit of an issue with  
OFBiz and we have had to change things various times over the years  
and things we depend on move around or as our needs change, and with  
our move toward using libraries that are ASF kosher (as we move  
toward/through incubation), it's really great to have something like  
Geronimo to work with.

-David



Mime
View raw message