I'll send the CLA, no problem.
We certainly have different overall priorities, so I agree - an
attempt at planning something too reusable seems like a waste of
time. I'll move ahead with the standalone provider code and then
we'll figure out how to integrate it.
Re JAXB2. I was wrong - it has substantial runtime, so it is much
less attractive from Cayenne standpoint. Still I am undecided on that.
So how far along are you guys on implementing JPA.
We are just starting. Cayenne engine supports maybe 80-90% of the
persistence functionality of the spec (it supports things that are
not there, but this is irrelevant for this discussion). Now we are
figuring out the approach to build a compliant JPA facade.
Andrus
On Feb 9, 2006, at 2:04 AM, David Blevins wrote:
On Feb 8, 2006, at 9:35 PM, Andrus Adamchik wrote:
On Feb 8, 2006, at 11:32 PM, David Blevins wrote:
Do you have a jira account? I'll add you to the OpenEJB jira.
Yes, my codehaus Jira id is "andrus".
Great. Just put you in the openejb-contributors group, so we can
now assign stuff to you.
Do you guys have any sort of tests cases for JPA yet?
No. The plan is to develop them in parallel with the
implementation code.
So how far along are you guys on implementing JPA.
Also, somewhat unrelated, what do you do for reading in
deployment descriptors? OpenEJB used to use Castor XML, then we
switched to XMLBeans in Geronimo.
I was thinking maybe JAXB2. One of the first steps will be
reading in a persistence.xml so we can pull out the JPA
PersistenceProvider and create those PersistenceUnitInfo thingies.
Is that something you'd want to work on?
Believe it or not Cayenne is using good old SAX API. Wasn't fun to
write the parser (not that we had much choice in 2001), but it
works and it is very fast.
I believe it. I actually did the same till we moved to sf.net and
set out to redesign how OpenEJB 0.8 - 1.0 work.
This time around I would go with something more fancy. JAXB is
probably a good option (IIRC it doesn't require extra runtime jars
- this is a big plus for the container-less JPA operation).
BTW, persistence.xml is pretty trivial (and doesn't seem to have a
schema in the spec), so a hand-parser would work fine. But the
entity-mapping.xml is much more involved.
Yea, it is. I'd probably just scrape what I want from it too if
were to do it in a container-less environment like you want to do.
can work on that. Since this is the code we would want to reuse
across OpenEJB/Geronimo/Cayenne, we need a separate subproject
that builds a separate small jar. The question is where do we put
it (package name-wise and physical repository). I suggest
"org.objectstyle.cayenne.jpa" and a subproject on codehaus (or I
can set up a repository on ObjectStyle.org).
I'm really more interested in someone getting experience on JAXB2
than reusing the code to marshall a persistence.xml. Specifically,
if it works well I'll want to roll it out instead of xmlbeans for
the other dozen and more deployment descriptors which have four
major versions each as well for our own config files.
I am not yet fully clear on the practical distinctions of the
PersistenceProvider operation within container compared to
standalone, but the plan is that cayenne-jpa.jar will be a full
standalone provider (that includes .par bootstrapping code), and
OpenEJB can extend some of its classes to do container-specific
tricks (and use it as a default provider if needed).
Does it make sense?
I'm more excited about seeing progress than where the code lives.
You could just get started on those details where ever is most
comfortable to you and as long as you are willing to sign a CLA and
submit a few reusable java files, we're good to go on our side. We
can copy/paste reuse and dual license on the parts where there is
slight overlap between ejb container and jpa provider. If that
becomes too hard, we can deal with it then.
If we can get somewhere fast on this, moving support for a JPA
provider into Geronimo 1.x is definitely doable. People would love
to have it.
What do you think?
-David
