Re: Dev - OFBiz Boot Refactor

Posted by Porter Woodward on May 03, 2006; 7:19pm
URL: http://ofbiz.116.s1.nabble.com/Dev-OFBiz-Boot-Refactor-tp167866p167880.html

I'd like to comment on option #3...

Are you considering an inversion of control container like Spring for
this task?   Then the spring config could then be tweaked to either wire
the container supplied resources such as (JMX, JDBC, JMS, JTA) - or
instance and load supplied services/servers for such functionality.

Essentially it would involve boiling a lot of stuff down to common
interfaces - but as most of the major APIs in the Java world are
centered around interfaces... and a lot of the OfBiz framework is
interface oriented...  this would seem to be an ideal mechanism to boot
strap the OfBiz framework into an application server.

The question(s) that then arise are:

Is the goal to be able to have multiple deployments of OfBiz per app
server?  If so - is it necessary for each deployment to have a "full
copy" of all OfBiz code?  Or, is it better to factor out the "shared"
portions of OfBiz so that they can live as "singletons" or shared
resources to multiple deployed OfBiz applications?

One possible outcome is a process that pulls the framework out - so that
it can be injected into a container.  Thus something like the entity
engine (or engines) would be loaded and configured by the container -
becoming a "named" resource.  And then individual OfBiz applications
could be started inside the container and get a handle to the
appropriate framework components by requesting them from the container.

So then you almost have a two part deployment.

1>  Deploy the framework.
    a>  Activates an application server/container with the OfBiz framework
    b>  Ideally only one version of the framework active at a time?
    c>  Core components configured using JNDI as provided by container.

2>  Deploy OfBiz aware application.
    a>  Configure using JNDI.
    b>  Requests known service providers from container.
    c>  Requires an "OfBiz Activated Application Server"

This probably just creates more questions, and only really underscores
my lack of understanding on how we all might like to use OfBiz with
respects to a J2EE container, etc.

- Porter Woodward


A. Zeneski wrote:

> 3) Refactor the OFBiz startup code. Develop a very slim java runtime  
> wrapper. A highly configurable tool which will setup an environment  
> and then deploy a java application. This would replace the way an  
> application server boots. First it would configure the environment  
> based on a configuration, set up an initial class loader then boot  
> the application as if it was called from the command line. This would  
> only work with application servers which are 100% pure java already  
> since it be almost impossible to do a generic JNI based tool.
>
> #3 is very much like creating a dynamic script to start any java  
> application; except it is written also in java. I will even consider  
> the idea of developing this outside of OFBiz under its own project to  
> make sure it remains generic and supported by a broader community.
>
> An initial prototype of this would only take a couple of days to  
> develop. As I expect to base it on what is in base/start today. It  
> will be slimmer and more configurable. I have thought about making it  
> JMX based, but maybe that would add too much overhead. It would  
> however allow it to be managed by standard JMX tools.
>
> If it was JMX based it would run off of MX4j (an Apache licensed  
> project). It would first create a very private class loader to start  
> the JMX server and then run a few beans. The primary bean would be  
> the environment setup and application loader. It would create a new  
> class loader so that the JMX instance running would not conflict with  
> any JMX servers running from the application. This would however add  
> more overhead which I am not sure is worth it for what we get in return.
>
> #2 and #3 would both include a JSR 88 standard J2EE application  
> deployment tool. This would be used to mount the web applications to  
> the application server. I have this partially written already from  
> when I was toying with Geronimo.
>
> Before I commit to begin working on any options, I wanted to get  
> feedback from people to see what they think the better solution is.  
> My vote currently is for #3. I am open to other suggestions. So,  
> let's get the ball rolling. Please feel free to comment, ask  
> questions, etc.
>
> Andy
>
>  
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>
>  

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev