JPA 2.1
Hi best ORM mapper implementers! I caught some mailing list mails which spoke about 2.1 implementation on the way. What's the current status? Spring 5 forces 2.1 compliance as a prerequisite so it should be nice to have a 2.1 support (also, I really dislike Hibernate as an orm, OpenJPA is far more bullet proof IMHO). Best regards, -- Charlie Mordant Full OSGI/EE stack made with Karaf: https://github.com/OsgiliathEnterprise/net.osgiliath.parent
Re: OpenJPA and auto-commit
Hi Bengt,
I think that is not really an OpenJPA issue, but a kind of a missbehavior.
I heard about a JIRA ticket telling that AriesJpa2 (K4.0.5 version) isn't
really using the persistence provider's classloader: it may be related...
The other point could be a start order behavior, but I also saw that
pax-jdbc karaf feature is now using karaf requirement and capabilities so
it could be also fixed ;).
So let's wait and see K4.0.6 version!
Regards,
2016-07-11 10:23 GMT+02:00 Bengt Rodehav <be...@rodehav.com>:
> Did you ever get an answer to this? I have the same problem using OpenJPA
> in Karaf with Aries JPA.
>
> When creating the Derby database, the JTA datasource is being used although
> I have also provided a non-JTA datasource for this purpose. To me it sounds
> like an OpenJPA problem.
>
> /Bengt
>
> 2014-12-02 22:30 GMT+01:00 Charlie Mordant <cmorda...@gmail.com>:
>
> > Hello again Rick,
> >
> > On my side, the bug seems to be a pax-jdbc-pool-aries one, I switched to
> > commons-dbcp2 and it seems to work well (7 CI builds without any error).
> >
> > Here's my persistence.xml if it can help on the Openjpa side:
> >
> >
> >
> >
> >
> org.apache.openjpa.persistence.PersistenceProviderImpl
> >
> >
> >
> > osgi:service/javax.sql.DataSource/(
> > osgi.jndi.service.name
> > =${project.parent.artifactId}.database)
> >
> > osgi:service/javax.sql.DataSource/(
> > osgi.jndi.service.name=${project.parent.artifactId}.database) > non-jta-data-source>
> >
> > net.osgiliath.hello.model.jpa.model.AbstractEntity
> >
> > net.osgiliath.hello.model.jpa.model.HelloEntity
> >
> > true
> >
> > NONE
> >
> >
> >
> >
> >
> > > "buildSchema(ForeignKeys=true,SchemaAction=refresh)"/>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Best regards,
> >
> >
> > Charlie
> >
> > 2014-12-02 18:48 GMT+01:00 Rick Curtis <curti...@gmail.com>:
> >
> > > Will you also post the contents of your persistence.xml?
> > >
> > > Thanks,
> > > Rick
> > >
> > > On Tue, Dec 2, 2014 at 10:33 AM, Charlie Mordant <cmorda...@gmail.com>
> > > wrote:
> > >
> > > > Hi Rick,
> > > >
> > > > Here's the full Trace, notice that sometimes, connection null
> arguments
> > > > error is not here, I'll try (not really voluntarily) to have one in
> the
> > > > next days.
> > > >
> > > >
> > > >
> > > > 2014-12-02 10:14:00,227 | ERROR | tenerContainer-1 | ServiceRecipe
> > > >| 15 - org.apache.aries.blueprint.core - 1.4.1 | Error
> > > > retrieving service from ServiceRecipe[name='.component-1']
> > > > org.osgi.service.blueprint.container.ComponentDefinitionException:
> > > > Error when instantiating bean helloObjectRepository of class
> > > >
> net.osgiliath.hello.model.jpa.repository.impl.HelloObjectJpaRepository
> > > > at
> > > >
> > >
> >
> org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:333)[15:org.apache.aries.blueprint.core:1.4.1]
> > > > at
> > > >
> > >
> >
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:806)[15:org.apache.aries.blueprint.core:1.4.1]
> > > > at
> > > >
> > >
> >
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)[15:org.apache.aries.blueprint.core:1.4.1]
> > > > at
> > > >
> > >
> >
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)[15:org.apache.aries.blueprint.core:1.4.1]
> > > > at
> > > > java.util.concurrent.FutureTask.run(FutureTask.java:262)[:1.7.0_71]
> > > > at
> > > >
> > >
> >
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[15:org.apache.aries.blueprint.core:1.4.1]
> > > > at
> > > >
> > >
> >
> org.apache.aries.blueprint.di.RefRecipe.internalCreate(RefRecipe.java:62)[15:org.apache.aries.blueprint.core:1.4.1]
> > > > at
> > > >
> > >
> >
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:106)[15:org.apache.aries.blueprint.core:1.4.1]
> > > > at
> > > >
Re: Java 8/Java 7 end of life
Hi Hal,
Has I said, I made an applicative framework (comparable to Wildfly,
Glassfish, Fuse), I'm not responsible of what my framework user's will do,
and I also can't tell them that it offers lambda/J8 BUT for the JPA service
(flooded in a hundred pages of documentation...).
Regards,
2015-03-16 14:27 GMT+01:00 Hal Hildebrand hal.hildebr...@me.com:
I think my question was more of why you have to do it in that way, rather
than putting whatever logic that needs lambdas somewhere else. Seems like
an easy thing to workaround.
On Mar 15, 2015, at 4:50 PM, Charlie Mordant cmorda...@gmail.com
wrote:
class Person{
@OneToMany
private Address address;
public getLocalisation() {
//Do stuff with lambdas to retrieve derived feature
}
}
class Address{
@OneToMany
private Localisation localisation;}
class Localisation{...}
2015-03-15 22:34 GMT+01:00 Hal Hildebrand hal.hildebr...@me.com:
Also, too, nothing about the 1.7 restrictions prevent anything from
happening wrt criteria queries and 1.8 I must say.
On Mar 15, 2015, at 4:28 PM, Hal Hildebrand hal.hildebr...@me.com
wrote:
True. But I am curious. What would be an example of what you need to
do.
Not just being flip ;) genuinely curious.
On Mar 15, 2015, at 3:55 PM, Charlie Mordant cmorda...@gmail.com
wrote:
It's also kinda nice to mix the JPA criteria API and J8 functions ;)
Also, I'm an applicative architect, how can I tell my product users to
use
J8 everywhere but in the model module... This has a little bit of
support
cost in a big company.
2015-03-15 19:26 GMT+01:00 Hal Hildebrand hal.hildebr...@me.com:
Heh. Really. Just modularize your code base. You can compile the orm
portion with 1.7 and do the rest with 1.8. It's not hard at all and
really.
It's what you should be doing anyway. Works like a charm.
1.8 is not an issue unless you pollute your domain model. Just treat
them
as pojos. Like God intended ;)
On Mar 15, 2015, at 12:22 PM, Charlie Mordant cmorda...@gmail.com
wrote:
Hi,
So the 2.2.x release is more advanced than the 2.3.x? Shouldn't be
nice
to
backport changes to 2.3 and make a new release?
J1.7 is near EOL and it should be nice to avoid loosing users
because
they're thinking that they can use OpenJPA with J8...
Regards,
2015-03-11 15:28 GMT+01:00 Hal Hildebrand hal.hildebr...@me.com:
Eh, it’s fine for me. My stuff is modularized so I can compile all
that
with 1.7 and I don’t need 1.8 features in the database model
anyway. No
worries.
On Mar 11, 2015, at 7:21 AM, Rick Curtis curti...@gmail.com
wrote:
Yes, supported wasn't added to 2.3.x. Try trunk or 2.2.x
On Wed, Mar 11, 2015 at 8:44 AM, Hal Hildebrand
hal.hildebr...@me.com
wrote:
Sorry, this fell out of my inbox.
I'm using 2.3.0 and JDK 1.8 and maven. If I change the target to
1.8
from
1.7, I get:
java.lang.IllegalArgumentException
at org.apache.xbean.asm4.ClassReader.init(Unknown Source)
at org.apache.xbean.asm4.ClassReader.init(Unknown Source)
at org.apache.xbean.asm4.ClassReader.init(Unknown Source)
at
org.apache.openjpa.enhance.AsmAdaptor.toJava7ByteArray(AsmAdaptor.java:93)
at
org.apache.openjpa.enhance.AsmAdaptor.writeJava7(AsmAdaptor.java:84)
at
org.apache.openjpa.enhance.AsmAdaptor.write(AsmAdaptor.java:54)
at
org.apache.openjpa.enhance.PCEnhancer.record(PCEnhancer.java:633)
at
org.apache.openjpa.enhance.PCEnhancer.record(PCEnhancer.java:619)
at
org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:4900)
at
org.apache.openjpa.ant.PCEnhancerTask.executeOn(PCEnhancerTask.java:89)
at
org.apache.openjpa.lib.ant.AbstractTask.execute(AbstractTask.java:184)
at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:390)
at org.apache.tools.ant.Target.performTasks(Target.java:411)
at
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
at
org.apache.tools.ant.Project.executeTarget(Project.java:1368)
at
org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:327)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute
Re: Java 8/Java 7 end of life
wrote: Hello, Does the Byte Code Enhancement work when compiled for 1.8? Thanks Regards, John Boblitz -Original Message- From: Hal Hildebrand [mailto:hal.hildebr...@me.com] Sent: Montag, 9. März 2015 16:21 To: users@openjpa.apache.org Subject: Re: Java 8/Java 7 end of life I can certainly confirm that OpenJPA runs on java 8. And even compiles when using source 1.7, target 1.7. Byte code enhancement works fine on the code when compiled in that fashion. On Mar 9, 2015, at 6:06 AM, Rick Curtis curti...@gmail.com wrote: OpenJPA 2.3.x and trunk should be functional with java8, but I don't think you can build OpenJPA with java8. On Mon, Mar 9, 2015 at 3:52 AM, Henno Vermeulen he...@huizemolenaar.nl wrote: Hello, AFAIK, OpenJPA still doesn't work with Java 8. Are there any plans of fixing this soon? Perhaps OpenJPA committers could give this some more priority? Oracle public support for Java 7 will end after April this year, see http://www.oracle.com/technetwork/java/javase/eol-135779.html If I understand well, this means that security issues in Oracle's Java 7 runtime will no longer be fixed so that an application using OpenJPA on Java 7 will become more and more vulnerable over time. The ticket for Java 8 was last updated in October 2014: https://issues.apache.org/jira/browse/OPENJPA-2386 Regards, Henno Vermeulen -- *Rick Curtis* -- *Rick Curtis* -- *Rick Curtis* -- Charlie Mordant Full OSGI/EE stack made with Karaf: https://github.com/OsgiliathEnterprise/net.osgiliath.parent
Re: Java 8/Java 7 end of life
It's also kinda nice to mix the JPA criteria API and J8 functions ;) Also, I'm an applicative architect, how can I tell my product users to use J8 everywhere but in the model module... This has a little bit of support cost in a big company. 2015-03-15 19:26 GMT+01:00 Hal Hildebrand hal.hildebr...@me.com: Heh. Really. Just modularize your code base. You can compile the orm portion with 1.7 and do the rest with 1.8. It's not hard at all and really. It's what you should be doing anyway. Works like a charm. 1.8 is not an issue unless you pollute your domain model. Just treat them as pojos. Like God intended ;) On Mar 15, 2015, at 12:22 PM, Charlie Mordant cmorda...@gmail.com wrote: Hi, So the 2.2.x release is more advanced than the 2.3.x? Shouldn't be nice to backport changes to 2.3 and make a new release? J1.7 is near EOL and it should be nice to avoid loosing users because they're thinking that they can use OpenJPA with J8... Regards, 2015-03-11 15:28 GMT+01:00 Hal Hildebrand hal.hildebr...@me.com: Eh, it’s fine for me. My stuff is modularized so I can compile all that with 1.7 and I don’t need 1.8 features in the database model anyway. No worries. On Mar 11, 2015, at 7:21 AM, Rick Curtis curti...@gmail.com wrote: Yes, supported wasn't added to 2.3.x. Try trunk or 2.2.x On Wed, Mar 11, 2015 at 8:44 AM, Hal Hildebrand hal.hildebr...@me.com wrote: Sorry, this fell out of my inbox. I'm using 2.3.0 and JDK 1.8 and maven. If I change the target to 1.8 from 1.7, I get: java.lang.IllegalArgumentException at org.apache.xbean.asm4.ClassReader.init(Unknown Source) at org.apache.xbean.asm4.ClassReader.init(Unknown Source) at org.apache.xbean.asm4.ClassReader.init(Unknown Source) at org.apache.openjpa.enhance.AsmAdaptor.toJava7ByteArray(AsmAdaptor.java:93) at org.apache.openjpa.enhance.AsmAdaptor.writeJava7(AsmAdaptor.java:84) at org.apache.openjpa.enhance.AsmAdaptor.write(AsmAdaptor.java:54) at org.apache.openjpa.enhance.PCEnhancer.record(PCEnhancer.java:633) at org.apache.openjpa.enhance.PCEnhancer.record(PCEnhancer.java:619) at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:4900) at org.apache.openjpa.ant.PCEnhancerTask.executeOn(PCEnhancerTask.java:89) at org.apache.openjpa.lib.ant.AbstractTask.execute(AbstractTask.java:184) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:390) at org.apache.tools.ant.Target.performTasks(Target.java:411) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.Project.executeTarget(Project.java:1368) at org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:327) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:108) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213) at org.apache.maven.cli.MavenCli.main(MavenCli.java:157) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
Re: Java 8/Java 7 end of life
class Person{
@OneToMany
private Address address;
public getLocalisation() {
//Do stuff with lambdas to retrieve derived feature
}
}
class Address{
@OneToMany
private Localisation localisation;}
class Localisation{...}
2015-03-15 22:34 GMT+01:00 Hal Hildebrand hal.hildebr...@me.com:
Also, too, nothing about the 1.7 restrictions prevent anything from
happening wrt criteria queries and 1.8 I must say.
On Mar 15, 2015, at 4:28 PM, Hal Hildebrand hal.hildebr...@me.com
wrote:
True. But I am curious. What would be an example of what you need to do.
Not just being flip ;) genuinely curious.
On Mar 15, 2015, at 3:55 PM, Charlie Mordant cmorda...@gmail.com
wrote:
It's also kinda nice to mix the JPA criteria API and J8 functions ;)
Also, I'm an applicative architect, how can I tell my product users to
use
J8 everywhere but in the model module... This has a little bit of
support
cost in a big company.
2015-03-15 19:26 GMT+01:00 Hal Hildebrand hal.hildebr...@me.com:
Heh. Really. Just modularize your code base. You can compile the orm
portion with 1.7 and do the rest with 1.8. It's not hard at all and
really.
It's what you should be doing anyway. Works like a charm.
1.8 is not an issue unless you pollute your domain model. Just treat
them
as pojos. Like God intended ;)
On Mar 15, 2015, at 12:22 PM, Charlie Mordant cmorda...@gmail.com
wrote:
Hi,
So the 2.2.x release is more advanced than the 2.3.x? Shouldn't be
nice
to
backport changes to 2.3 and make a new release?
J1.7 is near EOL and it should be nice to avoid loosing users because
they're thinking that they can use OpenJPA with J8...
Regards,
2015-03-11 15:28 GMT+01:00 Hal Hildebrand hal.hildebr...@me.com:
Eh, it’s fine for me. My stuff is modularized so I can compile all
that
with 1.7 and I don’t need 1.8 features in the database model
anyway. No
worries.
On Mar 11, 2015, at 7:21 AM, Rick Curtis curti...@gmail.com
wrote:
Yes, supported wasn't added to 2.3.x. Try trunk or 2.2.x
On Wed, Mar 11, 2015 at 8:44 AM, Hal Hildebrand
hal.hildebr...@me.com
wrote:
Sorry, this fell out of my inbox.
I'm using 2.3.0 and JDK 1.8 and maven. If I change the target to
1.8
from
1.7, I get:
java.lang.IllegalArgumentException
at org.apache.xbean.asm4.ClassReader.init(Unknown Source)
at org.apache.xbean.asm4.ClassReader.init(Unknown Source)
at org.apache.xbean.asm4.ClassReader.init(Unknown Source)
at
org.apache.openjpa.enhance.AsmAdaptor.toJava7ByteArray(AsmAdaptor.java:93)
at
org.apache.openjpa.enhance.AsmAdaptor.writeJava7(AsmAdaptor.java:84)
at
org.apache.openjpa.enhance.AsmAdaptor.write(AsmAdaptor.java:54)
at
org.apache.openjpa.enhance.PCEnhancer.record(PCEnhancer.java:633)
at
org.apache.openjpa.enhance.PCEnhancer.record(PCEnhancer.java:619)
at
org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:4900)
at
org.apache.openjpa.ant.PCEnhancerTask.executeOn(PCEnhancerTask.java:89)
at
org.apache.openjpa.lib.ant.AbstractTask.execute(AbstractTask.java:184)
at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:390)
at org.apache.tools.ant.Target.performTasks(Target.java:411)
at
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
at
org.apache.tools.ant.Project.executeTarget(Project.java:1368)
at
org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:327)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:108)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)
at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361
Re: OpenJPA and auto-commit
Hi Kevin,
Thank you for the idea, I'll do so :).
Best regards,
Charlie
2014-12-01 23:31 GMT+01:00 Kevin Sutter kwsut...@gmail.com:
Hi Charlie,
Most of my experience is in the Java EE space, not the OSGi/Aries
environment. Since WebSphere is using both Aries and OpenJPA, and
WebSphere supports both Java EE and OSGi programming models, you should be
able to get this combination to work. I'm just not sure what, if any,
additional magic WebSphere had to include... Have you been posting on the
Aries site as well?
Good luck,
Kevin
On Mon, Dec 1, 2014 at 3:53 PM, Charlie Mordant cmorda...@gmail.com
wrote:
Hi Kevin,
I removed the non-jta-datasource (referencing the same connection)
because
I thought it was the issue (and that was failing the same way).
Even if I add it, it also fails (randomly, sometimes it passes).
I’m not sure it is really OpenJpa related, as I’m using Aries-JPA/Tx,
Pax-JDBC.
I’m currently investigating, and if you’ve any other pointers I’ll sure
try :).
Thank you, and best regards,
Charlie
PS: if you’re also interested in the case, you can also try to see
where’s
the catch compiling this:
https://github.com/OsgiliathEnterprise/net.osgiliath.parent
https://github.com/OsgiliathEnterprise/net.osgiliath.parent (it will
once on three times fail on the hello sample blueprint test).
Le 1 déc. 2014 à 22:41, Kevin Sutter kwsut...@gmail.com a écrit :
Hi Charlie,
Since you are using SynchronizeMappings, you should be providing an
alternate datasource (non-jta-data-source) in addition to the
jta-data-source. OpenJPA requires access to the database in order to
define or adjust your schemas based on your Entity definitions.
Without
a
non-jta-data-source, OpenJPA will attempt to do this work within the
global
transaction. Unfortunately, the auto commit processing doesn't work
well
within a global transaction (as you have found out).
Hope this helps.
Kevin
On Sun, Nov 30, 2014 at 9:05 AM, Charlie Mordant cmorda...@gmail.com
wrote:
Hi OpenJPA Guru's,
I'm encountering an issue when openJPA participates to a global
transaction, I've got this weird error happening sometimes:
Caused by: openjpa-2.3.0-r422266:1540826 nonfatal general error
org.apache.openjpa.persistence.PersistenceException:
setAutoCommit(true) invalid during global transaction.
at
org.apache.openjpa.jdbc.meta.MappingTool.record(MappingTool.java:559)
at
org.apache.openjpa.jdbc.meta.MappingTool.record(MappingTool.java:455)
My persistence.xml is as simple as it can be:
[code]
persistence-unit name=${project.artifactId}Pu
transaction-type=JTA
providerorg.apache.openjpa.persistence.PersistenceProviderImpl/provider
jta-data-sourceosgi:service/javax.sql.DataSource/(amp;(
osgi.jndi.service.name
=${project.parent.artifactId}.database)(aries.managed=true))/
jta-data-source
properties
property name=openjpa.Log value=slf4j/
property name=openjpa.jdbc.SynchronizeMappings value=
buildSchema(ForeignKeys=true,SchemaAction=refresh)/
property name=openjpa.jdbc.DBDictionary value=derby/
/persistence-unit
[/code]
Is there any property/option to set somewhere?
Regards,
--
Charlie Mordant
Full OSGI/EE stack made with Karaf:
https://github.com/OsgiliathEnterprise/net.osgiliath.parent
--
Charlie Mordant
Full OSGI/EE stack made with Karaf:
https://github.com/OsgiliathEnterprise/net.osgiliath.parent
Re: OpenJPA and auto-commit
:155) at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:226) at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:59) at org.apache.aries.jpa.container.impl.CountingEntityManagerFactory.createEntityManager(CountingEntityManagerFactory.java:71) at org.apache.aries.jpa.container.context.transaction.impl.JTAPersistenceContextRegistry.getCurrentPersistenceContext(JTAPersistenceContextRegistry.java:152)[225:org.apache.aries.jpa.container.context:1.0.1] at org.apache.aries.jpa.container.context.transaction.impl.JTAEntityManager.getPersistenceContext(JTAEntityManager.java:87)[225:org.apache.aries.jpa.container.context:1.0.1] at org.apache.aries.jpa.container.context.transaction.impl.JTAEntityManager.getMetamodel(JTAEntityManager.java:409)[225:org.apache.aries.jpa.container.context:1.0.1] at org.springframework.data.jpa.repository.support.JpaEntityInformationSupport.getMetadata(JpaEntityInformationSupport.java:60) at org.springframework.data.jpa.repository.support.SimpleJpaRepository.init(SimpleJpaRepository.java:96) at net.osgiliath.hello.model.jpa.repository.impl.HelloObjectJpaRepository.init(HelloObjectJpaRepository.java:59) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)[:1.7.0_71] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)[:1.7.0_71] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)[:1.7.0_71] at java.lang.reflect.Constructor.newInstance(Constructor.java:526)[:1.7.0_71] at org.apache.aries.blueprint.utils.ReflectionUtils.newInstance(ReflectionUtils.java:329)[15:org.apache.aries.blueprint.core:1.4.1] at org.apache.aries.blueprint.container.BeanRecipe.newInstance(BeanRecipe.java:962)[15:org.apache.aries.blueprint.core:1.4.1] at org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:331)[15:org.apache.aries.blueprint.core:1.4.1] ... 32 more Best regards, Charlie 2014-12-02 15:23 GMT+01:00 Rick Curtis curti...@gmail.com: Charlie - Sorry I meant to reply to this thread while I was out on vacation. Can I have you post the entire stacktrace for the problem you're running into? This problem sounds familiar, but I can't recall the details. Thanks, Rick On Tue, Dec 2, 2014 at 3:09 AM, Charlie Mordant cmorda...@gmail.com wrote: Hi Kevin, Thank you for the idea, I'll do so :). Best regards, Charlie 2014-12-01 23:31 GMT+01:00 Kevin Sutter kwsut...@gmail.com: Hi Charlie, Most of my experience is in the Java EE space, not the OSGi/Aries environment. Since WebSphere is using both Aries and OpenJPA, and WebSphere supports both Java EE and OSGi programming models, you should be able to get this combination to work. I'm just not sure what, if any, additional magic WebSphere had to include... Have you been posting on the Aries site as well? Good luck, Kevin On Mon, Dec 1, 2014 at 3:53 PM, Charlie Mordant cmorda...@gmail.com wrote: Hi Kevin, I removed the non-jta-datasource (referencing the same connection) because I thought it was the issue (and that was failing the same way). Even if I add it, it also fails (randomly, sometimes it passes). I'm not sure it is really OpenJpa related, as I'm using Aries-JPA/Tx, Pax-JDBC. I'm currently investigating, and if you've any other pointers I'll sure try :). Thank you, and best regards, Charlie PS: if you're also interested in the case, you can also try to see where's the catch compiling this: https://github.com/OsgiliathEnterprise/net.osgiliath.parent https://github.com/OsgiliathEnterprise/net.osgiliath.parent (it will once on three times fail on the hello sample blueprint test). Le 1 déc. 2014 à 22:41, Kevin Sutter kwsut...@gmail.com a écrit : Hi Charlie, Since you are using SynchronizeMappings, you should be providing an alternate datasource (non-jta-data-source) in addition to the jta-data-source. OpenJPA requires access to the database in order to define or adjust your schemas based on your Entity definitions. Without a non-jta-data-source, OpenJPA will attempt to do this work within the global transaction. Unfortunately, the auto commit processing doesn't work well within a global transaction (as you have found out). Hope this helps. Kevin On Sun, Nov 30, 2014 at 9:05 AM, Charlie Mordant cmorda...@gmail.com wrote: Hi OpenJPA Guru's, I'm encountering an issue when openJPA participates to a global transaction, I've got this weird error happening sometimes
Re: OpenJPA and auto-commit
Hello again Rick,
On my side, the bug seems to be a pax-jdbc-pool-aries one, I switched to
commons-dbcp2 and it seems to work well (7 CI builds without any error).
Here's my persistence.xml if it can help on the Openjpa side:
persistence-unit name=${project.artifactId}Pu transaction-type=JTA
providerorg.apache.openjpa.persistence.PersistenceProviderImpl/provider
!-- TODO exported by database module --
jta-data-sourceosgi:service/javax.sql.DataSource/(osgi.jndi.service.name
=${project.parent.artifactId}.database)/jta-data-source
non-jta-data-sourceosgi:service/javax.sql.DataSource/(
osgi.jndi.service.name=${project.parent.artifactId}.database)/
non-jta-data-source
classnet.osgiliath.hello.model.jpa.model.AbstractEntity/class
classnet.osgiliath.hello.model.jpa.model.HelloEntity/class
exclude-unlisted-classestrue/exclude-unlisted-classes
validation-modeNONE/validation-mode
properties
property name=openjpa.Log value=slf4j/
property name=openjpa.jdbc.SynchronizeMappings value=
buildSchema(ForeignKeys=true,SchemaAction=refresh)/
property name=openjpa.jdbc.DBDictionary value=derby/
property name=openjpa.DataCache value=true/
property name=openjpa.RemoteCommitProvider value=sjvm/
/properties
/persistence-unit
Best regards,
Charlie
2014-12-02 18:48 GMT+01:00 Rick Curtis curti...@gmail.com:
Will you also post the contents of your persistence.xml?
Thanks,
Rick
On Tue, Dec 2, 2014 at 10:33 AM, Charlie Mordant cmorda...@gmail.com
wrote:
Hi Rick,
Here's the full Trace, notice that sometimes, connection null arguments
error is not here, I'll try (not really voluntarily) to have one in the
next days.
2014-12-02 10:14:00,227 | ERROR | tenerContainer-1 | ServiceRecipe
| 15 - org.apache.aries.blueprint.core - 1.4.1 | Error
retrieving service from ServiceRecipe[name='.component-1']
org.osgi.service.blueprint.container.ComponentDefinitionException:
Error when instantiating bean helloObjectRepository of class
net.osgiliath.hello.model.jpa.repository.impl.HelloObjectJpaRepository
at
org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:333)[15:org.apache.aries.blueprint.core:1.4.1]
at
org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:806)[15:org.apache.aries.blueprint.core:1.4.1]
at
org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)[15:org.apache.aries.blueprint.core:1.4.1]
at
org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)[15:org.apache.aries.blueprint.core:1.4.1]
at
java.util.concurrent.FutureTask.run(FutureTask.java:262)[:1.7.0_71]
at
org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[15:org.apache.aries.blueprint.core:1.4.1]
at
org.apache.aries.blueprint.di.RefRecipe.internalCreate(RefRecipe.java:62)[15:org.apache.aries.blueprint.core:1.4.1]
at
org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:106)[15:org.apache.aries.blueprint.core:1.4.1]
at
org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:284)[15:org.apache.aries.blueprint.core:1.4.1]
at
org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:251)[15:org.apache.aries.blueprint.core:1.4.1]
at
org.apache.aries.blueprint.container.ServiceRecipe.getService(ServiceRecipe.java:354)[15:org.apache.aries.blueprint.core:1.4.1]
at
org.apache.aries.blueprint.container.ServiceRecipe$TriggerServiceFactory.getService(ServiceRecipe.java:507)[15:org.apache.aries.blueprint.core:1.4.1]
at
org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:308)[org.apache.felix.framework-4.2.1.jar:]
at
org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:219)[org.apache.felix.framework-4.2.1.jar:]
at
org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:320)[org.apache.felix.framework-4.2.1.jar:]
at
org.apache.felix.framework.Felix.getService(Felix.java:3568)[org.apache.felix.framework-4.2.1.jar:]
at
org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:468)[org.apache.felix.framework-4.2.1.jar:]
at
org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.getServiceSecurely(AbstractServiceReferenceRecipe.java:238)[15:org.apache.aries.blueprint.core:1.4.1]
at
org.apache.aries.blueprint.container.ReferenceRecipe.getService(ReferenceRecipe.java:245)[15:org.apache.aries.blueprint.core:1.4.1]
at
org.apache.aries.blueprint.container.ReferenceRecipe.access$000(ReferenceRecipe.java:55)[15:org.apache.aries.blueprint.core:1.4.1]
at
org.apache.aries.blueprint.container.ReferenceRecipe
Re: OpenJPA and auto-commit
Hi Kevin,
I removed the non-jta-datasource (referencing the same connection) because I
thought it was the issue (and that was failing the same way).
Even if I add it, it also fails (randomly, sometimes it passes).
I’m not sure it is really OpenJpa related, as I’m using Aries-JPA/Tx, Pax-JDBC.
I’m currently investigating, and if you’ve any other pointers I’ll sure try :).
Thank you, and best regards,
Charlie
PS: if you’re also interested in the case, you can also try to see where’s the
catch compiling this:
https://github.com/OsgiliathEnterprise/net.osgiliath.parent
https://github.com/OsgiliathEnterprise/net.osgiliath.parent (it will once on
three times fail on the hello sample blueprint test).
Le 1 déc. 2014 à 22:41, Kevin Sutter kwsut...@gmail.com a écrit :
Hi Charlie,
Since you are using SynchronizeMappings, you should be providing an
alternate datasource (non-jta-data-source) in addition to the
jta-data-source. OpenJPA requires access to the database in order to
define or adjust your schemas based on your Entity definitions. Without a
non-jta-data-source, OpenJPA will attempt to do this work within the global
transaction. Unfortunately, the auto commit processing doesn't work well
within a global transaction (as you have found out).
Hope this helps.
Kevin
On Sun, Nov 30, 2014 at 9:05 AM, Charlie Mordant cmorda...@gmail.com
wrote:
Hi OpenJPA Guru's,
I'm encountering an issue when openJPA participates to a global
transaction, I've got this weird error happening sometimes:
Caused by: openjpa-2.3.0-r422266:1540826 nonfatal general error
org.apache.openjpa.persistence.PersistenceException:
setAutoCommit(true) invalid during global transaction.
at
org.apache.openjpa.jdbc.meta.MappingTool.record(MappingTool.java:559)
at
org.apache.openjpa.jdbc.meta.MappingTool.record(MappingTool.java:455)
My persistence.xml is as simple as it can be:
[code]
persistence-unit name=${project.artifactId}Pu transaction-type=JTA
providerorg.apache.openjpa.persistence.PersistenceProviderImpl/provider
jta-data-sourceosgi:service/javax.sql.DataSource/(amp;(
osgi.jndi.service.name
=${project.parent.artifactId}.database)(aries.managed=true))/
jta-data-source
properties
property name=openjpa.Log value=slf4j/
property name=openjpa.jdbc.SynchronizeMappings value=
buildSchema(ForeignKeys=true,SchemaAction=refresh)/
property name=openjpa.jdbc.DBDictionary value=derby/
/persistence-unit
[/code]
Is there any property/option to set somewhere?
Regards,
--
Charlie Mordant
Full OSGI/EE stack made with Karaf:
https://github.com/OsgiliathEnterprise/net.osgiliath.parent
OpenJPA and auto-commit
Hi OpenJPA Guru's,
I'm encountering an issue when openJPA participates to a global
transaction, I've got this weird error happening sometimes:
Caused by: openjpa-2.3.0-r422266:1540826 nonfatal general error
org.apache.openjpa.persistence.PersistenceException:
setAutoCommit(true) invalid during global transaction.
at org.apache.openjpa.jdbc.meta.MappingTool.record(MappingTool.java:559)
at org.apache.openjpa.jdbc.meta.MappingTool.record(MappingTool.java:455)
My persistence.xml is as simple as it can be:
[code]
persistence-unit name=${project.artifactId}Pu transaction-type=JTA
providerorg.apache.openjpa.persistence.PersistenceProviderImpl/provider
jta-data-sourceosgi:service/javax.sql.DataSource/(amp;(
osgi.jndi.service.name
=${project.parent.artifactId}.database)(aries.managed=true))/
jta-data-source
properties
property name=openjpa.Log value=slf4j/
property name=openjpa.jdbc.SynchronizeMappings value=
buildSchema(ForeignKeys=true,SchemaAction=refresh)/
property name=openjpa.jdbc.DBDictionary value=derby/
/persistence-unit
[/code]
Is there any property/option to set somewhere?
Regards,
--
Charlie Mordant
Full OSGI/EE stack made with Karaf:
https://github.com/OsgiliathEnterprise/net.osgiliath.parent
