Dev - Replacing JOTM and Carol...

[Jacopo Cappellato]

Hi all,

what do you think of this:

http://jencks.org/

"Jencks is a lightweight JCA container which is easy to deploy inside
Spring   to provide Message Driven POJOs".

It's licensed under the ASF 2.0 and by default reuses the Geronimo JCA
connector and TransactionManager.

They say it is easy to deploy inside of Spring however it is also
written that if you are not already using Spring then you need to add
the following jars

     * spring.jar
     * aopalliance.jar

I don't know anything about Spring, but I've verified that it is ASL 2.0
  licensed too.

What do you think of this?
Could it be a starting point to replace JOTM and Carol?

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

[David E. Jones]

Jacopo,

I'm not quite following you here... What sort of use for Jencks did you have in mind, or how would it help to replace JOTM/Carol and Minerva?

-David


Jacopo Cappellato wrote:

> Hi all,
>
> what do you think of this:
>
> http://jencks.org/
>
> "Jencks is a lightweight JCA container which is easy to deploy inside
> Spring   to provide Message Driven POJOs".
>
> It's licensed under the ASF 2.0 and by default reuses the Geronimo JCA
> connector and TransactionManager.
>
> They say it is easy to deploy inside of Spring however it is also
> written that if you are not already using Spring then you need to add
> the following jars
>
>      * spring.jar
>      * aopalliance.jar
>
> I don't know anything about Spring, but I've verified that it is ASL 2.0
>   licensed too.
>
> What do you think of this?
> Could it be a starting point to replace JOTM and Carol?
>
> Jacopo
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

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

[Jacopo Cappellato]

David,

well, maybe I'm totally wrong but, I think that they have succesfully
pulled the transaction manager out of Geronimo (and resolved all its
dependecies with other parts of Geronimo as well) so this could be of
some help for us too, i.e. we could try to do the same they did to pull
the tm out of Geronimo and use it in OFBiz.

Jacopo


David E Jones wrote:

> Jacopo,
>
> I'm not quite following you here... What sort of use for Jencks did you have in mind, or how would it help to replace JOTM/Carol and Minerva?
>
> -David
>
>
> Jacopo Cappellato wrote:
>> Hi all,
>>
>> what do you think of this:
>>
>> http://jencks.org/
>>
>> "Jencks is a lightweight JCA container which is easy to deploy inside
>> Spring   to provide Message Driven POJOs".
>>
>> It's licensed under the ASF 2.0 and by default reuses the Geronimo JCA
>> connector and TransactionManager.
>>
>> They say it is easy to deploy inside of Spring however it is also
>> written that if you are not already using Spring then you need to add
>> the following jars
>>
>>      * spring.jar
>>      * aopalliance.jar
>>
>> I don't know anything about Spring, but I've verified that it is ASL 2.0
>>   licensed too.
>>
>> What do you think of this?
>> Could it be a starting point to replace JOTM and Carol?
>>
>> Jacopo
>>  
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

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

[David E. Jones]

I started looking into this and put some basic stuff in place, but with no real success. The example from Jencks was interesting but used a class called GeronimoTransactionManager that must have been from some pre-1.0 release as it does not exist in 1.0 or in the current Geronimo SVN code base.

I randomly tried some objects found looking directly at the Geronimo JavaDocs, but with no success. In a cursory review I also could not find anything along these lines in the Geronimo docs.

The infrastructure I played with is in SVN. Just change the transaction-factory tag at the beginning of the entityengine.xml file to use the now commented out geronimo one. Changes can go in the GeronimoTransactionFactory class, which is direct for now rather than using JNDI. I figure we can worry about that later and the direct model in the Entity Engine is easier for now.

If anyone has any ideas or resources related to this that would be great...

Note that none of this attempts to replace Minerva (XA aware connection pool) yet, just starting with the transaction manager for now. Of course, if anyone has any ideas about that part of Geronimo it would also be appreciated.

Note also that this is an attempt to use the embedded approach to have certain parts of Geronimo running in OFBiz rather than deploying OFBiz in Geronimo (which isn't trivial with 1.0, but may be easier with later Geronimo releases).

-David


Jacopo Cappellato wrote:

> David,
>
> well, maybe I'm totally wrong but, I think that they have succesfully
> pulled the transaction manager out of Geronimo (and resolved all its
> dependecies with other parts of Geronimo as well) so this could be of
> some help for us too, i.e. we could try to do the same they did to pull
> the tm out of Geronimo and use it in OFBiz.
>
> Jacopo
>
>
> David E Jones wrote:
>> Jacopo,
>>
>> I'm not quite following you here... What sort of use for Jencks did you have in mind, or how would it help to replace JOTM/Carol and Minerva?
>>
>> -David
>>
>>
>> Jacopo Cappellato wrote:
>>> Hi all,
>>>
>>> what do you think of this:
>>>
>>> http://jencks.org/
>>>
>>> "Jencks is a lightweight JCA container which is easy to deploy inside
>>> Spring   to provide Message Driven POJOs".
>>>
>>> It's licensed under the ASF 2.0 and by default reuses the Geronimo JCA
>>> connector and TransactionManager.
>>>
>>> They say it is easy to deploy inside of Spring however it is also
>>> written that if you are not already using Spring then you need to add
>>> the following jars
>>>
>>>      * spring.jar
>>>      * aopalliance.jar
>>>
>>> I don't know anything about Spring, but I've verified that it is ASL 2.0
>>>   licensed too.
>>>
>>> What do you think of this?
>>> Could it be a starting point to replace JOTM and Carol?
>>>
>>> Jacopo
>>>  
>>> _______________________________________________
>>> Dev mailing list
>>> [hidden email]
>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>  
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>>
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

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

[Vinay Agarwal]

David,

 

My two cents are that it may be OK to lose some flexibility (as you mentioned earlier in March) and move on since a lot depends upon this change (license, JDK version etc.).

 

Regards,

Vinay Agarwal

 

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).

 

 

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

[Jacopo Cappellato]

David,

thanks for pushing this work forward!
I did some research about the GeronimoTransactionManager class and I've
discovered that it is one of three classes implemented in the Jencks
project to extend the Geronimo transaction manager; here is the link to
the source code in CVS:

http://cvs.jencks.codehaus.org/jencks/src/main/java/org/apache/geronimo/transaction/context/GeronimoTransactionManager.java?view=markup

I really don't know why they implemented it in the
org.apache.geronimo.transaction.context package instead of in the
org.jencks... package, however the source code are in the jencks
distribution.

Hope this helps... I'd love to help you more than this, but I'm still a
bit confused by the transaction manager framework, sorry!

Jacopo


David E Jones wrote:

> I started looking into this and put some basic stuff in place, but with no real success. The example from Jencks was interesting but used a class called GeronimoTransactionManager that must have been from some pre-1.0 release as it does not exist in 1.0 or in the current Geronimo SVN code base.
>
> I randomly tried some objects found looking directly at the Geronimo JavaDocs, but with no success. In a cursory review I also could not find anything along these lines in the Geronimo docs.
>
> The infrastructure I played with is in SVN. Just change the transaction-factory tag at the beginning of the entityengine.xml file to use the now commented out geronimo one. Changes can go in the GeronimoTransactionFactory class, which is direct for now rather than using JNDI. I figure we can worry about that later and the direct model in the Entity Engine is easier for now.
>
> If anyone has any ideas or resources related to this that would be great...
>
> Note that none of this attempts to replace Minerva (XA aware connection pool) yet, just starting with the transaction manager for now. Of course, if anyone has any ideas about that part of Geronimo it would also be appreciated.
>
> Note also that this is an attempt to use the embedded approach to have certain parts of Geronimo running in OFBiz rather than deploying OFBiz in Geronimo (which isn't trivial with 1.0, but may be easier with later Geronimo releases).
>
> -David
>

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

[David E. Jones]

Just to clear up one point real quick: the move to Geronimo 1.0 won't help with the JDK 1.5 issues. It turns out that Geronimo 1.0 does not support Java 1.5 and must run on a Java 1.4 series JVM right now... That should change with the next release of Geronimo (due out soon?). With Geronimo from their SVN repository it is evidently possible but requires modifications as OpenEJB has some 1.4 dependent stuff stuff (not that we need it... hence one possible route for modifications if someone had enough free time...).

-David


Vinay Agarwal wrote:

> David,
>
>  
>
> My two cents are that it may be OK to lose some flexibility (as you
> mentioned earlier in March) and move on since a lot depends upon this
> change (license, JDK version etc.).
>
>  
>
> Regards,
>
> Vinay Agarwal
>
>  
>
> 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).
>
>  
>
>  
>
>
> ------------------------------------------------------------------------
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

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

[David E. Jones]

Okay, cute... I'll look into that. I'm 99% sure I know why they would use that package: because the Geronimo code has some protected fields or methods that they need to use in order to do what they do. This doesn't work with certain security setting in Java, but is a nice trick that can be made to work without changing the "other project".

We did this for a while with BeanShell until it became a problem and now just use a modified version of BeanShell (to support caching of interpreted scripts).

-David


Jacopo Cappellato wrote:

> David,
>
> thanks for pushing this work forward!
> I did some research about the GeronimoTransactionManager class and I've
> discovered that it is one of three classes implemented in the Jencks
> project to extend the Geronimo transaction manager; here is the link to
> the source code in CVS:
>
> http://cvs.jencks.codehaus.org/jencks/src/main/java/org/apache/geronimo/transaction/context/GeronimoTransactionManager.java?view=markup
>
> I really don't know why they implemented it in the
> org.apache.geronimo.transaction.context package instead of in the
> org.jencks... package, however the source code are in the jencks
> distribution.
>
> Hope this helps... I'd love to help you more than this, but I'm still a
> bit confused by the transaction manager framework, sorry!
>
> Jacopo
>
>
> David E Jones wrote:
>> I started looking into this and put some basic stuff in place, but with no real success. The example from Jencks was interesting but used a class called GeronimoTransactionManager that must have been from some pre-1.0 release as it does not exist in 1.0 or in the current Geronimo SVN code base.
>>
>> I randomly tried some objects found looking directly at the Geronimo JavaDocs, but with no success. In a cursory review I also could not find anything along these lines in the Geronimo docs.
>>
>> The infrastructure I played with is in SVN. Just change the transaction-factory tag at the beginning of the entityengine.xml file to use the now commented out geronimo one. Changes can go in the GeronimoTransactionFactory class, which is direct for now rather than using JNDI. I figure we can worry about that later and the direct model in the Entity Engine is easier for now.
>>
>> If anyone has any ideas or resources related to this that would be great...
>>
>> Note that none of this attempts to replace Minerva (XA aware connection pool) yet, just starting with the transaction manager for now. Of course, if anyone has any ideas about that part of Geronimo it would also be appreciated.
>>
>> Note also that this is an attempt to use the embedded approach to have certain parts of Geronimo running in OFBiz rather than deploying OFBiz in Geronimo (which isn't trivial with 1.0, but may be easier with later Geronimo releases).
>>
>> -David
>>
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

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

[David E. Jones]

Jacopo, and others,

Okay... with SVN rev 7464 the GeronimoTransactionFactory now seems to be functional. Thanks for your help looking things up Jacopo. I looked into Jencks a bit more and it looks like there are some people (like David Jencks) working on both Jencks and Geronimo, and it may be that the things we are now using from the Jencks project could eventually be part of Geronimo itself, making embedded use easier. For now, we have the Jencks jar. That may be another reason why these classes are in the org.apache.geronimo package, they would like them to go over there eventually...

Anyway, we could now use some help testing this!

To enable it (it's not enabled by default yet), just uncomment line 35 in entityengine.xml:

    <!-- <transaction-factory class="org.ofbiz.geronimo.GeronimoTransactionFactory"/> -->

and comment out lines 39-42 that have the current JNDI tx factory setup.

Note that this is still using Minerva for the JDBC XA-aware connection pool. It looks like Jencks might have some things to help us there as well, but my time is up for the day on this stuff.

BTW: it looks like the entity engine JUnit tests all pass, so we're good to go with that anyway... It's great to have regression tests. ;) Thanks to Si and everyone who helped on those.

-David


Jacopo Cappellato wrote:

> David,
>
> thanks for pushing this work forward!
> I did some research about the GeronimoTransactionManager class and I've
> discovered that it is one of three classes implemented in the Jencks
> project to extend the Geronimo transaction manager; here is the link to
> the source code in CVS:
>
> http://cvs.jencks.codehaus.org/jencks/src/main/java/org/apache/geronimo/transaction/context/GeronimoTransactionManager.java?view=markup
>
> I really don't know why they implemented it in the
> org.apache.geronimo.transaction.context package instead of in the
> org.jencks... package, however the source code are in the jencks
> distribution.
>
> Hope this helps... I'd love to help you more than this, but I'm still a
> bit confused by the transaction manager framework, sorry!
>
> Jacopo
>
>
> David E Jones wrote:
>> I started looking into this and put some basic stuff in place, but with no real success. The example from Jencks was interesting but used a class called GeronimoTransactionManager that must have been from some pre-1.0 release as it does not exist in 1.0 or in the current Geronimo SVN code base.
>>
>> I randomly tried some objects found looking directly at the Geronimo JavaDocs, but with no success. In a cursory review I also could not find anything along these lines in the Geronimo docs.
>>
>> The infrastructure I played with is in SVN. Just change the transaction-factory tag at the beginning of the entityengine.xml file to use the now commented out geronimo one. Changes can go in the GeronimoTransactionFactory class, which is direct for now rather than using JNDI. I figure we can worry about that later and the direct model in the Entity Engine is easier for now.
>>
>> If anyone has any ideas or resources related to this that would be great...
>>
>> Note that none of this attempts to replace Minerva (XA aware connection pool) yet, just starting with the transaction manager for now. Of course, if anyone has any ideas about that part of Geronimo it would also be appreciated.
>>
>> Note also that this is an attempt to use the embedded approach to have certain parts of Geronimo running in OFBiz rather than deploying OFBiz in Geronimo (which isn't trivial with 1.0, but may be easier with later Geronimo releases).
>>
>> -David
>>
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

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

[David E. Jones]

BTW, the implications of this for the Apache Incubation effort are good...

With this we should be able to remove the jotm component. It will just take a little work to move certain JOTM-dependent classes from the entity component to the jotm component, and then move that to the specialized directory just in case anyone wants it at some point.

With the licensing on Minerva we can keep it as a separate open source project and just include the jar in "Apache OFBiz". My thoughts on this are to move minerva to the specialized folder as well to have a place to keep it, and we'll just have a pre-build minerva jar in the entity component or something.

That means we are pretty much there for removing LGPL and GPL dependencies and so if this is all working okay we can move the bulk of OFBiz to the Apache SVN servers.

When we do that we'll probably want to start using their Jira server too... This will probably mean going with an empty Jira project and creating new issue only there. I'll change the current Jira server (and I've checked to make sure this is possible) to not allow any new issues, but current issues can stay there until resolved, or until moved to the Apache Jira server.

-David


David E Jones wrote:

> Jacopo, and others,
>
> Okay... with SVN rev 7464 the GeronimoTransactionFactory now seems to be functional. Thanks for your help looking things up Jacopo. I looked into Jencks a bit more and it looks like there are some people (like David Jencks) working on both Jencks and Geronimo, and it may be that the things we are now using from the Jencks project could eventually be part of Geronimo itself, making embedded use easier. For now, we have the Jencks jar. That may be another reason why these classes are in the org.apache.geronimo package, they would like them to go over there eventually...
>
> Anyway, we could now use some help testing this!
>
> To enable it (it's not enabled by default yet), just uncomment line 35 in entityengine.xml:
>
>     <!-- <transaction-factory class="org.ofbiz.geronimo.GeronimoTransactionFactory"/> -->
>
> and comment out lines 39-42 that have the current JNDI tx factory setup.
>
> Note that this is still using Minerva for the JDBC XA-aware connection pool. It looks like Jencks might have some things to help us there as well, but my time is up for the day on this stuff.
>
> BTW: it looks like the entity engine JUnit tests all pass, so we're good to go with that anyway... It's great to have regression tests. ;) Thanks to Si and everyone who helped on those.
>
> -David
>
>
> Jacopo Cappellato wrote:
>> David,
>>
>> thanks for pushing this work forward!
>> I did some research about the GeronimoTransactionManager class and I've
>> discovered that it is one of three classes implemented in the Jencks
>> project to extend the Geronimo transaction manager; here is the link to
>> the source code in CVS:
>>
>> http://cvs.jencks.codehaus.org/jencks/src/main/java/org/apache/geronimo/transaction/context/GeronimoTransactionManager.java?view=markup
>>
>> I really don't know why they implemented it in the
>> org.apache.geronimo.transaction.context package instead of in the
>> org.jencks... package, however the source code are in the jencks
>> distribution.
>>
>> Hope this helps... I'd love to help you more than this, but I'm still a
>> bit confused by the transaction manager framework, sorry!
>>
>> Jacopo
>>
>>
>> David E Jones wrote:
>>> I started looking into this and put some basic stuff in place, but with no real success. The example from Jencks was interesting but used a class called GeronimoTransactionManager that must have been from some pre-1.0 release as it does not exist in 1.0 or in the current Geronimo SVN code base.
>>>
>>> I randomly tried some objects found looking directly at the Geronimo JavaDocs, but with no success. In a cursory review I also could not find anything along these lines in the Geronimo docs.
>>>
>>> The infrastructure I played with is in SVN. Just change the transaction-factory tag at the beginning of the entityengine.xml file to use the now commented out geronimo one. Changes can go in the GeronimoTransactionFactory class, which is direct for now rather than using JNDI. I figure we can worry about that later and the direct model in the Entity Engine is easier for now.
>>>
>>> If anyone has any ideas or resources related to this that would be great...
>>>
>>> Note that none of this attempts to replace Minerva (XA aware connection pool) yet, just starting with the transaction manager for now. Of course, if anyone has any ideas about that part of Geronimo it would also be appreciated.
>>>
>>> Note also that this is an attempt to use the embedded approach to have certain parts of Geronimo running in OFBiz rather than deploying OFBiz in Geronimo (which isn't trivial with 1.0, but may be easier with later Geronimo releases).
>>>
>>> -David
>>>
>>  
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

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

[Andrew Zeneski]

Again, tell me why we don't just comment out Carol, throw in a quick  
RMI Registry class (Free ones all over the place, I have one, MX4J  
has one) and use continue to use JOTM (BSD License)??

On May 1, 2006, at 4:58 AM, David E Jones wrote:

>
> Okay, cute... I'll look into that. I'm 99% sure I know why they  
> would use that package: because the Geronimo code has some  
> protected fields or methods that they need to use in order to do  
> what they do. This doesn't work with certain security setting in  
> Java, but is a nice trick that can be made to work without changing  
> the "other project".
>
> We did this for a while with BeanShell until it became a problem  
> and now just use a modified version of BeanShell (to support  
> caching of interpreted scripts).
>
> -David
>
>
> Jacopo Cappellato wrote:
>> David,
>>
>> thanks for pushing this work forward!
>> I did some research about the GeronimoTransactionManager class and  
>> I've
>> discovered that it is one of three classes implemented in the Jencks
>> project to extend the Geronimo transaction manager; here is the  
>> link to
>> the source code in CVS:
>>
>> http://cvs.jencks.codehaus.org/jencks/src/main/java/org/apache/ 
>> geronimo/transaction/context/GeronimoTransactionManager.java?
>> view=markup
>>
>> I really don't know why they implemented it in the
>> org.apache.geronimo.transaction.context package instead of in the
>> org.jencks... package, however the source code are in the jencks
>> distribution.
>>
>> Hope this helps... I'd love to help you more than this, but I'm  
>> still a
>> bit confused by the transaction manager framework, sorry!
>>
>> Jacopo
>>
>>
>> David E Jones wrote:
>>> I started looking into this and put some basic stuff in place,  
>>> but with no real success. The example from Jencks was interesting  
>>> but used a class called GeronimoTransactionManager that must have  
>>> been from some pre-1.0 release as it does not exist in 1.0 or in  
>>> the current Geronimo SVN code base.
>>>
>>> I randomly tried some objects found looking directly at the  
>>> Geronimo JavaDocs, but with no success. In a cursory review I  
>>> also could not find anything along these lines in the Geronimo docs.
>>>
>>> The infrastructure I played with is in SVN. Just change the  
>>> transaction-factory tag at the beginning of the entityengine.xml  
>>> file to use the now commented out geronimo one. Changes can go in  
>>> the GeronimoTransactionFactory class, which is direct for now  
>>> rather than using JNDI. I figure we can worry about that later  
>>> and the direct model in the Entity Engine is easier for now.
>>>
>>> If anyone has any ideas or resources related to this that would  
>>> be great...
>>>
>>> Note that none of this attempts to replace Minerva (XA aware  
>>> connection pool) yet, just starting with the transaction manager  
>>> for now. Of course, if anyone has any ideas about that part of  
>>> Geronimo it would also be appreciated.
>>>
>>> Note also that this is an attempt to use the embedded approach to  
>>> have certain parts of Geronimo running in OFBiz rather than  
>>> deploying OFBiz in Geronimo (which isn't trivial with 1.0, but  
>>> may be easier with later Geronimo releases).
>>>
>>> -David
>>>
>>
>>
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

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

[Jacopo Cappellato]

Andy,

it's interesting to read your opinion about this important subject. I
see pros and cons for both JOTM and Geronimo TM:

# JOTM - pros
1) it works fine for OFBiz
2) the integration is stable, it has been in OFBiz for many years
3) the core developers (you and David and probably someone else, not me)
already know how to deal with it

# JOTM - cons
1) my impression is that the project is not actively maintained and
developed by the objectweb comunity (very few messages in the lists etc...)
2) it is licensed under the BSD license, but there are some license
issues because in the JOTM distribution the howl.jar (used for
journaling) is included and howl is released under the LGPL license;
now, there is a debate on this (can a LGPL jar be included and
distributed in a MIT style licensed project or not? at the ASF it seems
that they are more inclined to say 'no')

#Geronimo TM - pros
1) actively maintained by the Geronimo community under the ASF
2) no license issues, it is licensed under the ASL2.0
3) it's always good to have one more open source option to choose from
(JOTM or Geronimo)
4) after the initial integration problems, David seems to have found a
way to integrate it (in the embedded style like JOTM)... why should we
stop now? ;-)

#Geronimo TM - cons
1) it is a new tool for OFBiz, we will have to test it and it could
bring some instabilities in the short term
2) the core team will have to learn this new tool (no one in this
community seems to have used it before)

What do you (Andy, and others as well) think of this?

Jacopo

A. Zeneski wrote:

> Again, tell me why we don't just comment out Carol, throw in a quick  
> RMI Registry class (Free ones all over the place, I have one, MX4J  
> has one) and use continue to use JOTM (BSD License)??
>
> On May 1, 2006, at 4:58 AM, David E Jones wrote:
>
>> Okay, cute... I'll look into that. I'm 99% sure I know why they  
>> would use that package: because the Geronimo code has some  
>> protected fields or methods that they need to use in order to do  
>> what they do. This doesn't work with certain security setting in  
>> Java, but is a nice trick that can be made to work without changing  
>> the "other project".
>>
>> We did this for a while with BeanShell until it became a problem  
>> and now just use a modified version of BeanShell (to support  
>> caching of interpreted scripts).
>>
>> -David
>>
>>
>> Jacopo Cappellato wrote:
>>> David,
>>>
>>> thanks for pushing this work forward!
>>> I did some research about the GeronimoTransactionManager class and  
>>> I've
>>> discovered that it is one of three classes implemented in the Jencks
>>> project to extend the Geronimo transaction manager; here is the  
>>> link to
>>> the source code in CVS:
>>>
>>> http://cvs.jencks.codehaus.org/jencks/src/main/java/org/apache/ 
>>> geronimo/transaction/context/GeronimoTransactionManager.java?
>>> view=markup
>>>
>>> I really don't know why they implemented it in the
>>> org.apache.geronimo.transaction.context package instead of in the
>>> org.jencks... package, however the source code are in the jencks
>>> distribution.
>>>
>>> Hope this helps... I'd love to help you more than this, but I'm  
>>> still a
>>> bit confused by the transaction manager framework, sorry!
>>>
>>> Jacopo
>>>
>>>
>>> David E Jones wrote:
>>>> I started looking into this and put some basic stuff in place,  
>>>> but with no real success. The example from Jencks was interesting  
>>>> but used a class called GeronimoTransactionManager that must have  
>>>> been from some pre-1.0 release as it does not exist in 1.0 or in  
>>>> the current Geronimo SVN code base.
>>>>
>>>> I randomly tried some objects found looking directly at the  
>>>> Geronimo JavaDocs, but with no success. In a cursory review I  
>>>> also could not find anything along these lines in the Geronimo docs.
>>>>
>>>> The infrastructure I played with is in SVN. Just change the  
>>>> transaction-factory tag at the beginning of the entityengine.xml  
>>>> file to use the now commented out geronimo one. Changes can go in  
>>>> the GeronimoTransactionFactory class, which is direct for now  
>>>> rather than using JNDI. I figure we can worry about that later  
>>>> and the direct model in the Entity Engine is easier for now.
>>>>
>>>> If anyone has any ideas or resources related to this that would  
>>>> be great...
>>>>
>>>> Note that none of this attempts to replace Minerva (XA aware  
>>>> connection pool) yet, just starting with the transaction manager  
>>>> for now. Of course, if anyone has any ideas about that part of  
>>>> Geronimo it would also be appreciated.
>>>>
>>>> Note also that this is an attempt to use the embedded approach to  
>>>> have certain parts of Geronimo running in OFBiz rather than  
>>>> deploying OFBiz in Geronimo (which isn't trivial with 1.0, but  
>>>> may be easier with later Geronimo releases).
>>>>
>>>> -David
>>>>
>>>
>>> _______________________________________________
>>> Dev mailing list
>>> [hidden email]
>>> http://lists.ofbiz.org/mailman/listinfo/dev
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

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

[Jacopo Cappellato]

Andy, all,

I just realized (looking at
http://ofbizwiki.go-integral.com/Wiki.jsp?page=LibrariesIncludedInOFBiz)
there is an error in one of the points in my previous post: #2 of JOTM cons.

So it's not true that howl.jar is LGPL licensed; it is BSD licensed: for
this reason, please ignore the whole point #2 of JOTM cons.

So it seems that, from a license point of view, we are very near to have
fixed our problems with the transaction management stuff: both JOTM
(removing Carol as mentioned by Andy) and Geronimo TM can be used for this.

Jacopo

Jacopo Cappellato wrote:

> Andy,
>
> it's interesting to read your opinion about this important subject. I
> see pros and cons for both JOTM and Geronimo TM:
>
> # JOTM - pros
> 1) it works fine for OFBiz
> 2) the integration is stable, it has been in OFBiz for many years
> 3) the core developers (you and David and probably someone else, not me)
> already know how to deal with it
>
> # JOTM - cons
> 1) my impression is that the project is not actively maintained and
> developed by the objectweb comunity (very few messages in the lists etc...)
> 2) it is licensed under the BSD license, but there are some license
> issues because in the JOTM distribution the howl.jar (used for
> journaling) is included and howl is released under the LGPL license;
> now, there is a debate on this (can a LGPL jar be included and
> distributed in a MIT style licensed project or not? at the ASF it seems
> that they are more inclined to say 'no')
>
> #Geronimo TM - pros
> 1) actively maintained by the Geronimo community under the ASF
> 2) no license issues, it is licensed under the ASL2.0
> 3) it's always good to have one more open source option to choose from
> (JOTM or Geronimo)
> 4) after the initial integration problems, David seems to have found a
> way to integrate it (in the embedded style like JOTM)... why should we
> stop now? ;-)
>
> #Geronimo TM - cons
> 1) it is a new tool for OFBiz, we will have to test it and it could
> bring some instabilities in the short term
> 2) the core team will have to learn this new tool (no one in this
> community seems to have used it before)
>
> What do you (Andy, and others as well) think of this?
>
> Jacopo
>

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