Re: JPA plugin (was Re: Java 1.4 and JEE 5)
On Aug 11, 2006, at 2:41 PM, David Blevins wrote: On Aug 9, 2006, at 1:21 AM, David Blevins wrote: I'm going to start a branch tomorrow to experiment with JPA stuff Done. Got a branch up here: - Revision 430900: /geronimo/branches/jpa-plugin Didn't turn out to need this as I'm not changing anything. Going to add the plugins to the sandbox instead and delete the branch I made. -David Also threw up a wiki page: - http://cwiki.apache.org/confluence/display/GMOxSBOX/JPA+Plugin I think I also got Dain roped into helping me with some of the naming parts (bought him breakfast and sprung it on him while he was all in a good mood). We're sitting right next o each other here at a coffee shop so hopefully we can rise to the challenge of keeping stuff on the list. The last idea in my head last night before I went to sleep was that I thought one good approach was to create the PersistenceUnitInfo objects sans their references to DataSources and shove them into a special JNDI Reference object that will pull the DataSource from JNDI and create the EntityManagerFactory and pass that back in the getValue method (or whatever it's called) of the JNDI Reference upon a lookup. The user would still be responsible for configuring the name of the DataSource in the persistence.xml and that the DataSource should come from the right pool (i.e. the non-tx pool). Again, this is for app-managed JPA. Container-managed JPA is another ball of wax. Anyway, more later. -David
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
On Aug 12, 2006, at 2:52 PM, David Blevins wrote: Seems like I'm walking in mid-conversation, but I hope I can add some details. Geez, I just had *seven* missing emails in this thread show up in my mailbox. Not sure what's going on with the mail, but that explains the strange gaps. -David
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
On Aug 12, 2006, at 10:03 PM, Jeff Genender wrote:
David Blevins wrote:
Seems like I'm walking in mid-conversation, but I hope I can add some
details.
On Aug 11, 2006, at 8:30 PM, Aaron Mulder wrote:
On 8/11/06, Jeff Genender [EMAIL PROTECTED] wrote:
Ok, I understand where you are going with this. I totally agree
with
your thinking here. But...IIUC...in the web app, if you are
including
your own PU, you likely wouldn't be using the JNDI (and thus the
container) for this and would be declaring use of the spi bootstrap
directly:
EntityManagerFactory emf =
Persistence.createEntityManagerFactory(mywebpersistenceunit)
That's one way any component (servlet, ejb, ee app client, or java se
app) can get an EntityManagerFactory. But as Aaron says, anyone
(servlet, ejb, ee app client) who wants a DataSource managed by the
container has to use JNDI or dependecy injection (which is JNDI
driven
in JEE).
Well...that wasn't my point ;-) My point was there was no reason to
access the JNDI to get an EMF for a stand alone web app. However,
there
is nothing wrong with the persistence.xml declaring access to the JNDI
for the datasource...even in a stand alone web app... i.e:
persistence
persistence-unit name=myPU transaction-type=JTA
jta-data-sourcejava:/MySQLDS/jta-data-source
...
In this case...the code I showed could still apply to get a container
managed datasource...as does yours ;-)
Just checked my spec again and it looks like we're both wrong,
support for Persistence.createEntityManagerFactory isn't required in
an EE environment. It'd probably be a good idea to support if other
EE platforms will be supporting it, though.
-David
Jeff
E.g. a Servlet with this:
public class MySerlvet extends HttpServlet {
@Resource EntityManagerFactory myEmf;
}
Or the equivalent EJB:
@Stateful public class ShoppingCart {
@Resource EntityManagerFactory myEmf;
}
At this moment it won't be a problem, since the plugin only supports
web apps, but with Blevins' expertise it should be easy enough to
support EJB JARs too. Eventually we'll need to get clever --
perhaps
detecting that correctly-named JPA GBeans already exist in the
parent
tree so it's not necessary to redefine them for the web app. In
fact,
that's probably the way to go.
Happy to help in whatever approach you're taking. As I mentioned my
current thinking is to wrap JNDI with an extended JNDI and put
the JPA
resources in there so EJBs or Servlets that have persistence.xml
files
in their archives can use them. I like your idea on checking to
see if
a gbean is already defined and not redefining it (it being the JPA
factory). From a spec perspective, I can find anything that requires
this. Have you found something? Best I can find is that the
persistence classes themselves (i.e. your persistent pojo classes)
have
to come from the same classloader and can't be reloaded in a child
classloader if they were also listed in a parent classloader.
-David
Thanks,
Aaron
And when using the EJB, you would call the JNDI. Therefore, I
don't
think this is a problem at all.
Thanks,
Aaron
But unless
the spi jar uses some sort of mechanism using static
declarations or
componanents like Spring, then it really shouldn't be an issue.
If it
is, I think its reasonable to claim storage of duplicate PUs in
the same
package causing the problem (again, like the Spring Commons
Logging
problem).
Thanks,
Aaron
Aaron Mulder wrote:
So what happens if an EJB JAR has a persistence.xml and a web
app in
the same EAR has a separate persistence.xml? If we just look
in the
class loader, when we go to deploy the web app, we'll see
them both
because the EJB JAR is added to the parent classpath of the
WAR. Is
there a good way to distinguish resource in my ClassLoader
from
resources in my ClassLoader tree?
Thanks,
Aaron
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
This isn't a problem. The spec actually says that the web app should be able to see both persistence units. Also, we are just creating a map of the persistent units visible, the user still has to choose which ones to lookup using our magic namespace which is way out side the specification. -dain On Aug 11, 2006, at 6:32 PM, Aaron Mulder wrote: So what happens if an EJB JAR has a persistence.xml and a web app in the same EAR has a separate persistence.xml? If we just look in the class loader, when we go to deploy the web app, we'll see them both because the EJB JAR is added to the parent classpath of the WAR. Is there a good way to distinguish resource in my ClassLoader from resources in my ClassLoader tree? Thanks, Aaron
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
On Aug 11, 2006, at 8:30 PM, Aaron Mulder wrote: On 8/11/06, Jeff Genender [EMAIL PROTECTED] wrote: Ok, I understand where you are going with this. I totally agree with your thinking here. But...IIUC...in the web app, if you are including your own PU, you likely wouldn't be using the JNDI (and thus the container) for this and would be declaring use of the spi bootstrap directly: EntityManagerFactory emf = Persistence.createEntityManagerFactory(mywebpersistenceunit) But with the plugin we're working on, you can look up app-managed EntityManagerFactories in JNDI. Even without JNDI, we'd have to intercept the process to connect the EMF to the DataSource named in persistence.xml. So when you deploy a web app, we look for a persistence.xml in order to read all the settings, connect the web app to the data source and the JPA provider in question, and add the EntityManagerFactories to JNDI. This really isn't a big problem for us, because we are building the pu index at runtime so we can just lookup datasources in the kernel (or JNDI via some magic). Actually, I'm pretty sure the spec gives examples of a stateless session bean using app-managed EMFs and they're injected not looked up the way you're saying. I think that's only for Java SE clients. EJBs support both injection and jndi lookup (the former just uses the latter under the covers). For SE clients, you have to use code like this: EntityManagerFactory emf = javax.persistence.Persistence.createEntityManagerFactory(Order); EntityManager em = emf.createEntityManager(); Any JEE application can use the code above, but it is not recommended. JEE components also get to decide to use application managed injected or looked up EMF or a container managed EM. -dain
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
Seems like I'm walking in mid-conversation, but I hope I can add some
details.
On Aug 11, 2006, at 8:30 PM, Aaron Mulder wrote:
On 8/11/06, Jeff Genender [EMAIL PROTECTED] wrote:
Ok, I understand where you are going with this. I totally agree with
your thinking here. But...IIUC...in the web app, if you are
including
your own PU, you likely wouldn't be using the JNDI (and thus the
container) for this and would be declaring use of the spi bootstrap
directly:
EntityManagerFactory emf =
Persistence.createEntityManagerFactory(mywebpersistenceunit)
That's one way any component (servlet, ejb, ee app client, or java se
app) can get an EntityManagerFactory. But as Aaron says, anyone
(servlet, ejb, ee app client) who wants a DataSource managed by the
container has to use JNDI or dependecy injection (which is JNDI
driven in JEE).
E.g. a Servlet with this:
public class MySerlvet extends HttpServlet {
@Resource EntityManagerFactory myEmf;
}
Or the equivalent EJB:
@Stateful public class ShoppingCart {
@Resource EntityManagerFactory myEmf;
}
At this moment it won't be a problem, since the plugin only supports
web apps, but with Blevins' expertise it should be easy enough to
support EJB JARs too. Eventually we'll need to get clever -- perhaps
detecting that correctly-named JPA GBeans already exist in the parent
tree so it's not necessary to redefine them for the web app. In fact,
that's probably the way to go.
Happy to help in whatever approach you're taking. As I mentioned my
current thinking is to wrap JNDI with an extended JNDI and put the
JPA resources in there so EJBs or Servlets that have persistence.xml
files in their archives can use them. I like your idea on checking
to see if a gbean is already defined and not redefining it (it being
the JPA factory). From a spec perspective, I can find anything that
requires this. Have you found something? Best I can find is that
the persistence classes themselves (i.e. your persistent pojo
classes) have to come from the same classloader and can't be reloaded
in a child classloader if they were also listed in a parent classloader.
-David
Thanks,
Aaron
And when using the EJB, you would call the JNDI. Therefore, I don't
think this is a problem at all.
Thanks,
Aaron
But unless
the spi jar uses some sort of mechanism using static
declarations or
componanents like Spring, then it really shouldn't be an
issue. If it
is, I think its reasonable to claim storage of duplicate PUs in
the same
package causing the problem (again, like the Spring Commons
Logging
problem).
Thanks,
Aaron
Aaron Mulder wrote:
So what happens if an EJB JAR has a persistence.xml and a
web app in
the same EAR has a separate persistence.xml? If we just
look in the
class loader, when we go to deploy the web app, we'll see
them both
because the EJB JAR is added to the parent classpath of
the WAR. Is
there a good way to distinguish resource in my
ClassLoader from
resources in my ClassLoader tree?
Thanks,
Aaron
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
David Blevins wrote:
Seems like I'm walking in mid-conversation, but I hope I can add some
details.
On Aug 11, 2006, at 8:30 PM, Aaron Mulder wrote:
On 8/11/06, Jeff Genender [EMAIL PROTECTED] wrote:
Ok, I understand where you are going with this. I totally agree with
your thinking here. But...IIUC...in the web app, if you are including
your own PU, you likely wouldn't be using the JNDI (and thus the
container) for this and would be declaring use of the spi bootstrap
directly:
EntityManagerFactory emf =
Persistence.createEntityManagerFactory(mywebpersistenceunit)
That's one way any component (servlet, ejb, ee app client, or java se
app) can get an EntityManagerFactory. But as Aaron says, anyone
(servlet, ejb, ee app client) who wants a DataSource managed by the
container has to use JNDI or dependecy injection (which is JNDI driven
in JEE).
Well...that wasn't my point ;-) My point was there was no reason to
access the JNDI to get an EMF for a stand alone web app. However, there
is nothing wrong with the persistence.xml declaring access to the JNDI
for the datasource...even in a stand alone web app... i.e:
persistence
persistence-unit name=myPU transaction-type=JTA
jta-data-sourcejava:/MySQLDS/jta-data-source
...
In this case...the code I showed could still apply to get a container
managed datasource...as does yours ;-)
Jeff
E.g. a Servlet with this:
public class MySerlvet extends HttpServlet {
@Resource EntityManagerFactory myEmf;
}
Or the equivalent EJB:
@Stateful public class ShoppingCart {
@Resource EntityManagerFactory myEmf;
}
At this moment it won't be a problem, since the plugin only supports
web apps, but with Blevins' expertise it should be easy enough to
support EJB JARs too. Eventually we'll need to get clever -- perhaps
detecting that correctly-named JPA GBeans already exist in the parent
tree so it's not necessary to redefine them for the web app. In fact,
that's probably the way to go.
Happy to help in whatever approach you're taking. As I mentioned my
current thinking is to wrap JNDI with an extended JNDI and put the JPA
resources in there so EJBs or Servlets that have persistence.xml files
in their archives can use them. I like your idea on checking to see if
a gbean is already defined and not redefining it (it being the JPA
factory). From a spec perspective, I can find anything that requires
this. Have you found something? Best I can find is that the
persistence classes themselves (i.e. your persistent pojo classes) have
to come from the same classloader and can't be reloaded in a child
classloader if they were also listed in a parent classloader.
-David
Thanks,
Aaron
And when using the EJB, you would call the JNDI. Therefore, I don't
think this is a problem at all.
Thanks,
Aaron
But unless
the spi jar uses some sort of mechanism using static declarations or
componanents like Spring, then it really shouldn't be an issue.
If it
is, I think its reasonable to claim storage of duplicate PUs in
the same
package causing the problem (again, like the Spring Commons Logging
problem).
Thanks,
Aaron
Aaron Mulder wrote:
So what happens if an EJB JAR has a persistence.xml and a web
app in
the same EAR has a separate persistence.xml? If we just look
in the
class loader, when we go to deploy the web app, we'll see
them both
because the EJB JAR is added to the parent classpath of the
WAR. Is
there a good way to distinguish resource in my ClassLoader
from
resources in my ClassLoader tree?
Thanks,
Aaron
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
On Aug 9, 2006, at 1:21 AM, David Blevins wrote: I'm going to start a branch tomorrow to experiment with JPA stuff Done. Got a branch up here: - Revision 430900: /geronimo/branches/jpa-plugin Also threw up a wiki page: - http://cwiki.apache.org/confluence/display/GMOxSBOX/JPA+Plugin I think I also got Dain roped into helping me with some of the naming parts (bought him breakfast and sprung it on him while he was all in a good mood). We're sitting right next o each other here at a coffee shop so hopefully we can rise to the challenge of keeping stuff on the list. The last idea in my head last night before I went to sleep was that I thought one good approach was to create the PersistenceUnitInfo objects sans their references to DataSources and shove them into a special JNDI Reference object that will pull the DataSource from JNDI and create the EntityManagerFactory and pass that back in the getValue method (or whatever it's called) of the JNDI Reference upon a lookup. The user would still be responsible for configuring the name of the DataSource in the persistence.xml and that the DataSource should come from the right pool (i.e. the non-tx pool). Again, this is for app-managed JPA. Container-managed JPA is another ball of wax. Anyway, more later. -David
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
On Aug 8, 2006, at 12:22 PM, Jeff Genender wrote: Aaron, Please look at the openejb3-persistence module as it does a majority of what you described below... 1) Takes a classloader 2) looks for persistence.xml files 3) parses found persistence.xml files 4) Creates EntityManagerFactories based on the persistence.xml file specifications. 5) Loads it into JNDI So all you really need to so is provide the classloader and it will handle the rest. It may need some tweaking, but it should put you in the ballpark of what you need. Heads up, going to use all this code. Likely going to split up the PersistenceDeployer class to delay the data source lookup and EntityManagerFactory creation till someone tries to lookup it up from JNDI. Basically what I described in my previous email. -David You can find the code here: http://svn.codehaus.org/openejb/trunk/openejb3/container/openejb- persistence/ Jeff Aaron Mulder wrote: On 8/8/06, David Blevins [EMAIL PROTECTED] wrote: What approach are you taking to get this done? I was thinking to do App-managed EntityManagers, the EntityManagerFactories looked up through JNDI, and available to both web apps and ejbs. First of all, the work I'm doing on this is mostly helping with the Geronimo integration... so I'm praying my JPA answers are sensible. :) So far the idea is to put an EntityManagerFactory in JNDI for each persistence unit at java:comp/env/jpa/(persistence-unit-name) . The problem is that every component type in Geronimo uses a different GBean and attribute to hold the JNDI context. It turns out that Jetty and Tomcat both use the same attribute name on the WebModule implementation, which makes that easy. If you can contribute the knowhow for EJBs, that would be great -- we just figured web apps were the low hanging fruit for JPA. You make a note about working on an OpenJPA provider, which makes me wonder. The way a JPA provider is plugged in is standard, so you shouldn't need to write support for a particular provider. Any details on why that would be required in the code you're working on? Form a user perspective, it's mainly the necessary configuration options and documentation. But on the back end, I expect there's going to be one JPA plugin with the core logic, and then separate ones for each provider that set up the class path for that provider and register with the main JPA plugin. We haven't yet worked out that part, but to give a trivial example, Hibernate dies with some kind of XML gripe if we just add it as a dependency of the current JPA plugin and try to use it. So there's going to be some amount of work to get each provider fully integrated as far as I can tell. Regardless, I'm glad I'm not the only one working on this :) I'll get our code onto SourceForge soon, so this can be a less theoretical discussion. :) In the mean time, have you had any better ideas as to how to read the persistence.xml and write GBeans into the web app than to reload and rewrite the serialized Configuration after the main web app deployer finishes? Thanks, Aaron
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
David Blevins wrote: On Aug 8, 2006, at 12:22 PM, Jeff Genender wrote: Aaron, Please look at the openejb3-persistence module as it does a majority of what you described below... 1) Takes a classloader 2) looks for persistence.xml files 3) parses found persistence.xml files 4) Creates EntityManagerFactories based on the persistence.xml file specifications. 5) Loads it into JNDI So all you really need to so is provide the classloader and it will handle the rest. It may need some tweaking, but it should put you in the ballpark of what you need. Heads up, going to use all this code. Likely going to split up the PersistenceDeployer class to delay the data source lookup and EntityManagerFactory creation till someone tries to lookup it up from JNDI. Basically what I described in my previous email. Sounds like a good way to handle it. Jeff -David You can find the code here: http://svn.codehaus.org/openejb/trunk/openejb3/container/openejb-persistence/ Jeff Aaron Mulder wrote: On 8/8/06, David Blevins [EMAIL PROTECTED] wrote: What approach are you taking to get this done? I was thinking to do App-managed EntityManagers, the EntityManagerFactories looked up through JNDI, and available to both web apps and ejbs. First of all, the work I'm doing on this is mostly helping with the Geronimo integration... so I'm praying my JPA answers are sensible. :) So far the idea is to put an EntityManagerFactory in JNDI for each persistence unit at java:comp/env/jpa/(persistence-unit-name) . The problem is that every component type in Geronimo uses a different GBean and attribute to hold the JNDI context. It turns out that Jetty and Tomcat both use the same attribute name on the WebModule implementation, which makes that easy. If you can contribute the knowhow for EJBs, that would be great -- we just figured web apps were the low hanging fruit for JPA. You make a note about working on an OpenJPA provider, which makes me wonder. The way a JPA provider is plugged in is standard, so you shouldn't need to write support for a particular provider. Any details on why that would be required in the code you're working on? Form a user perspective, it's mainly the necessary configuration options and documentation. But on the back end, I expect there's going to be one JPA plugin with the core logic, and then separate ones for each provider that set up the class path for that provider and register with the main JPA plugin. We haven't yet worked out that part, but to give a trivial example, Hibernate dies with some kind of XML gripe if we just add it as a dependency of the current JPA plugin and try to use it. So there's going to be some amount of work to get each provider fully integrated as far as I can tell. Regardless, I'm glad I'm not the only one working on this :) I'll get our code onto SourceForge soon, so this can be a less theoretical discussion. :) In the mean time, have you had any better ideas as to how to read the persistence.xml and write GBeans into the web app than to reload and rewrite the serialized Configuration after the main web app deployer finishes? Thanks, Aaron
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
On Aug 8, 2006, at 11:52 AM, Aaron Mulder wrote: So far the idea is to put an EntityManagerFactory in JNDI for each persistence unit at java:comp/env/jpa/(persistence-unit-name) . The problem is that every component type in Geronimo uses a different GBean and attribute to hold the JNDI context. So check this idea out -- you'll flip. What if we use the context.xml to override the class that registers the root java: jndi provider :) Dain and I were going back and forth on what would be the easiest way to slice in something that could also work for 1.1.x and that was the best we came up with. You basically override the jndi provider with one that will first check for objects that are java:comp/jpa/(persistence-unit-name) and delegate that to the special JPA plugin functionality. Notice I've used java:comp/jpa instead of java:comp/env/jpa. The idea being that it's a global thing and not specific to an ENC of a component. This new JNDI provider would not be JPA specific either, it would require a reference collection of things that implemented javax.naming.Context or perhaps as an alternate javax.naming.spi.ObjectFactory. You could actually register a hole bunch of them and add all sorts of extended jndi ability via other gbeans and plugins. -David
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
Weird, but possible, I guess. :) Thanks, Aaron On 8/11/06, David Blevins [EMAIL PROTECTED] wrote: So check this idea out -- you'll flip. What if we use the context.xml to override the class that registers the root java: jndi provider :) Dain and I were going back and forth on what would be the easiest way to slice in something that could also work for 1.1.x and that was the best we came up with. You basically override the jndi provider with one that will first check for objects that are java:comp/jpa/(persistence-unit-name) and delegate that to the special JPA plugin functionality. Notice I've used java:comp/jpa instead of java:comp/env/jpa. The idea being that it's a global thing and not specific to an ENC of a component. This new JNDI provider would not be JPA specific either, it would require a reference collection of things that implemented javax.naming.Context or perhaps as an alternate javax.naming.spi.ObjectFactory. You could actually register a hole bunch of them and add all sorts of extended jndi ability via other gbeans and plugins. -David
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
So what happens if an EJB JAR has a persistence.xml and a web app in the same EAR has a separate persistence.xml? If we just look in the class loader, when we go to deploy the web app, we'll see them both because the EJB JAR is added to the parent classpath of the WAR. Is there a good way to distinguish resource in my ClassLoader from resources in my ClassLoader tree? Thanks, Aaron
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
Isn't this the same problem we (and other app servers) have with Spring and Commons Logging? If you are duplicating the persistence units, then it should be handled the same way its handled for Spring, yes? Aaron Mulder wrote: So what happens if an EJB JAR has a persistence.xml and a web app in the same EAR has a separate persistence.xml? If we just look in the class loader, when we go to deploy the web app, we'll see them both because the EJB JAR is added to the parent classpath of the WAR. Is there a good way to distinguish resource in my ClassLoader from resources in my ClassLoader tree? Thanks, Aaron
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
On 8/11/06, Jeff Genender [EMAIL PROTECTED] wrote: Isn't this the same problem we (and other app servers) have with Spring and Commons Logging? If you are duplicating the persistence units, then it should be handled the same way its handled for Spring, yes? What way is that? Thanks, Aaron Aaron Mulder wrote: So what happens if an EJB JAR has a persistence.xml and a web app in the same EAR has a separate persistence.xml? If we just look in the class loader, when we go to deploy the web app, we'll see them both because the EJB JAR is added to the parent classpath of the WAR. Is there a good way to distinguish resource in my ClassLoader from resources in my ClassLoader tree? Thanks, Aaron
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
Aaron Mulder wrote: On 8/11/06, Jeff Genender [EMAIL PROTECTED] wrote: Isn't this the same problem we (and other app servers) have with Spring and Commons Logging? If you are duplicating the persistence units, then it should be handled the same way its handled for Spring, yes? What way is that? Server -- EAR -- WAR Based upon the delegation model, the version of Commons Logging or Spring was utilized at the Server or EAR level if it existed. The issue was that the Spring calls would utilize the Server/EAR (since already loaded) and the WAR calls would get CNFEs since the server/EAR had no downward view into the WAR. Thus our reason to play with the filtering of classes for modules. With regard to duplicating PUs, in theory, it shouldn't make a difference if the PU was already loaded in a parent loader. But unless the spi jar uses some sort of mechanism using static declarations or componanents like Spring, then it really shouldn't be an issue. If it is, I think its reasonable to claim storage of duplicate PUs in the same package causing the problem (again, like the Spring Commons Logging problem). Thanks, Aaron Aaron Mulder wrote: So what happens if an EJB JAR has a persistence.xml and a web app in the same EAR has a separate persistence.xml? If we just look in the class loader, when we go to deploy the web app, we'll see them both because the EJB JAR is added to the parent classpath of the WAR. Is there a good way to distinguish resource in my ClassLoader from resources in my ClassLoader tree? Thanks, Aaron
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
On 8/11/06, Jeff Genender [EMAIL PROTECTED] wrote: With regard to duplicating PUs, in theory, it shouldn't make a difference if the PU was already loaded in a parent loader. I think it does. The web app is not necessarily supposed to see JPA configurations in an EJB JAR, only JPA configurations at the EAR level. And I don't think we have a way to distinguish between the two. Further, I don't think we'd want the web app to do it's own processing of a persistence.xml at the EAR level -- I think we'd want the EAR to do the processing and just expose that common JPA configuration to the web app (the spec is pretty clear on that). Whereas if the persistence.xml is in the web app, it should do all the JPA processing as part of the web app deployment. So I think that somehow we'd like a web app to be able to discriminate between persistence.xml in me (do lots of deployment processing), persistence.xml in my EAR (use shared configuration), and persistence.xml in other modules in the EAR that happen to have been merged into the EAR ClassLoader (ignore). Thanks, Aaron But unless the spi jar uses some sort of mechanism using static declarations or componanents like Spring, then it really shouldn't be an issue. If it is, I think its reasonable to claim storage of duplicate PUs in the same package causing the problem (again, like the Spring Commons Logging problem). Thanks, Aaron Aaron Mulder wrote: So what happens if an EJB JAR has a persistence.xml and a web app in the same EAR has a separate persistence.xml? If we just look in the class loader, when we go to deploy the web app, we'll see them both because the EJB JAR is added to the parent classpath of the WAR. Is there a good way to distinguish resource in my ClassLoader from resources in my ClassLoader tree? Thanks, Aaron
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
Aaron Mulder wrote: On 8/11/06, Jeff Genender [EMAIL PROTECTED] wrote: With regard to duplicating PUs, in theory, it shouldn't make a difference if the PU was already loaded in a parent loader. I think it does. The web app is not necessarily supposed to see JPA configurations in an EJB JAR, only JPA configurations at the EAR level. And I don't think we have a way to distinguish between the two. Further, I don't think we'd want the web app to do it's own processing of a persistence.xml at the EAR level -- I think we'd want the EAR to do the processing and just expose that common JPA configuration to the web app (the spec is pretty clear on that). Whereas if the persistence.xml is in the web app, it should do all the JPA processing as part of the web app deployment. So I think that somehow we'd like a web app to be able to discriminate between persistence.xml in me (do lots of deployment processing), persistence.xml in my EAR (use shared configuration), and persistence.xml in other modules in the EAR that happen to have been merged into the EAR ClassLoader (ignore). Ok, I understand where you are going with this. I totally agree with your thinking here. But...IIUC...in the web app, if you are including your own PU, you likely wouldn't be using the JNDI (and thus the container) for this and would be declaring use of the spi bootstrap directly: EntityManagerFactory emf = Persistence.createEntityManagerFactory(mywebpersistenceunit) And when using the EJB, you would call the JNDI. Therefore, I don't think this is a problem at all. Thanks, Aaron But unless the spi jar uses some sort of mechanism using static declarations or componanents like Spring, then it really shouldn't be an issue. If it is, I think its reasonable to claim storage of duplicate PUs in the same package causing the problem (again, like the Spring Commons Logging problem). Thanks, Aaron Aaron Mulder wrote: So what happens if an EJB JAR has a persistence.xml and a web app in the same EAR has a separate persistence.xml? If we just look in the class loader, when we go to deploy the web app, we'll see them both because the EJB JAR is added to the parent classpath of the WAR. Is there a good way to distinguish resource in my ClassLoader from resources in my ClassLoader tree? Thanks, Aaron
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
On 8/11/06, Jeff Genender [EMAIL PROTECTED] wrote: Ok, I understand where you are going with this. I totally agree with your thinking here. But...IIUC...in the web app, if you are including your own PU, you likely wouldn't be using the JNDI (and thus the container) for this and would be declaring use of the spi bootstrap directly: EntityManagerFactory emf = Persistence.createEntityManagerFactory(mywebpersistenceunit) But with the plugin we're working on, you can look up app-managed EntityManagerFactories in JNDI. Even without JNDI, we'd have to intercept the process to connect the EMF to the DataSource named in persistence.xml. So when you deploy a web app, we look for a persistence.xml in order to read all the settings, connect the web app to the data source and the JPA provider in question, and add the EntityManagerFactories to JNDI. Actually, I'm pretty sure the spec gives examples of a stateless session bean using app-managed EMFs and they're injected not looked up the way you're saying. I think that's only for Java SE clients. At this moment it won't be a problem, since the plugin only supports web apps, but with Blevins' expertise it should be easy enough to support EJB JARs too. Eventually we'll need to get clever -- perhaps detecting that correctly-named JPA GBeans already exist in the parent tree so it's not necessary to redefine them for the web app. In fact, that's probably the way to go. Thanks, Aaron And when using the EJB, you would call the JNDI. Therefore, I don't think this is a problem at all. Thanks, Aaron But unless the spi jar uses some sort of mechanism using static declarations or componanents like Spring, then it really shouldn't be an issue. If it is, I think its reasonable to claim storage of duplicate PUs in the same package causing the problem (again, like the Spring Commons Logging problem). Thanks, Aaron Aaron Mulder wrote: So what happens if an EJB JAR has a persistence.xml and a web app in the same EAR has a separate persistence.xml? If we just look in the class loader, when we go to deploy the web app, we'll see them both because the EJB JAR is added to the parent classpath of the WAR. Is there a good way to distinguish resource in my ClassLoader from resources in my ClassLoader tree? Thanks, Aaron
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
Aaron Mulder wrote: On 8/11/06, Jeff Genender [EMAIL PROTECTED] wrote: Ok, I understand where you are going with this. I totally agree with your thinking here. But...IIUC...in the web app, if you are including your own PU, you likely wouldn't be using the JNDI (and thus the container) for this and would be declaring use of the spi bootstrap directly: EntityManagerFactory emf = Persistence.createEntityManagerFactory(mywebpersistenceunit) But with the plugin we're working on, you can look up app-managed EntityManagerFactories in JNDI. Even without JNDI, we'd have to intercept the process to connect the EMF to the DataSource named in persistence.xml. So when you deploy a web app, we look for a persistence.xml in order to read all the settings, connect the web app to the data source and the JPA provider in question, and add the EntityManagerFactories to JNDI. Actually, I'm pretty sure the spec gives examples of a stateless session bean using app-managed EMFs and they're injected not looked up the way you're saying. I think that's only for Java SE clients. Correct...but the spec is assuming a container. My point was...if you included a PU as part of a war, then clearly its not an EJB deployment...thus what is the use for JNDI storage? You could manually store it, but why? IIRC, the injection was for the container...and if used in a stand alone web app (thus assuming JNDI), your access to a war contained PU would be via the spi. At this moment it won't be a problem, since the plugin only supports web apps, but with Blevins' expertise it should be easy enough to support EJB JARs too. Eventually we'll need to get clever -- perhaps detecting that correctly-named JPA GBeans already exist in the parent tree so it's not necessary to redefine them for the web app. In fact, that's probably the way to go. Right...I see the issue being more of a GBean issue at the end of the day, so I get where you are coming from. Thanks, Aaron And when using the EJB, you would call the JNDI. Therefore, I don't think this is a problem at all. Thanks, Aaron But unless the spi jar uses some sort of mechanism using static declarations or componanents like Spring, then it really shouldn't be an issue. If it is, I think its reasonable to claim storage of duplicate PUs in the same package causing the problem (again, like the Spring Commons Logging problem). Thanks, Aaron Aaron Mulder wrote: So what happens if an EJB JAR has a persistence.xml and a web app in the same EAR has a separate persistence.xml? If we just look in the class loader, when we go to deploy the web app, we'll see them both because the EJB JAR is added to the parent classpath of the WAR. Is there a good way to distinguish resource in my ClassLoader from resources in my ClassLoader tree? Thanks, Aaron
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
Personally, I'm happy that Aaron still wants to work on Geronimo at all. If he wants to work out on SourceForge, that's really his decision no matter what the reasons. I don't see an upside to pushing the topic. As long as he doesn't get upset that others are working on potentially the same thing inside Geronimo, then we're in good shape. Hey Aaron, I'm going to start a branch tomorrow to experiment with JPA stuff, you and your crew are obviously welcome to play in my sandbox :) Regardless, I really like the discussion we're having -- helps keep me focused and I like comparing notes. Best case scenario, we end up with some excellent JPA functionality for 1.1 and 1.2 as well as plugins for ASL and GPL JPA providers. These are things users need badly. Good goals. -David On Aug 8, 2006, at 10:34 PM, Kevan Miller wrote: Aaron, 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 [EMAIL PROTECTED] wrote: On Aug 8, 2006, at 3:47 PM, Aaron Mulder wrote: On 8/8/06, David Blevins [EMAIL PROTECTED] 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 geronimo.apache.org, 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
JPA plugin (was Re: Java 1.4 and JEE 5)
On Aug 8, 2006, at 11:10 AM, Aaron Mulder wrote: On 8/8/06, David Blevins [EMAIL PROTECTED] wrote: I'm hacking away at some way to allow people to use OpenJPA in their apps -- don't know how that will turnout just yet -- and was thinking a plugin would be best for that as it wouldn't force Geronimo to go JDK 1.5. We're working on a plugin that adds JPA support to web apps (assuming you started Geronimo in Java 5). If you can help with the OpenJPA provider, that would be great. I think there should be something to show for this soon. I'm eagerly awating Jason's fix to the car-maven-plugin so we can pop a plugin out of a Maven build. :) What approach are you taking to get this done? I was thinking to do App-managed EntityManagers, the EntityManagerFactories looked up through JNDI, and available to both web apps and ejbs. You make a note about working on an OpenJPA provider, which makes me wonder. The way a JPA provider is plugged in is standard, so you shouldn't need to write support for a particular provider. Any details on why that would be required in the code you're working on? Regardless, I'm glad I'm not the only one working on this :) -David
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
Can't speak for Aaron, but I guess this is not so much the code referencing provider-specific API, but configuration including provider jars... ant testing that it works of course :-) Andrus On Aug 8, 2006, at 2:26 PM, David Blevins wrote: On Aug 8, 2006, at 11:10 AM, Aaron Mulder wrote: On 8/8/06, David Blevins [EMAIL PROTECTED] wrote: I'm hacking away at some way to allow people to use OpenJPA in their apps -- don't know how that will turnout just yet -- and was thinking a plugin would be best for that as it wouldn't force Geronimo to go JDK 1.5. We're working on a plugin that adds JPA support to web apps (assuming you started Geronimo in Java 5). If you can help with the OpenJPA provider, that would be great. I think there should be something to show for this soon. I'm eagerly awating Jason's fix to the car-maven-plugin so we can pop a plugin out of a Maven build. :) What approach are you taking to get this done? I was thinking to do App-managed EntityManagers, the EntityManagerFactories looked up through JNDI, and available to both web apps and ejbs. You make a note about working on an OpenJPA provider, which makes me wonder. The way a JPA provider is plugged in is standard, so you shouldn't need to write support for a particular provider. Any details on why that would be required in the code you're working on? Regardless, I'm glad I'm not the only one working on this :) -David
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
On 8/8/06, David Blevins [EMAIL PROTECTED] wrote: What approach are you taking to get this done? I was thinking to do App-managed EntityManagers, the EntityManagerFactories looked up through JNDI, and available to both web apps and ejbs. First of all, the work I'm doing on this is mostly helping with the Geronimo integration... so I'm praying my JPA answers are sensible. :) So far the idea is to put an EntityManagerFactory in JNDI for each persistence unit at java:comp/env/jpa/(persistence-unit-name) . The problem is that every component type in Geronimo uses a different GBean and attribute to hold the JNDI context. It turns out that Jetty and Tomcat both use the same attribute name on the WebModule implementation, which makes that easy. If you can contribute the knowhow for EJBs, that would be great -- we just figured web apps were the low hanging fruit for JPA. You make a note about working on an OpenJPA provider, which makes me wonder. The way a JPA provider is plugged in is standard, so you shouldn't need to write support for a particular provider. Any details on why that would be required in the code you're working on? Form a user perspective, it's mainly the necessary configuration options and documentation. But on the back end, I expect there's going to be one JPA plugin with the core logic, and then separate ones for each provider that set up the class path for that provider and register with the main JPA plugin. We haven't yet worked out that part, but to give a trivial example, Hibernate dies with some kind of XML gripe if we just add it as a dependency of the current JPA plugin and try to use it. So there's going to be some amount of work to get each provider fully integrated as far as I can tell. Regardless, I'm glad I'm not the only one working on this :) I'll get our code onto SourceForge soon, so this can be a less theoretical discussion. :) In the mean time, have you had any better ideas as to how to read the persistence.xml and write GBeans into the web app than to reload and rewrite the serialized Configuration after the main web app deployer finishes? Thanks, Aaron
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
I forgot to mention -- it seems that every JPA provider has been compiled against a different version of the JPA spec, which is a little obnoxious. :) Thanks, Aaron On 8/8/06, Aaron Mulder [EMAIL PROTECTED] wrote: On 8/8/06, David Blevins [EMAIL PROTECTED] wrote: What approach are you taking to get this done? I was thinking to do App-managed EntityManagers, the EntityManagerFactories looked up through JNDI, and available to both web apps and ejbs. First of all, the work I'm doing on this is mostly helping with the Geronimo integration... so I'm praying my JPA answers are sensible. :) So far the idea is to put an EntityManagerFactory in JNDI for each persistence unit at java:comp/env/jpa/(persistence-unit-name) . The problem is that every component type in Geronimo uses a different GBean and attribute to hold the JNDI context. It turns out that Jetty and Tomcat both use the same attribute name on the WebModule implementation, which makes that easy. If you can contribute the knowhow for EJBs, that would be great -- we just figured web apps were the low hanging fruit for JPA. You make a note about working on an OpenJPA provider, which makes me wonder. The way a JPA provider is plugged in is standard, so you shouldn't need to write support for a particular provider. Any details on why that would be required in the code you're working on? Form a user perspective, it's mainly the necessary configuration options and documentation. But on the back end, I expect there's going to be one JPA plugin with the core logic, and then separate ones for each provider that set up the class path for that provider and register with the main JPA plugin. We haven't yet worked out that part, but to give a trivial example, Hibernate dies with some kind of XML gripe if we just add it as a dependency of the current JPA plugin and try to use it. So there's going to be some amount of work to get each provider fully integrated as far as I can tell. Regardless, I'm glad I'm not the only one working on this :) I'll get our code onto SourceForge soon, so this can be a less theoretical discussion. :) In the mean time, have you had any better ideas as to how to read the persistence.xml and write GBeans into the web app than to reload and rewrite the serialized Configuration after the main web app deployer finishes? Thanks, Aaron
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
Aaron, Please look at the openejb3-persistence module as it does a majority of what you described below... 1) Takes a classloader 2) looks for persistence.xml files 3) parses found persistence.xml files 4) Creates EntityManagerFactories based on the persistence.xml file specifications. 5) Loads it into JNDI So all you really need to so is provide the classloader and it will handle the rest. It may need some tweaking, but it should put you in the ballpark of what you need. You can find the code here: http://svn.codehaus.org/openejb/trunk/openejb3/container/openejb-persistence/ Jeff Aaron Mulder wrote: On 8/8/06, David Blevins [EMAIL PROTECTED] wrote: What approach are you taking to get this done? I was thinking to do App-managed EntityManagers, the EntityManagerFactories looked up through JNDI, and available to both web apps and ejbs. First of all, the work I'm doing on this is mostly helping with the Geronimo integration... so I'm praying my JPA answers are sensible. :) So far the idea is to put an EntityManagerFactory in JNDI for each persistence unit at java:comp/env/jpa/(persistence-unit-name) . The problem is that every component type in Geronimo uses a different GBean and attribute to hold the JNDI context. It turns out that Jetty and Tomcat both use the same attribute name on the WebModule implementation, which makes that easy. If you can contribute the knowhow for EJBs, that would be great -- we just figured web apps were the low hanging fruit for JPA. You make a note about working on an OpenJPA provider, which makes me wonder. The way a JPA provider is plugged in is standard, so you shouldn't need to write support for a particular provider. Any details on why that would be required in the code you're working on? Form a user perspective, it's mainly the necessary configuration options and documentation. But on the back end, I expect there's going to be one JPA plugin with the core logic, and then separate ones for each provider that set up the class path for that provider and register with the main JPA plugin. We haven't yet worked out that part, but to give a trivial example, Hibernate dies with some kind of XML gripe if we just add it as a dependency of the current JPA plugin and try to use it. So there's going to be some amount of work to get each provider fully integrated as far as I can tell. Regardless, I'm glad I'm not the only one working on this :) I'll get our code onto SourceForge soon, so this can be a less theoretical discussion. :) In the mean time, have you had any better ideas as to how to read the persistence.xml and write GBeans into the web app than to reload and rewrite the serialized Configuration after the main web app deployer finishes? Thanks, Aaron
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
Is that code in the incubator at Apache now? Jeff Genender wrote: Aaron, Please look at the openejb3-persistence module as it does a majority of what you described below... 1) Takes a classloader 2) looks for persistence.xml files 3) parses found persistence.xml files 4) Creates EntityManagerFactories based on the persistence.xml file specifications. 5) Loads it into JNDI So all you really need to so is provide the classloader and it will handle the rest. It may need some tweaking, but it should put you in the ballpark of what you need. You can find the code here: http://svn.codehaus.org/openejb/trunk/openejb3/container/openejb-persistence/ Jeff Aaron Mulder wrote: On 8/8/06, David Blevins [EMAIL PROTECTED] wrote: What approach are you taking to get this done? I was thinking to do App-managed EntityManagers, the EntityManagerFactories looked up through JNDI, and available to both web apps and ejbs. First of all, the work I'm doing on this is mostly helping with the Geronimo integration... so I'm praying my JPA answers are sensible. :) So far the idea is to put an EntityManagerFactory in JNDI for each persistence unit at java:comp/env/jpa/(persistence-unit-name) . The problem is that every component type in Geronimo uses a different GBean and attribute to hold the JNDI context. It turns out that Jetty and Tomcat both use the same attribute name on the WebModule implementation, which makes that easy. If you can contribute the knowhow for EJBs, that would be great -- we just figured web apps were the low hanging fruit for JPA. You make a note about working on an OpenJPA provider, which makes me wonder. The way a JPA provider is plugged in is standard, so you shouldn't need to write support for a particular provider. Any details on why that would be required in the code you're working on? Form a user perspective, it's mainly the necessary configuration options and documentation. But on the back end, I expect there's going to be one JPA plugin with the core logic, and then separate ones for each provider that set up the class path for that provider and register with the main JPA plugin. We haven't yet worked out that part, but to give a trivial example, Hibernate dies with some kind of XML gripe if we just add it as a dependency of the current JPA plugin and try to use it. So there's going to be some amount of work to get each provider fully integrated as far as I can tell. Regardless, I'm glad I'm not the only one working on this :) I'll get our code onto SourceForge soon, so this can be a less theoretical discussion. :) In the mean time, have you had any better ideas as to how to read the persistence.xml and write GBeans into the web app than to reload and rewrite the serialized Configuration after the main web app deployer finishes? Thanks, Aaron
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
Unfortunately, that code is not particularly applicable to Geronimo 1.1 web applications. Just to give a tiny example, a web app never has an InitialContext to store JNDI data, only a Map. I'm guessing you also have some special hooking during EJB deployment to invoke the PersistenceDeployer, and there are no such hooks that I'm aware of in Geronimo 1.1. Anyway, the remaining issues are not to do with the steps you described, they're mainly to do with things like the best way to hook into the web app deployment sequence (working, but not too pretty) and handling dynamic registration of providers (not implemented yet). Thanks, Aaron On 8/8/06, Jeff Genender [EMAIL PROTECTED] wrote: Aaron, Please look at the openejb3-persistence module as it does a majority of what you described below... 1) Takes a classloader 2) looks for persistence.xml files 3) parses found persistence.xml files 4) Creates EntityManagerFactories based on the persistence.xml file specifications. 5) Loads it into JNDI So all you really need to so is provide the classloader and it will handle the rest. It may need some tweaking, but it should put you in the ballpark of what you need. You can find the code here: http://svn.codehaus.org/openejb/trunk/openejb3/container/openejb-persistence/ Jeff Aaron Mulder wrote: On 8/8/06, David Blevins [EMAIL PROTECTED] wrote: What approach are you taking to get this done? I was thinking to do App-managed EntityManagers, the EntityManagerFactories looked up through JNDI, and available to both web apps and ejbs. First of all, the work I'm doing on this is mostly helping with the Geronimo integration... so I'm praying my JPA answers are sensible. :) So far the idea is to put an EntityManagerFactory in JNDI for each persistence unit at java:comp/env/jpa/(persistence-unit-name) . The problem is that every component type in Geronimo uses a different GBean and attribute to hold the JNDI context. It turns out that Jetty and Tomcat both use the same attribute name on the WebModule implementation, which makes that easy. If you can contribute the knowhow for EJBs, that would be great -- we just figured web apps were the low hanging fruit for JPA. You make a note about working on an OpenJPA provider, which makes me wonder. The way a JPA provider is plugged in is standard, so you shouldn't need to write support for a particular provider. Any details on why that would be required in the code you're working on? Form a user perspective, it's mainly the necessary configuration options and documentation. But on the back end, I expect there's going to be one JPA plugin with the core logic, and then separate ones for each provider that set up the class path for that provider and register with the main JPA plugin. We haven't yet worked out that part, but to give a trivial example, Hibernate dies with some kind of XML gripe if we just add it as a dependency of the current JPA plugin and try to use it. So there's going to be some amount of work to get each provider fully integrated as far as I can tell. Regardless, I'm glad I'm not the only one working on this :) I'll get our code onto SourceForge soon, so this can be a less theoretical discussion. :) In the mean time, have you had any better ideas as to how to read the persistence.xml and write GBeans into the web app than to reload and rewrite the serialized Configuration after the main web app deployer finishes? Thanks, Aaron
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
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. More bellow... but in a different order. On Aug 8, 2006, at 11:52 AM, Aaron Mulder wrote: In the mean time, have you had any better ideas as to how to read the persistence.xml and write GBeans into the web app than to reload and rewrite the serialized Configuration after the main web app deployer finishes? 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. So far the idea is to put an EntityManagerFactory in JNDI for each persistence unit at java:comp/env/jpa/(persistence-unit-name) . The problem is that every component type in Geronimo uses a different GBean and attribute to hold the JNDI context. It turns out that Jetty and Tomcat both use the same attribute name on the WebModule implementation, which makes that easy. If you can contribute the knowhow for EJBs, that would be great -- we just figured web apps were the low hanging fruit for JPA. 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 Form a user perspective, it's mainly the necessary configuration options and documentation. But on the back end, I expect there's going to be one JPA plugin with the core logic, and then separate ones for each provider that set up the class path for that provider and register with the main JPA plugin. 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. -David
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
On Aug 8, 2006, at 12:23 PM, Matt Hogstrom wrote: Is that code in the incubator at Apache now? /me hopes matt knew the answer to that question when he did an OpenEJB release yesterday :) Jeff Genender wrote: Aaron, Please look at the openejb3-persistence module as it does a majority of what you described below... 1) Takes a classloader 2) looks for persistence.xml files 3) parses found persistence.xml files 4) Creates EntityManagerFactories based on the persistence.xml file specifications. 5) Loads it into JNDI So all you really need to so is provide the classloader and it will handle the rest. It may need some tweaking, but it should put you in the ballpark of what you need. You can find the code here: http://svn.codehaus.org/openejb/trunk/openejb3/container/openejb- persistence/ Jeff Aaron Mulder wrote: On 8/8/06, David Blevins [EMAIL PROTECTED] wrote: What approach are you taking to get this done? I was thinking to do App-managed EntityManagers, the EntityManagerFactories looked up through JNDI, and available to both web apps and ejbs. First of all, the work I'm doing on this is mostly helping with the Geronimo integration... so I'm praying my JPA answers are sensible. :) So far the idea is to put an EntityManagerFactory in JNDI for each persistence unit at java:comp/env/jpa/(persistence-unit-name) . The problem is that every component type in Geronimo uses a different GBean and attribute to hold the JNDI context. It turns out that Jetty and Tomcat both use the same attribute name on the WebModule implementation, which makes that easy. If you can contribute the knowhow for EJBs, that would be great -- we just figured web apps were the low hanging fruit for JPA. You make a note about working on an OpenJPA provider, which makes me wonder. The way a JPA provider is plugged in is standard, so you shouldn't need to write support for a particular provider. Any details on why that would be required in the code you're working on? Form a user perspective, it's mainly the necessary configuration options and documentation. But on the back end, I expect there's going to be one JPA plugin with the core logic, and then separate ones for each provider that set up the class path for that provider and register with the main JPA plugin. We haven't yet worked out that part, but to give a trivial example, Hibernate dies with some kind of XML gripe if we just add it as a dependency of the current JPA plugin and try to use it. So there's going to be some amount of work to get each provider fully integrated as far as I can tell. Regardless, I'm glad I'm not the only one working on this :) I'll get our code onto SourceForge soon, so this can be a less theoretical discussion. :) In the mean time, have you had any better ideas as to how to read the persistence.xml and write GBeans into the web app than to reload and rewrite the serialized Configuration after the main web app deployer finishes? Thanks, Aaron
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
On 8/8/06, David Blevins [EMAIL PROTECTED] 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. 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
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
:) David Blevins wrote: On Aug 8, 2006, at 12:23 PM, Matt Hogstrom wrote: Is that code in the incubator at Apache now? /me hopes matt knew the answer to that question when he did an OpenEJB release yesterday :) Jeff Genender wrote: Aaron, Please look at the openejb3-persistence module as it does a majority of what you described below... 1) Takes a classloader 2) looks for persistence.xml files 3) parses found persistence.xml files 4) Creates EntityManagerFactories based on the persistence.xml file specifications. 5) Loads it into JNDI So all you really need to so is provide the classloader and it will handle the rest. It may need some tweaking, but it should put you in the ballpark of what you need. You can find the code here: http://svn.codehaus.org/openejb/trunk/openejb3/container/openejb-persistence/ Jeff Aaron Mulder wrote: On 8/8/06, David Blevins [EMAIL PROTECTED] wrote: What approach are you taking to get this done? I was thinking to do App-managed EntityManagers, the EntityManagerFactories looked up through JNDI, and available to both web apps and ejbs. First of all, the work I'm doing on this is mostly helping with the Geronimo integration... so I'm praying my JPA answers are sensible. :) So far the idea is to put an EntityManagerFactory in JNDI for each persistence unit at java:comp/env/jpa/(persistence-unit-name) . The problem is that every component type in Geronimo uses a different GBean and attribute to hold the JNDI context. It turns out that Jetty and Tomcat both use the same attribute name on the WebModule implementation, which makes that easy. If you can contribute the knowhow for EJBs, that would be great -- we just figured web apps were the low hanging fruit for JPA. You make a note about working on an OpenJPA provider, which makes me wonder. The way a JPA provider is plugged in is standard, so you shouldn't need to write support for a particular provider. Any details on why that would be required in the code you're working on? Form a user perspective, it's mainly the necessary configuration options and documentation. But on the back end, I expect there's going to be one JPA plugin with the core logic, and then separate ones for each provider that set up the class path for that provider and register with the main JPA plugin. We haven't yet worked out that part, but to give a trivial example, Hibernate dies with some kind of XML gripe if we just add it as a dependency of the current JPA plugin and try to use it. So there's going to be some amount of work to get each provider fully integrated as far as I can tell. Regardless, I'm glad I'm not the only one working on this :) I'll get our code onto SourceForge soon, so this can be a less theoretical discussion. :) In the mean time, have you had any better ideas as to how to read the persistence.xml and write GBeans into the web app than to reload and rewrite the serialized Configuration after the main web app deployer finishes? Thanks, Aaron
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
On Aug 8, 2006, at 12:47 PM, Aaron Mulder wrote: On 8/8/06, David Blevins [EMAIL PROTECTED] 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. That's cool. Maybe we can still work something out in terms of provider wrappers. Who knows. 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 agree we need a better way, but that's not a feature I plan on working on. 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? Was just going to shove it in every ENC as anything else would require us to start supporting the EJB 3 ejb-jar.xml. 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. You probably don't want to do that. That would only work if the Persistence provider did zero caching. You really can't go swapping out the connections underneath an EntityManager that caches. It is relevant to webapps too as they are allowed to create an EntityManager from the EntityManagerFactory, call begin transaction on it, shove it in to the Session, and pull it out at a later request and call commit on it. -David
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
On Aug 8, 2006, at 1:43 PM, David Blevins wrote: On Aug 8, 2006, at 12:47 PM, Aaron Mulder wrote: On 8/8/06, David Blevins [EMAIL PROTECTED] 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. That's cool. Maybe we can still work something out in terms of provider wrappers. Who knows. 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 agree we need a better way, but that's not a feature I plan on working on. I agree we need something like this. The namespace driven builders in the pluggable jacc patch would probably work for your quartz plugin (i.e. you can put a new namespace/xml into any g. plan in the gbean section and if there's a registered builder for it, it will get picked up). Doing something like this for j2ee supported stuff is a lot harder since you have to deal with 2 sets of xml, at least one of which might not be there at all. The SwitchingModuleBuilder is as far as I've gotten in this direction. 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? Was just going to shove it in every ENC as anything else would require us to start supporting the EJB 3 ejb-jar.xml. 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. You probably don't want to do that. That would only work if the Persistence provider did zero caching. You really can't go swapping out the connections underneath an EntityManager that caches. It is relevant to webapps too as they are allowed to create an EntityManager from the EntityManagerFactory, call begin transaction on it, shove it in to the Session, and pull it out at a later request and call commit on it. I'm don't understand the tx support in jpa yet. To get container managed to work you definitely need the new tx manager interface to get the cache flushed. Maybe theres a way to explicitly flush the jpa cache in which case you could use UserTx around the whole thing. If jpa can actually control tx itself you should be using a no-tx db pool. thanks david jencks -David
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
On 8/8/06, Kevan Miller [EMAIL PROTECTED] wrote: On Aug 8, 2006, at 3:47 PM, Aaron Mulder wrote: On 8/8/06, David Blevins [EMAIL PROTECTED] 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 geronimo.apache.org, 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. 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
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
On Aug 8, 2006, at 2:52 PM, Aaron Mulder wrote: On 8/8/06, Kevan Miller [EMAIL PROTECTED] wrote: On Aug 8, 2006, at 3:47 PM, Aaron Mulder wrote: On 8/8/06, David Blevins [EMAIL PROTECTED] 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? If you want to ultimately bring the code to apache, it is the easiest thing, since it avoids the large legal hurdle later. Working in the sandbox also earns the others you are working with karma with the Geronimo community. On the other hand, it is very difficult to work via patches and can be a serious demotivator. In the end, I want to see this effort be successful, so if the team you are working with can handle patch based development, I'd really encourage you bring the code to the sandbox as soon as possible, if not please bring it later. 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? I don't think there is a clear answer to this, but it is being discussed on the apache legal mailing list. If you are interested, I suggest you bring it up on that list, because this is a clear case of supporting an *optional* GPL based implementation. -dain
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
Aaron, 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 [EMAIL PROTECTED] wrote: On Aug 8, 2006, at 3:47 PM, Aaron Mulder wrote: On 8/8/06, David Blevins [EMAIL PROTECTED] 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 geronimo.apache.org, 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... --kevan 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
