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
