[OFBiz] Dev - More on Infrastructure (JOTM/Minerva vs Geronimo, etc)

[David E. Jones]

I spent a few hours today researching Geronimo, mainly because it  
seems to be the best candidate as an alternative to the current tools  
we are using, which have some licensing issues (JOTM and Minerva).  
With Minerva there is also a disadvantage that we are stuck  
maintaining it. After a few bug fixes early on everything seems to be  
okay with it, but the license clearance for use in the Apache-ized  
OFBiz will be trickier.

Anyway, I could sum up research into Geronimo as a fresh bad taste in  
my mouth. It's been over 2 years since we moved to our own container/ 
component infrastructure so that J2EE implementation modules would  
run inside OFBiz instead of OFBiz running inside an app server. I was  
really hoping that in that time the standards would improve. They  
haven't. I was also hoping that at least in Geronimo we would find  
that the always necessary proprietary extensions (because the core  
standards are woefully inadequate) to be more convenient.

All we really want is to have an application that includes a set of  
lower level tools, web applications, etc in a single package that is  
easy to deploy, even for someone that is not technical nor familiar  
with how the lower level tools are organized or built. That was the  
main goal with the OFBiz component stuff, and it has been great to  
work with for the last couple of years.

Back to Geronimo: using an EAR file (which can be deployed "exploded"  
or in a directory instead of an EAR zip file) gets us pretty close,  
and with the Geronimo proprietary extensions we can refer to general  
jar files (don't seem to be able to do exploded directories of  
classpath resources... would have to try that), but the problem is  
they can't be inside the EAR... It's really frustrating that they  
have gone with one of the things that I so didn't like about Tomcat  
that it was one of the big reasons we used Jetty for a long time:  
that you must copy the jar files into their directories instead of  
referring to them where they live "naturally".

So, we could ship with Geronimo instead of the container stuff, but  
we have various classpath issues to resolve. We could take all of the  
third party libraries we use and put them under the geronimo/ 
repository directory using their directory organization conventions,  
and then in the OFBiz build have it drop all jars it makes under the  
geronimo/repository directory, and then refer to those in probably 2  
EARs (one for framework, one for application that would depend on the  
framework EAR).

There is some more unpleasantness... If we can't find a way to refer  
to certain directories in their current locations but instead are  
forced to put them in a jar file, we are going to lose some  
convenient change and retry stuff we can do now, mainly with the  
scripts on the classpath (all files in each component/script  
directory, mostly simple-method XML files). This whole classpath  
thing in an app server is messy enough that it would be nice to get  
everything _off_ the classpath that we can. In other words, we'd move  
to directories relative to a component home directory instead of on  
the classpath. This would require a fair number of changes, like the  
location of every single simple-method location in their service  
definitions.

It would be really nice to have an easy way to deploy in other app  
servers, but the standards bodies are not being overly helpful...  
Short of that, it would at least be nice to deploy easily deploy in a  
certain app server that we can deliver with OFBiz for easier out of  
the box usage, since probably the majority (head count wise) of OFBiz  
users just use it out of the box rather than deploying it in a  
separate app server, and most of us would probably prefer to not have  
to deal with the app server configuration and deployment...

Anyway, that's my rant for today. I've been trying to think of  
creative ways around this... For example:

1. Use the lower-level Geronimo jars embedded in OFBiz, kind of like  
the JOTM, etc jars are. This has the unfortunate disadvantage that  
these don't appear to be designed for this, so it could be rather  
tricky...

2. Create Geronimo-specific GBeans to do classloader changes in Java  
code rather than configuration. This would be pretty non-standard and  
experimental, and even if it did work initially it would be possible  
for changes to be made in Geronimo that would break our stuff, or  
perhaps require changes to our code (if we're lucky). I'm not sure if  
this would even work... Right now we play with the classloader a LOT  
on startup and my hope is that we could move this code over...

One way or another it would be nice to use the current config files  
as-is to avoid redundancy, though that may not be possible. We may  
have to have 2 lists of classpath resources and webapps and what not.  
Actually that means we have to have one set for each app server, and  
for each variation over time/versions of that app server. We tried  
doing that once and it is a REAL MESS! I'd rather not go there again.

Andy has been working on this and communicating with some of the  
Geronimo people. Hopefully we'll find a good resolution to this. If  
anyone has any ideas or wants to help out with this, that would be  
great.

I know Andy has some stuff to take care of some things, like I guess  
some GBeans and such, and perhaps we can create a branch in SVN or a  
set of resources that aren't being used by default (this would be my  
preference to make it easier for people to play with it).

-David


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2466 bytes
Desc: not available
Url : http://lists.ofbiz.org/pipermail/dev/attachments/20060306/60eaecc1/smime.bin