geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <>
Subject Re: JPA plugin (was Re: Java 1.4 and JEE 5)
Date Wed, 09 Aug 2006 05:34:11 GMT
I didn't disagree with your conclusion. You gave 3 reasons for not  
performing the work at Apache. All you needed was one -- licensing  
issues prevent this work from occurring at Apache. Maybe so, but so  
far only you have made that evaluation. I'm not intimating that you  
are wrong, only that, to my knowledge, it hasn't been discussed...

You gave two additional reasons for not performing the work at  
Apache. I commented on those two reasons. The rest inline...

On Aug 8, 2006, at 5:52 PM, Aaron Mulder wrote:

> On 8/8/06, Kevan Miller <> wrote:
>> On Aug 8, 2006, at 3:47 PM, Aaron Mulder wrote:
>> > On 8/8/06, David Blevins <> wrote:
>> >> So who is we and why SourceForge?  I can certainly see having
>> >> Hibernate provider plugins and stuff there, but I definitely  
>> intend
>> >> on writing the core bits in Geronimo svn.
>> >
>> > "we" is myself and some folks at Chariot.  At SourceForge  
>> because 1)
>> > we need some place to collaborate on the code and that's impossible
>> > under RTC, 2) we are working primarily with TopLink during  
>> development
>> > and that's impossible at Apache, 3) it was easier to set up a
>> > SourceForge project than Codehaus and I don't know what to make of
>> > Google, and 4) I was explicitly told that plugin development  
>> should be
>> > done outside of Apache.
>> Regarding 1) -- too bad you feel this way.
> Well, how would you recommend working on new features with others?
> Normally you commit when you're at a point that you want to share and
> then others can update.  Under RTC, you have to post to a Jira and
> propose a vote and get 3 PMC members on board before anyone else can
> update.  So really, it's collaboration via pasting patches to Jira.
> That's ridiculous.  The next alternative is a branch.  I've seen Dain
> and Jason do the branch thing, and it looked to me like they spent as
> much time trying to keep the branch in sync with trunk as actually
> working on the branch.  No thanks.  So what do you recommend?  Do
> everything in the sandbox?

So, which is it? Do you want the code to come to Geronimo, or not? If  
you do, then I suggest you work with the community in realizing that.  
Communicate your plans, discuss your ideas, and follow the community  
process for contributing code.

>> Regarding 4) -- that's news to me and I can see no reason why that
>> would be true.
> Please, enlighten me as to how we can work with TopLink and Hibernate
> within the context of Geronimo?  Are we allowed to include GPL modules
> in the build now?  And how do I work with people who have cycles to
> contribute but aren't committers?  Are we back to collaboration via
> patches on Jira?  Also, how about the fact that Matt and Alan have
> remained firmly opposed to new features in the 1.1 branch.  So where
> do you recommend we develop JPA for Geronimo 1.1?  Sandbox?

You said "4) I was explicitly told that plugin development should be  
done outside of Apache". This implies that no plugin should ever be  
implemented within Apache. I wasn't questioning the specifics of your  
case, I was questioning the generalities of that statement. I can see  
no reason why it would be true.

I agree with Matt and Alan, but why would a plugin need to be within  
the 1.1 branch? How about geronimo/plugins/app-jpa/trunk? Or  
initially, sandbox/app-jpa/trunk?

> Look, you have to admit, it's not realistic for all Geronimo-related
> development to be done within the context of Geronimo.  ActiveMQ,
> OpenEJB, and TranQL have gone forever as independent projects, Jencks
> and WebSphere CE are heavily leveraging Geronimo, LifeRay and Apache
> Directory are certainly not developing their stuff at
>, I could give 20 examples.

Yes, and World Hunger is a bad thing. I never said that your plugin  
should be developed at Apache. I just questioned some of the reasons  
why you said it *could* not be developed at Apache.

> Please list the advantages of developing plugins inside the Geronimo
> project.  To me, plugins are best developed elsewhere, and what we
> learn developing the plugins should feed ideas for improvements into
> the core product, so it can better support a wider variety of plugins
> in the future.

Advantages? Well, that would be whatever the skills, knowledge, and  
dedication of the community can contribute. Also, it seems like  
communication would be more efficient with work occurring within the  
community, not outside.

That said, there are perfectly valid personal, technical, and legal  
reasons for plugin work to occur outside of Geronimo. RTC and "no  
plugins at apache" are not good reasons, IMO...


> Thanks,
>     Aaron
>> >> Nothing other than I intend to try and hook the main deployers
>> >> similarly to the way we did for processing the webservice.xml.   
>> Aka,
>> >> whip up some interface, hard code the deployers to call it at a
>> >> logical point in the deployment process.
>> >
>> > We're targeting Geronimo 1.1, which means we only have what we  
>> have,
>> > and I think I have to do it the ugly way.
>> >
>> > If we're talking about future releases, I strongly oppose adding
>> > another hardcoded "deployment helper".  I think we need a  
>> generic list
>> > of auxilliary deployers that can get invoked every time a J2EE
>> > application module is deployed.  For example, the Quartz plugin  
>> lets
>> > you include scheduled jobs in a WAR and so it needs to hook into  
>> the
>> > WAR deployment process too.  As long as we have all these various
>> > things that want to do that, let's make it pluggable.
>> >
>> >> I like the naming convention.  There is a JNDI context attribute
>> >> essentially on each EjbDeployment object -- think OpenEJB 1.0.  In
>> >> the related EjbDeployment GBean it's called  
>> "componentContextMap" and
>> >> it's simply a Map that's converted to an ENC via a call to
>> >> "EnterpriseNamingContext.createEnterpriseNamingContext"
>> >
>> > OK, that sounds easy enough.  But if you have one
>> > META-INF/persistence.xml file in your EJB JAR, how do you know  
>> which
>> > EJBs should get the JNDI entries?  Or is there some convention  
>> to map
>> > individual EJBs to differently-named persistence.xml files, or  
>> to map
>> > persistence units in persistence.xml to individual EJBs?
>> >
>> >> Sure.  You only attempting to do Application-Managed JPA support
>> >> (EntityManagerFactory objects in JNDI ENCs), so the plugin  
>> approach
>> >> will work fine.  When it comes to Container-Managed JPA support
>> >> (proxied EntityManagers in JNDI, tracked by connections and  
>> enrolled
>> >> in the transaction context), you're going to have a tougher  
>> time.  At
>> >> that point we're more likely to start by taking the connector  
>> support
>> >> and expanding it to include JPA.
>> >
>> > Yeah, not targeting container-managed JPA support with this plugin.
>> >
>> > We are using a Geronimo DB pool for persistence, though.  So  
>> doesn't
>> > that mean it would be included in any transaction that was going on
>> > already?  Not too relevant for web apps, but would JPA in a Session
>> > Bean inherit the Session Bean transaction settings?  I'm not  
>> sure at
>> > what point in the process the DataSource or Connection notices that
>> > there's a transaction going on and enlists itself.
>> >
>> > Thanks,
>> >      Aaron

View raw message