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
smime.p7s
Description: S/MIME cryptographic signature
