You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Jean-Louis MONTEIRO <je...@atosorigin.com> on 2010/03/25 11:47:55 UTC
JPA 2.0 support in OpenEJB
Hi,
I spent some time trying to add JPA 2.0 support in OpenEJB (
https://issues.apache.org/jira/browse/OPENEJB-1236 OPENEJB-1236 ).
Actually, it's just a draft but it seems to work fine ;)
I'd like to have some feedback about the patch attached to the JIRA.
>From my understanding and tests, it works with JPA 1.0 implementation as
well as with JPA 2.0 implementation. Obviously, using JPA 2.0 feature with
an JPA 1.0 implementation will cause errors.
BTW, to play a bit with JPA 2.0, i changed the hibernate 3 sample.
You can have a look and play!
Thanks in advance for the feedback.
Jean-Louis
--
View this message in context: http://n4.nabble.com/JPA-2-0-support-in-OpenEJB-tp1690430p1690430.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: JPA 2.0 support in OpenEJB
Posted by Jean-Louis MONTEIRO <je...@atosorigin.com>.
Nobody got time to have a look?
Jean-Louis
Jean-Louis MONTEIRO wrote:
>
> Hi,
>
> I spent some time trying to add JPA 2.0 support in OpenEJB (
> https://issues.apache.org/jira/browse/OPENEJB-1236 OPENEJB-1236 ).
>
> Actually, it's just a draft but it seems to work fine ;)
> I'd like to have some feedback about the patch attached to the JIRA.
> From my understanding and tests, it works with JPA 1.0 implementation as
> well as with JPA 2.0 implementation. Obviously, using JPA 2.0 feature with
> an JPA 1.0 implementation will cause errors.
>
> BTW, to play a bit with JPA 2.0, i changed the hibernate 3 sample.
> You can have a look and play!
>
> Thanks in advance for the feedback.
> Jean-Louis
>
>
>
--
View this message in context: http://n4.nabble.com/JPA-2-0-support-in-OpenEJB-tp1690430p1836763.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: Code formatting
Posted by dsh <da...@googlemail.com>.
If you want Eclipse to not reformat the source code while saving a
file you have to de-activate Save Actions under Window > Preferences >
Java > Editor > Save Actions. Or just use a Eclipse code template that
matches the proposed style :)
Cheers
Daniel
On Fri, Sep 17, 2010 at 10:49 PM, David Blevins <da...@visi.com> wrote:
>
> On Sep 16, 2010, at 1:36 PM, Andy wrote:
>
>>>
>> Thanks people - I will go through and reformat anything I have touched.
>
> Cool. Also an FYI that we use two spaces in the xml docs rather than 4.
>
> As a matter of style I tend to try not to reformat with actual code changes, just so people can actually see the real change. Sometime's I'll quick reformat something and check it in with a simple "reformatted" comment before digging in and doing the real work.
>
> Love to see all the activity. This is great!
>
>
> -David
>
>
>
Re: Code formatting
Posted by David Blevins <da...@visi.com>.
On Sep 16, 2010, at 1:36 PM, Andy wrote:
>>
> Thanks people - I will go through and reformat anything I have touched.
Cool. Also an FYI that we use two spaces in the xml docs rather than 4.
As a matter of style I tend to try not to reformat with actual code changes, just so people can actually see the real change. Sometime's I'll quick reformat something and check it in with a simple "reformatted" comment before digging in and doing the real work.
Love to see all the activity. This is great!
-David
Re: Code formatting
Posted by Andy <an...@orprovision.com>.
On 16.09.2010 17:07, Karan Malhi wrote:
> Also discussed here
> http://www.mail-archive.com/openejb-dev@incubator.apache.org/msg01231.html
>
> On Thu, Sep 16, 2010 at 10:59 AM, Mohammad Nour El-Din<
> nour.mohammad@gmail.com> wrote:
>
>> Hi Andy...
>>
>> This issue has been discussed in this thread
>> http://marc.info/?l=openejb-development&m=122420938019348&w=2 .
>>
>> On Thu, Sep 16, 2010 at 9:36 AM, Andy<an...@orprovision.com>
>> wrote:
>>> Hi All,
>>>
>>> Do we have any standard source code formatting rules anywhere?
>>>
>>> I am using Netbeans default formatting, but this may not be to everyone's
>>> taste.
>>>
>>> Regards,
>>>
>>> Andy
>>>
>>>
>>
>>
>> --
>> Thanks
>> - Mohammad Nour
>> Author of (WebSphere Application Server Community Edition 2.0 User Guide)
>> http://www.redbooks.ibm.com/abstracts/sg247585.html
>> - LinkedIn: http://www.linkedin.com/in/mnour
>> - Blog: http://tadabborat.blogspot.com
>> ----
>> "Life is like riding a bicycle. To keep your balance you must keep moving"
>> - Albert Einstein
>>
>> "Writing clean code is what you must do in order to call yourself a
>> professional. There is no reasonable excuse for doing anything less
>> than your best."
>> - Clean Code: A Handbook of Agile Software Craftsmanship
>>
>> "Stay hungry, stay foolish."
>> - Steve Jobs
>>
>
>
Thanks people - I will go through and reformat anything I have touched.
Re: Code formatting
Posted by Karan Malhi <ka...@gmail.com>.
Also discussed here
http://www.mail-archive.com/openejb-dev@incubator.apache.org/msg01231.html
On Thu, Sep 16, 2010 at 10:59 AM, Mohammad Nour El-Din <
nour.mohammad@gmail.com> wrote:
> Hi Andy...
>
> This issue has been discussed in this thread
> http://marc.info/?l=openejb-development&m=122420938019348&w=2 .
>
> On Thu, Sep 16, 2010 at 9:36 AM, Andy <an...@orprovision.com>
> wrote:
> > Hi All,
> >
> > Do we have any standard source code formatting rules anywhere?
> >
> > I am using Netbeans default formatting, but this may not be to everyone's
> > taste.
> >
> > Regards,
> >
> > Andy
> >
> >
>
>
>
> --
> Thanks
> - Mohammad Nour
> Author of (WebSphere Application Server Community Edition 2.0 User Guide)
> http://www.redbooks.ibm.com/abstracts/sg247585.html
> - LinkedIn: http://www.linkedin.com/in/mnour
> - Blog: http://tadabborat.blogspot.com
> ----
> "Life is like riding a bicycle. To keep your balance you must keep moving"
> - Albert Einstein
>
> "Writing clean code is what you must do in order to call yourself a
> professional. There is no reasonable excuse for doing anything less
> than your best."
> - Clean Code: A Handbook of Agile Software Craftsmanship
>
> "Stay hungry, stay foolish."
> - Steve Jobs
>
--
Karan Singh Malhi
Re: Code formatting
Posted by Mohammad Nour El-Din <no...@gmail.com>.
Hi Andy...
This issue has been discussed in this thread
http://marc.info/?l=openejb-development&m=122420938019348&w=2 .
On Thu, Sep 16, 2010 at 9:36 AM, Andy <an...@orprovision.com> wrote:
> Hi All,
>
> Do we have any standard source code formatting rules anywhere?
>
> I am using Netbeans default formatting, but this may not be to everyone's
> taste.
>
> Regards,
>
> Andy
>
>
--
Thanks
- Mohammad Nour
Author of (WebSphere Application Server Community Edition 2.0 User Guide)
http://www.redbooks.ibm.com/abstracts/sg247585.html
- LinkedIn: http://www.linkedin.com/in/mnour
- Blog: http://tadabborat.blogspot.com
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein
"Writing clean code is what you must do in order to call yourself a
professional. There is no reasonable excuse for doing anything less
than your best."
- Clean Code: A Handbook of Agile Software Craftsmanship
"Stay hungry, stay foolish."
- Steve Jobs
Code formatting
Posted by Andy <an...@orprovision.com>.
Hi All,
Do we have any standard source code formatting rules anywhere?
I am using Netbeans default formatting, but this may not be to
everyone's taste.
Regards,
Andy
Re: JPA 2.0 support in OpenEJB
Posted by Andy <an...@orprovision.com>.
On 17.09.2010 02:16, David Blevins wrote:
> On Sep 16, 2010, at 6:14 AM, Andy wrote:
>
>> On 16.09.2010 14:20, Jean-Louis MONTEIRO wrote:
>>> Hi David,
>>>
>>> I checked with OpenJPA guys and this feature has been disabled.
>>> Have a look here https://issues.apache.org/jira/browse/OPENJPA-651
>>> https://issues.apache.org/jira/browse/OPENJPA-651
>>>
>>> But, we can get back to the OpenJPA 1.x behavior using the property
>>> openjpa.RuntimeUnenhancedClasses=supported.
>>>
>>> With this property set, it works fine now.
>>> Regarding the discussion and the JIRA, it may be great to get a better
>>> solution.
>>>
>>> Jean-Louis
>>>
>> Just checked that in ;-)
> Definitely a step in the right direction. We'll probably want a fix in OpenEJB rather than requiring all apps to compensate for the OpenJPA change.
>
> I swizzled our existing PersistenceProviderProperties class to be aware of the openjpa.RuntimeUnenhancedClasses=supported flag and set it if it isn't found.
>
> http://svn.apache.org/viewvc?view=revision&revision=997956
>
> With that we should be able to remove the 'openjpa.RuntimeUnenhancedClasses' flags from all our tests/examples and everything should still work. Might be a good idea to do that so we know the auto-setting support works and users are getting the same experience we are.
>
>
> -David
>
>
>
Will do that right away - Now I know where to make such changes in the
future :-)
Andy.
Re: Pom optimization
Posted by Stephen Connolly <st...@gmail.com>.
I'm more than willing to help if I can find the cycles
-Stephen (Maven Committer & PMC member)
On 17 September 2010 22:07, David Blevins <da...@visi.com> wrote:
>
> On Sep 17, 2010, at 12:30 AM, Andy wrote:
>
> > The question is, how happy are you for commiters (I guess I mean me, but
> also anyone interested) to try and clean up some of these issues in trunk? -
> Or would a pure Java 1.6 branch be the safer option, at least until wide
> ranging changes are tested by several devs on varying platforms.
>
> Changes of any kind are welcome. Basic rule of thumb is to post a note to
> the list and be open to changes. You're doing both already, so great :)
>
> > I would like to put something as drastic as this in the top pom (which
> overrides the Apache 7 pom), and work down from there:
> >
> > <plugin>
> > <groupId>org.apache.maven.plugins</groupId>
> > <artifactId>maven-compiler-plugin</artifactId>
> > <version>2.3.2</version>
> > <configuration>
> > <source>1.6</source>
> > <target>1.6</target>
> > </configuration>
> > </plugin>
> >
> > I'd also like to ensure that all poms reference their parents throughout
> the project so that it is possible to pull up plugin and dependency
> definitions as high as possible.
>
> On this one just make sure to leave the examples untouched. They are
> intentionally not using any parent pom so that each one is a completely
> self-contained example.
>
> > This cannot be done without builds initially failing until all issues are
> resolved - Issues meaning all the ones that arise on 'other' devs machines
> when everything seems fine on a local build ;-)
>
> On the note of things failing. Would be great to get us setup in Hudson
> for CI and publishing binaries: https://hudson.apache.org/hudson/
>
> As far as I know it's a matter of filing a request here:
> https://issues.apache.org/jira/browse/INFRA
>
>
> -David
>
> PS Careful of "thread hijacking" (starting new threads by replying to an
> unrelated email). It makes things look like one big discussion in email
> clients that support threading and most the online archives like Nabble (
> http://openejb.979440.n4.nabble.com/OpenEJB-Dev-f982480.html )
>
>
Re: Pom optimization
Posted by dsh <da...@googlemail.com>.
Opened a JIRA for the Hudson part of this note:
https://issues.apache.org/jira/browse/INFRA-2998
On Fri, Sep 17, 2010 at 11:07 PM, David Blevins <da...@visi.com> wrote:
>
> On Sep 17, 2010, at 12:30 AM, Andy wrote:
>
>> The question is, how happy are you for commiters (I guess I mean me, but also anyone interested) to try and clean up some of these issues in trunk? - Or would a pure Java 1.6 branch be the safer option, at least until wide ranging changes are tested by several devs on varying platforms.
>
> Changes of any kind are welcome. Basic rule of thumb is to post a note to the list and be open to changes. You're doing both already, so great :)
>
>> I would like to put something as drastic as this in the top pom (which overrides the Apache 7 pom), and work down from there:
>>
>> <plugin>
>> <groupId>org.apache.maven.plugins</groupId>
>> <artifactId>maven-compiler-plugin</artifactId>
>> <version>2.3.2</version>
>> <configuration>
>> <source>1.6</source>
>> <target>1.6</target>
>> </configuration>
>> </plugin>
>>
>> I'd also like to ensure that all poms reference their parents throughout the project so that it is possible to pull up plugin and dependency definitions as high as possible.
>
> On this one just make sure to leave the examples untouched. They are intentionally not using any parent pom so that each one is a completely self-contained example.
>
>> This cannot be done without builds initially failing until all issues are resolved - Issues meaning all the ones that arise on 'other' devs machines when everything seems fine on a local build ;-)
>
> On the note of things failing. Would be great to get us setup in Hudson for CI and publishing binaries: https://hudson.apache.org/hudson/
>
> As far as I know it's a matter of filing a request here: https://issues.apache.org/jira/browse/INFRA
>
>
> -David
>
> PS Careful of "thread hijacking" (starting new threads by replying to an unrelated email). It makes things look like one big discussion in email clients that support threading and most the online archives like Nabble ( http://openejb.979440.n4.nabble.com/OpenEJB-Dev-f982480.html )
>
>
Re: Pom optimization
Posted by dsh <da...@googlemail.com>.
I can fill the JIRA and work together with Gavin to setup the Hudson build.
Cheers
Daniel
On Fri, Sep 17, 2010 at 11:07 PM, David Blevins <da...@visi.com> wrote:
>
> On Sep 17, 2010, at 12:30 AM, Andy wrote:
>
>> The question is, how happy are you for commiters (I guess I mean me, but also anyone interested) to try and clean up some of these issues in trunk? - Or would a pure Java 1.6 branch be the safer option, at least until wide ranging changes are tested by several devs on varying platforms.
>
> Changes of any kind are welcome. Basic rule of thumb is to post a note to the list and be open to changes. You're doing both already, so great :)
>
>> I would like to put something as drastic as this in the top pom (which overrides the Apache 7 pom), and work down from there:
>>
>> <plugin>
>> <groupId>org.apache.maven.plugins</groupId>
>> <artifactId>maven-compiler-plugin</artifactId>
>> <version>2.3.2</version>
>> <configuration>
>> <source>1.6</source>
>> <target>1.6</target>
>> </configuration>
>> </plugin>
>>
>> I'd also like to ensure that all poms reference their parents throughout the project so that it is possible to pull up plugin and dependency definitions as high as possible.
>
> On this one just make sure to leave the examples untouched. They are intentionally not using any parent pom so that each one is a completely self-contained example.
>
>> This cannot be done without builds initially failing until all issues are resolved - Issues meaning all the ones that arise on 'other' devs machines when everything seems fine on a local build ;-)
>
> On the note of things failing. Would be great to get us setup in Hudson for CI and publishing binaries: https://hudson.apache.org/hudson/
>
> As far as I know it's a matter of filing a request here: https://issues.apache.org/jira/browse/INFRA
>
>
> -David
>
> PS Careful of "thread hijacking" (starting new threads by replying to an unrelated email). It makes things look like one big discussion in email clients that support threading and most the online archives like Nabble ( http://openejb.979440.n4.nabble.com/OpenEJB-Dev-f982480.html )
>
>
Re: Pom optimization
Posted by David Blevins <da...@visi.com>.
On Sep 17, 2010, at 12:30 AM, Andy wrote:
> The question is, how happy are you for commiters (I guess I mean me, but also anyone interested) to try and clean up some of these issues in trunk? - Or would a pure Java 1.6 branch be the safer option, at least until wide ranging changes are tested by several devs on varying platforms.
Changes of any kind are welcome. Basic rule of thumb is to post a note to the list and be open to changes. You're doing both already, so great :)
> I would like to put something as drastic as this in the top pom (which overrides the Apache 7 pom), and work down from there:
>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-compiler-plugin</artifactId>
> <version>2.3.2</version>
> <configuration>
> <source>1.6</source>
> <target>1.6</target>
> </configuration>
> </plugin>
>
> I'd also like to ensure that all poms reference their parents throughout the project so that it is possible to pull up plugin and dependency definitions as high as possible.
On this one just make sure to leave the examples untouched. They are intentionally not using any parent pom so that each one is a completely self-contained example.
> This cannot be done without builds initially failing until all issues are resolved - Issues meaning all the ones that arise on 'other' devs machines when everything seems fine on a local build ;-)
On the note of things failing. Would be great to get us setup in Hudson for CI and publishing binaries: https://hudson.apache.org/hudson/
As far as I know it's a matter of filing a request here: https://issues.apache.org/jira/browse/INFRA
-David
PS Careful of "thread hijacking" (starting new threads by replying to an unrelated email). It makes things look like one big discussion in email clients that support threading and most the online archives like Nabble ( http://openejb.979440.n4.nabble.com/OpenEJB-Dev-f982480.html )
Pom optimization
Posted by Andy <an...@orprovision.com>.
Hi David,
I've been working my way through this great resource in order to try and
make heads and tails of maven:
http://www.sonatype.com/books/maven-book/reference/public-book.html
Especially taking notes on:
http://www.sonatype.com/books/maven-book/reference/optimizing.html
It seems that there are a lot of inheritance issues with the current
trunk which leads to a lot of duplicated plugins and deps down the
chain, but often with differing versions. The final build basically does
the best job it can at resolving all required versions.
I know it is a huge and dangerous task to make wide ranging pom changes,
and I have just bitten the bullet and made some changes to several poms.
The question is, how happy are you for commiters (I guess I mean me, but
also anyone interested) to try and clean up some of these issues in
trunk? - Or would a pure Java 1.6 branch be the safer option, at least
until wide ranging changes are tested by several devs on varying platforms.
I would like to put something as drastic as this in the top pom (which
overrides the Apache 7 pom), and work down from there:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
</configuration>
</plugin>
I'd also like to ensure that all poms reference their parents throughout
the project so that it is possible to pull up plugin and dependency
definitions as high as possible.
This cannot be done without builds initially failing until all issues
are resolved - Issues meaning all the ones that arise on 'other' devs
machines when everything seems fine on a local build ;-)
Regards,
Andy.
Re: JPA 2.0 support in OpenEJB
Posted by David Blevins <da...@visi.com>.
On Sep 16, 2010, at 6:14 AM, Andy wrote:
> On 16.09.2010 14:20, Jean-Louis MONTEIRO wrote:
>> Hi David,
>>
>> I checked with OpenJPA guys and this feature has been disabled.
>> Have a look here https://issues.apache.org/jira/browse/OPENJPA-651
>> https://issues.apache.org/jira/browse/OPENJPA-651
>>
>> But, we can get back to the OpenJPA 1.x behavior using the property
>> openjpa.RuntimeUnenhancedClasses=supported.
>>
>> With this property set, it works fine now.
>> Regarding the discussion and the JIRA, it may be great to get a better
>> solution.
>>
>> Jean-Louis
>>
> Just checked that in ;-)
Definitely a step in the right direction. We'll probably want a fix in OpenEJB rather than requiring all apps to compensate for the OpenJPA change.
I swizzled our existing PersistenceProviderProperties class to be aware of the openjpa.RuntimeUnenhancedClasses=supported flag and set it if it isn't found.
http://svn.apache.org/viewvc?view=revision&revision=997956
With that we should be able to remove the 'openjpa.RuntimeUnenhancedClasses' flags from all our tests/examples and everything should still work. Might be a good idea to do that so we know the auto-setting support works and users are getting the same experience we are.
-David
Re: JPA 2.0 support in OpenEJB
Posted by Andy <an...@orprovision.com>.
On 16.09.2010 14:20, Jean-Louis MONTEIRO wrote:
> Hi David,
>
> I checked with OpenJPA guys and this feature has been disabled.
> Have a look here https://issues.apache.org/jira/browse/OPENJPA-651
> https://issues.apache.org/jira/browse/OPENJPA-651
>
> But, we can get back to the OpenJPA 1.x behavior using the property
> openjpa.RuntimeUnenhancedClasses=supported.
>
> With this property set, it works fine now.
> Regarding the discussion and the JIRA, it may be great to get a better
> solution.
>
> Jean-Louis
>
Just checked that in ;-)
Andy.
Re: JPA 2.0 support in OpenEJB
Posted by Jean-Louis MONTEIRO <je...@atosorigin.com>.
Hi David,
I checked with OpenJPA guys and this feature has been disabled.
Have a look here https://issues.apache.org/jira/browse/OPENJPA-651
https://issues.apache.org/jira/browse/OPENJPA-651
But, we can get back to the OpenJPA 1.x behavior using the property
openjpa.RuntimeUnenhancedClasses=supported.
With this property set, it works fine now.
Regarding the discussion and the JIRA, it may be great to get a better
solution.
Jean-Louis
--
View this message in context: http://openejb.979440.n4.nabble.com/JPA-2-0-support-in-OpenEJB-tp1690430p2542051.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: JPA 2.0 support in OpenEJB
Posted by David Blevins <da...@visi.com>.
On Sep 7, 2010, at 8:01 AM, Jean-Louis MONTEIRO wrote:
>
> Hi all,
>
> Some tests in UnenhancedTest.java fail because some classes are unenhanced.
> #testUnenhancedComplexIdJta
> #testUnenhancedComplexIdResourceLocal
>
> Regarding OPENEJB-628, this test case is only due to some OpenJPA bugs.
> We are now using OpenJPA 2.x and those bugs may be fixed.
>
> Can i comment the 2 test cases?
I see these three failing:
core.cmp.jpa.UnenhancedTest.txt:testUnenhancedComplexIdJta
core.cmp.jpa.UnenhancedTest.txt:testUnenhancedComplexIdResourceLocal
core.stateful.EntityManagerPropogationTest.txt:test
The first two are less concerning, but the EntityManagerPropogationTest is a critical test.
The entity bean involved in that test is very simple. If there's a way we can turn back on the subclassing functionality of OpenJPA, then that might do the trick. I just hope they haven't removed it completely.
-David
Re: JPA 2.0 support in OpenEJB
Posted by Jean-Louis MONTEIRO <je...@atosorigin.com>.
Hi all,
Some tests in UnenhancedTest.java fail because some classes are unenhanced.
#testUnenhancedComplexIdJta
#testUnenhancedComplexIdResourceLocal
Regarding OPENEJB-628, this test case is only due to some OpenJPA bugs.
We are now using OpenJPA 2.x and those bugs may be fixed.
Can i comment the 2 test cases?
Jean-Louis
--
View this message in context: http://openejb.979440.n4.nabble.com/JPA-2-0-support-in-OpenEJB-tp1690430p2529857.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: JPA 2.0 support in OpenEJB
Posted by Jean-Louis MONTEIRO <je...@atosorigin.com>.
Hi all,
Working again on that issue.
May be some tests will fail this week.
Apologize.
JLouis
--
View this message in context: http://openejb.979440.n4.nabble.com/JPA-2-0-support-in-OpenEJB-tp1690430p2528015.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: JPA 2.0 support in OpenEJB
Posted by Jean-Louis MONTEIRO <je...@atosorigin.com>.
Hi David,
I need to investigate a bit more cause 2 test cases are still failing
because of OpenJPA load time enhancements.
I'm trying to understand why it fails?
Is it due to OpenJPA changes (from 1.x to 2.x)?
Or is it due to JPA 2 support in OpenEJB?
Anyway, that's a topic i definitely need to achieve ASAP.
Jean-Louis
David Blevins wrote:
>
>
> On Mar 25, 2010, at 3:47 AM, Jean-Louis MONTEIRO wrote:
>
>>
>> Hi,
>>
>> I spent some time trying to add JPA 2.0 support in OpenEJB (
>> https://issues.apache.org/jira/browse/OPENEJB-1236 OPENEJB-1236 ).
>>
>> Actually, it's just a draft but it seems to work fine ;)
>> I'd like to have some feedback about the patch attached to the JIRA.
>>> From my understanding and tests, it works with JPA 1.0 implementation as
>> well as with JPA 2.0 implementation. Obviously, using JPA 2.0 feature
>> with
>> an JPA 1.0 implementation will cause errors.
>>
>> BTW, to play a bit with JPA 2.0, i changed the hibernate 3 sample.
>> You can have a look and play!
>
> Code looks good! Haven't had a chance to check out the related test
> failures. Regardless of the failures, we're definitely on the right
> track! The change is surprisingly small for so much added functionality
> :)
>
> Going to be great to get this feature out there! There are a ton of
> people who want it :)
>
>
> -David
>
>
>
--
View this message in context: http://openejb.979440.n4.nabble.com/JPA-2-0-support-in-OpenEJB-tp1690430p2130498.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: JPA 2.0 support in OpenEJB
Posted by David Blevins <da...@visi.com>.
On Mar 25, 2010, at 3:47 AM, Jean-Louis MONTEIRO wrote:
>
> Hi,
>
> I spent some time trying to add JPA 2.0 support in OpenEJB (
> https://issues.apache.org/jira/browse/OPENEJB-1236 OPENEJB-1236 ).
>
> Actually, it's just a draft but it seems to work fine ;)
> I'd like to have some feedback about the patch attached to the JIRA.
>> From my understanding and tests, it works with JPA 1.0 implementation as
> well as with JPA 2.0 implementation. Obviously, using JPA 2.0 feature with
> an JPA 1.0 implementation will cause errors.
>
> BTW, to play a bit with JPA 2.0, i changed the hibernate 3 sample.
> You can have a look and play!
Code looks good! Haven't had a chance to check out the related test failures. Regardless of the failures, we're definitely on the right track! The change is surprisingly small for so much added functionality :)
Going to be great to get this feature out there! There are a ton of people who want it :)
-David