geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <>
Subject Re: JPA plugin (was Re: Java 1.4 and JEE 5)
Date Tue, 08 Aug 2006 21:52:51 GMT
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?

> 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?

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.

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.


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