Re: What we have so far
Thanks Patrick, Are there any other pieces of code that I'd need to get running to XML? I'm happy to keep experimenting with what we have, unless you know there's something missing (I'd rather not distract you from dropping the JDBC code). Regards, On 7/18/06, Patrick Linskey [EMAIL PROTECTED] wrote: I don't think that anyone has actually tried to wire up the XML store manager at runtime based on the code in the svn repository. Right now, we're focussed mostly on getting the JDBC code drop ready, and so have been neglecting any polishing / testing / etc. of the code that *is* in the repo. -Patrick -- Patrick Linskey BEA Systems, Inc. -Original Message- From: Michael Dick [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 18, 2006 1:00 PM To: open-jpa-dev@incubator.apache.org Subject: What we have so far Hi all, I've been trying to run some basic tests with the recent code drop. I've been able to get an EntityMangerFactory and EntityManager, but I'm getting stuck when I connect to a database. I had to add some properties to persistence.xml to create the emf and em. Here's the relevant code : properties property name=openjpa.BrokerFactory !-- I tried org.apache.openjpa.BrokerFactory but it didn't work for me -- value= org.apache.openjpa.abstractstore.AbstractStoreBrokerFactory / property name=org.apache.openjpa.abstractstore.AbstractStoreManager value=org.apache.openjpa.xmlstore.XMLStoreManager / /properties I was also able to get the PCEnhancer to run against some entity classes. The only obstacle there was getting the classpath set up appropriately. When I try to find or persist an entity I get an exception like this : 0|false|0.0.1 org.apache.openjpa.persistence.PersistenceException: null at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:820) at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:703) at org.apache.openjpa.kernel.DelegatingBroker.find(DelegatingBroker.java :176) at org.apache.openjpa.persistence.EntityManagerImpl.find( EntityManagerImpl.java:303) . . . at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run( RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main( RemoteTestRunner.java:196) Caused by: java.lang.NullPointerException at java.io.File.init(File.java:220) at org.apache.openjpa.xmlstore.XMLFileHandler.getFile( XMLFileHandler.java:113) at org.apache.openjpa.xmlstore.XMLFileHandler.load(XMLFileHandler.java :77) at org.apache.openjpa.xmlstore.XMLStore.getMap(XMLStore.java:77) at org.apache.openjpa.xmlstore.XMLStore.getData(XMLStore.java:56) at org.apache.openjpa.xmlstore.XMLStoreManager.initialize( XMLStoreManager.java:105) at org.apache.openjpa.kernel.DelegatingStoreManager.initialize( DelegatingStoreManager.java:108) at org.apache.openjpa.kernel.ROPStoreManager.initialize( ROPStoreManager.java:57) at org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:842) at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:794) ... 22 more Is this expected with the code that is currently in SVN, or do I just need some more configuration properties? Thanks, -- -Michael Dick ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -- -Michael Dick
Re: [jira] Commented: (OPENJPA-12) Default to strictIdentityTypes for JPA
I think it would be better to pass the TCK without any properties that change behavior. Does anyone know if Sun has a guideline regarding the configuration properties? On 8/15/06, Patrick Linskey (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/OPENJPA-12?page=comments#action_12428175 ] Patrick Linskey commented on OPENJPA-12: I know that we changed this in our JPA TCK test-running environment via the property setting. I guess the question at hand is whether the default should be to be strict or to be lenient for JPA installations. Does anyone have a dissenting opinion? Default to strictIdentityTypes for JPA -- Key: OPENJPA-12 URL: http://issues.apache.org/jira/browse/OPENJPA-12 Project: OpenJPA Issue Type: Bug Components: jpa Reporter: Michael Dick Priority: Minor Attachments: patch.txt The default behavior with OpenJPA is to be very forgiving regarding the Primary Key types passed in when calling EntityManager.find or EntityManager.getReference . For example if an Entity has an ID of type Long OpenJPA will attempt to convert anything that extend java.lang.Number and Strings (maybe others). This is a nice feature, but I don't think it should be the default behavior. The JPA spec indicates that an IllegalArgumentException should be thrown if the second argument is not a valid type for the Entity's primary key. There is some room for interpretation as to what constitutes a valid type, conversion for all Numbers makes sense, but String might be pushing it. Workaround : Add the following to persistence.xml property name=openjpa.Compatibility value=strictIdentityValues=true / Proposed Solution : The OpenJPA compatibility plugin provides a mechanism to enforce strict identity checking (defaulting to false). There's no need to change the default in the kernel (other persistence apis like JDO might be more lenient) so I propose changing the default in PersistenceProductDerivation.beforeConfigurationLoad(). Changing it there should only effect the JPA facade and leave the OpenJPA kernel's default in place for other facades. The value may be overridden by adding the following property to persistence.xml property name=openjpa.Compatibility value=strictIdentityValues=false / -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- -Michael Dick
Re: JIRA bug tracking of code changes
+1 for adding enforcement. At worst it's a minor inconvenience, and it's a good habit to get into. If there's an impact to any other projects or if it's going to be a nightmare to implement I'll reconsider. -Mike On 8/18/06, Craig L Russell [EMAIL PROTECTED] wrote: I have asked the question on infrastructure@, but we might also find out if the others on openjpa want to have enforcement of JIRA issue on commits. What do you all think? Craig On Aug 18, 2006, at 8:34 AM, Kevin Sutter wrote: That did the trick, Craig. Thanks! Now that we are on the same page, we're back to your original question of whether this is enforceable or not. (And, if we even to make this enforceable.) I would guess that we have to revert to some outside tooling such as SCMBug to make this enforceable. Kevin On 8/18/06, Craig L Russell [EMAIL PROTECTED] wrote: Hi Kevin, You should be able to see svn now. I added you to openjpa-developers (you need this anyway). I added jira-users to permissions to see svn checkins. (Actually, this should be the default for all svn checkins for the Apache installation. I've made a note). Try it now. Craig On Aug 18, 2006, at 6:17 AM, Kevin Sutter wrote: Craig, I must be blind or something. I looked at OPENJPA-3 before and I don't see the change history. I see the attached diff file, but that won't always be the case with committers. I am logged into JIRA. Is there some other configuration that I need to do to view these changes? Thanks, Kevin On 8/18/06, Craig L Russell [EMAIL PROTECTED] wrote: Hi Kevin, On Aug 17, 2006, at 7:16 AM, Kevin Sutter wrote: As a start, it would be good if we had this plugin support: http://www.atlassian.com/software/jira/docs/v3.2/ svn_integration.html Do we know if this is available for our SVN/JIRA setup within Apache? Having the extra tab with the corresponding file adds, deletes, and modifies would be nice. Absolutely Apache JIRA do have this installed. Take a look at the bug OPENJPA-3 below that has a checkin associated. What I don't know is whether they offer forced JIRA on every checkin. Craig Kevin On 8/17/06, Craig L Russell [EMAIL PROTECTED] wrote: Hi Kevin, SVN does have a tie-in to JIRA at Apache. The key is to include the project-issue as the first characters of the commit message. Then JIRA will magically (ask infrastructure) pick up the commit and update the issue for you. http://issues.apache.org/jira/browse/OPENJPA-3 svn commit -m Brett Porter's patch to resolve OPENJPA-3 openjpa- lib/ src/test/java/org/apache/openjpa/lib/util/ TestPropertiesParser.java But to answer your other questions, On Aug 16, 2006, at 9:10 AM, Kevin Sutter wrote: Hi, Looking for some guidance from more experienced Apache developers... Is there a means of enforcing the SVN commit process to include a JIRA bug or enhancement number so that the code changes are associated with that particular bug or enhancement? I searched some mailing list archives and found that the Apache Logging project at least investigated this process, but I couldn't tell if it turned into something real or not. Don't know. Would be nice. I know there are tools like SCMBug which provide something like this.. Specifically, I would like to enforce rules similar to the following: o Enforces that you specify a bug id [#n] will all commits to SVN (or, whatever syntax works with JIRA) o Enforces that you specify a comment with all commits that is at least 10 characters long (or, some arbitrary length) o Enforces that you have a valid user ID with the Tracker o Enforces that you have specified a valid bug id (the bug exists and is in the proper state, e.g. not CLOSED or CANCELLED) Is this configurable with Apache projects usage of SVN and JIRA? And, if this is configurable, would OpenJPA be interested in enforcing this type of mechanism? I've used these type of processes with other open-source projects and found the history useful when reviewing old bug reports. I'd be interested in enforcing some of these rules. My experience with this kind of enforcement is that it's just another process hoop to jump through, and while some developers find it stifling, I find it good to have some additional structure. But first things first. Is there an enforcement arm of svn? Craig Thanks, Kevin Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/ products/ jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/ products/ jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO?
Re: openjpa.zip
FWIW I'm happy to take a crack at this if we have enough approval to make a change. Should I go ahead and open a JIRA feature? -Michael Dick On 9/30/06, Kevin Sutter [EMAIL PROTECTED] wrote: Agree. The openjpa-version.jar should be sufficient for distribution. Kevin On 9/29/06, Patrick Linskey [EMAIL PROTECTED] wrote: Hi, Currently, the openjpa-version.zip that gets built in the openjpa-project module contains all the individual module jars *and* the openjpa-all-version.jar. Is this desirable / necessary? My feeling is that the dist should contain just openjpa-all-version.jar, possibly renamed to openjpa-version.jar. Thoughts? -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: WASTransformer
+1 for moving to org.apache.openjpa.ee. I don't really have a strong feeling about where the class should go. As you said it's really a build utility, I just wasn't sure where the best place was to put it. +0.5 for moving the logic in to WASManagedRuntime.main(). Go ahead and move it unless someone objects, there's no real need for another class. +0 on beanshell. I don't know enough about beanshell, I don't have a reason to not change it if beanshell will work better. -Mike On 10/27/06, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: On Oct 27, 2006, at 9:41 AM, Abe White wrote: Does anyone mind if I move this class from the org.apache.openjpa.util package to the org.apache.openjpa.ee package? It's a very EE-specific class, and in my mind is not a general utility other parts of the system will ever use. I'd even consider removing the class altogether and just moving its main() method to the WASManagedRuntime -- it's really just a build helper for the WASManagedRuntime. +1 for moving it to org.apache.openjpa.ee. Alternatively, we could establish some sort of top-level build module and put it there, as the class is only invoked as part of the build process. Or even do the work of the class in beanshell or something in our build scripts (assuming maven supports it). Ideally, it would be a Maven plugin, but unfortunately, I haven't found any simple way of including a plugin with the OpenJPA source. The Maven plugin API is simple enough to write to, but Maven seems to require that the plugin be installed in the repository in order to be usable by a project, which means that it can't just be included as a module to the openjpa project, but instead needs to be maintained as a separate project. Very annoying. Anyway, I don't think it is too bad to invoke it from the maven- antrun-plugin. It is possible to embed a beanshell script within a maven-antrun-plugin as well, but if the logic is at all complex, it is just as easy to include it in a helper class. I have no opinion on whether the logic should be moved into WASManagedRuntime.main() or not. Thoughts? __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: WASTransformer
On 10/27/06, Abe White [EMAIL PROTECTED] wrote: +0.5 for moving the logic in to WASManagedRuntime.main(). Go ahead and move it unless someone objects, there's no real need for another class. I went ahead and did this. I also moved WASManagedRuntime's caching logic to its endConfiguration() callback to avoid the threading issues that seemed inherent in using delayed caching. Finally, I made the members of WASManagedRuntime private instead of protected, just because the rest of the codebase only uses protected members when a class is meant to be extended. Let me know if you see problems with any of these changes. One more thing: I removed the logging of errors that are thrown as exceptions. IMO, if you're throwing an exception, you're making it the caller's choice on how to handle it, including whether to log it. That's been our practice throughout the codebase, anyway. Otherwise you tend to wind up with the same errors being recorded many times. I screwed up there. I should have used log.Trace() instead of log.Error(). I agree that we shouldn't be logging exceptions as a matter of course (certainly not at the most visible logging level). In general I think it is useful to include them in diagnostic traces. I usually direct trace to a file and I've found it helpful to have the exceptions included in the trace (maybe that's because I'm lazy and I don't handle the exceptions as well as I should in the app). On the other hand it looks like the EntityManager exposes the configuration and the log to the application and the application could log the message. If our best practice is not to write to the log when you throw an exception then I'll avoid doing it in the future. Thanks for catching it for me. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -- -Michael Dick
Re: Build OpenJPA from svn
Hi Michael, If you're starting from scratch with Maven there can be some problems downloading the dependencies. The way to resolve them is to try the build again. If you look through the mailing list archives (Fri, 25 Aug 2006 15:52:04 GMT by Marc Logemann). Here's a link to the archive, http://mail-archives.apache.org/mod_mbox/incubator-open-jpa-dev/200608.mbox/thread. If you're seeing something like this : roject ID: org.apache.maven.doxia:doxia-sink-api Reason: Error getting POM for 'org.apache.maven.doxia:doxia-sink-api' from the repository: Error transferring file org.apache.maven.doxia:doxia-sink-api:pom:1.0-alpha-8 from the specified remote repositories: central (http://repo1.maven.org/maven2), apache.snapshots (http://svn.apache.org/maven-snapshot-repository), snapshots (http://snapshots.maven.codehaus.org/maven2) Then you're best bet is to run maven again. it might take a few times but eventually you'll get all the dependencies. If you're seeing something completely different, then please post the error that you're seeing and I'll try to help. On 10/29/06, Michael Post [EMAIL PROTECTED] wrote: Hello, i want to build the openjpa from the current subversion-repository. The download works great, but building with maven (mvn install) finish with errors. Some packages can not be downloaded from there source on the apache.org-server. Can anyone give me a build-version from openjpa per pm or can me give some fixes / advice for my prob? Thanks Michael -- -Michael Dick
Re: Possible performance concerns?
On 10/27/06, Abe White [EMAIL PROTECTED] wrote: Fair enough. But, unless Kodo is replacing the JPQL parsing, I don't see how you can get around this problem. I suppose it's possible that other performance improvements could negate the performance hit associated with the reflective class loading. But, it would seem that if Kodo 4.1 is using OpenJPA, then these same type of issues would exist there. Kodo caches compiled queries. Is there a plugin point where we could add a compiled query cache? It seems like something that would be nice to have in OpenJPA, even if it isn't as robust as the one in Kodo. Also, regarding a name-type cache, we already have that in OpenJPA with the MetaDataRepository.getMetaData(String alias, ...) method. I don't know anything about our JPQL parsing, but I'm sure it's already using that method. Maybe it tries to use both that method and then reflective loading if no alias exists? Does it try to load anything other than the from clause members as classes? I did a little playing around, in my non-exhaustive testing it seemed to call classForName each time you accessed a field on an Entity. Select p.firstName from Person p where p.id = 1 called QueryImpl.classForName twice. Select p.firstName from Person p called classForName once. I really haven't looked into this enough to know whether I'm just being dense, is there a way to cache the class so we don't have to look it up each time? ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -- -Michael Dick
Re: add-was-interfaces
Hi Patrick,
I just ran svn update and mvn clean package and I didn't get the error and I
didn't put any WebSphere jars on the classpath (ran it at home to make
sure). Are you using the newer version of Serp by any chance? I tried the
-X and -e flags with maven and I didn't see the same problem, I'm not sure
what else I could be doing different.
As far as I know the WebSphere interfaces aren't published (as class files)
anywhere so we can't compile against them. To get around the problem I used
Serp to add the interface to the class. At the time I didn't see any errors
from Serp, but if that's no longer the case we'll have to come up with
something else.
One alternative is to create a stub class similar to what we do for
sun.misc.Perf in openjpa-lib, assuming that doesn't violate a license
agreement.
On 11/6/06, Patrick Linskey [EMAIL PROTECTED] wrote:
Hi,
I get the following stack trace when running 'mvn package'. It looks
like I don't have some required IBM classes in my classpath.
Surprisingly, this exception does not cause the build to fail, but
presumably, the output bytes are not the same as if this had run
successfully.
Does anyone have any suggestions for either getting the classes into the
classpath or moving the exception to runtime, so that there aren't
build-time dependency issues resulting in different jars from the same
sources?
Thanks,
-Patrick
Partial stack trace:
[INFO] [antrun:run {execution: add-was-interfaces}]
[INFO] Executing tasks
[java] java.lang.IllegalArgumentException:
java.lang.NoClassDefFoundError:
com/ibm/websphere/jtaextensions/SynchronizationCallback
[java] at
org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:180)
[java] at org.apache.tools.ant.taskdefs.Java.run(Java.java:710)
[java] at
org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:178)
[java] at
org.apache.tools.ant.taskdefs.Java.execute(Java.java:84)
[java] at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
[java] at org.apache.tools.ant.Task.perform(Task.java:364)
[java] at org.apache.tools.ant.Target.execute(Target.java:341)
[java] at
org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntM
ojo.java:108)
[java] at
org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:83)
[java] at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginMa
nager.java:412)
[java] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Default
LifecycleExecutor.java:534)
.
[java] Caused by: java.lang.IllegalArgumentException:
java.lang.NoClassDefFoundError:
com/ibm/websphere/jtaextensions/SynchronizationCallback
[java] at serp.util.Strings.toClass(Strings.java:211)
[java] at serp.util.Strings.toClass(Strings.java:140)
[java] at serp.bytecode.BCClass.getType(BCClass.java:565)
[java] at serp.bytecode.BCClass.write(BCClass.java:202)
[java] at
org.apache.openjpa.ee.WASManagedRuntime.main(WASManagedRuntime.java:412)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
--
-Michael Dick
Re: add-was-interfaces
I wish I'd thought to try that :-).
I have a hack that should get around the problem. I opened a a JIRA report
#76 to track the problem (not trying to steal credit, just didn't want to
pass patch files around the mailing list).
Thanks for catching the problem.
On 11/6/06, Patrick Linskey [EMAIL PROTECTED] wrote:
Looks like it only happens on a non-clean run. Makes sense, since
presumably on the second run, it tries to instantiate the then-processed
plugin, at which time the exception occurs.
Interesting. It could be that you're using serp in a way that requires
the classes to be loadable.
(Can't investigate further... dinner is calling...)
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
-Original Message-
From: Michael Dick [mailto:[EMAIL PROTECTED]
Sent: Monday, November 06, 2006 7:14 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: add-was-interfaces
Hi Patrick,
I just ran svn update and mvn clean package and I didn't get
the error and I
didn't put any WebSphere jars on the classpath (ran it at home to make
sure). Are you using the newer version of Serp by any chance?
I tried the
-X and -e flags with maven and I didn't see the same problem,
I'm not sure
what else I could be doing different.
As far as I know the WebSphere interfaces aren't published
(as class files)
anywhere so we can't compile against them. To get around the
problem I used
Serp to add the interface to the class. At the time I didn't
see any errors
from Serp, but if that's no longer the case we'll have to come up with
something else.
One alternative is to create a stub class similar to what we do for
sun.misc.Perf in openjpa-lib, assuming that doesn't violate a license
agreement.
On 11/6/06, Patrick Linskey [EMAIL PROTECTED] wrote:
Hi,
I get the following stack trace when running 'mvn package'. It looks
like I don't have some required IBM classes in my classpath.
Surprisingly, this exception does not cause the build to fail, but
presumably, the output bytes are not the same as if this had run
successfully.
Does anyone have any suggestions for either getting the
classes into the
classpath or moving the exception to runtime, so that there aren't
build-time dependency issues resulting in different jars
from the same
sources?
Thanks,
-Patrick
Partial stack trace:
[INFO] [antrun:run {execution: add-was-interfaces}]
[INFO] Executing tasks
[java] java.lang.IllegalArgumentException:
java.lang.NoClassDefFoundError:
com/ibm/websphere/jtaextensions/SynchronizationCallback
[java] at
org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.
java:180)
[java] at
org.apache.tools.ant.taskdefs.Java.run(Java.java:710)
[java] at
org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:178)
[java] at
org.apache.tools.ant.taskdefs.Java.execute(Java.java:84)
[java] at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
[java] at org.apache.tools.ant.Task.perform(Task.java:364)
[java] at
org.apache.tools.ant.Target.execute(Target.java:341)
[java] at
org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(Ab
stractAntM
ojo.java:108)
[java] at
org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:83)
[java] at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(Defau
ltPluginMa
nager.java:412)
[java] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoa
ls(Default
LifecycleExecutor.java:534)
.
[java] Caused by: java.lang.IllegalArgumentException:
java.lang.NoClassDefFoundError:
com/ibm/websphere/jtaextensions/SynchronizationCallback
[java] at serp.util.Strings.toClass(Strings.java:211)
[java] at serp.util.Strings.toClass(Strings.java:140)
[java] at serp.bytecode.BCClass.getType(BCClass.java:565)
[java] at serp.bytecode.BCClass.write(BCClass.java:202)
[java] at
org.apache.openjpa.ee.WASManagedRuntime.main(WASManagedRuntime
.java:412)
[java] at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
--
Patrick Linskey
BEA Systems, Inc.
__
_
Notice: This email message, together with any attachments,
may contain
information of BEA
Re: svn commit: r472680 - /incubator/openjpa/trunk/openjpa-project/assembly.xml
No, I was seeing the same thing. I ended up creating a jar-assembly.xml file
which unpacked openjpa-all-${version}.jar to a temp directory then re-jarred
it as /target/aggregate/openjpa-${version}.jar. Then I noticed you already
fixed the problem.
I don't particularly like recreating the jar, but if it'll help I can send a
patch of what I had.
On 11/8/06, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:
I'd be happy to have a non -all suffixed jar, but without my last
change, I wasn't seeing *any* openjpaXXX.jar file being put into
the .zip package.
Are you seeing something different?
On Nov 8, 2006, at 3:33 PM, Michael Dick wrote:
This puts the -all suffix back into the jar name. We took it out in
OPENJPA-65. It's just a name, might not be a big deal.
I'm not sure if there's a good way to remove the -all suffix. I
suppose one
could unpack openjpa-all-${version} and repackage it (I think
that's what we
were doing before). It's probably possible to have a script rename
the jar
before the zip gets created too, but the timing might get tricky.
Or maybe I'm missing something I've tried it with clean build and
without
this time though :-)
-Mike
On 11/8/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: mprudhom
Date: Wed Nov 8 14:59:41 2006
New Revision: 472680
URL: http://svn.apache.org/viewvc?view=revrev=472680
Log:
Manually include the openjpa-all module in the zip file. For some
reason,
it wasn't being included in the package.
Modified:
incubator/openjpa/trunk/openjpa-project/assembly.xml
Modified: incubator/openjpa/trunk/openjpa-project/assembly.xml
URL:
http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-
project/assembly.xml?view=diffrev=472680r1=472679r2=472680
=
=
--- incubator/openjpa/trunk/openjpa-project/assembly.xml (original)
+++ incubator/openjpa/trunk/openjpa-project/assembly.xml Wed Nov 8
14:59:41 2006
@@ -59,6 +59,14 @@
/fileSets
dependencySets
dependencySet
+outputDirectory//outputDirectory
+unpackfalse/unpack
+scoperuntime/scope
+includes
+includeorg.apache.openjpa:openjpa-all/include
+/includes
+/dependencySet
+dependencySet
outputDirectory/lib/outputDirectory
unpackfalse/unpack
scoperuntime/scope
--
-Michael Dick
Re: svn commit: r472680 - /incubator/openjpa/trunk/openjpa-project/assembly.xml
I'm fine with leaving it in - it shouldn't hold up the release, I just
wanted it noted. I should have mentioned that in the first post.
Better to take the time and get it fixed right rather than hack something in
anyway :-)
On 11/8/06, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:
Can we live with the -all- name for right now? I'm trying to get
ready to vote on a release, and I've found that playing with that
stuff can wind up being a lot more time consuming than I always
expect it to be.
On Nov 8, 2006, at 3:50 PM, Michael Dick wrote:
No, I was seeing the same thing. I ended up creating a jar-
assembly.xml file
which unpacked openjpa-all-${version}.jar to a temp directory then
re-jarred
it as /target/aggregate/openjpa-${version}.jar. Then I noticed you
already
fixed the problem.
I don't particularly like recreating the jar, but if it'll help I
can send a
patch of what I had.
On 11/8/06, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:
I'd be happy to have a non -all suffixed jar, but without my last
change, I wasn't seeing *any* openjpaXXX.jar file being put into
the .zip package.
Are you seeing something different?
On Nov 8, 2006, at 3:33 PM, Michael Dick wrote:
This puts the -all suffix back into the jar name. We took it out in
OPENJPA-65. It's just a name, might not be a big deal.
I'm not sure if there's a good way to remove the -all suffix. I
suppose one
could unpack openjpa-all-${version} and repackage it (I think
that's what we
were doing before). It's probably possible to have a script rename
the jar
before the zip gets created too, but the timing might get tricky.
Or maybe I'm missing something I've tried it with clean build and
without
this time though :-)
-Mike
On 11/8/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: mprudhom
Date: Wed Nov 8 14:59:41 2006
New Revision: 472680
URL: http://svn.apache.org/viewvc?view=revrev=472680
Log:
Manually include the openjpa-all module in the zip file. For some
reason,
it wasn't being included in the package.
Modified:
incubator/openjpa/trunk/openjpa-project/assembly.xml
Modified: incubator/openjpa/trunk/openjpa-project/assembly.xml
URL:
http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-
project/assembly.xml?view=diffrev=472680r1=472679r2=472680
=
=
--- incubator/openjpa/trunk/openjpa-project/assembly.xml
(original)
+++ incubator/openjpa/trunk/openjpa-project/assembly.xml Wed
Nov 8
14:59:41 2006
@@ -59,6 +59,14 @@
/fileSets
dependencySets
dependencySet
+outputDirectory//outputDirectory
+unpackfalse/unpack
+scoperuntime/scope
+includes
+includeorg.apache.openjpa:openjpa-all/include
+/includes
+/dependencySet
+dependencySet
outputDirectory/lib/outputDirectory
unpackfalse/unpack
scoperuntime/scope
--
-Michael Dick
--
-Michael Dick
Re: svn commit: r492225 - in /incubator/openjpa/trunk: openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/meta/ openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/schema/ openjpa-jdbc/src/main/resourc
I'm a little unclear on why the code is in ClassMapping, too. It seems like
it could go in the SchemaGenerator along with generatePrimaryKeys(),
generateIndexes(), etc.
Pinaki, is there any reason why we can't move the code into a more common
location?
On 1/3/07, Abe White [EMAIL PROTECTED] wrote:
I don't agree with this implementation. It doesn't leave any room
for customization through MappingDefaults, it ties the ClassMapping
to the XMLSchemaParser (?!), and it's totally different than our
mapping of indexes, foreign keys, and primary keys, the other
supported constraint types.
+mapUniqueConstraints();
+}
+
+/**
+ * Adds unique constraints to the mapped table.
+ *
+ */
+void mapUniqueConstraints() {
+Log log = getRepository().getLog();
+Collection uniqueInfos = _info.getUniqueConstraints();
+if (uniqueInfos == null || uniqueInfos.isEmpty())
+return;
+Iterator iter = uniqueInfos.iterator();
+Table table = getTable();
+int i = 1;
+while (iter.hasNext()) {
+XMLSchemaParser.UniqueInfo uniqueInfo =
+(XMLSchemaParser.UniqueInfo)iter.next();
+if (uniqueInfo.cols == null || uniqueInfo.cols.isEmpty())
+continue;
+String constraintName = table.getName() + _UNIQUE_ + i;
+i++;
+Unique uniqueConstraint = table.addUnique
(constraintName);
+Iterator uniqueColumnNames = uniqueInfo.cols.iterator();
+while (uniqueColumnNames.hasNext()) {
+String uniqueColumnName = (String)
uniqueColumnNames.next();
+Column uniqueColumn = table.getColumn
(uniqueColumnName);
+if (uniqueColumn != null) {
+uniqueConstraint.addColumn(uniqueColumn);
+} else {
+table.removeUnique(uniqueConstraint);
+if (log.isWarnEnabled())
+log.warn(_loc.get(missing-unique-column,
this,
+table.getName(), uniqueColumnName));
+break;
+}
}
}
}
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
--
-Michael Dick
Re: Errors setting up openjpa projects in Eclipse
On 1/6/07, Igor Fedorenko [EMAIL PROTECTED] wrote: How do you generate Eclipse projects? mvn eclipse:eclipse from OpenJPA source root almost ;-) works for me. I manually fix openjpa-kernel/target/generated-sources source path after importing projects, but everything else seems to be handled properly. This works for me. The only other thing you need to do is define a M2_REPO classpath variable which points to your maven 2 repository. Rahul Thakur wrote: Hi, I am just starting out with OpenJPA and tried generating and importing projects in an Eclipse workspace but I get to see the following errors for all the imported modules. [snip - as copied from Problems view] Severity and Description Path Resource Location Creation Time Id Cannot nest output folder 'openjpa-examples/target/classes/META-INF' inside output folder 'openjpa-examples/target/classes' openjpa-examples Build path 1168072979859 63185 It looks like you have openjpa-examples/target/classes/ specified as a source folder, and openjpa-examples/target/classes/META-INF specified as the output folder. Try using these Source Folders : openjpa-examples/src/main/java openjpa-examples/src/test/java Output Folder : openjpa-examples/target/classes This is what maven should set up when you run mvn eclipse:eclipse. [/snip] Thanks in advance, Rahul -- -Michael Dick
Re: Missing ProductDerivation resource error
atorg.apache.openjpa.conf.BrokerFactoryValue.clinit(
BrokerFactoryValue.java:47)
atorg.apache.openjpa.conf.OpenJPAConfigurationImpl.init(
OpenJPAConfigurationImpl.java:178)ator
g.apache.openjpa.conf.OpenJPAConfigurationImpl.init(
OpenJPAConfigurationImpl.java:154)
atorg.apache.openjpa.conf.OpenJPAConfigurationImpl.init(
OpenJPAConfigurationImpl.java:145)
atorg.apache.openjpa.enhance.PCEnhancer.main(PCEnhancer.java:3605)Caused
by: java.util.MissingResourceException: Your system is missingproduct
derivations. Product derivations provide configuration optionsfor supported
datastores and specifications. You must have
aMETA-INF/services/org.apache.openjpa.lib.conf.ProductDerivation file inyour
classpath listing the available derivation classes, and some listedclass
must be instantiable. Typically this file is bundled as part ofthe
distribution. Have you unbundled it, or unbundled its listedclasses? If you
are using ant, a common solution to this problem is toplace the jar
libraries of the OpenJPA distribution in the${user.home}/.ant/lib
directory. Another common cause of this problem isan overly-restrictive
security manager.{1}
atorg.apache.openjpa.lib.conf.ProductDerivations.clinit(
ProductDerivations.java:64)... 5 more[ERROR]
[INFO]
[ERROR]
BUILD ERROR[INFO]
[INFO]
The OpenJPA Enhancer tool exited with a non-null exit code.[INFO]
[DEBUG]
Traceorg.apache.maven.lifecycle.LifecycleExecutionException: The
OpenJPAEnhancer tool exited with a non-null exit code.
atorg.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(
DefaultLifecycleExecutor.java:559)
atorg.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal
(DefaultLifecycleExecutor.java:488)
atorg.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(
DefaultLifecycleExecutor.java:458)
atorg.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoa
lAndHandleFailures(DefaultLifecycleExecutor.java:306)
atorg.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(
DefaultLifecycleExecutor.java:273)
atorg.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(
DefaultLifecycleExecutor.java:140)
atorg.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)at
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)at
org.apache.maven.cli.MavenCli.main(MavenCli.java:256)at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
atsun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)
atsun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)at
java.lang.reflect.Method.invoke(Method.java:585)
atorg.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)at
org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
atorg.codehaus.classworlds.Launcher.mainWit
hExitCode(Launcher.java:430)at
org.codehaus.classworlds.Launcher.main(Launcher.java:375)Caused by:
org.apache.maven.plugin.MojoExecutionException: The OpenJPAEnhancer tool
exited with a non-null exit code.
atorg.codehaus.mojo.openjpa.OpenJpaEnhancerMojo.enhance(
OpenJpaEnhancerMojo.java:194)
atorg.codehaus.mojo.openjpa.OpenJpaEnhancerMojo.execute(
OpenJpaEnhancerMojo.java:88)
atorg.apache.maven.plugin.DefaultPluginManager.executeMojo(
DefaultPluginManager.java:412)
atorg.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(
DefaultLifecycleExecutor.java:534)... 16 more[INFO]
[/snip]
--
-Michael Dick
Re: Missing ProductDerivation resource error
the properties or pro pertiesFile attributes of the task's nested config element. This can also occur if your OpenJPA distribution jars are corrupt, or if your security policy is o verly strict. at org.apache.openjpa.meta.MetaDataRepository.initializeMetaDataFactory( MetaDataRepository.java :1470) at org.apache.openjpa.meta.MetaDataRepository.endConfiguration( MetaDataRepository.java:1463) at org.apache.openjpa.lib.conf.Configurations.configureInstance( Configurations.java:422) at org.apache.openjpa.lib.conf.Configurations.configureInstance( Configurations.java:347) at org.apache.openjpa.lib.conf.PluginValue.instantiate(PluginValue.java:99) at org.apache.openjpa.lib.conf.ObjectValue.instantiate (ObjectValue.java:70) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.newMetaDataRepositoryInstance (OpenJPAConfigurationImpl.java:831) at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java :3652) at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:3635) at org.apache.openjpa.enhance.PCEnhancer.main(PCEnhancer.java:3607) [ERROR] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] The OpenJPA Enhancer tool exited with a non-null exit code. [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: The OpenJPA Enhancer tool exited with a non-null exit code. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals ( DefaultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal( DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal ( DefaultLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures (DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments ( DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute( DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java :322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java :39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode (Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: The OpenJPA Enhancer tool exited with a non-null exit code. at org.codehaus.mojo.openjpa.OpenJpaEnhancerMojo.enhance( OpenJpaEnhancerMojo.java:194) at org.codehaus.mojo.openjpa.OpenJpaEnhancerMojo.execute( OpenJpaEnhancerMojo.java:88) at org.apache.maven.plugin.DefaultPluginManager.executeMojo ( DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals( DefaultLifecycleExecutor.java:534) ... 16 more [/snip] - Original Message - From: Michael Dick [EMAIL PROTECTED] To: open-jpa-dev@incubator.apache.org Sent: Monday, January 08, 2007 5:39 AM Subject: Re: Missing ProductDerivation resource error Hi Rahul, It looks like the plugin is only adding the openjpa-kernel and openjpa-lib jars to the classpath. Can you configure the plugin to use openjpa-all? The the product derivations are aggregated in the openjpa-all jar file which should resolve the missing resource problem. -- -Michael Dick
Locking in AbstractBrokerFactory
Hi, We've been running some multi-threaded tests with OpenJPA in a managed environment and it looks like we've hit a bit of a bottleneck. Many of the threads are waiting on the lock in AbstractBrokerFactory.newBroker(). I took a look at the code inside the lock and it looks like the main thing it's doing is managing a cache of EntityManagers. If there's a EM/Broker associated with the current transaction and its user password (not sure why we're checking them) match then the EM is returned to the caller. I thought that the transaction to EM relationship was maintained by the container (section 5.1 of the JPA spec). At first glance it looks like we're duplicating effort, are there other reasons that OpenJPA needs to maintain the relationship between transactions and EMs? Besides this cache for the EMs, is there any reason to have a heavy lock in newBroker()? I get the feeling I'm missing something obvious here. Thanks, -- -Michael Dick
Re: [DISCUSS] Move to TestNG?
For what it's worth Marc is right. I've used testng via the surefire plugin as a front end to running jUnit tests. In my case I just tried to get them to run in parallel, but we should be able to use groups in the same manner. On 2/1/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Here's a good article comparing TestNG with JUnit: http://www-128.ibm.com/developerworks/java/library/j-cq08296/ IMO, the groups feature is nice, but isn't necessarily sufficient to justify a lot of effort porting over tests (since we could always just check a system property before running expected failure tests or something). However, one feature that does sound very nice is their support for parametric testing. If I understand it correctly, this would allow us to automatically run tests against various data model implementations. This would be nice, because we could have a set of interfaces for data models and implementations that vary their mapping details (single-table mapping, table-per-class mapping, joined mapping, mappings with attributes in secondary tables, orm.xml mappings, etc), and transparently run the same tests against each of the data models. This would dramatically expand the completeness of our tests, since historically we have only done things like TestJustAFewSimpleOperationsAgaintCompositePrimaryKeyClasses, TestSomeOtherNuanceOfEmbeddedRelations, etc. Also, note that I don't think that using TestNG vs. JUnit is necessarily an xor proposition: I think that Maven's surefire harness can run against both frameworks simultaneously, and aggregate the test results. I'm not sure though. I'll play around with it a little bit today and let you all know the results. On Feb 1, 2007, at 11:08 AM, Patrick Linskey wrote: Hi, According to the discussion at https://issues.apache.org/jira/browse/OPENJPA-123, it looks like TestNG's concept of test groups could let us easily create tests that are expected to fail, and exclude them from test runs until the corresponding behavior is fixed / feature is implemented. What do you guys think about moving to TestNG? I believe that the work involved is minimal; there are some conversion tools / compatibility modes or something. -Patrick -- Patrick Linskey BEA Systems, Inc. __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -- -Michael Dick
Exception when using java.sql.Date as an id
Hi,
I'm getting the following exception when I try to fetch an entity with a
java.sql.Date as the id :
java.lang.NoSuchMethodError: org.apache.openjpa.util.DateId.getId
()Ljava/sql/Date;
at mikedd.entities.SqlDatePK.pcCopyKeyFieldsFromObjectId (SqlDatePK.java
)
at mikedd.entities.SqlDatePK.pcNewInstance(SqlDatePK.java)
at org.apache.openjpa.enhance.PCRegistry.newInstance(PCRegistry.java
:118)
at org.apache.openjpa.kernel.StateManagerImpl.initialize (
StateManagerImpl.java:247)
at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(
JDBCStoreManager.java:327)
at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(
JDBCStoreManager.java:252)
at org.apache.openjpa.kernel.DelegatingStoreManager.initialize(
DelegatingStoreManager.java:108)
at org.apache.openjpa.kernel.ROPStoreManager.initialize(
ROPStoreManager.java:54)
at org.apache.openjpa.kernel.BrokerImpl.initialize (BrokerImpl.java:868)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:826)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:743)
at org.apache.openjpa.kernel.DelegatingBroker.find (
DelegatingBroker.java:169)
at org.apache.openjpa.persistence.EntityManagerImpl.find(
EntityManagerImpl.java:346)
at mikedd.tests.TestSqlDateId.testFindAfterClear(TestSqlDateId.java:25)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke (Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
. . .
It's coming from the generated bytecode which expects there to be a getId
method that returns the same type of the Id, however java.sql.Date is using
the same ID class as java.util.Date. Do we need a separate class for
java.sql.Date?
Here's the entity and testcase that I'm running (in case I missed something
along the way)
Entity :
import java.sql.Date;
import javax.persistence.Entity;
import javax.persistence.Id;
@Entity
public class SqlDatePK {
@Id
private Date id;
private String name;
. . .
}
Testcase :
public void testFindAfterClear() {
SqlDatePK sql;
EntityManager em = _emf.createEntityManager();
long ms = 101010; // arbitrary date.
java.sql.Date date = new java.sql.Date(ms);
em.getTransaction().begin();
sql = new SqlDatePK();
sql.setId(date);
em.persist(sql);
em.getTransaction().commit();
em.clear();
sql = null;
sql = em.find(SqlDatePK.class, date);
. . .
}
Thanks in advance,
--
-Michael Dick
Re: Exception when using java.sql.Date as an id
Thanks, I'll open a JIRA report and take a crack at a solution.
On 2/7/07, Craig L Russell [EMAIL PROTECTED] wrote:
On Feb 7, 2007, at 1:55 PM, Patrick Linskey wrote:
It's coming from the generated bytecode which expects there
to be a getId
method that returns the same type of the Id, however
java.sql.Date is using
the same ID class as java.util.Date. Do we need a separate class for
java.sql.Date ?
It looks like we either need a separate type for java.sql.Date (and
presumably java.sql.Timestamp), or we need to change the logic to
accept
a getId() method that returns a type that is assignable from the id
field's type.
It's probably cleaner if we have separate classes for the different
types. That is, have the getId method in the new
org.apache.openjpa.util.SQLDateId return the proper type
(java.sql.Date). After all, java.sql.{Date, Time, Timestamp} are not
really the same as java.util.Date.
Craig
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
__
_
Notice: This email message, together with any attachments, may
contain
information of BEA Systems, Inc., its subsidiaries and
affiliated
entities, that may be confidential, proprietary, copyrighted
and/or
legally privileged, and is intended solely for the use of the
individual
or entity named in this message. If you are not the intended
recipient,
and have received this message in error, please immediately return
this
by email and then delete it.
-Original Message-
From: Michael Dick [mailto: [EMAIL PROTECTED]
Sent: Wednesday, February 07, 2007 12:57 PM
To: open-jpa-dev@incubator.apache.org
Subject: Exception when using java.sql.Date as an id
Hi,
I'm getting the following exception when I try to fetch an
entity with a
java.sql.Date as the id :
java.lang.NoSuchMethodError: org.apache.openjpa.util.DateId.getId
()Ljava/sql/Date;
at mikedd.entities.SqlDatePK.pcCopyKeyFieldsFromObjectId
(SqlDatePK.java
)
at mikedd.entities.SqlDatePK.pcNewInstance(SqlDatePK.java)
at
org.apache.openjpa.enhance.PCRegistry.newInstance(PCRegistry.java
:118)
at org.apache.openjpa.kernel.StateManagerImpl.initialize (
StateManagerImpl.java:247)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(
JDBCStoreManager.java:327)
at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(
JDBCStoreManager.java:252)
at org.apache.openjpa.kernel.DelegatingStoreManager.initialize (
DelegatingStoreManager.java:108)
at org.apache.openjpa.kernel.ROPStoreManager.initialize(
ROPStoreManager.java:54)
at org.apache.openjpa.kernel.BrokerImpl.initialize
(BrokerImpl.java:868)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:826)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:743)
at org.apache.openjpa.kernel.DelegatingBroker.find (
DelegatingBroker.java:169)
at org.apache.openjpa.persistence.EntityManagerImpl.find(
EntityManagerImpl.java:346)
at
mikedd.tests.TestSqlDateId.testFindAfterClear (TestSqlDateId.java:25)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke (Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java :154)
. . .
It's coming from the generated bytecode which expects there
to be a getId
method that returns the same type of the Id, however
java.sql.Date is using
the same ID class as java.util.Date. Do we need a separate class for
java.sql.Date?
Here's the entity and testcase that I'm running (in case I
missed something
along the way)
Entity :
import java.sql.Date;
import javax.persistence.Entity;
import javax.persistence.Id ;
@Entity
public class SqlDatePK {
@Id
private Date id;
private String name;
. . .
}
Testcase :
public void testFindAfterClear() {
SqlDatePK sql;
EntityManager em = _emf.createEntityManager();
long ms = 101010; // arbitrary date.
java.sql.Date date = new java.sql.Date(ms);
em.getTransaction().begin();
sql = new SqlDatePK();
sql.setId(date);
em.persist(sql);
em.getTransaction().commit();
em.clear();
sql = null;
sql = em.find(SqlDatePK.class , date);
. . .
}
Thanks in advance,
--
-Michael Dick
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
--
-Michael Dick
Re: [VOTE] Upgrade Derby dependency from 10.2.1.6 to 10.2.2.0
+1 (belated). On 2/4/07, Craig L Russell [EMAIL PROTECTED] wrote: +1 Craig On Feb 3, 2007, at 12:39 AM, Marc Prud'hommeaux wrote: In the interest of keeping up with the latest-and-greatest, I propose we upgrade our project dependency on the stand-alone Derby database JDBC driver for our testing and distribution zip from Derby 10.2.1.6 to the latest public version 10.2.2.0. This won't affect any core code or behavior at all, it will only affect the testing and the Derby database jar we provide with the distribution. A vote of +1 approves the upgrade, a vote of -1 indicates that you don't think we should upgrade. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! -- -Michael Dick
Re: [VOTE] Move JPA API dependency from dev.java.net to geronimo version
+1 On 2/10/07, Eddie O'Neil [EMAIL PROTECTED] wrote: +1 On 2/9/07, Craig L Russell [EMAIL PROTECTED] wrote: +1 My vote is as much related to dissatisfaction with the maven repo that is used by glassfish as with the time it takes to get anything done through official channels. Craig On Feb 8, 2007, at 9:41 PM, Marc Prud'hommeaux wrote: It turns out that the JPA API we've been building against (the one from https://maven-repository.dev.java.net/repository/ javax.persistence/jars/persistence-api-1.0.jar) is not actually the final version of the spec: there are some minor (and binary- compatible) changes (some annotations don't have runtime retention, for example), but they are enough to prevent us from passing all the compatibility tests we need. The Geronimo API jar (http://mirrors.ibiblio.org/pub/mirrors/maven2/ org/apache/geronimo/specs/geronimo-jpa_3.0_spec/geronimo- jpa_3.0_spec-1.0.jar) is compliant, as far as I can tell. How do people feel about changing the dependency from persistence- api-1.0.jar to geronimo-jpa_3.0_spec-1.0.jar? I've run through all our tests, and they pass with the Geronimo version. This would have the added advantage of unifying our spec jars to all be using the Geronimo versions. +1 indicates that you approve of the change -1 indicated that you disagree that the change should be made Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! -- -Michael Dick
Re: Test failure @ svn revision 511041
The tests passed for me this morning on one of my systems, but I'll run again to make sure. FWIW, I am having the NPE problem with the tests on a different system On that system I set the OpenJPA logging level to ERROR instead of INFO and the tests passed. I'm guessing it's a hokey timing / filesystem thing, but I haven't had time to look at it too much. The tests just completed for me with revision 511062, I think we're ok. -Mike On 2/23/07, Patrick Linskey [EMAIL PROTECTED] wrote: I haven't been able to run the persistence models test since my email of a week or so ago. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: Pinaki Poddar Sent: Friday, February 23, 2007 10:43 AM To: open-jpa-dev@incubator.apache.org Subject: Test failure @ svn revision 511041 I am seeing a test failure @ revision 511041, $ mvn package The following test is failing: org.apache.openjpa.persistence.models.company.propertyaccess.T estPropert yCompanyModel#testBasicQueries Runs on Apache Derby 10.2.2.0 - (485682) Apache Derby Embedded JDBC Driver 10.2.2.0 - (485682)). Will someone please verify that the tests are passing in their environment? Pinaki Poddar BEA Systems 415.402.7317 __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -- -Michael Dick
Re: Test failure @ svn revision 511041
) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.GeneratedMethodAccessor90.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.junit.JUnitTestSet.execute (JUnitTestSet.java:210) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSe t(AbstractDirectoryTestSuite.java:135) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute (AbstractDirectoryTestSuite.java:122) at org.apache.maven.surefire.Surefire.run(Surefire.java:129) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess (SurefireBooter.java:225) at org.apache.maven.surefire.booter.SurefireBooter.main (SurefireBooter.java:747) ... Results : Tests run: 76, Failures: 0, Errors: 1, Skipped: 0 On Feb 23, 2007, at 12:20 PM, Pinaki Poddar wrote: I should have the same code as you. Did you try changing the log level? Yes I too am at $svnversion -c 406193:511043 Changing log level to error in openjpa-persistence-jdbc/pom.xml did not impact the test failure. Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: Michael Dick [mailto:[EMAIL PROTECTED] Sent: Friday, February 23, 2007 11:58 AM To: open-jpa-dev@incubator.apache.org Subject: Re: Test failure @ svn revision 511041 I think so, that's what's specified in pom.xml (except for openjpa-integration) and it should be picked up from there. Log entries like this show up when I run the tests : 17 test INFO [main] openjpa.jdbc.JDBC - Using dictionary class org.apache.openjpa.jdbc.sql.DerbyDictionary (Apache Derby 10.2.2.0 - (485682) ,Apache Derby Embedded JDBC Driver 10.2.2.0 - (485682)). Svnversion -c gives me this output : [EMAIL PROTECTED]:~/work/jpa/openjpa$ svnversion -c 406193:511043 I should have the same code as you. Did you try changing the log level? On 2/23/07, Pinaki Poddar [EMAIL PROTECTED] wrote: The stacktrace points that it *may* be a driver issue (the error is NPE with Derby driver and not an SQLException) java.lang.NullPointerException at org.apache.derby.exe.ac9a855bfax0110xefd2xc9f7x000780800.e11 (Unkno wn Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.derby.impl.services.reflect.ReflectMethod.invoke(Unknown Source) at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRow C or e(Unknown Source) at org.apache.derby.impl.sql.execute.JoinResultSet.openCore(Unknown Source) at org.apache.derby.impl.sql.execute.JoinResultSet.openCore(Unknown Source) at org.apache.derby.impl.sql.execute.JoinResultSet.openCore(Unknown Source) at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore (Un kn own Source) at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open (Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement (Unk no wn Source) Are you using the same driver? Runs on Apache Derby 10.2.2.0 - (485682) Apache Derby Embedded JDBC Driver 10.2.2.0 - (485682)). Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: Michael Dick [mailto:[EMAIL PROTECTED] Sent: Friday, February 23, 2007 11:44 AM To: open-jpa-dev@incubator.apache.org Subject: Re: Test failure @ svn revision 511041 The tests passed for me this morning
Re: [VOTE] ArgumentException : More parameters were passed to execute() than were declared
On 4/2/07, Patrick Linskey [EMAIL PROTECTED] wrote: I have no problem adding this to the release. I was hoping to get OpenJPA-185 and OpenJPA-179 in as soon as I got commit access, and then start the release process. You should have commit access now. Is there anything else that we need to get in? If these are the only changes we need, I'll go ahead and start the release this afternoon. I think that the next step is to create an 0.9.8 goal within JIRA and move everything except those things we plan for 0.9.7 out to 0.9.8. Once we've done that and resolved all the 0.9.7 issues, we should be ready to build a release. How do I create a goal in JIRA? I don't seem to have access to do so, but I'm using the same ID that I had before I became a committer. It happens to be the same username as my Apache account, is there something I need to do to link them? I'm assuming that you've got the link to the release process that Marc put together, right? Yes, I've been going through that and the Apache documentation this morning. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: Michael Dick [mailto:[EMAIL PROTECTED] Sent: Monday, April 02, 2007 10:58 AM To: open-jpa-dev@incubator.apache.org Subject: Re: [VOTE] ArgumentException : More parameters were passed to execute() than were declared I have no problem adding this to the release. I was hoping to get OpenJPA-185 and OpenJPA-179 in as soon as I got commit access, and then start the release process. Is there anything else that we need to get in? If these are the only changes we need, I'll go ahead and start the release this afternoon. On 4/2/07, Patrick Linskey [EMAIL PROTECTED] wrote: I don't think that it's been cut yet. Mike: where do we stand on the 0.9.7 process? -Patrick -- Patrick Linskey BEA Systems, Inc. __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED] Sent: Monday, April 02, 2007 9:23 AM To: open-jpa-dev@incubator.apache.org Subject: Re: [VOTE] ArgumentException : More parameters were passed to execute() than were declared Is this something we can put in 0.9.7 or has that been cut already? -dain On Apr 1, 2007, at 10:07 PM, Craig L Russell wrote: +1 to remove the restriction. As long as no parameters are missing, the query should be considered sufficient. Craig On Apr 1, 2007, at 9:30 AM, Marc Prud'hommeaux wrote: Seem fair enough to get rid of the description. I've opened https://issues.apache.org/jira/browse/OPENJPA-196 describing the issue. +1 from me to remove the restriction that there be exactly as many positional parameters declared as were assigned. On Mar 31, 2007, at 7:32 PM, Dain Sundstrom wrote: Actually, I think there is a bigger problem... Say I have a query like this: SELECT x FROM foo AS x WHERE foo.name = ?2 The org.apache.openjpa.kernel.QueryImpl.assertParameters(...) code assumes that if I have 1 parameter it is numbered ?1, but in EJB 2.1 this was not a requirement and there are certification tests that verify you are allowed to have unused parameters (e.g, in my example about ?1 and ?N where N2 are all not used). I couldn't find any text in the specification that says that all all positional parameters must be used in the query, but I did find text that say the EJB-QL 3.0 language is an extension of the EJB-QL 2.1 language: The Java Persistence query language is an extension of the Enterprise Java Beans query language, EJB QL, definedin[5]. So I think we must remove the extra-params check, but I would be happy with a don't check for extra-params flag. -dain On Mar 31, 2007, at 8:56 AM, Dain Sundstrom wrote: I'm
Re: 0.9.8 release
All too easy, thank you both! I just added the files. Release-notes and Changes came mostly from JIRA. Building.txt was stolen from the building OpenJPA page (credit there should go to Marc). On 4/2/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Besides the issues mentioned above I think we'll need to add a change log, building.txt (for the source archive) and a release notes file (I thought we had one, but I didn't see it - maybe I'm blind). No, we didn't have one with the last release, since it was our initial release. I wonder if we can just export the JIRA list for issues fixed since the last release and use it as the release notes, since much of what we changed was done via JIRA issues. I'll take a crack at those tonight as well. On Apr 2, 2007, at 6:16 PM, Michael Dick wrote: Earlier today I created the 0.9.8 release in JIRA, and moved most of the open issues from 0.9.7 to 0.9.8. There's one open issue against 0.9.7 - OpenJPA-179 and I'll submit a fix for that later tonight (or move it to 0.9.8). Marc just committed the fix for OpenJPA-196, if there are any other issues that we need to include please move them back to 0.9.7. Besides the issues mentioned above I think we'll need to add a change log, building.txt (for the source archive) and a release notes file (I thought we had one, but I didn't see it - maybe I'm blind). I'll take a crack at those tonight as well. Assuming there aren't any other major issues, I'll go ahead and create the tags etc. tomorrow. Thanks, -- -Michael Dick
Re: svn commit: r525006 - in /incubator/openjpa/trunk: openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/meta/ openjpa-persistence-jdbc/src/main/java/org/apache/openjpa/persistence/jdbc/
;
+}
}
Modified: incubator/openjpa/trunk/openjpa-persistence-jdbc/src/main/
java/org/apache/openjpa/persistence/jdbc/
PersistenceMappingDefaults.java
URL: http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-
persistence-jdbc/src/main/java/org/apache/openjpa/persistence/jdbc/
PersistenceMappingDefaults.java?
view=diffrev=525006r1=525005r2=525006
==
--- incubator/openjpa/trunk/openjpa-persistence-jdbc/src/main/java/
org/apache/openjpa/persistence/jdbc/PersistenceMappingDefaults.java
(original)
+++ incubator/openjpa/trunk/openjpa-persistence-jdbc/src/main/java/
org/apache/openjpa/persistence/jdbc/PersistenceMappingDefaults.java
Mon Apr 2 19:48:10 2007
@@ -15,6 +15,7 @@
*/
package org.apache.openjpa.persistence.jdbc;
+import org.apache.commons.lang.StringUtils;
import org.apache.openjpa.jdbc.meta.ClassMapping;
import org.apache.openjpa.jdbc.meta.Discriminator;
import org.apache.openjpa.jdbc.meta.FieldMapping;
@@ -114,17 +115,31 @@
@Override
public String getTableName(ClassMapping cls, Schema schema) {
+String name = ;
+
+if(StringUtils.isNotEmpty(schema.getName())) {
+name +=schema.getName() + '.';
+}
+
if (cls.getTypeAlias() != null)
-return cls.getTypeAlias();
+name += cls.getTypeAlias();
+
else
-return Strings.getClassName(
-cls.getDescribedType()).replace('$', '_');
+name += Strings.getClassName(cls.getDescribedType
()).replace('$',
+'_');
+
+return name;
}
@Override
public String getTableName(FieldMapping fm, Schema schema) {
+String name = ;
+if(StringUtils.isNotEmpty(schema.getName())) {
+name +=schema.getName() + '.';
+}
+
// base name is table of defining type + '_'
-String name = fm.getDefiningMapping().getTable().getName()
+ _;
+name += fm.getDefiningMapping().getTable().getName() + _;
// if this is an assocation table, spec says to suffix
with table of
// the related type. spec doesn't cover other cases; we're
going to
Modified: incubator/openjpa/trunk/openjpa-persistence-jdbc/src/main/
java/org/apache/openjpa/persistence/jdbc/
XMLPersistenceMappingParser.java
URL: http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-
persistence-jdbc/src/main/java/org/apache/openjpa/persistence/jdbc/
XMLPersistenceMappingParser.java?
view=diffrev=525006r1=525005r2=525006
==
--- incubator/openjpa/trunk/openjpa-persistence-jdbc/src/main/java/
org/apache/openjpa/persistence/jdbc/
XMLPersistenceMappingParser.java (original)
+++ incubator/openjpa/trunk/openjpa-persistence-jdbc/src/main/java/
org/apache/openjpa/persistence/jdbc/
XMLPersistenceMappingParser.java Mon Apr 2 19:48:10 2007
@@ -50,6 +50,7 @@
import org.apache.openjpa.meta.ClassMetaData;
import org.apache.openjpa.meta.FieldMetaData;
import org.apache.openjpa.meta.JavaTypes;
+import org.apache.openjpa.meta.MetaDataRepository;
import org.apache.openjpa.persistence.XMLPersistenceMetaDataParser;
import static org.apache.openjpa.persistence.jdbc.MappingTag.*;
@@ -910,4 +911,18 @@
TRUE,
FALSE
}
+
+@Override
+protected void endClass(String elem)
+throws SAXException {
+if (StringUtils.isNotEmpty(_schema)) {
+Class cls = classForName(currentClassName());
+
+MetaDataRepository repos = getRepository();
+ClassMapping meta = (ClassMapping)
repos.getCachedMetaData(cls);
+
+meta.getMappingInfo().setDefaultSchemaName(_schema);
+}
+super.endClass(elem);
+}
}
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual or
entity named in this message. If you are not the intended recipient, and
have received this message in error, please immediately return this by email
and then delete it.
--
-Michael Dick
Index: openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/meta/MappingInfo.java
===
--- openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/meta/MappingInfo.java
(revision 525234)
+++ openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/meta/MappingInfo.java
(working copy)
@@ -465,9 +465,13 @@
schema = null;
schemaName = given.substring(0, dotIdx);
given = given.substring(dotIdx + 1);
-} else if (schema == null)
+} else if (schema == null) {
schemaName
Re: svn commit: r525006 - in /incubator/openjpa/trunk: openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/meta/ openjpa-persistence-jdbc/src/main/java/org/apache/openjpa/persistence/jdbc/
Thanks Patrick, That's exactly what I needed. I'll add a testcase shortly. I read through your response to one of Dave's commits and I think it applies to mine as well. Rather than hijacking that thread, I'm re-posting the relevant part here along with my response : I don't think that we should rush this change in just so it's in 0.9.7; we can always delay 0.9.7 if it's a must-have, or have a 0.9.8 that follows soon thereafter. Generally-speaking, my experience is that once code gets committed, it tends to not get cleaned up, so the argument let's get it in for the release and then fix it later usually ends up turning into let's get it in for the release. This seems especially true for a change like this, that is exposing new APIs (the hints). Thoughts? I agree. We need to try and avoid the commit and fix later mentality. If the code is not ready then it shouldn't be committed or the release should wait until the code is ready. On the other hand, I think there are cases where we can include limited functionality in the current release and then complete the function in release+1. An example of this is what I intended to do in OpenJPA-179. My intent was to include the support for default schemas which effected only the entities in orm.xml in 0.9.7, and then add support for persistence-unit wide defaults in 0.9.8. As Abe pointed out the code wasn't ready to be committed, and it needs to either be made ready or excluded from 0.9.8. For the record, I can go either way regarding OpenJPA-179 with one exception - I'm unlikely to finish the persistence unit wide changes in the near future, so if that's required it would be better to leave the function out of the release. On 4/3/07, Patrick Linskey [EMAIL PROTECTED] wrote: Hi, You might want to take a look at the SQLListenerTestCase -- it's very useful for ensuring that the right SQL is issued by a given command. That, in conjunction with direct invocations of MappingTool.run () with a Configuration obtained from the test case's EMF, and JDK1.4 regex support, should make it pretty simple to put together a unit test case. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: Michael Dick [mailto: [EMAIL PROTECTED] Sent: Tuesday, April 03, 2007 11:55 AM To: open-jpa-dev@incubator.apache.org Subject: Re: svn commit: r525006 - in /incubator/openjpa/trunk: openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/meta/ openjpa-persistence-jdbc/src/main/java/org/apache/openjpa/pers istence/jdbc/ Hi Abe, The testing I've done was to take a rather simple entity hierarchy and use the mapping tool to generate sql. Most of the verification was manual inspection of the sql file. I didn't decide on the best way to test it in a unit test - I suppose generating the file and grepping for the expected results or generating the tables and using native queries to check that they exist would work. Both approaches seem a bit kludgy to me - maybe there are better options that haven't occurred to me yet. I'll attach the tests that I have to the JIRA report rather than cluttering up everyone's inbox. There are also similar tests in our FVT bucket, which is where we found the problem. I know there's more cleanup to be done here, but I thought it was worth getting a first stab at it done in time for 0.9.7. I've attached a patch with some of the changes you noted. It probably won't save you much time, but it can't hurt. Thank you for taking a look at the changes. On 4/3/07, Abe White [EMAIL PROTECTED] wrote: I see several possible problems with this commit. Are there tests for this functionality checked in? 1. The property and logic for using the DefaultSchemaName are defined in MappingInfo, but the default schema name is only ever set into ClassMappingInfos. Not FieldMappingInfos, DiscriminatorMappingInfos, etc. Definitely oversight on my part. 2. MappingInfo uses the default schema name sometimes (line 445) but ignores it other times (line 469). Another good catch - I missed the else clause, but it doesn't seem to resolve #3. 3. It should not be necessary to prepend the schema name to the table name in PersistenceMappingDefaults. The schema is already known. Was that code added based on any testing? If so, perhaps it is because of problem #2 above. I didn't have much luck
Re: Programmatical EntityManagerFactory init
Hi Erwan,
What do you have in persistence.xml?
It should contain something like this :
persistence xmlns=http://java.sun.com/xml/ns/persistence;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
version=1.0
persistence-unit name=teamplay_test
. . .
/persistence-unit
/persistence
One thing to watch out for is if you've defined a provider inside the
persistence unit. If that is the case the provider needs to be
org.apache.openjpa.persistence.PersistenceProviderImpl (assuming you want to
use OpenJPA).
If persistence.xml does contain the persistence unit then I'm not sure what
would cause the problem. Maybe a classpath issue?
-Mike
On 4/6/07, Erwan Le Goulven [EMAIL PROTECTED] wrote:
Messieurs-dames,
As I could not find much clues about the right way to do it, here I come:
I'm trying to get an EntityManagerFactory properly setup from the
Persistence class, but I cannot get further than the following exception
javax.persistence.PersistenceException: No Persistence provider for
EntityManager named teamplay_test
at javax.persistence.Persistence.createEntityManagerFactory(
Persistence.java:89)
at com.gdteam.teamplay.domain.manager.TeamplayEMFactoryManager.get (
TeamplayEMFactoryManager.java:60)
at com.gdteam.teamplay.test.persistence.PersistenceUtilTest.setUp(
PersistenceUtilTest.java:19)
at junit.framework.TestCase.runBare(TestCase.java:125)
at junit.framework.TestResult$1.protect (TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
Here is the code part that leads to the exception:
public class TeamplayEMFactoryManager {
...
private final MapString, String props = new HashMapString,
String();
private final MapString, EntityManagerFactory map = new
HashMapString, EntityManagerFactory();
...
private TeamplayEMFactoryManager() {
props.put(openjpa.ConnectionDriverName, org.hsqldb.jdbcDriver
);
props.put(openjpa.ConnectionUserName, sa);
props.put(openjpa.ConnectionPassword, );
props.put(openjpa.Log, DefaultLevel=WARN, Tool=INFO);
props.put(openjpa.MetaDataFactory,
jpa(Types=+buildTypes()+));
}
..
public EntityManagerFactory get(String url) {
EntityManagerFactory factory = null;
if (null == url || url.length() == 0 ) {
url = default;
}
factory = this.map.get(url);
if (null == factory) {
if ( default.equals(url)) {
1- factory = Persistence.createEntityManagerFactory(null);
} else {
MapString , String map = new HashMapString,
String(props);
map.put(openjpa.ConnectionURL , buildUrl(url));
2- factory = Persistence.createEntityManagerFactory(url,map);
}
this.map.put(url, factory);
}
return factory;
}
...
}
Note :
I'm using a persistence.xml for single persitence unit creation, and this
test works fine. I've had a dive into the source code, and found the
provider is lookuped and found by the glassfish persistence implementation
class. The exception is raised on the open jpa side, and I know I'm
missing
some configuration elements, but I cannot guess what's missing?
any hint?
thank you guys
Re: svn commit: r525997 - in /incubator/openjpa/trunk: openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/kernel/ openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/ openjpa-jdbc/src/main/resource
On 4/6/07, Abe White [EMAIL PROTECTED] wrote: Why is this setting called IsolationLevel where our global setting is called TransactionIsolation? Shouldn't this local setting just be called Isolation for consistency? Same with the FetchPlan facade. Personally, I feel that 'IsolationLevel' is a more-well-known term for the concept. I'm fine with either name, though. Does anyone else have an opinion on this? I think get/setIsolation would be more consistent with the global TransactionIsolation property. I doubt the lack of a Level suffix is going to hurt. I'm inclined to agree with Abe - it matches the java.sql.Connectioninterface and should be standard enough. It's not a big deal IMHO but it doesn't hurt to be consistent. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -- -Michael Dick
Re: @Column with precision and scale - how does it work?
I don't think Derby supports specifying the precision on type DOUBLE (maybe
other datbases do).
You should be able to specify the precision through the @Column annotation.
I believe @Column(columnDefinition=DECIMAL(5,2)) will work. I'm not sure
whether precision=x, scale=y with a type that maps to DECIMAL instead of
DOUBLE.
On 4/10/07, Jacek Laskowski [EMAIL PROTECTED] wrote:
Hi,
I wonder how I could restrict what values are inserted into a table
using @Column(precision=5, scale=2). When does it matter?
I'm using OpenJPA 0.9.7-SNAPSHOT with Derby and with the following:
@Column(precision = 5, scale = 2)
public double getPensja() {
return pensja;
}
OpenJPA executes the following CREATE
2969 derbyPU TRACE [main] openjpa.jdbc.SQL - t 11533424, conn
18662247 executing stmnt 23119024 CREATE TABLE Osoba (numer BIGINT
NOT NULL, dzienImienin TIMESTAMP, dzienUrodzin
TIMESTAMP, imie VARCHAR(255), kraj VARCHAR(255), nazwisko
VARCHAR(255), wersja INTEGER, pensja DOUBLE, tytul VARCHAR(255),
PRIMARY KEY (numer))
How could I restrict the precision and scale of the pensja field? Is
the columnDefinition attribute of @Column the last resort? When is the
others used? What databases are supported?
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
--
-Michael Dick
Re: @Column with precision and scale - how does it work?
I'm sorry, I misunderstood your question. I'm afraid I don't know how we determine when to apply the scale and precision. In this case the value should be ignored, since there's no way to set it on the column. If the attribute was of type BigDecimal then I think the precision and scale should apply. The catch here is that it looks like we're mapping BigDecimal to DOUBLE so that won't work. I'll have to take a closer look to determine where that mapping occurs, and what the correct mapping(s) should be. Would you mind opening a JIRA report for the problem? http://issues.apache.org/jira/browse/OPENJPA -Mike On 4/10/07, Jacek Laskowski [EMAIL PROTECTED] wrote: On 4/10/07, Michael Dick [EMAIL PROTECTED] wrote: I don't think Derby supports specifying the precision on type DOUBLE (maybe other datbases do). You're right - it doesn't. You should be able to specify the precision through the @Column annotation. I believe @Column(columnDefinition=DECIMAL(5,2)) will work. DECIMAL is a synonim of NUMERIC and either works well. I'm not sure whether precision=x, scale=y with a type that maps to DECIMAL instead of DOUBLE. That's my question how OpenJPA recognizes whether the attributes should be used or not. I don't think precision and scale are not used at all. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: svn commit: r527320 [1/2] - in /incubator/openjpa/branches/0.9.7-incubating: ./ openjpa-all/ openjpa-examples/ openjpa-integration/ openjpa-integration/examples/ openjpa-integration/tck/ openjpa-j
Hi Craig, Well I didn't intentionally remove them :-). It looks like they were removed by the maven plugin and this is one of the automated commits that it does. Looks like another gotcha with the tool. I'm going to rollback the changes again and see if I can fix the endline and the copyright problems. For the time being I'll leave the artifacts on people.apache.org/~mikedd. There should be another set of commits coming through later tonight tonight. Thanks for noticing the copyright problem. On 4/10/07, Craig L Russell [EMAIL PROTECTED] wrote: Hi Mike, Did you accidentally remove the licenses from the xml files??? Craig On Apr 10, 2007, at 2:59 PM, [EMAIL PROTECTED] wrote: Modified: incubator/openjpa/branches/0.9.7-incubating/openjpa- examples/pom.xml URL: http://svn.apache.org/viewvc/incubator/openjpa/branches/0.9.7- incubating/openjpa-examples/pom.xml? view=diffrev=527320r1=527319r2=527320 == --- incubator/openjpa/branches/0.9.7-incubating/openjpa-examples/ pom.xml (original) +++ incubator/openjpa/branches/0.9.7-incubating/openjpa-examples/ pom.xml Tue Apr 10 14:59:02 2007 @@ -1,22 +1,4 @@ -?xml version=1.0 encoding=UTF-8? -!-- - Copyright 2006 The Apache Software Foundation. - - Licensed under the Apache License, Version 2.0 (the License); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an AS IS BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. --- -project xmlns=http://maven.apache.org/POM/4.0.0; - xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; - xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; +project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http:// maven.apache.org/maven-v4_0_0.xsd modelVersion4.0.0/modelVersion groupIdorg.apache.openjpa/groupId artifactIdopenjpa-examples/artifactId @@ -27,7 +9,7 @@ parent groupIdorg.apache.openjpa/groupId artifactIdopenjpa/artifactId -version0.9.7-incubating-SNAPSHOT/version +version0.9.7-incubating/version Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! -- -Michael Dick
Artifact names
Hi, I'm hitting a bit of a snag with the staging repository for release 0.9.7. Recently we made changes to remove -project from our the zip file names. The problem is that the maven install and deploy goals ignore the names we provide and generate their own names ( openjpa-project-0.9.7-incubating-xxx.zip). I searched through the users@maven.apache.org mailing list archives and it turns out this is a fairly common problem - usually resulting in a response of working as designed. Here's an example http://www.nabble.com/Installation-and-deployment-tf1449780s177.html#a3916784 Does anyone vehemently object to putting -project back into the names for the 0.9.7 release? The only other way I know of to fix the names that get deployed would be to change the artifactId in the pom files (basically switch openjpa with openjpa-project). Switching the names will impact anyone who has a dependency on the base openjpa project. They'll have to update the version number anyway, but it will still be a little confusing if they used to depend on openjpa-0.9.6 and now they depend on openjpa-project-0.9.7. Thanks, -- -Michael Dick
Re: Artifact names
On 4/11/07, Patrick Linskey [EMAIL PROTECTED] wrote: Does anyone vehemently object to putting -project back into the names for the 0.9.7 release? I don't vehemently object for the 0.9.7 release, but I do vehemently object for the 1.0 release. I don't like these random bugs / limitations of our build process making their way into the project artifacts. I agree, I don't think I can resolve it cleanly in a timely manner for 0.9.7but I don't think they should be permanent additions. I searched through the users@maven.apache.org mailing list archives and it turns out this is a fairly common problem - usually resulting in a response of working as designed. Here's an example http://www.nabble.com/Installation-and-deployment-tf1449780s17 7.html#a3916784 Any chance that we can convince the people involved that while it may be working as designed, it's a common difficulty? I'll try. I suspect their argument will be that using the artifactId guarantees uniqueness in the repository. I think that having the artifactId in the path is unique enough. As a last resort we could bite the bullet and switch the artifactIds. It's not particularly friendly but it wouldn't be the end of the world to make the change on a major release boundary (hopefully when we leave the incubator). -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: Michael Dick [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 11, 2007 8:34 AM To: open-jpa-dev@incubator.apache.org Subject: Artifact names Hi, I'm hitting a bit of a snag with the staging repository for release 0.9.7. Recently we made changes to remove -project from our the zip file names. The problem is that the maven install and deploy goals ignore the names we provide and generate their own names ( openjpa-project-0.9.7-incubating-xxx.zip). I searched through the users@maven.apache.org mailing list archives and it turns out this is a fairly common problem - usually resulting in a response of working as designed. Here's an example http://www.nabble.com/Installation-and-deployment-tf1449780s17 7.html#a3916784 Does anyone vehemently object to putting -project back into the names for the 0.9.7 release? The only other way I know of to fix the names that get deployed would be to change the artifactId in the pom files (basically switch openjpa with openjpa-project). Switching the names will impact anyone who has a dependency on the base openjpa project. They'll have to update the version number anyway, but it will still be a little confusing if they used to depend on openjpa-0.9.6 and now they depend on openjpa-project-0.9.7. Thanks, -- -Michael Dick Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -- -Michael Dick
Re: Artifact names
You're right, if / when we bypass the deploy phase and execute scp (or something similar) ourselves then it'll be easy to put in the renaming logic. Thanks Patrick and Marc, On 4/11/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Michael- I personally think that keeping -project- in the artifact zip name is tolerable. I too had looked around (albeit briefly) for a solution to this a while ago, and found none. Once OpenJPA is out of incubation and we are deploying releases to the Apache mirror system, we'll probably need to put in some more deployment-oriented logic that doesn't use the deploy phase, so at that time we might be able to put in some renaming logic. +1 for tolerating the artifact name openjpa-project-0.9.7- incubating.zip. On Apr 11, 2007, at 8:34 AM, Michael Dick wrote: Hi, I'm hitting a bit of a snag with the staging repository for release 0.9.7. Recently we made changes to remove -project from our the zip file names. The problem is that the maven install and deploy goals ignore the names we provide and generate their own names ( openjpa-project-0.9.7-incubating-xxx.zip). I searched through the users@maven.apache.org mailing list archives and it turns out this is a fairly common problem - usually resulting in a response of working as designed. Here's an example http://www.nabble.com/Installation-and-deployment- tf1449780s177.html#a3916784 Does anyone vehemently object to putting -project back into the names for the 0.9.7 release? The only other way I know of to fix the names that get deployed would be to change the artifactId in the pom files (basically switch openjpa with openjpa-project). Switching the names will impact anyone who has a dependency on the base openjpa project. They'll have to update the version number anyway, but it will still be a little confusing if they used to depend on openjpa-0.9.6 and now they depend on openjpa-project-0.9.7. Thanks, -- -Michael Dick -- -Michael Dick
Re:[RESCINDED] [VOTE] publish openjpa 0.9.7-incubating release
I'm rescinding this vote due to issues with the license header included in the source files. Thanks Craig for finding the problem. I've removed the artifacts from my home directory on people.apache.org - I'll publish a new release candidate early this week. On 4/13/07, Craig L Russell [EMAIL PROTECTED] wrote: Hi Mike, I now understand that your message only mentioned a subset of the artifacts that we're planning on publishing for the release of 0.9.7. On Apr 13, 2007, at 1:54 PM, Michael Dick wrote: Marc beat me to it, but in case this helps here's the xml that can be used to access the staging repository : repositories repository idstaging-repository/id namemikedd's staging repository/name url http://people.apache.org/~mikedd/staging-repositoryhttp:// people.apache.org/%7Emikedd/staging-repository /url /repository . . . /repositories All the OpenJPA artifacts can be accessed this way (at least I was able to download them). If there are other artifacts that we need to publish then I'll go ahead and put them on people.apache.org/~mikedd too. Maybe we just need to include these instructions in the email that we send out for the vote? Yes, I think this would make it clear that we're not releasing just the binary and source zip files but the binary maven jar and pom artifacts as well. It was the message not the staging of the artifacts that threw me off. Thanks! Craig Thanks, On 4/13/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Craig- I'm really asking that the 0.9.7 release that we plan to put into the incubating repository needs to be put to a vote at the same time as we release the other artifacts. The pom.xml and the openjpa- all.0.9.7-incubating.jar should be part of the vote and available in the staging repository. I'm not sure I completely understand your issue, but I am guessing you are either asking whether other maven-friendly jar artifacts were created for the release, or else whether those jar artifacts need to be listed and voted on. In the previous release, we just voted on the final binary (http:// people.apache.org/~mikedd/staging-repository/org/apache/openjpa/ openjpa-project/0.9.7-incubating/openjpa-project-0.9.7-incubating- binary.zip). The deploy process does also deploy the other module jars (e.g., see http://people.apache.org/~mikedd/staging-repository/ org/apache/openjpa/openjpa-all/0.9.7-incubating/), so you should be able access them in a pom.xml just like any repository. AFAIK, this is how all the other projects that use Maven have done it (e.g., ActiveMQ). Since the other deployed artifacts are either identical to, or derivative from, the binary assembly, it seems to me that listing every uploaded artifact might be needlessly cumbersome. Please let me know if I have mis-understood your issue. On Apr 13, 2007, at 12:40 PM, Craig L Russell wrote: Hi Marc, Artifacts need to be approved (voted on by the PMC) before they are put into repositories. The 0.9.6 release was put into the incubating repository only after it was approved by the IPMC. I'm really asking that the 0.9.7 release that we plan to put into the incubating repository needs to be put to a vote at the same time as we release the other artifacts. The pom.xml and the openjpa- all.0.9.7-incubating.jar should be part of the vote and available in the staging repository. Craig On Apr 13, 2007, at 12:09 PM, Marc Prud'hommeaux wrote: Craig- I thought we were going to also release a maven download for the jar file containing all the openjpa stuff and a pom that contains the dependencies. This would enable folks using maven to simply put the five lines of code naming the dependency into their pom and put the incubating repository into their maven repositories list and they would be done. Note that they can do that already with the existing artifacts, since Maven downloads transitive dependencies. For example, this pom.xml works fine for me in that it downloads and uses all of the OpenJPA libraries and dependencies: ?xml version=1.0 encoding=UTF-8? project modelVersion4.0.0/modelVersion groupIdsome-project/groupId artifactIdsome-artifact/artifactId packagingjar/packaging nameMy Project/name version1.0.0/version repositories repository idapache-snapshots/id urlhttp://people.apache.org/repo/m2-incubating- repository/url /repository /repositories dependencies dependency groupIdorg.apache.openjpa/groupId artifactIdopenjpa-all/artifactId version0.9.6-incubating/version /dependency /dependencies /project There might be some other good reasons to make a separate distribution that bundles all of the jars into a single uber-jar, but, as I
Re: [RESCINDED] [VOTE] publish openjpa 0.9.7-incubating release
Unfortunately I just deleted them - it'll take a few minutes to re-publish. On 4/14/07, Eddie O'Neil [EMAIL PROTECTED] wrote: Mike-- Thanks; is there any chance that the old artifacts are still around somewhere? I was going to give them a review this weekend which could save us a release round trip if any issues crop up. If they're around somewhere, send along a link. Thanks. Eddie On 4/14/07, Michael Dick [EMAIL PROTECTED] wrote: I'm rescinding this vote due to issues with the license header included in the source files. Thanks Craig for finding the problem. I've removed the artifacts from my home directory on people.apache.org - I'll publish a new release candidate early this week. On 4/13/07, Craig L Russell [EMAIL PROTECTED] wrote: Hi Mike, I now understand that your message only mentioned a subset of the artifacts that we're planning on publishing for the release of 0.9.7. On Apr 13, 2007, at 1:54 PM, Michael Dick wrote: Marc beat me to it, but in case this helps here's the xml that can be used to access the staging repository : repositories repository idstaging-repository/id namemikedd's staging repository/name url http://people.apache.org/~mikedd/staging-repositoryhttp:// people.apache.org/%7Emikedd/staging-repository /url /repository . . . /repositories All the OpenJPA artifacts can be accessed this way (at least I was able to download them). If there are other artifacts that we need to publish then I'll go ahead and put them on people.apache.org/~mikedd too. Maybe we just need to include these instructions in the email that we send out for the vote? Yes, I think this would make it clear that we're not releasing just the binary and source zip files but the binary maven jar and pom artifacts as well. It was the message not the staging of the artifacts that threw me off. Thanks! Craig Thanks, On 4/13/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Craig- I'm really asking that the 0.9.7 release that we plan to put into the incubating repository needs to be put to a vote at the same time as we release the other artifacts. The pom.xml and the openjpa- all.0.9.7-incubating.jar should be part of the vote and available in the staging repository. I'm not sure I completely understand your issue, but I am guessing you are either asking whether other maven-friendly jar artifacts were created for the release, or else whether those jar artifacts need to be listed and voted on. In the previous release, we just voted on the final binary (http:// people.apache.org/~mikedd/staging-repository/org/apache/openjpa/ openjpa-project/0.9.7-incubating/openjpa-project-0.9.7-incubating- binary.zip). The deploy process does also deploy the other module jars (e.g., see http://people.apache.org/~mikedd/staging-repository/ org/apache/openjpa/openjpa-all/0.9.7-incubating/), so you should be able access them in a pom.xml just like any repository. AFAIK, this is how all the other projects that use Maven have done it (e.g., ActiveMQ). Since the other deployed artifacts are either identical to, or derivative from, the binary assembly, it seems to me that listing every uploaded artifact might be needlessly cumbersome. Please let me know if I have mis-understood your issue. On Apr 13, 2007, at 12:40 PM, Craig L Russell wrote: Hi Marc, Artifacts need to be approved (voted on by the PMC) before they are put into repositories. The 0.9.6 release was put into the incubating repository only after it was approved by the IPMC. I'm really asking that the 0.9.7 release that we plan to put into the incubating repository needs to be put to a vote at the same time as we release the other artifacts. The pom.xml and the openjpa- all.0.9.7-incubating.jar should be part of the vote and available in the staging repository. Craig On Apr 13, 2007, at 12:09 PM, Marc Prud'hommeaux wrote: Craig- I thought we were going to also release a maven download for the jar file containing all the openjpa stuff and a pom that contains the dependencies. This would enable folks using maven to simply put the five lines of code naming the dependency into their pom and put the incubating repository into their maven repositories list and they would be done. Note that they can do that already with the existing artifacts, since Maven downloads transitive dependencies. For example, this pom.xml works fine for me in that it downloads and uses all of the OpenJPA libraries and dependencies: ?xml version=1.0 encoding=UTF-8? project modelVersion4.0.0/modelVersion groupIdsome-project/groupId
[VOTE] publish openjpa 0.9.7-incubating release
OpenJPA People- In accordance with the Incubating Releases guidelines at http://incubator.apache.org/incubation/Incubation_Policy.html#Releases , I've taken another shot at making a release and start a vote on publishing a 0.9.7-incubating release of OpenJPA. The release candidate is at: http://people.apache.org/~mikedd/staging-repository/org/apache/openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7-incubating-binary.ziphttp://people.apache.org/%7Emikedd/staging-repository/org/apache/openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7-incubating-binary.zip The GPG signature and MD5 checksums are at: http://people.apache.org/~mikedd/staging-repository/org/apache/openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7-incubating-binary.zip.aschttp://people.apache.org/%7Emikedd/staging-repository/org/apache/openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7-incubating-binary.zip.asc http://people.apache.org/~mikedd/staging-repository/org/apache/openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7-incubating-binary.zip.md5http://people.apache.org/%7Emikedd/staging-repository/org/apache/openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7-incubating-binary.zip.md5 The sources, sources GPG signature and sources MD5 checksum are available at: http://people.apache.org/~mikedd/staging-repository/org/apache/openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7-incubating-source.zip http://people.apache.org/%7Emikedd/staging-repository/org/apache/openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7-incubating-source.zip http://people.apache.org/~mikedd/staging-repository/org/apache/openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7-incubating-source.zip.asc http://people.apache.org/%7Emikedd/staging-repository/org/apache/openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7-incubating-source.zip.asc http://people.apache.org/~mikedd/staging-repository/org/apache/openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7-incubating-source.zip.md5 http://people.apache.org/%7Emikedd/staging-repository/org/apache/openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7-incubating-source.zip.md5 A branch for this release candidate has been created at : https://svn.apache.org/repos/asf/incubator/openjpa/branches/0.9.7-incubating-RC2 https://svn.apache.org/repos/asf/incubator/openjpa/tags/0.9.7-incubating/ The release has been published to a staging repository on people.apache.org. The staging repository may be used in a maven 2 build file by adding the following information : . . . repositories repository idstaging-repository/id namemikedd's staging repository/name url http://people.apache.org/~mikedd/staging-repository /url /repository . . . /repositories . . . dependencies dependency groupIdorg.apache.openjpa/groupId artifactIdopenjpa-all/artifactId version0.9.7-incubating/version /dependency . . . /dependencies Please vote to publish this incubating release on the project Web page: http://cwiki.apache.org/openjpa/downloads.html This vote will remain open until 11:15 CST on Thursday April 19th A +1 indicates that you approve of the release, a -1 indicates a vote against making a release -- -Michael Dick
Re: [VOTE] publish openjpa 0.9.7-incubating release
Thanks Marc, How do I upload my key to http://incubator.apache.org/openjpa/KEYS ? The only documentation I've found indicates that I need to upload it, but not where the key needs to go. Before I create another release candidate (to remove the docbook jar), should we try to address the other minor issues? Craig and Patrick have responded to most of them, but there are a few others. Minor issues: - The .zip distribution contains .asc files for the .md5 and .sha1 files, which are unnecessary. They're unnecessary, but I've been ignoring them since they aren't hurting anything. It isn't too hard to get rid of them though. I think the gpg plugin for maven signs the .md5 and sha1 files too (I'd have to check though). - The source distribution contains a derby.log file at: source-dist/openjpa-persistence-jdbc/derby.log This is pretty easy to clean up, and I'll do that before I create another release candidate. The other issues Craig and Patrick have responded to. If any of them can be fixed quickly then we can include them in the new release candidate. On 4/18/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Good idea ... I've gone ahead and done that. It should make things a little easier to manage. On Apr 18, 2007, at 10:45 AM, Patrick Linskey wrote: This is there because we draw in all the dependencies that we don't explicitly exclude in the openjpa-project/assembly.xml, and at some point, someone (probably me) added docbook-xsl as a dependency so as to ensure that the docbook processing phase had access to the stylesheets. Is it possible to invert that, so that we only include certain dependencies? -Patrick -- Patrick Linskey BEA Systems, Inc. __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On Behalf Of Marc Prud'hommeaux Sent: Wednesday, April 18, 2007 10:23 AM To: open-jpa-dev@incubator.apache.org Subject: Re: [VOTE] publish openjpa 0.9.7-incubating release On Apr 18, 2007, at 10:11 AM, Patrick Linskey wrote: - The binary distribution contains a new JAR file whose license is unclear; this is: binary-dist/lib/docbook-xsl-1.67.2.zip That dependency is unnecessary -- it's needed to build the docs, but not by the runtime. This is there because we draw in all the dependencies that we don't explicitly exclude in the openjpa-project/assembly.xml, and at some point, someone (probably me) added docbook-xsl as a dependency so as to ensure that the docbook processing phase had access to the stylesheets. I've gone ahead and fixed this in the trunk by adding it to the exclude list (revision 530094). Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -- -Michael Dick
Re: [VOTE] publish openjpa 0.9.7-incubating release
I'd rather not cut another release, but I think we do need to resolve the issue with the docbook jar. If we can live with the extra jar then the vote can proceed. If I go back and remove the jar, republish etc. I'm assuming we'll have to restart the clock on the vote, correct me if I'm wrong in this regard. On 4/18/07, Craig L Russell [EMAIL PROTECTED] wrote: For the record, I'm still +1 for release. But if you want to cut another to fix the minor items that have been surfaced, it's ok with me. Craig On Apr 18, 2007, at 11:42 AM, Eddie O'Neil wrote: Mike-- RE the KEYS file, you can just ssh to people.apache.org and check the KEYS file out directly into /www/incubator.apache.org/openjpa/ directory. No uploading necessary! :) To be sure -- the rest of the items are just nits which could mostly be cleaned up just by deleting the directories / files after they're uploaded. I don't have strong feelings about them, so just do whatever the community feels is best. Certainly, it's fine to ship them for 0.9.7. Cheers, Eddie On 4/18/07, Michael Dick [EMAIL PROTECTED] wrote: Thanks Marc, How do I upload my key to http://incubator.apache.org/openjpa/ KEYS ? The only documentation I've found indicates that I need to upload it, but not where the key needs to go. Before I create another release candidate (to remove the docbook jar), should we try to address the other minor issues? Craig and Patrick have responded to most of them, but there are a few others. Minor issues: - The .zip distribution contains .asc files for the .md5 and .sha1 files, which are unnecessary. They're unnecessary, but I've been ignoring them since they aren't hurting anything. It isn't too hard to get rid of them though. I think the gpg plugin for maven signs the .md5 and sha1 files too (I'd have to check though). - The source distribution contains a derby.log file at: source-dist/openjpa-persistence-jdbc/derby.log This is pretty easy to clean up, and I'll do that before I create another release candidate. The other issues Craig and Patrick have responded to. If any of them can be fixed quickly then we can include them in the new release candidate. On 4/18/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Good idea ... I've gone ahead and done that. It should make things a little easier to manage. On Apr 18, 2007, at 10:45 AM, Patrick Linskey wrote: This is there because we draw in all the dependencies that we don't explicitly exclude in the openjpa-project/assembly.xml, and at some point, someone (probably me) added docbook-xsl as a dependency so as to ensure that the docbook processing phase had access to the stylesheets. Is it possible to invert that, so that we only include certain dependencies? -Patrick -- Patrick Linskey BEA Systems, Inc. _ _ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On Behalf Of Marc Prud'hommeaux Sent: Wednesday, April 18, 2007 10:23 AM To: open-jpa-dev@incubator.apache.org Subject: Re: [VOTE] publish openjpa 0.9.7-incubating release On Apr 18, 2007, at 10:11 AM, Patrick Linskey wrote: - The binary distribution contains a new JAR file whose license is unclear; this is: binary-dist/lib/docbook-xsl-1.67.2.zip That dependency is unnecessary -- it's needed to build the docs, but not by the runtime. This is there because we draw in all the dependencies that we don't explicitly exclude in the openjpa-project/assembly.xml, and at some point, someone (probably me) added docbook-xsl as a dependency so as to ensure that the docbook processing phase had access to the stylesheets. I've gone ahead and fixed this in the trunk by adding it to the exclude list (revision 530094). Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -- -Michael Dick Craig Russell
Re: [DISCUSS] required vs. optional dependencies
In general I agree with Patrick. I'm +0 regarding including Derby, it's nice for the examples, but it just doesn't seem right to include a preferred database . No logical reason, just personal preference. On 4/18/07, Patrick Linskey [EMAIL PROTECTED] wrote: - commons-logging-1.0.4.jar (used only in CommonsLogFactory when logging is configured to use commons) I think that we should leave this out altogether. Anyone who wants to use commons logging will presumably have commons logging. - commons-pool-1.3.jar (used only in TCPRemoteCommitProvider for distributed data caching) We should keep this, since it is required for one of our built-in options, although it's unfortunate to have the extra dependency for just one bit of code. - geronimo-jms_1.1_spec-1.0.1.jar (used only in JMSRemoteCommitProvider for distributed data caching) We should leave this out, since anyone who uses the JMS RCP will need to have a JMS server, and will therefore presumably have JMS jars. - derby-10.2.2.0.jar (provided only as a convenience for getting started with the examples quickly) I think that we should keep this. My question: should we differentiate between the required libraries and the optional ones (perhaps by putting them in an /optional/ directory or something)? Does anyone have experience with how this is done with other Apache projects? I think that we should make the changes I outlined above, and we should not create an /optional/ for other things. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On Behalf Of Marc Prud'hommeaux Sent: Wednesday, April 18, 2007 11:31 AM To: open-jpa-dev@incubator.apache.org Subject: [DISCUSS] required vs. optional dependencies Currently with OpenJPA, we ship with the following jars in the lib/ directory: * commons-lang-2.1.jar * commons-collections-3.2.jar * geronimo-jta_1.0.1B_spec-1.0.1.jar * geronimo-jpa_3.0_spec-1.0.jar * geronimo-j2ee-connector_1.5_spec-1.0.1.jar * serp-1.11.0.jar - commons-logging-1.0.4.jar (used only in CommonsLogFactory when logging is configured to use commons) - commons-pool-1.3.jar (used only in TCPRemoteCommitProvider for distributed data caching) - geronimo-jms_1.1_spec-1.0.1.jar (used only in JMSRemoteCommitProvider for distributed data caching) - derby-10.2.2.0.jar (provided only as a convenience for getting started with the examples quickly) The jars marked with stars (*) are the only ones that are actually required for OpenJPA to function in the common cases (the examples included in the distribution all run if you have just the starred libraries + derby). My question: should we differentiate between the required libraries and the optional ones (perhaps by putting them in an /optional/ directory or something)? Does anyone have experience with how this is done with other Apache projects? Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -- -Michael Dick
Re: [VOTE] publish openjpa 0.9.7-incubating release
I probably should have worded that differently since I haven't run the tests against DB2. I believe Dave's team has. Dave, can you comment on how big the impact of OpenJPA-222 is? On 4/18/07, Patrick Linskey [EMAIL PROTECTED] wrote: I'm a little nervous about OpenJPA-222. From talking with Dave it sounds like it has a large effect on DB2. I'd like to get that issue resolved if possible. I'm a little nervous about scope creep. Is there some good reason why OPENJPA-222 needs to be resolved now vs. later? -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: Michael Dick [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 18, 2007 2:24 PM To: open-jpa-dev@incubator.apache.org Subject: Re: [VOTE] publish openjpa 0.9.7-incubating release On 4/18/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Michael- On Apr 18, 2007, at 12:27 PM, Michael Dick wrote: I'd rather not cut another release, but I think we do need to resolve the issue with the docbook jar. If we can live with the extra jar then the vote can proceed. Personally, I think it is sufficiently ugly to release with the docbook jar to justify starting another release. However, if others disagree, I'll happily accede to the majority. For now, my vote changes to +0. I agree but like you I can be talked out of it. I'll take another look over everything and start another release tonight / tomorrow. I'm a little nervous about OpenJPA-222. From talking with Dave it sounds like it has a large effect on DB2. I'd like to get that issue resolved if possible. -- -Michael Dick Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -- -Michael Dick
Re: [RESCINDED] [VOTE] publish openjpa 0.9.7-incubating release
Sorry, I meant to send this out sooner but I'm rescinding this vote. The docbook jar needs to be removed and we need to resolve the problem with DB2. On 4/19/07, Craig L Russell [EMAIL PROTECTED] wrote: Hi Kevin, I agree that the problem with sub-selects on DB2 seems significant enough to stop the release. Craig On Apr 19, 2007, at 7:52 AM, Kevin Sutter wrote: Another alternative is to back out the changes for OPENJPA-182 until we get the complete solution.. But, looking at the changes for OPENJPA-182, that looks to be quite the job and I'm not sure how many of these parts have been touched since that commit... I would rather wait until OPENJPA-222 tests clean and then go forward with another vote... But, I am open to other suggestions. Kevin On 4/19/07, Kevin Sutter [EMAIL PROTECTED] wrote: Craig and others, Here's the scoop with OPENJPA-222... A couple of weeks ago, DaveW committed some changes to OPENJPA-182. Patrick reviewed the changes and through discussions on the dev mailing list and the Issue itself, re-worked and re-committed the changes. We dropped the ball and didn't sufficiently test these new changes against DB2 until recently. We are finding that basically any sub-selects will not work with DB2 with the changes for OPENJPA-182. The changes for OPENJPA-222 will resolve these issues. This problem (no sub-selects with DB2) seems severe enough to warrant a re-spin of the release. I know this pushes us out another couple of days, but I think from a customer perspective, it's worth the effort. As far as this 0.9.7 being bundled with some significant release... We (IBM) were planning to use the 0.9.7 release with a refresh of the EJB3 Feature Pack. Our plans have since changed, so the urgency is no longer present. I just want any OpenJPA release to be usable and not regress expected function. Thanks, Kevin On 4/18/07, Craig L Russell [EMAIL PROTECTED] wrote: This isn't the last release of openjpa. What is the urgency for fixing this before our major event (the last release before exiting the incubator)? Is this release planned to be bundled with some other significant release? Craig On Apr 18, 2007, at 4:40 PM, Michael Dick wrote: I probably should have worded that differently since I haven't run the tests against DB2. I believe Dave's team has. Dave, can you comment on how big the impact of OpenJPA-222 is? On 4/18/07, Patrick Linskey [EMAIL PROTECTED] wrote: I'm a little nervous about OpenJPA-222. From talking with Dave it sounds like it has a large effect on DB2. I'd like to get that issue resolved if possible. I'm a little nervous about scope creep. Is there some good reason why OPENJPA-222 needs to be resolved now vs. later? -Patrick -- Patrick Linskey BEA Systems, Inc. _ __ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: Michael Dick [mailto:[EMAIL PROTECTED] ] Sent: Wednesday, April 18, 2007 2:24 PM To: open-jpa-dev@incubator.apache.org Subject: Re: [VOTE] publish openjpa 0.9.7-incubating release On 4/18/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Michael- On Apr 18, 2007, at 12:27 PM, Michael Dick wrote: I'd rather not cut another release, but I think we do need to resolve the issue with the docbook jar. If we can live with the extra jar then the vote can proceed. Personally, I think it is sufficiently ugly to release with the docbook jar to justify starting another release. However, if others disagree, I'll happily accede to the majority. For now, my vote changes to +0. I agree but like you I can be talked out of it. I'll take another look over everything and start another release tonight / tomorrow. I'm a little nervous about OpenJPA-222. From talking with Dave it sounds like it has a large effect on DB2. I'd like to get that issue resolved if possible. -- -Michael Dick Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message
Re: svn commit: r530563 - in /incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/jdbc: TestIsolationLevelOverride.java TestSelectForUpdateOverride.java
() == 1) || ((DB2Dictionary)dict)
-.getDb2ServerType()== 2) {
+.getDb2ServerType()== 2)) {
assertEquals(1, sql.size());
assertSQL(SELECT t0.booleanField, t0.byteField,
+ t0.charField, t0.dateField, t0.doubleField,
@@ -71,9 +71,9 @@
+ FOR UPDATE OF optimize for 1 row);
}
// it is DB2 v82 or later
-else if (dict instanceof DB2Dictionary
(((DB2Dictionary)dict).
+else if (dict instanceof DB2Dictionary
DB2Dictionary)dict).
getDb2ServerType() == 3) || ((DB2Dictionary)dict)
-.getDb2ServerType() == 4) {
+.getDb2ServerType() == 4)) {
assertEquals(1, sql.size());
assertSQL(SELECT t0.booleanField, t0.byteField,
+ t0.charField, t0.dateField, t0.doubleField,
--
-Michael Dick
Re: svn commit: r530563 - in /incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/jdbc: TestIsolationLevelOverride.java TestSelectForUpdateOverride.java
Dave beat me to it, but I was able to verify that the unit tests pass on
Derby and DB2. Has anyone tried running on Oracle? I know it shouldn't
matter for this fix but it can't hurt.
On 4/19/07, Michael Dick [EMAIL PROTECTED] wrote:
Looks like the fail got moved outside of the if(dict instanceof
DB2Dictionary) check.
I'll put in a fix.
On 4/19/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: wisneskid
Date: Thu Apr 19 14:58:46 2007
New Revision: 530563
URL: http://svn.apache.org/viewvc?view=revrev=530563
Log:
OPENJPA 222 fix for the testcases for DB2
Modified:
incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/jdbc/TestIsolationLevelOverride.java
incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/jdbc/TestSelectForUpdateOverride.java
Modified:
incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/jdbc/TestIsolationLevelOverride.java
URL:
http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/jdbc/TestIsolationLevelOverride.java?view=diffrev=530563r1=530562r2=530563
==
---
incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/jdbc/TestIsolationLevelOverride.java
(original)
+++
incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/jdbc/TestIsolationLevelOverride.java
Thu Apr 19 14:58:46 2007
@@ -82,9 +82,9 @@
.getIsolation());
q.getResultList();
-if (dict instanceof DB2Dictionary
(((DB2Dictionary)dict).
+if (dict instanceof DB2Dictionary
DB2Dictionary)dict).
getDb2ServerType() == 1) || ((DB2Dictionary)dict)
-.getDb2ServerType()== 2) {
+.getDb2ServerType()== 2)) {
assertEquals(1, sql.size());
assertSQL(SELECT t0.id, t0.booleanField,
t0.byteField,
+ t0.charField, t0.dateField, t0.doubleField
,
@@ -95,9 +95,9 @@
}
// it is DB2 v82 or later
-else if (dict instanceof DB2Dictionary
(((DB2Dictionary)dict).
+else if (dict instanceof DB2Dictionary
DB2Dictionary)dict).
getDb2ServerType() == 3) || ((DB2Dictionary)dict)
-.getDb2ServerType() == 4) {
+.getDb2ServerType() == 4)) {
assertEquals(1, sql.size());
assertSQL(SELECT t0.id, t0.booleanField,
t0.byteField,
+ t0.charField, t0.dateField, t0.doubleField
,
@@ -126,9 +126,9 @@
((JDBCFetchPlan) em.getFetchPlan())
.setIsolation(IsolationLevel.SERIALIZABLE);
em.find(AllFieldTypes.class, 0);
-if (dict instanceof DB2Dictionary
(((DB2Dictionary)dict).
+if (dict instanceof DB2Dictionary
DB2Dictionary)dict).
getDb2ServerType() == 1) || ((DB2Dictionary)dict)
-.getDb2ServerType()== 2) {
+.getDb2ServerType()== 2)) {
assertEquals(1, sql.size());
assertSQL(SELECT t0.booleanField, t0.byteField,
+ t0.charField, t0.dateField, t0.doubleField
,
@@ -138,9 +138,9 @@
+ FOR UPDATE OF optimize for 1 row);
}
// it is DB2 v82 or later
-else if (dict instanceof DB2Dictionary
(((DB2Dictionary)dict).
+else if (dict instanceof DB2Dictionary
DB2Dictionary)dict).
getDb2ServerType() == 3) || ((DB2Dictionary)dict)
-.getDb2ServerType() == 4) {
+.getDb2ServerType() == 4)) {
assertEquals(1, sql.size());
assertSQL(SELECT t0.booleanField , t0.byteField,
+ t0.charField, t0.dateField, t0.doubleField,
Modified:
incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/jdbc/TestSelectForUpdateOverride.java
URL:
http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/jdbc/TestSelectForUpdateOverride.java?view=diffrev=530563r1=530562r2=530563
==
---
incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/jdbc/TestSelectForUpdateOverride.java
(original)
+++
incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/jdbc
[VOTE] [THIRD ATTEMPT] publish openjpa 0.9.7-incubating release
OpenJPA People- In accordance with the Incubating Releases guidelines at http://incubator.apache.org/incubation/Incubation_Policy.html#Releases , I've taken another shot at making a release and start a vote on publishing a 0.9.7-incubating release of OpenJPA. The release candidate is at: http://people.apache.org/~mikedd/staging-repository/org/apache/openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7-incubating-binary.ziphttp://people.apache.org/%7Emikedd/staging-repository/org/apache/openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7-incubating-binary.zip The GPG signature and MD5 checksums are at: http://people.apache.org/~mikedd/staging-repository/org/apache/openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7-incubating-binary.zip.aschttp://people.apache.org/%7Emikedd/staging-repository/org/apache/openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7-incubating-binary.zip.asc http://people.apache.org/~mikedd/staging-repository/org/apache/openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7-incubating-binary.zip.md5http://people.apache.org/%7Emikedd/staging-repository/org/apache/openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7-incubating-binary.zip.md5 The sources, sources GPG signature and sources MD5 checksum are available at: http://people.apache.org/~mikedd/staging-repository/org/apache/openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7-incubating-source.zip http://people.apache.org/%7Emikedd/staging-repository/org/apache/openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7-incubating-source.zip http://people.apache.org/~mikedd/staging-repository/org/apache/openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7-incubating-source.zip.asc http://people.apache.org/%7Emikedd/staging-repository/org/apache/openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7-incubating-source.zip.asc http://people.apache.org/~mikedd/staging-repository/org/apache/openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7-incubating-source.zip.md5 http://people.apache.org/%7Emikedd/staging-repository/org/apache/openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7-incubating-source.zip.md5 A branch for this release candidate has been created at : https://svn.apache.org/repos/asf/incubator/openjpa/branches/0.9.7-incubating-RC2 The release has been published to a staging repository on people.apache.org. The staging repository may be used in a maven 2 build file by adding the following information : . . . repositories repository idstaging-repository/id namemikedd's staging repository/name url http://people.apache.org/~mikedd/staging-repositoryhttp://people.apache.org/%7Emikedd/staging-repository /url /repository . . . /repositories . . . dependencies dependency groupIdorg.apache.openjpa/groupId artifactIdopenjpa-all/artifactId version0.9.7-incubating/version /dependency . . . /dependencies Known issues : There are a few .rsrc files included in the release which do not contain licensing information. The issue has been discussed in several threads on the open-jpa-dev mailing list (links follow). To summarize : orm-xsd.rsrc and persistence-xsd.rsrc are copies of the official JPA schemas under CDDL that are properly attributed in LICENSE.txt java-keywords.rsrc does not contain IP schemas-doctype.rsrc does contain IP however the parser for this file does not support comments. These issues will be addressed in a future release. For more information please see the discussion on the mailing list (roughly) starting here http://www.nabble.com/forum/ViewPost.jtp?post=10022158framed=y Please vote to publish this incubating release on the project Web page: http://cwiki.apache.org/openjpa/downloads.html This vote will remain open until 14:40 CST on Tuesday April 24th. A +1 indicates that you approve of the release, a -1 indicates a vote against making a release -- -Michael Dick
Re: Artifact names
I've been overriding the deployment location for the staging directory. I
thought I made the changes back to trunk, but I must have missed it, I just
added it back in.
The changes configure the deploy plugin to look for a
deploy.altRepositoryvariable, if it's found we'll deploy to that
location.
The variable can be added in ${M2_HOME}/settings.xml like this :
profiles
profile
idrelease/id
properties deploy.altRepository
people.apache.org::default::scp://people.apache.org/home/mikedd/public_html/staging-repository
/deploy.altRepository
/properties
/profile
/profiles
Run mvn -Prelease deploy and watch for scp and it will deploy to the
alternate location. If you just do the build from a subproject it should
work (haven't tried it though).
On 4/25/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:
Does anyone happen to know if there is a way to override the
repository part of the distributionManagement section of the
pom.xml? If we were able to do that, we could keep the individual jar
artifacts deployed to the http://people.apache.org/repo/m2-snapshot-
repository/org/apache/openjpa/ (so people can reference the
individual artifacts as usual), but upload the artifacts from the
openjpa-project sub-pom to a separate location?
On Apr 25, 2007, at 10:29 AM, Craig L Russell wrote:
+1 to all that.
What JDO does is publish the non-maven artifacts to the dist/db
directory (JDO is a db sub-project) and there is a script that
allows us to use the mirrors to let folks get the binary or source
download. And we publish the maven artifacts so that a user can
just write a pom and five lines of code later maven will download
the dependency tree. Sweet.
Craig
On Apr 25, 2007, at 7:07 AM, Eddie O'Neil wrote:
While in incubation, the best place for non-Maven downloads is here:
http://people.apache.org/dist/incubator/
Once out of incubation, the right place is here:
http://www.apache.org/dist/
which ties an artifact into the mirroring system. Then, there's a
particular way to format the project's download page in order to list
all of the mirrors as download options for that artifact a la:
http://struts.apache.org/download.cgi
Eddie
On 4/25/07, Michael Dick [EMAIL PROTECTED] wrote:
On 4/24/07, Phill Moran [EMAIL PROTECTED] wrote:
I don't think you want the tarball in maven. Personally I would
not look
for it
there or go searching my local repo to open and get examples,
docs etc.
Can we
keep the tarball on OpenJPA and the minimal compile an
execution jar on
Maven.
Keep in mind that this jar is replicated on maven, corp repo
then local
repo - a
lot of wasted space if not absolutely necessary.
Phill
I agree, if we put the tarball in a different location then we
should remove
it from the maven repository at the same time. It shouldn't be
too tricky to
separate the tarball generation from the normal build processing
(in which
case maven won't deploy the tarball).
Assuming this is the right way to go, where would be put the
tarball?
-Original Message-
From: Patrick Linskey [mailto:[EMAIL PROTECTED]
Sent: April 24, 2007 10:49 PM
To: open-jpa-dev@incubator.apache.org
Subject: RE: Artifact names
Personally, I think both are valuable as they serve
different needs
for different development environments.
I agree completely. Just wondering if we should be publishing
the tarball
via
mvn.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email message, together with any attachments, may
contain
information of BEA Systems, Inc., its subsidiaries and
affiliated
entities, that may be confidential, proprietary,
copyrighted and/or
legally
privileged, and is intended solely for the use of the
individual or entity
named
in this message. If you are not the intended recipient, and
have received
this
message in error, please immediately return this by email and
then delete
it.
-Original Message-
From: Eddie O'Neil [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 24, 2007 7:41 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Artifact names
It's a fair question -- if you want people to be able to sync
dependencies from Maven directly into their projects via pom.xml
references, then the Maven repository is the way to go.
If you want to distribute a single package that contains
everything
(binaries, docs, samples, etc) needed to get started with
OpenJPA and
doesn't require the user to use the Maven project model, then
the
source / binary zip archives are the way to go.
Personally, I think both are valuable as they serve
different needs
for different development environments.
Eddie
On 4/24/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:
On Apr 24, 2007, at 7:27 PM
Re: svn commit: r534647 - /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/SelectImpl.java
How about a testcase? :-)
On 5/2/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: wisneskid
Date: Wed May 2 15:53:39 2007
New Revision: 534647
URL: http://svn.apache.org/viewvc?view=revrev=534647
Log:
Fix for issue OPENJPA-51. It should also resolve issue OPENJPA-173.
Change to use BitSet.
Modified:
incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/SelectImpl.java
Modified:
incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/SelectImpl.java
URL:
http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/SelectImpl.java?view=diffrev=534647r1=534646r2=534647
==
---
incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/SelectImpl.java
(original)
+++
incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/SelectImpl.java
Wed May 2 15:53:39 2007
@@ -26,6 +26,7 @@
import java.sql.Types;
import java.util.AbstractList;
import java.util.ArrayList;
+import java.util.BitSet;
import java.util.Collection;
import java.util.Collections;
import java.util.HashMap;
@@ -164,7 +165,7 @@
// bit 1 : correspond to alias 1, etc.
// if the bit is set, the corresponding alias has been removed from
parent
// and recorded under subselect.
-private int _removedAliasFromParent = 0;
+private BitSet _removedAliasFromParent = new BitSet(16);
/**
* Helper method to return the proper table alias for the given alias
index.
@@ -1496,7 +1497,7 @@
return;
if (_parent._joins != null !_parent._joins.isEmpty()) {
boolean removed = false;
-if (_removedAliasFromParent 0)
+if (!_removedAliasFromParent.isEmpty())
removed = _parent._joins.joins().removeAll(pj.joins());
if (!removed)
pj.joins().removeAll(_parent._joins.joins());
@@ -1914,7 +1915,7 @@
if (alias != null) {
if (removeAliasFromParent) {
recordTableAlias(table, key, alias);
-_removedAliasFromParent |= (1 alias.intValue());
+_removedAliasFromParent.set(alias.intValue());
}
return alias;
}
Re: [VOTE] Graduate from Incubation
+1 On 5/3/07, Kevin Sutter [EMAIL PROTECTED] wrote: +1, Thanks Craig for pushing this along. Much appreciated! On 5/3/07, Brian McCallister [EMAIL PROTECTED] wrote: +1 With the caveat that you remove me from the PMC list -- I don't merit inclusion :-) -Brian On May 3, 2007, at 7:22 AM, Craig L Russell wrote: This vote is to send the attached draft board resolution to the incubator for the purpose of graduation from the incubator to the Apache OpenJPA project. +1 We're ready; let's graduate 0 Don't care -1 Let's wait Establish the Apache OpenJPA project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project, to be known as Apache OpenJPA, related to the implementation of object persistence, including, but not limited to, Java Persistence API, for distribution at no charge to the public; NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the OpenJPA PMC be and hereby is charged with the creation and maintenance of Apache OpenJPA; and be it further RESOLVED, that the office of Vice President, Apache OpenJPA be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the OpenJPA PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache OpenJPA PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the OpenJPA PMC: Eddie O'Neil[EMAIL PROTECTED] Geir Magnusson Jr. [EMAIL PROTECTED] Brian McCallister [EMAIL PROTECTED] Patrick Linskey [EMAIL PROTECTED] Craig Russell [EMAIL PROTECTED] Kevin Sutter[EMAIL PROTECTED] Abe White [EMAIL PROTECTED] Marc Prud'hommeaux [EMAIL PROTECTED] NOW, THEREFORE, BE IT FURTHER RESOLVED, that Craig Russell be appointed to the office of Vice President, Apache OpenJPA, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial OpenJPA PMC be and hereby is tasked with the migration and rationalization of the Apache Incubator OpenJPA podling; and be it further RESOLVED, that all responsibility pertaining to the Apache Incubator OpenJPA podling and encumbered upon the Apache Incubator PMC are hereafter discharged. Craig Russell DB PMC, OpenJPA PPMC [EMAIL PROTECTED] http://db.apache.org/jdo
Re: [DISCUSS] Packaging with maven
Some comments below On 5/4/07, Craig L Russell [EMAIL PROTECTED] wrote: I'd like reopen the discussion on how to package and name our artifacts. I think the current setup could be improved, to give a better experience for users who might not be using maven for dependency management. It's easy for us to change now before graduation because once we graduate, people will need to update their dependencies anyway so there are no backward compatibility issues. The name of the single jar that has all of the openjpa stuff in it except for the documentation and examples is currently called openjpa- all. This name is confusing because unless they RTFM, people don't really know that it's not all the code you need, just all the jpa code. So I'd like to call this artifact openjpa. +1 But we already have a project with that name, and that project builds the distributions. So I'd rename the current openjpa to openjpa-dist. Its ultimate destination in the Apache mirror structure is under www.apache.org/dist/openjpa once we graduate, so having dist in the project name helps understanding that this project builds the artifacts that go into dist. Separate from the artifacts that are published via maven. +1 Finally, the openjpa-all jar includes its subcomponents as dependencies. I think this is wrong, since you end up with a class path with openjpa-all.jar as well as openjpa-kernel.jar and all the others. I would like to change this too. I did a little experimenting and it looks like the dependencies aren't needed in openjpa-all, but they are needed for openjpa-project (to populate the lib directory). Moving the dependencies into openjpa-project should be safe. We're also going to need to change the deploy logic to strip out the -project suffix from the zip files. We've talked about it before when I was releasing 0.9.7 (and before that when Marc was working on 0.9.6), but I haven't had time to look into it. It should be fairly easy to make the change. Thoughts? Craig Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! -Michael Dick
Re: [VOTE] Packaging with maven
+1 What would the impact be if we renamed openjpa-all to openjpa? We could change our checkout instructions to read svn co http://svn.apache.org/repos/asf/incubator/openjpa/trunkopenjpa-parent and then the directories match the artifactId's in pom.xml. The only reason I think this is worth doing is to avoid confusion for new developers down the road. It's just one more thing that we have to remember and explain. Maybe there's an impact to changing the directory name that I missed though. -Mike On 5/6/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Poking around the ActiveMQ pom.xml files, I notice that you can have a different artifactId than the module name (i.e., directory) you are in. I hadn't known you could do this. Currently, our artifacts name are: trunk/pom.xml: openjpa trunk/openjpa-all/pom.xml: openjpa-all trunk/openjpa-project/pom.xml: openjpa-project We could change these to: trunk/pom.xml: openjpa-parent trunk/openjpa-all/pom.xml: openjpa trunk/openjpa-project/pom.xml: apache-openjpa I've tested this out, and it results in the openjpa aggregate jar being named openjpa-VERSION.jar, the dependency being simply named openjpa, and the assembly is named apache-openjpa-VERSION.zip . None of the directories needed to be renamed. I've attached the patch that does this to https://issues.apache.org/jira/browse/OPENJPA-194 Since this will mess up people who currently have maven dependencies on OpenJPA (i.e., people who depend on openjpa-all will now need to depend on openjpa), we should probably get this hammered out before leaving incubation. So I've gone ahead and turned the [DISCUSS] into a [VOTE] to see if we should go ahead and do this. A vote of +1 means we should do the renaming, -1 means we should not, and 0 means don't care. The vote will remain open until Wednesday May 9th at 23:59 GMT. On May 4, 2007, at 6:55 AM, Michael Dick wrote: Some comments below On 5/4/07, Craig L Russell [EMAIL PROTECTED] wrote: I'd like reopen the discussion on how to package and name our artifacts. I think the current setup could be improved, to give a better experience for users who might not be using maven for dependency management. It's easy for us to change now before graduation because once we graduate, people will need to update their dependencies anyway so there are no backward compatibility issues. The name of the single jar that has all of the openjpa stuff in it except for the documentation and examples is currently called openjpa- all. This name is confusing because unless they RTFM, people don't really know that it's not all the code you need, just all the jpa code. So I'd like to call this artifact openjpa. +1 But we already have a project with that name, and that project builds the distributions. So I'd rename the current openjpa to openjpa-dist. Its ultimate destination in the Apache mirror structure is under www.apache.org/dist/openjpa once we graduate, so having dist in the project name helps understanding that this project builds the artifacts that go into dist. Separate from the artifacts that are published via maven. +1 Finally, the openjpa-all jar includes its subcomponents as dependencies. I think this is wrong, since you end up with a class path with openjpa-all.jar as well as openjpa-kernel.jar and all the others. I would like to change this too. I did a little experimenting and it looks like the dependencies aren't needed in openjpa-all, but they are needed for openjpa-project (to populate the lib directory). Moving the dependencies into openjpa-project should be safe. We're also going to need to change the deploy logic to strip out the -project suffix from the zip files. We've talked about it before when I was releasing 0.9.7 (and before that when Marc was working on 0.9.6), but I haven't had time to look into it. It should be fairly easy to make the change. Thoughts? Craig Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/ jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! -Michael Dick
Re: DB2 support
Hi William, I have been running OpenJPA against DB2 v9 with no major issues, and I believe others on the forums have been doing so as well. Admittedly this isn't a certification, but it's at least anecdotal evidence that DB2 v9 will work. For KODO I'd have to refer you to BEA's support statement, but I'd be surprised if they did not support DB2 as well. I'm not sure what you mean by cases to run OpenJPA/KODO on DB2. If you're looking for instructions on how to run the OpenJPA unit tests against DB2 I can help you with that. If you'd prefer to try running your own application against DB2 all you need to do is add the appropriate connection properties to persistence.xml : Something like this should work. . . . properties . . . property name=openjpa.ConnectionDriverName value= com.ibm.db2.jcc.DB2Driver / property name=openjpa.ConnectionURL value=jdbc:db2://localhost:5/TEST / property name=openjpa.ConnectionUserName value=db2user / property name=openjpa.ConnectionPassword value=db2password / . . . /properties . . . Regards, Michael DIck On 5/9/07, William Cai [EMAIL PROTECTED] wrote: Hi list, AFAIK, the latest DB2 version is DB2 enterprise server edition V9.1. But but current OpenJDK only supports DB2 UDB v8.1. Do we have any plans to certify DB2 UDB V8.2 and DB2 v9 recently? Or more realistically -- are there any cases to run OpenJPA/KODO on DB2 UDB v8.2 or DB2 v9? Any input is greatly appreciated. Thanks, William Database Name Database Version JDBC Driver Name JDBC Driver Version Apache Derby 10.1.2.1 Apache Derby Embedded JDBC Driver 10.1.2.1 Borland Interbase 7.1.0.202 Interclient 4.5.1 Borland JDataStore 6.0 Borland JDataStore 6.0 DB2 8.1 IBM DB2 JDBC Universal Driver 1.0.581
Re: DB2 support
OK, now that I found the relevant section in the documentation I understand what William is asking for. What level of testing do we need to do before we can add a new version of DB2 to the list of supported databases? Is just running our unit test bucket sufficient to add a new database to the list or do we need a more formal process? On 5/9/07, Michael Dick [EMAIL PROTECTED] wrote: Hi William, I have been running OpenJPA against DB2 v9 with no major issues, and I believe others on the forums have been doing so as well. Admittedly this isn't a certification, but it's at least anecdotal evidence that DB2 v9 will work. For KODO I'd have to refer you to BEA's support statement, but I'd be surprised if they did not support DB2 as well. I'm not sure what you mean by cases to run OpenJPA/KODO on DB2. If you're looking for instructions on how to run the OpenJPA unit tests against DB2 I can help you with that. If you'd prefer to try running your own application against DB2 all you need to do is add the appropriate connection properties to persistence.xml : Something like this should work. . . . properties . . . property name=openjpa.ConnectionDriverName value= com.ibm.db2.jcc.DB2Driver / property name=openjpa.ConnectionURL value=jdbc:db2://localhost:5/TEST / property name=openjpa.ConnectionUserName value=db2user / property name=openjpa.ConnectionPassword value=db2password / . . . /properties . . . Regards, Michael DIck On 5/9/07, William Cai [EMAIL PROTECTED] wrote: Hi list, AFAIK, the latest DB2 version is DB2 enterprise server edition V9.1. But but current OpenJDK only supports DB2 UDB v8.1. Do we have any plans to certify DB2 UDB V8.2 and DB2 v9 recently? Or more realistically -- are there any cases to run OpenJPA/KODO on DB2 UDB v8.2 or DB2 v9? Any input is greatly appreciated. Thanks, William Database Name Database Version JDBC Driver Name JDBC Driver Version Apache Derby 10.1.2.1 Apache Derby Embedded JDBC Driver 10.1.2.1 Borland Interbase 7.1.0.202 Interclient 4.5.1 Borland JDataStore 6.0 Borland JDataStore 6.0 DB2 8.1 IBM DB2 JDBC Universal Driver 1.0.581
Re: [VOTE RESULT] Packaging with maven
+1 Thanks Marc. On 5/9/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Sounds good to me. On May 9, 2007, at 3:28 PM, Patrick Linskey wrote: Note that I only changed the artifact names, not the directory names in which they reside. We can always start another vote on shuffling around the directory names if people deem it a worthwhile endeavor. I think that we should make the change, for the sake of reducing future confusion. But we should probably just do it when we move out of the incubator svn repo, since we'll presumably have to do other changes at that time. -Patrick On 5/9/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: With 5 +1 votes and no -1 or 0 votes, the proposal passes. I've gone ahead and committed the patch for OPENJPA-194. Note that I only changed the artifact names, not the directory names in which they reside. We can always start another vote on shuffling around the directory names if people deem it a worthwhile endeavor. On May 6, 2007, at 2:27 PM, Marc Prud'hommeaux wrote: Poking around the ActiveMQ pom.xml files, I notice that you can have a different artifactId than the module name (i.e., directory) you are in. I hadn't known you could do this. Currently, our artifacts name are: trunk/pom.xml: openjpa trunk/openjpa-all/pom.xml: openjpa-all trunk/openjpa-project/pom.xml: openjpa-project We could change these to: trunk/pom.xml: openjpa-parent trunk/openjpa-all/pom.xml: openjpa trunk/openjpa-project/pom.xml: apache-openjpa I've tested this out, and it results in the openjpa aggregate jar being named openjpa-VERSION.jar, the dependency being simply named openjpa, and the assembly is named apache-openjpa- VERSION.zip. None of the directories needed to be renamed. I've attached the patch that does this to https://issues.apache.org/ jira/ browse/OPENJPA-194 Since this will mess up people who currently have maven dependencies on OpenJPA (i.e., people who depend on openjpa-all will now need to depend on openjpa), we should probably get this hammered out before leaving incubation. So I've gone ahead and turned the [DISCUSS] into a [VOTE] to see if we should go ahead and do this. A vote of +1 means we should do the renaming, -1 means we should not, and 0 means don't care. The vote will remain open until Wednesday May 9th at 23:59 GMT. On May 4, 2007, at 6:55 AM, Michael Dick wrote: Some comments below On 5/4/07, Craig L Russell [EMAIL PROTECTED] wrote: I'd like reopen the discussion on how to package and name our artifacts. I think the current setup could be improved, to give a better experience for users who might not be using maven for dependency management. It's easy for us to change now before graduation because once we graduate, people will need to update their dependencies anyway so there are no backward compatibility issues. The name of the single jar that has all of the openjpa stuff in it except for the documentation and examples is currently called openjpa- all. This name is confusing because unless they RTFM, people don't really know that it's not all the code you need, just all the jpa code. So I'd like to call this artifact openjpa. +1 But we already have a project with that name, and that project builds the distributions. So I'd rename the current openjpa to openjpa- dist. Its ultimate destination in the Apache mirror structure is under www.apache.org/dist/openjpa once we graduate, so having dist in the project name helps understanding that this project builds the artifacts that go into dist. Separate from the artifacts that are published via maven. +1 Finally, the openjpa-all jar includes its subcomponents as dependencies. I think this is wrong, since you end up with a class path with openjpa-all.jar as well as openjpa-kernel.jar and all the others. I would like to change this too. I did a little experimenting and it looks like the dependencies aren't needed in openjpa-all, but they are needed for openjpa-project (to populate the lib directory). Moving the dependencies into openjpa-project should be safe. We're also going to need to change the deploy logic to strip out the -project suffix from the zip files. We've talked about it before when I was releasing 0.9.7 (and before that when Marc was working on 0.9.6), but I haven't had time to look into it. It should be fairly easy to make the change. Thoughts? Craig Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/ products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! -Michael Dick -- Patrick Linskey 202 669 5907
Re: Will reversemappingTask() generate EJB3 annotations?
That's what I've found too. The reversemapping tool will create new java files based on the database tables, and provide an orm.xml file. No annotations though. You can always add them based on the generated orm.xml file although that might be easier said than done if you have a lot of entities. -mike On 5/16/07, Phill Moran [EMAIL PROTECTED] wrote: I am not sure that it will annotate your exiting code but (I think) it will make an external mapping file for you or generate the annotated classes from the ground up. Check out the MappingTool class/docs -Original Message- From: linda rae [mailto:[EMAIL PROTECTED] Sent: May 16, 2007 8:58 AM To: open-jpa-dev@incubator.apache.org; open-jpa-dev@incubator.apache.org Subject: Will reversemappingTask() generate EJB3 annotations? I apologize if this question has been previously asked and answered. I have googled for an answer with no luck. I have been requested to use OpenJPA on a project. The tool appears straight forward and works well, I have ran the reverse engineering example on my own DB - it works great. However... no EJB3 annotations were generated (@Entity, etc). What configuration option must I define to have the reversemapping tool generate an EJB3 EntityEJB? A short response would be great - any response would would really help (am I asking for something that does not exist?) Thank-you, Linda Rae
Re: the pain of post processing bytecode (another beg for a simple reflection/cglib alternative like hibernate)
Hi James,
I don't know how easy this is to do with IDEA, but what I've done in Eclipse
is to create the project via mvn eclipse:eclipse then create a run
definition for org.apache.openjpa.enhance.PCEnhancer. With no other
classpath tweaking it enhances the entities in the output directory and I'm
up and running.
Another alternative would be to use dynamic enhancement when you run in your
IDE. In eclipse you can just add -javaagent:${path.to.openjpa-xxx.jar} as a
vm argument and you won't have to run the enhancer at all.
Patrick also mentioned writing an IDEA plug-in (not sure if that's the right
name) that would do the enhancement. I believe he ran into a few snags
getting access to IntelliJ jars. This or something similar might be a good
solution for you. Ideally we'll have Eclipse, IDEA and NetBeans plugins
someday.
Eclipse also allows user defined builders to be run in addition to the
default java compiler. The builders can be ant scripts or java programs -
either one should be able to enhance your entities. I have never used IDEA,
but I suspect it includes a similar concept.
All that being said I'm not trying to dismiss your idea of adding a cglib
interface - I'm just sharing what has worked for me and some ideas that
might also work for you. It's a bit specific to Eclipse, but from what I've
heard IDEA is a very good IDE and I suspect it can do them as well.
-Mike
On 5/17/07, James.Strachan [EMAIL PROTECTED] wrote:
Firstly before I start, openjpa is a great piece of software; I'm
particularly fond of the documentation and in particular the query
language
parts. The CSS for the site is also awesome :)
However compared to hibernate, openjpa is still pretty painful to use from
an end users perspective and I don't think this should be the case; plus I
don't think it'll take much time to fix. While the pain is still fresh in
my
mind I thought I'd post on how much more painful openjpa is to use in a
project. If you're short on time, the basic idea is its that bytecode post
processing stuff thats to blame :). Yes I know its probably faster that
way
- its just so painful for Java programmers to work with. (And yes I know
one
day we'll all have IDE plugins that hide the bytecode stuff etc etc).
So the first thing is having to mess with your build (ant or maven) to get
the post processing properly integrated. Depending on if you have
persistent
entities in your main or test area this can often trip you up a little (as
it did me). I don't know about folks on this list but the whole idea of
having to mess with my maven build gives me the jitters :). When you get
that far the maven planets are aligned with openjpa, the next hurdle you
hit is how do you run stuff in your IDE. If like me you use IDEA and maven
2, the project gets auto-created by default for all projects you work on.
However these don't work when you use openjpa as you hit the dreaded
'cannot
function at all as you've not run the up front bytecode post processor you
dummy!' type error when trying to run stuff in your IDE.
So you then add the maven-generated classes to the front of the classpath
in
your project. Hooray, after a day or two's work, you can now actually use
openjpa in your IDE and your build. YAY! The downside is that now when
navigating around your Java code, whenever you navigate into an entity
bean,
IDEA shows you the bytecode - not the source code as its confused since
the
bytecode generated stuff is different to the source code it knows about.
So
now you're faced with a dilemma - choose between navigating nicely around
your source code - or being able to actually run/debug your application. I
won't even get into the refactoring pain or having to continuously run
maven
builds while developing code to avoid getting code completion/compile
errors
etc. (I prefer to keep in my IDE where possible).
Compare this whole malarkey with hibernate. You add hibernate to your pom,
generate your project and you're good to go. No messing with your project
build; no messing with some secret ninja IDE stuff to be able to actually
run debug your code while still being able to actually navigate the
source. It just works. Now it might work in a crappy slow way and
openjpa
might be way way more efficient and powerful and whatnot - but I'd rather
have a cheap car that just works than a ferrari that you can only drive on
a
tuesday if its sunny, but not too hot and refuses to even start if its
wet.
FWIW I've just given up using openjpa for development; its just way too
painful. (I'm even hacking projects I work on so I use openjpa in the
maven
build but explicitly switch to hibernate in development mode; yeah its
more
work but at least I can use my IDE properly again).
I'm cool with putting post processing into the build system (though that
should really only be an optimisation); but please can we have some
inefficient but usable reflection/cglib type approach so folks can easily
switch from hibernate to openjpa (and stay there) without
Re: the pain of post processing bytecode (another beg for a simple reflection/cglib alternative like hibernate)
Hi Philippe,
It looks like your attachment was dropped by the mailing list so I'm
guessing a little here. I did try setting all of this up from scratch with
one of my Eclipse projects, here's what I did.
Downloaded openjpa-project-0.9.7-incubating-source.zip and
openjpa-project-0.9.7-incubating-binary.zip and extract them (directory
/home/mikedd/downloads in my case).
Add the openjpa-* jar to my Eclipse project's classpath as an external jar.
I'm cheating a bit and picking up the other dependencies from my maven
repository, but that shouldn't matter.
Create a run definition for your application. Add
-javaagent:/home/mikedd/download/openjpa-project-0.9.7-incubating/openjpa-
0.9.7-incubating.jar as a vm arg. On the source tab add the source
directories for each OpenJPA subproject (ie /home/mikedd/downloads/openjpa-
project-0.9.7-incubating-source/openjpa-persistence/src/main/java ).
I think that's about it then you should be able to run your application,
debug OpenJPA or your entities if you want, etc. The mailing list has
rejected my message whenever I attach screenshots so I'll send them directly
to you instead.
Hope this helps,
-Michael Dick
On 5/20/07, Philippe Alexis [EMAIL PROTECTED] wrote:
Hi Everyone,
Not meaning to hi-jack it, I'll piggy-back on this thread because I've
made some progress setting up
OpenJPA as an Eclipse project thanks to some tips below from Michael. It's
been a long arduous road
over the whole weekend...
I went for compile-time enhancement via an Ant script as a user-defined
builder because as per the
attached screenshot, Eclipse-VM-params.PNG, (I hope having that is not
against the list's policy)
dynamic enhancement via -javaagent:${path_to_openjpa-*.jar} hasn't worked
so far and yields the error
message as shown in Eclipse's Console window. Is it working? I doubt it.
There's no [openjpac] output by Ant.
At least, the end of it says Build Successful.
The other screenshot, Eclipse-BrokerFactory-not-found.png, is where I've
reached stepping through the project
this far, running the Main.java of the Deity example.
You did not name the factory class with the required property
openjpa.BrokerFactory.
Normally this property defaults appropriately; have you forgotten to
include all the OpenJPA jars in your classpath?
Where would that be defined by default?
Would anyone be so kind as to post a similar screenshot of what's required
as Source folders to successfully debug
OpenJPA under Eclipse? I'm probably not too far but it's... late.
J-Philippe.
On 5/17/07, Michael Dick [EMAIL PROTECTED] wrote:
Hi James,
I don't know how easy this is to do with IDEA, but what I've done in
Eclipse
is to create the project via mvn eclipse:eclipse then create a run
definition for org.apache.openjpa.enhance.PCEnhancer . With no other
classpath tweaking it enhances the entities in the output directory and
I'm
up and running.
Eclipse also allows user defined builders to be run in addition to the
default java compiler. The builders can be ant scripts or java programs
-
either one should be able to enhance your entities. I have never used
IDEA,
but I suspect it includes a similar concept.
All that being said I'm not trying to dismiss your idea of adding a
cglib
interface - I'm just sharing what has worked for me and some ideas that
might also work for you. It's a bit specific to Eclipse, but from what
I've
heard IDEA is a very good IDE and I suspect it can do them as well.
-Mike
On 5/17/07, James.Strachan [EMAIL PROTECTED] wrote:
Firstly before I start, openjpa is a great piece of software; I'm
particularly fond of the documentation and in particular the query
language
parts. The CSS for the site is also awesome :)
However compared to hibernate, openjpa is still pretty painful to use
from
an end users perspective and I don't think this should be the case;
plus I
don't think it'll take much time to fix. While the pain is still fresh
in
my
mind I thought I'd post on how much more painful openjpa is to use in
a
project. If you're short on time, the basic idea is its that bytecode
post
processing stuff thats to blame :). Yes I know its probably faster
that
way
- its just so painful for Java programmers to work with. (And yes I
know
one
day we'll all have IDE plugins that hide the bytecode stuff etc etc).
So the first thing is having to mess with your build (ant or maven) to
get
the post processing properly integrated. Depending on if you have
persistent
entities in your main or test area this can often trip you up a little
(as
it did me). I don't know about folks on this list but the whole idea
of
having to mess with my maven build gives me the jitters :). When you
get
that far the maven planets are aligned with openjpa, the next hurdle
you
hit is how do you run stuff in your IDE. If like me you use IDEA and
maven
2, the project gets auto-created by default for all projects you work
on.
However
[jira] Resolved: (OPENJPA-12) Default to strictIdentityTypes for JPA
[ http://issues.apache.org/jira/browse/OPENJPA-12?page=all ] Michael Dick resolved OPENJPA-12. - Resolution: Invalid Per comments on the dev mailing list. If the TCK passes with the property specified then there's no need to change the default behavior. I'm setting the resolution to invalid since it isn't really a bug (won't fix didn't sound right). Default to strictIdentityTypes for JPA -- Key: OPENJPA-12 URL: http://issues.apache.org/jira/browse/OPENJPA-12 Project: OpenJPA Issue Type: Bug Components: jpa Reporter: Michael Dick Priority: Minor Attachments: patch.txt The default behavior with OpenJPA is to be very forgiving regarding the Primary Key types passed in when calling EntityManager.find or EntityManager.getReference. For example if an Entity has an ID of type Long OpenJPA will attempt to convert anything that extend java.lang.Number and Strings (maybe others). This is a nice feature, but I don't think it should be the default behavior. The JPA spec indicates that an IllegalArgumentException should be thrown if the second argument is not a valid type for the Entity's primary key. There is some room for interpretation as to what constitutes a valid type, conversion for all Numbers makes sense, but String might be pushing it. Workaround : Add the following to persistence.xml property name=openjpa.Compatibility value=strictIdentityValues=true / Proposed Solution : The OpenJPA compatibility plugin provides a mechanism to enforce strict identity checking (defaulting to false). There's no need to change the default in the kernel (other persistence apis like JDO might be more lenient) so I propose changing the default in PersistenceProductDerivation.beforeConfigurationLoad(). Changing it there should only effect the JPA facade and leave the OpenJPA kernel's default in place for other facades. The value may be overridden by adding the following property to persistence.xml property name=openjpa.Compatibility value=strictIdentityValues=false / -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (OPENJPA-34) Problem detecting parent's access type with runtime enhancement.
Problem detecting parent's access type with runtime enhancement. - Key: OPENJPA-34 URL: http://issues.apache.org/jira/browse/OPENJPA-34 Project: OpenJPA Issue Type: Bug Reporter: Michael Dick Priority: Minor Attachments: employee-project.zip I have a small hierarchy of entities specified in an xml descriptor (orm.xml), Employee, PartTimeEmployee and FullTimeEmployee. PartTimeEmployee and FullTimeEmployee extend Employee which is a MappedSuperclass. If I don't explicitly set the access type for either PartTimeEmployee or FullTimeEmployee in orm.xml and I use the static enhancer (org.apache.openjpa.enhance.PCEnhancer) everything works fine. If I use runtime enhancement I get a warning like this : 184 INFO [main] openjpa.MetaData - Found 3 classes with metadata in 7 milliseconds. 88 INFO [main] openjpa.Runtime - Starting OpenJPA 0.0.0 180 INFO [main] openjpa.jdbc.JDBC - Using dictionary class org.apache.openjpa.jdbc.sql.DerbyDictionary. 277 INFO [main] openjpa.MetaData - Found 4 classes with metadata in 1 milliseconds. 985 INFO [main] openjpa.MetaData - Parsing resource file:/home/mikedd/workspaces/openjpa/mdd/target/classes/META-INF/orm.xml. 1307 INFO [main] openjpa.MetaData - Parsing class mdd.entities.descriptor.Employee. 1356 INFO [main] openjpa.MetaData - Parsing class mdd.entities.descriptor.Employee. 1356 INFO [main] openjpa.MetaData - Parsing package mdd.entities.descriptor.Employee. 1385 INFO [main] openjpa.MetaData - Parsing class mdd.entities.descriptor.PartTimeEmployee. 1385 INFO [main] openjpa.MetaData - Parsing class mdd.entities.descriptor.PartTimeEmployee. 1389 INFO [main] openjpa.MetaData - Parsing class mdd.entities.descriptor.FullTimeEmployee. 1390 INFO [main] openjpa.MetaData - Parsing class mdd.entities.descriptor.FullTimeEmployee. 1394 INFO [main] openjpa.MetaData - Parsing class mdd.entities.descriptor.AbstractPersonnel. 1422 WARN [main] openjpa.Enhance - An exception was thrown while attempting to perform class file transformation on mdd/entities/descriptor/FullTimeEmployee: 4|false|0.0.0 org.apache.openjpa.util.UserException: Detected the following possible violations of the restrictions placed on property access persistent types: The member for for persistent property mdd.entities.descriptor.FullTimeEmployee.salary was not a method: private float mdd.entities.descriptor.FullTimeEmployee.salary. at org.apache.openjpa.enhance.PCEnhancer.processViolations(PCEnhancer.java:520) at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:287) at org.apache.openjpa.enhance.PCClassFileTransformer.transform(PCClassFileTransformer.java:122) at sun.instrument.TransformerManager.transform(TransformerManager.java:141) at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:174) at java.lang.ClassLoader.defineClassImpl(Native Method) From what I can tell after running the debugger the error occurs because the runtime enhancer isn't able to find the parent's metadata (and from that the access type). I don't think the spec is very clear in this regard. Access isn't a required attribute for entities, but the spec doesn't indicate what should happen if it isn't present (or if it does I didn't find it). I don't know whether this is a limitation of runtime enhancement (again I didn't see it documented anywhere, but maybe I didn't look hard enough). There are also plenty of solutions, specifying a default access type in orm.xml, or just adding access=PROPERTY to the entity will work. If it's not an architectural limitation though, I think we should try to get runtime enhancement to work in the same manner as static enhancement. In case it helps here's my javaagent setting : -javaagent:/home/mikedd/.m2/repository/org/apache/openjpa/openjpa-kernel-5/0.9.0-SNAPSHOT/openjpa-kernel-5-0.9.0-SNAPSHOT.jar=scanDevPath=true,MetaDataFactory=jpa I've attached the source that I've used to produce the problem, include the eclipse .project and .classpath files (you'll probably have to update these). There's also a pom.xml which can be used to compile or at least set up the classpath in eclipse. I don't know how to toggle between runtime and static enhancement with maven so I haven't used it to run the tests. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OPENJPA-24) Allow OpenJPA to be extensible
[ http://issues.apache.org/jira/browse/OPENJPA-24?page=comments#action_12436323 ] Michael Dick commented on OPENJPA-24: - Thanks Abe, I was able to load a custom EMF with your changes. I might have more questions when I get a chance to experiment a little more. Allow OpenJPA to be extensible -- Key: OPENJPA-24 URL: http://issues.apache.org/jira/browse/OPENJPA-24 Project: OpenJPA Issue Type: Bug Components: kernel Reporter: Kevin Sutter Assigned To: Kevin Sutter The current OpenJPA architecture is not extendable to other implementations. For example, if somebody wanted to provide their own PersistenceProvider implementation, simply extending the org.apache.openjpa.PersistenceProviderImpl would not suffice due to the dependencies in the ConfigurationProviderImpl. The discussion for this improvement was started on the dev mailing list. Once it was determined that there was more to this request than a simple conditional or two, we decided to open a JIRA report. The complete history of this request can be found in the OpenJPA dev mailing list. The first message was posted by me (Kevin Sutter) on August 14, titled Extending the OpenJPA Implementation. I will attempt to paraphrase the current state of the problem... We have three main players in this issue. The PersistenceProvider, the ConfigurationProvider, and the ProductDerivation (along with the various implementations of these interfaces). Currently, the ConfigurationProvider is in the lib and is unaware of any specific persistence requirements. The ProductDerivation is in the kernel and, unfortunately, is aware of persistence requirements, specifically the spec and store types. Abe's postings have indicated that we need to make these two interfaces more aware of each other and work with each other. We need to start with either making ConfigurationProvider more persistence-aware and move it into kernel, or make ProductDerivations less persistence-aware and move it into lib. The latter approach is preferred. After we get this re-organization of the base framework complete, we still have a couple of other issues ot resolve: * Still need the ability to extend EMF's through a ProductDerivation. This should be doable by adding a new PluginValue to indicate what class of EMF to load. * There is still a question as to whether we will need to provide a custom PersistenceProviderImpl and ConfigurationProviderImpl pair. I still think this will be necessary. And, one of Abe's posts indicated that this might help with class loading issues when multiple versions of OpenJPA-based implementations are available in the same system. I also posted these questions last Friday. (Abe has responded with some answers, but I wanted to get this JIRA report created before trying to paraphrase his answers.) * You mention in several places about separating away the notion of specs and stores. In a general sense, I understand what these are. But, can you elaborate on how these types are used in the ConfigurationProvider and ProductDerivation interfaces? * I've moved the ProductDerivation interface to the lib and added the load methods from the ConfigurationProvider (as described in your previous notes). And, I've started to clean up the implementations that depend on these interfaces. But, concerning the implementation of the load methods... Now that we need to return a ConfigurationProvider, would you expect that we just new up a ConfigurationProviderImpl and then just call across to the load methods on the implementation? Since we want to keep the ProductDerivations stateless, I'm not sure how else you were expecting to create a ConfigurationProvider to return on these load methods. * Now that ConfigurationProvider is bare, the ConfigurationTestConfigurationProvider doesn't have much function. I'll need to take a look to see if this is even required any longer. * Can you shed a bit more light on the Configurations class? It doesn't implement nor extend any interfaces or classes, but it seems to provide many of the same methods as ConfigurationProvider, but as statics. And, it's dependent on having a Provider. Can you explain the relationship of this class in the bigger picture and how you think it might be affected by thes changes? That's enough for the initial JIRA report. We will now track this problem here instead of the dev mailing list. Thanks. Kevin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (OPENJPA-65) Remove zip files from zip archive and remove -all from openjpa-all-${version}.jar
Remove zip files from zip archive and remove -all from
openjpa-all-${version}.jar
---
Key: OPENJPA-65
URL: http://issues.apache.org/jira/browse/OPENJPA-65
Project: OpenJPA
Issue Type: Task
Reporter: Michael Dick
Priority: Minor
The goal of this task is to change the packaging of the OpenJPA zip file so
that the individual modules (openjpa-lib, openjpa-kernel, etc) are not
included. The class files contained in the modules are already included in
openjpa-all-${version}.jar.
the task will also remove -all from openjpa-all-${version}.jar in order to
avoid confusion.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OPENJPA-65) Remove zip files from zip archive and remove -all from openjpa-all-${version}.jar
[ http://issues.apache.org/jira/browse/OPENJPA-65?page=all ]
Michael Dick updated OPENJPA-65:
Attachment: openjpa-65.patch.txt
Attaching patch file.
The patch removes the modules from openjpa.zip and renames the jar created in
openjpa-all.
Remove zip files from zip archive and remove -all from
openjpa-all-${version}.jar
---
Key: OPENJPA-65
URL: http://issues.apache.org/jira/browse/OPENJPA-65
Project: OpenJPA
Issue Type: Task
Reporter: Michael Dick
Priority: Minor
Attachments: openjpa-65.patch.txt
The goal of this task is to change the packaging of the OpenJPA zip file so
that the individual modules (openjpa-lib, openjpa-kernel, etc) are not
included. The class files contained in the modules are already included in
openjpa-all-${version}.jar.
the task will also remove -all from openjpa-all-${version}.jar in order to
avoid confusion.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (OPENJPA-76) add-was-interfaces ant task throws exception on a non-clean build.
add-was-interfaces ant task throws exception on a non-clean build.
-
Key: OPENJPA-76
URL: http://issues.apache.org/jira/browse/OPENJPA-76
Project: OpenJPA
Issue Type: Bug
Components: kernel
Reporter: Michael Dick
Patrick Linskey found the problem and posted to the dev mailing list. Here's
the original post :
Hi,
I get the following stack trace when running 'mvn package'. It looks
like I don't have some required IBM classes in my classpath.
Surprisingly, this exception does not cause the build to fail, but
presumably, the output bytes are not the same as if this had run
successfully.
Does anyone have any suggestions for either getting the classes into the
classpath or moving the exception to runtime, so that there aren't
build-time dependency issues resulting in different jars from the same
sources?
Thanks,
-Patrick
Partial stack trace:
[INFO] [antrun:run {execution: add-was-interfaces}]
[INFO] Executing tasks
[java] java.lang.IllegalArgumentException:
java.lang.NoClassDefFoundError:
com/ibm/websphere/jtaextensions/SynchronizationCallback
[java] at
org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:180)
[java] at org.apache.tools.ant.taskdefs.Java.run(Java.java:710)
[java] at
org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:178)
[java] at
org.apache.tools.ant.taskdefs.Java.execute(Java.java:84)
[java] at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
[java] at org.apache.tools.ant.Task.perform(Task.java:364)
[java] at org.apache.tools.ant.Target.execute(Target.java:341)
[java] at
org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntM
ojo.java:108)
[java] at
org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:83)
[java] at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginMa
nager.java:412)
[java] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Default
LifecycleExecutor.java:534)
.
[java] Caused by: java.lang.IllegalArgumentException:
java.lang.NoClassDefFoundError:
com/ibm/websphere/jtaextensions/SynchronizationCallback
[java] at serp.util.Strings.toClass(Strings.java:211)
[java] at serp.util.Strings.toClass(Strings.java:140)
[java] at serp.bytecode.BCClass.getType(BCClass.java:565)
[java] at serp.bytecode.BCClass.write(BCClass.java:202)
[java] at
org.apache.openjpa.ee.WASManagedRuntime.main(WASManagedRuntime.java:412)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
Upon further examination the problem occurs if the WASSynchronization class is
modified a second time (ie you don't run mvn clean before running mvn package).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (OPENJPA-65) Remove zip files from zip archive and remove -all from openjpa-all-${version}.jar
[ http://issues.apache.org/jira/browse/OPENJPA-65?page=all ]
Michael Dick resolved OPENJPA-65.
-
Resolution: Fixed
Forgot to close this earlier.
The individual models have been removed from the distribution zip files. The
-all suffix was also removed from the openjpa jar, but it has crept back in.
Since removing the modules was the main point of this report (IMHO) I'm marking
it as closed.
The -all suffix can be removed by using the outputFileNameMapping tag forthe
openjpa-all dependencySet in assembly.xml. Here's what the dependecy set might
look like :
dependencySet
outputDirectory//outputDirectory
unpackfalse/unpack
scoperuntime/scope
outputFileNameMappingopenjpa-${version}.${extension}/outputFileNameMapping
includes
includeorg.apache.openjpa:openjpa-all/include
/includes
/dependencySet
Remove zip files from zip archive and remove -all from
openjpa-all-${version}.jar
---
Key: OPENJPA-65
URL: http://issues.apache.org/jira/browse/OPENJPA-65
Project: OpenJPA
Issue Type: Task
Reporter: Michael Dick
Priority: Minor
The goal of this task is to change the packaging of the OpenJPA zip file so
that the individual modules (openjpa-lib, openjpa-kernel, etc) are not
included. The class files contained in the modules are already included in
openjpa-all-${version}.jar.
the task will also remove -all from openjpa-all-${version}.jar in order to
avoid confusion.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (OPENJPA-116) EntityManager.getDelegate should throw an IllegalStateException
EntityManager.getDelegate should throw an IllegalStateException
Key: OPENJPA-116
URL: https://issues.apache.org/jira/browse/OPENJPA-116
Project: OpenJPA
Issue Type: Bug
Reporter: Michael Dick
Priority: Minor
EntityManager.getDelegate() should throw an IllegalStateException if the
EntityManager has been closed.
I noticed then when debugging other problems. According to the javadoc
http://java.sun.com/javaee/5/docs/api/javax/persistence/EntityManager.html#getDelegate()
we need to throw an exception if the EM has been closed.
In case I missed anything here's what I did to reproduce the problem.
EntityManagerFactory _emf =
Persistence.createEntityManagerFactory(test);
EntityManager em = _emf.createEntityManager();
em.close();
try {
Object o = em.getDelegate();
fail();
}
catch(IllegalStateException ise) {
System.out.println(Caught expected exception);
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-116) EntityManager.getDelegate should throw an IllegalStateException
[
https://issues.apache.org/jira/browse/OPENJPA-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dick updated OPENJPA-116:
-
Attachment: openjpa-116-patch.txt
EntityManager.getDelegate should throw an IllegalStateException
Key: OPENJPA-116
URL: https://issues.apache.org/jira/browse/OPENJPA-116
Project: OpenJPA
Issue Type: Bug
Reporter: Michael Dick
Priority: Minor
Attachments: openjpa-116-patch.txt
EntityManager.getDelegate() should throw an IllegalStateException if the
EntityManager has been closed.
I noticed then when debugging other problems. According to the javadoc
http://java.sun.com/javaee/5/docs/api/javax/persistence/EntityManager.html#getDelegate()
we need to throw an exception if the EM has been closed.
In case I missed anything here's what I did to reproduce the problem.
EntityManagerFactory _emf =
Persistence.createEntityManagerFactory(test);
EntityManager em = _emf.createEntityManager();
em.close();
try {
Object o = em.getDelegate();
fail();
}
catch(IllegalStateException ise) {
System.out.println(Caught expected exception);
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-132) java.lang.NoSuchMethodError for entity with ID of type java.sql.Date
java.lang.NoSuchMethodError for entity with ID of type java.sql.Date
Key: OPENJPA-132
URL: https://issues.apache.org/jira/browse/OPENJPA-132
Project: OpenJPA
Issue Type: Bug
Components: kernel
Reporter: Michael Dick
Opening JIRA report to track the following problem (posted to development forum
http://www.nabble.com/Exception-when-using-java.sql.Date-as-an-id-tf3189597.html)
I'm getting the following exception when I try to fetch an entity with a
java.sql.Date as the id :
java.lang.NoSuchMethodError:
org.apache.openjpa.util.DateId.getId()Ljava/sql/Date;
at mikedd.entities.SqlDatePK.pcCopyKeyFieldsFromObjectId (SqlDatePK.java)
at mikedd.entities.SqlDatePK.pcNewInstance(SqlDatePK.java)
at org.apache.openjpa.enhance.PCRegistry.newInstance(PCRegistry.java:118)
at org.apache.openjpa.kernel.StateManagerImpl.initialize
(StateManagerImpl.java:247)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:327)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:252)
at
org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:108)
at
org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:54)
at org.apache.openjpa.kernel.BrokerImpl.initialize (BrokerImpl.java:868)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:826)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:743)
at org.apache.openjpa.kernel.DelegatingBroker.find
(DelegatingBroker.java:169)
at
org.apache.openjpa.persistence.EntityManagerImpl.find(EntityManagerImpl.java:346)
at mikedd.tests.TestSqlDateId.testFindAfterClear(TestSqlDateId.java:25)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke (Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
. . .
It's coming from the generated bytecode which expects there to be a getId
method that returns the same type of the Id, however java.sql.Date is using the
same ID class as java.util.Date. Do we need a separate class for java.sql.Date?
Responses from Patrick and Craig follow. The consensus so far is to provide ID
separate classes for java.sql.Date and java.util.Date.
It looks like we either need a separate type for java.sql.Date (and
presumably java.sql.Timestamp), or we need to change the logic to accept
a getId() method that returns a type that is assignable from the id
field's type.
-Patrick
It's probably cleaner if we have separate classes for the different
types. That is, have the getId method in the new
org.apache.openjpa.util.SQLDateId return the proper type
(java.sql.Date). After all, java.sql.{Date, Time, Timestamp} are not
really the same as java.util.Date.
-Craig
FTR, I think that I prefer separate classes as well; it's clearer, and
avoids any ambiguity with other subclasses in the future.
-Patrick
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-139) PersistenceException merging an entity with a Calendar field.
PersistenceException merging an entity with a Calendar field. -- Key: OPENJPA-139 URL: https://issues.apache.org/jira/browse/OPENJPA-139 Project: OpenJPA Issue Type: Bug Components: kernel Reporter: Michael Dick I get the following exception when I try to merge an entity which contains a java.util.Calendar field. 0|true|0.0.0 org.apache.openjpa.persistence.PersistenceException: mikedd.entities.CalendarEntity.cal at org.apache.openjpa.kernel.AttachStrategy.attachField(AttachStrategy.java:255) at org.apache.openjpa.kernel.VersionAttachStrategy.attach(VersionAttachStrategy.java:131) at org.apache.openjpa.kernel.AttachManager.attach(AttachManager.java:236) at org.apache.openjpa.kernel.AttachManager.attach(AttachManager.java:97) at org.apache.openjpa.kernel.BrokerImpl.attach(BrokerImpl.java:3141) at org.apache.openjpa.kernel.DelegatingBroker.attach(DelegatingBroker.java:1128) at org.apache.openjpa.persistence.EntityManagerImpl.merge(EntityManagerImpl.java:650) at mikedd.tests.TestCalendar.testMergeCalendar(TestCalendar.java:47) snip I'm running the test in eclipse and my classpath probably isn't set up to properly display the openjpa version, output from svnversion -c : 406193:505052M It looks like we're missing a case statement for JavaTypes.CALENDAR in org.apache.openjpa.kernelAttachStrategy.attachField. I added one under JavaTypes.DATE and that resolved the issue for me. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-140) Wrong package name in test classes
Wrong package name in test classes -- Key: OPENJPA-140 URL: https://issues.apache.org/jira/browse/OPENJPA-140 Project: OpenJPA Issue Type: Bug Reporter: Michael Dick It looks like the package for some of the new test classes is out of sync with where they are in the filesystem : Hi Mike, This is clearly wrong. Can you file a JIRA? Craig On Feb 9, 2007, at 8:17 AM, Michael Dick wrote: Hi Marc, The classes in incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/ apache/openjpa/persistence/models declare package org.apache.openjpa.persistence.models.company. This is causing a lot of errors in Eclipse, maven builds fine though. Is this intentional? Thanks, -Mike I'm not sure whether the java files should be moved or if the package declarations need to be changed though. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-156) Cache class object used to create plugin values
Cache class object used to create plugin values --- Key: OPENJPA-156 URL: https://issues.apache.org/jira/browse/OPENJPA-156 Project: OpenJPA Issue Type: Sub-task Reporter: Michael Dick -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-156) Cache class object used to create plugin values
[ https://issues.apache.org/jira/browse/OPENJPA-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dick updated OPENJPA-156: - Attachment: openjpa-156.patch.txt Another performance issue we've run into is the call to Strings.toClass(clsName, findDerivedLoader(conf, loader)) in Configurations.newInstance(). To work around the problem we tried caching the Class created for a given ClassLoader. It's a relatively simple cache, but it yielded noticeable performance improvements. The attached patch is relative to openjpa-lib, I can attach one that is relative to trunk if that will help. Cache class object used to create plugin values --- Key: OPENJPA-156 URL: https://issues.apache.org/jira/browse/OPENJPA-156 Project: OpenJPA Issue Type: Sub-task Reporter: Michael Dick Attachments: openjpa-156.patch.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-160) Reuse BrokerImpl objects
[ https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475102 ] Michael Dick commented on OPENJPA-160: -- Another performance issue we've run into is the overhead of creating a new BrokerImpl object when the application calls createEntityManager. The JPA spec clearly states that the provider needs to return a new EntityManager instance, and we're not trying to circumvent that requirement. However it seems plausible that we could reuse the underlying BrokerImpl object, once all the persistence data has been cleared (ie after BrokerImpl.free has been called). Implementing a fairly simple object reuse pool resulted in a significant performance improvement in our testing. I don't see this as being a violation of the intent of the spec, but I'd rather get a sense of consensus before I/we go any further. Questions : 1. Is there a reason why we can't reuse the BrokerImpl objects? 2. Assuming we can reuse the objects, where should we put the reuse pool? The original implementation created a static map in AbstractBrokerFactory. I'm not sure that's the best place for it though. BrokerImpl isn't a final class it's possible that different configurations could use different broker implementations (through the broker plugin). Maybe we need a new plugin which indicates that class to use as a Broker pool? 3. Should we pool the broker instances by default? I think we'll want this to be configurable, but I'm not sure it needs to be on by default. Justification : We've been running tests with the Sun Application Server and adding in a BrokerImpl reuse pool brings the performance on par with Hibernate. Reuse BrokerImpl objects Key: OPENJPA-160 URL: https://issues.apache.org/jira/browse/OPENJPA-160 Project: OpenJPA Issue Type: Sub-task Reporter: Michael Dick -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-160) Reuse BrokerImpl objects
[ https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475455 ] Michael Dick commented on OPENJPA-160: -- We ran some more performance tests with the latest OpenJPA code and the issue appears to be with creating an instance of the BrokerImpl (when Configurations calls Class.newInstance). I was surprised that creating a new instance turned out to take so much time and I don't know what we'd could (or would want to) tinker with to try to make it faster to create. I'm not thrilled about adding the complexity of a reuse pool so I'm open to suggestions. The pool that we used before was a two level pool thread.toString+user+pass - collection of brokers. Adding a non static field to AbstractBrokerFactory sounds feasible too (unless there's an alternative to pooling). Still looking into whether we need a key in BrokerImpl - I'll follow up on that as well. Reuse BrokerImpl objects Key: OPENJPA-160 URL: https://issues.apache.org/jira/browse/OPENJPA-160 Project: OpenJPA Issue Type: Sub-task Reporter: Michael Dick -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-160) Reuse BrokerImpl objects
[ https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dick updated OPENJPA-160: - Attachment: perf2.jpg I have a screenshot from the performance tool. I don't have access to the performance test environment right now but I'll see what else I can share on Monday. Reuse BrokerImpl objects Key: OPENJPA-160 URL: https://issues.apache.org/jira/browse/OPENJPA-160 Project: OpenJPA Issue Type: Sub-task Reporter: Michael Dick Attachments: perf2.jpg -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-160) Reuse BrokerImpl objects
[ https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dick updated OPENJPA-160: - Attachment: perf3.jpg Here's a jpg with the call to Class.newInstance() expanded. The data is from a different execution though so the numbers are a little different but they show the same problem. It looks like the time is spent in reflection accessing the constructor. I don't know what data to gather next though. Reuse BrokerImpl objects Key: OPENJPA-160 URL: https://issues.apache.org/jira/browse/OPENJPA-160 Project: OpenJPA Issue Type: Sub-task Reporter: Michael Dick Attachments: perf2.jpg, perf3.jpg -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-132) java.lang.NoSuchMethodError for entity with ID of type java.sql.Date
[
https://issues.apache.org/jira/browse/OPENJPA-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482448
]
Michael Dick commented on OPENJPA-132:
--
I'm fine using Abe's patch. The patch I submitted was just focussed on
java.sql.Date, not the other java.sql classes. A simpler fix which adds more
function is usually a good thing.
java.lang.NoSuchMethodError for entity with ID of type java.sql.Date
Key: OPENJPA-132
URL: https://issues.apache.org/jira/browse/OPENJPA-132
Project: OpenJPA
Issue Type: Bug
Components: kernel
Reporter: Michael Dick
Priority: Minor
Fix For: 0.9.7
Attachments: OpenJPA-132.patch.txt
Opening JIRA report to track the following problem (posted to development
forum
http://www.nabble.com/Exception-when-using-java.sql.Date-as-an-id-tf3189597.html)
I'm getting the following exception when I try to fetch an entity with a
java.sql.Date as the id :
java.lang.NoSuchMethodError:
org.apache.openjpa.util.DateId.getId()Ljava/sql/Date;
at mikedd.entities.SqlDatePK.pcCopyKeyFieldsFromObjectId (SqlDatePK.java)
at mikedd.entities.SqlDatePK.pcNewInstance(SqlDatePK.java)
at org.apache.openjpa.enhance.PCRegistry.newInstance(PCRegistry.java:118)
at org.apache.openjpa.kernel.StateManagerImpl.initialize
(StateManagerImpl.java:247)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:327)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:252)
at
org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:108)
at
org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:54)
at org.apache.openjpa.kernel.BrokerImpl.initialize (BrokerImpl.java:868)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:826)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:743)
at org.apache.openjpa.kernel.DelegatingBroker.find
(DelegatingBroker.java:169)
at
org.apache.openjpa.persistence.EntityManagerImpl.find(EntityManagerImpl.java:346)
at mikedd.tests.TestSqlDateId.testFindAfterClear(TestSqlDateId.java:25)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke (Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
. . .
It's coming from the generated bytecode which expects there to be a getId
method that returns the same type of the Id, however java.sql.Date is using
the same ID class as java.util.Date. Do we need a separate class for
java.sql.Date?
Responses from Patrick and Craig follow. The consensus so far is to provide
ID separate classes for java.sql.Date and java.util.Date.
It looks like we either need a separate type for java.sql.Date (and
presumably java.sql.Timestamp), or we need to change the logic to accept
a getId() method that returns a type that is assignable from the id
field's type.
-Patrick
It's probably cleaner if we have separate classes for the different
types. That is, have the getId method in the new
org.apache.openjpa.util.SQLDateId return the proper type
(java.sql.Date). After all, java.sql.{Date, Time, Timestamp} are not
really the same as java.util.Date.
-Craig
FTR, I think that I prefer separate classes as well; it's clearer, and
avoids any ambiguity with other subclasses in the future.
-Patrick
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-179) Schemas defined in orm.xml are only applied when a name is also specified.
Schemas defined in orm.xml are only applied when a name is also specified. --- Key: OPENJPA-179 URL: https://issues.apache.org/jira/browse/OPENJPA-179 Project: OpenJPA Issue Type: Bug Components: jpa Affects Versions: 0.9.6, 0.9.7 Reporter: Michael Dick Fix For: 0.9.7 If a default schema name is specified (either as a mapping file default or a persistence unit default) it will only be applied if a table name is also included in the same xml descriptor. For example if the xml file looks like this ?xml version=1.0 encoding=UTF-8? entity-mappings xmlns=http://java.sun.com/xml/ns/persistence/orm; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/persistence/orm http://java.sun.com/xml/ns/persistence/orm_1_0.xsd; version=1.0 persistence-unit-metadata persistence-unit-defaults schemaDefSchema/schema /persistence-unit-defaults /persistence-unit-metadata entity class=mdd.MyEntity attributes id name=id/id basic name=name/basic /attributes /entity entity class=mdd.MyEntityWithTable table name=MyEntityWithTable/ attributes id name=id/id basic name=name/basic /attributes /entity /entity-mappings The default schema will be applied to MyEntityWithTable, but will not be applied to MyEntity. The same applies if the xml looks like this : ?xml version=1.0 encoding=UTF-8? entity-mappings xmlns=http://java.sun.com/xml/ns/persistence/orm; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/persistence/orm http://java.sun.com/xml/ns/persistence/orm_1_0.xsd; version=1.0 schemaDefSchema/schema . . . /entity-mappings I think there are two problems here : 1. The mapping file default schema (example 2) should apply to every entity in the xml mapping file (except where it's overridden by another entry or an annotation). 2. A schema defined in the persistence-unit-defaults tag should apply to all entities in the persistence unit, not just the ones defined or overridden in the xml file. This default is overridden my the mapping file default schema, other xml schema entries and annotations. I'll attach a simple sample of the problem, in case I'm missing something. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-176) Exception prefixes should be human-readable
[ https://issues.apache.org/jira/browse/OPENJPA-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483852 ] Michael Dick commented on OPENJPA-176: -- It looks like we just use type + error if the type isn't recognized. +1 as it is, but I'm not opposed to changing type + error to unexpected error or something similar. Exception prefixes should be human-readable --- Key: OPENJPA-176 URL: https://issues.apache.org/jira/browse/OPENJPA-176 Project: OpenJPA Issue Type: Improvement Components: diagnostics Affects Versions: 0.9.0, 0.9.6 Reporter: Marc Prud'hommeaux Assigned To: Marc Prud'hommeaux Priority: Trivial Attachments: OPENJPA-176.patch OpenJPA prefixes all exception messages with a string of the form exception type|is fatal|version, restulting in strings like 4|false|0.9.6-incubating org.apache.openjpa.persistence.PersistenceException. This isn't very useful to the casual observer, since no translation of the meaning of the fields is done. it would be nice if we translated the fatal and type parameters, so that the string looked like user-error|recoverable|0.9.6-incubating. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-185) optional attribute is not overriden by xml descriptor
optional attribute is not overriden by xml descriptor - Key: OPENJPA-185 URL: https://issues.apache.org/jira/browse/OPENJPA-185 Project: OpenJPA Issue Type: Bug Affects Versions: 0.9.6, 0.9.0 Reporter: Michael Dick Fix For: 0.9.7 The optional attribute of the @Basic annotation is not being overriden if it's defined in orm.xml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-185) optional attribute is not overriden by xml descriptor
[ https://issues.apache.org/jira/browse/OPENJPA-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dick updated OPENJPA-185: - Attachment: OpenJPA-185.patch.txt optional attribute is not overriden by xml descriptor - Key: OPENJPA-185 URL: https://issues.apache.org/jira/browse/OPENJPA-185 Project: OpenJPA Issue Type: Bug Affects Versions: 0.9.0, 0.9.6 Reporter: Michael Dick Fix For: 0.9.7 Attachments: OpenJPA-185.patch.txt The optional attribute of the @Basic annotation is not being overriden if it's defined in orm.xml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-192) WASManagedRuntime's tm is used despite exception initializing WASManagedRuntime.
WASManagedRuntime's tm is used despite exception initializing WASManagedRuntime. - Key: OPENJPA-192 URL: https://issues.apache.org/jira/browse/OPENJPA-192 Project: OpenJPA Issue Type: Bug Reporter: Michael Dick Phill Moran reported a problem with WASManagedRuntime and Spring. Attached is the relevant portion of the stack trace : org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.jav a:196) Caused by: 4|true|0.0.0 org.apache.openjpa.persistence.InvalidStateException: An error occured reflecting WebSphere proprietary interfaces. Please ensure that you are running the application from within WebSphere Application Server (version 5.0.2 or newer). FailedObject: javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial at org.apache.openjpa.ee.WASManagedRuntime.endConfiguration(WASManagedRuntime.java: 344) at org.apache.openjpa.ee.AutomaticManagedRuntime.getTransactionManager(AutomaticMan agedRuntime.java:124) ... 39 more NestedThrowables: javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:645) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288) at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:325) at javax.naming.InitialContext.lookup(InitialContext.java:392) at org.apache.openjpa.ee.JNDIManagedRuntime.getTransactionManager(JNDIManagedRuntim e.java:51) at org.apache.openjpa.ee.AutomaticManagedRuntime.getTransactionManager(AutomaticMan agedRuntime.java:140) I don't believe this is the root of the problem that he's running into, but it needs to be cleaned up before we go further. The error occurs when we configure the WASManagedRuntime and one approach is to swallow the exception at that time and proceed. A better approach is to look for a WebSphere signiture in the constructor to WASManagedRuntime, if it's not found throw an exception. The exception is handled by AutomaticRuntime and prevents WASManagedRuntime from being used again (this is similar to what WLSManagedRuntime does). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-192) WASManagedRuntime's tm is used despite exception initializing WASManagedRuntime.
[ https://issues.apache.org/jira/browse/OPENJPA-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dick updated OPENJPA-192: - Attachment: OpenJPA-192.patch.txt Attaching a rudimentary patch. The patch tries to find an instance of the WebSphere jtaextensions class whenever we create a new WASManagedRuntime instance. If the class isn't found a ClassNotFoundException will be thrown and the WASManagedRuntime instance won't be created. Basically it prevents an extraneous error from being logged when WebSphere isn't being used. WASManagedRuntime's tm is used despite exception initializing WASManagedRuntime. - Key: OPENJPA-192 URL: https://issues.apache.org/jira/browse/OPENJPA-192 Project: OpenJPA Issue Type: Bug Reporter: Michael Dick Attachments: OpenJPA-192.patch.txt Phill Moran reported a problem with WASManagedRuntime and Spring. Attached is the relevant portion of the stack trace : org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.jav a:196) Caused by: 4|true|0.0.0 org.apache.openjpa.persistence.InvalidStateException: An error occured reflecting WebSphere proprietary interfaces. Please ensure that you are running the application from within WebSphere Application Server (version 5.0.2 or newer). FailedObject: javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial at org.apache.openjpa.ee.WASManagedRuntime.endConfiguration(WASManagedRuntime.java: 344) at org.apache.openjpa.ee.AutomaticManagedRuntime.getTransactionManager(AutomaticMan agedRuntime.java:124) ... 39 more NestedThrowables: javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:645) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288) at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:325) at javax.naming.InitialContext.lookup(InitialContext.java:392) at org.apache.openjpa.ee.JNDIManagedRuntime.getTransactionManager(JNDIManagedRuntim e.java:51) at org.apache.openjpa.ee.AutomaticManagedRuntime.getTransactionManager(AutomaticMan agedRuntime.java:140) I don't believe this is the root of the problem that he's running into, but it needs to be cleaned up before we go further. The error occurs when we configure the WASManagedRuntime and one approach is to swallow the exception at that time and proceed. A better approach is to look for a WebSphere signiture in the constructor to WASManagedRuntime, if it's not found throw an exception. The exception is handled by AutomaticRuntime and prevents WASManagedRuntime from being used again (this is similar to what WLSManagedRuntime does). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OPENJPA-185) optional attribute is not overriden by xml descriptor
[ https://issues.apache.org/jira/browse/OPENJPA-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dick reassigned OPENJPA-185: Assignee: Michael Dick optional attribute is not overriden by xml descriptor - Key: OPENJPA-185 URL: https://issues.apache.org/jira/browse/OPENJPA-185 Project: OpenJPA Issue Type: Bug Affects Versions: 0.9.0, 0.9.6 Reporter: Michael Dick Assigned To: Michael Dick Fix For: 0.9.7 Attachments: OpenJPA-185.patch.txt The optional attribute of the @Basic annotation is not being overriden if it's defined in orm.xml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-185) optional attribute is not overriden by xml descriptor
[ https://issues.apache.org/jira/browse/OPENJPA-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dick resolved OPENJPA-185. -- Resolution: Fixed optional attribute is not overriden by xml descriptor - Key: OPENJPA-185 URL: https://issues.apache.org/jira/browse/OPENJPA-185 Project: OpenJPA Issue Type: Bug Affects Versions: 0.9.0, 0.9.6 Reporter: Michael Dick Assigned To: Michael Dick Fix For: 0.9.7 Attachments: OpenJPA-185.patch.txt The optional attribute of the @Basic annotation is not being overriden if it's defined in orm.xml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-198) Finish fix for persistence-unit-defaults
Finish fix for persistence-unit-defaults Key: OPENJPA-198 URL: https://issues.apache.org/jira/browse/OPENJPA-198 Project: OpenJPA Issue Type: Sub-task Affects Versions: 0.9.8 Reporter: Michael Dick Assigned To: Michael Dick The changes for OpenJPA-179 (revision 525006) fix the problem where default schemas are not processed at all, however there are still some issues. 1. The persistence-unit-defaults only apply to entities within the xml descriptor, they will not apply to annotated entities which are in the same persistence unit. 2. In order to override the default schema the table name must be specified. These issues still need to be addressed, but can wait until after version 0.9.7 to be resolved. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-179) Schemas defined in orm.xml are only applied when a name is also specified.
[ https://issues.apache.org/jira/browse/OPENJPA-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dick resolved OPENJPA-179. -- Resolution: Fixed Fixed with revision 525006. Schemas defined in orm.xml are only applied when a name is also specified. --- Key: OPENJPA-179 URL: https://issues.apache.org/jira/browse/OPENJPA-179 Project: OpenJPA Issue Type: Bug Components: jpa Affects Versions: 0.9.6, 0.9.7 Reporter: Michael Dick Assigned To: Michael Dick Fix For: 0.9.7 Attachments: OpenJPA-179-example.zip If a default schema name is specified (either as a mapping file default or a persistence unit default) it will only be applied if a table name is also included in the same xml descriptor. For example if the xml file looks like this ?xml version=1.0 encoding=UTF-8? entity-mappings xmlns=http://java.sun.com/xml/ns/persistence/orm; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/persistence/orm http://java.sun.com/xml/ns/persistence/orm_1_0.xsd; version=1.0 persistence-unit-metadata persistence-unit-defaults schemaDefSchema/schema /persistence-unit-defaults /persistence-unit-metadata entity class=mdd.MyEntity attributes id name=id/id basic name=name/basic /attributes /entity entity class=mdd.MyEntityWithTable table name=MyEntityWithTable/ attributes id name=id/id basic name=name/basic /attributes /entity /entity-mappings The default schema will be applied to MyEntityWithTable, but will not be applied to MyEntity. The same applies if the xml looks like this : ?xml version=1.0 encoding=UTF-8? entity-mappings xmlns=http://java.sun.com/xml/ns/persistence/orm; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/persistence/orm http://java.sun.com/xml/ns/persistence/orm_1_0.xsd; version=1.0 schemaDefSchema/schema . . . /entity-mappings I think there are two problems here : 1. The mapping file default schema (example 2) should apply to every entity in the xml mapping file (except where it's overridden by another entry or an annotation). 2. A schema defined in the persistence-unit-defaults tag should apply to all entities in the persistence unit, not just the ones defined or overridden in the xml file. This default is overridden my the mapping file default schema, other xml schema entries and annotations. I'll attach a simple sample of the problem, in case I'm missing something. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS
[ https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487098 ] Michael Dick commented on OPENJPA-182: -- I have no practical experience with Sybase, but I did find this in their TransactSQL user's guide : Changing the isolation level for a query You can change the isolation level for a query by using the at isolation clause with the select or readtext statements. The at isolation clause supports isolation levels 0, 1, and 3. It does not support isolation level 2. The read uncommitted, read committed, and serializable options of at isolation represent isolation levels as listed below: at isolation option Isolation level read uncommited 0 read committed 1 serializable3 For example, the following two statements query the same table at isolation levels 0 and 3, respectively: select * from titles at isolation read uncommitted select * from titles at isolation serializable There's more information online here: http://manuals.sybase.com/onlinebooks/group-as/asg1250e/sqlug/@Generic__BookTextView/53911;hf=0 db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS -- Key: OPENJPA-182 URL: https://issues.apache.org/jira/browse/OPENJPA-182 Project: OpenJPA Issue Type: New Feature Components: jdbc Environment: db2 database driver for zOS, AS400, Unix, Windows, Linux Reporter: David Wisneski Assigned To: David Wisneski Attachments: OPENJPA-182.patch, openJPA182.patch A while back we changed the syntax of update locking from FOR UPDATE OF to WITH RS USE AND KEEP UPDATE LOCKS. Additional changes are required because 1. if isolation=serializable is configured, then the syntax should be WITH RR USE AND KEEP UDPATE LOCKS 2. when using DB2/400 on iSeries machines, the syntax is WITH RS USE AND KEEP EXCLUSIVE LOCKS or WITH RR USE AND KEEP EXCLUSIVE LOCKS because DB2/400 only supports read or exclusive locks. 3. DB2 supports both a FETCH FIRST ROWS and update LOCKS clauses. So we change supportsLockingWithSelectRange = true in the AbstractDB2Dictionary class and change the DB2Dictionary to append the correct LOCKS syntax depending on vendor, release and isolation level. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-211) CLONE -java.lang.VerifyError on websphere 6.1 with Spring 2.0.3 and OpenJpa 0.96/0.97
[ https://issues.apache.org/jira/browse/OPENJPA-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488108 ] Michael Dick commented on OPENJPA-211: -- It looks like WASManagedRuntime is having trouble finding the WebSphere specific transaction classes. Are you still running in the embedded test environment in RAD or does the problem occur on a standalone WebSphere server? RAD handles the classpath a little differently (or at least it used to back in version 5) and that might contribute to the problem. Have you changed any of the classloader settings (ie PARENT_LAST)? CLONE -java.lang.VerifyError on websphere 6.1 with Spring 2.0.3 and OpenJpa 0.96/0.97 - Key: OPENJPA-211 URL: https://issues.apache.org/jira/browse/OPENJPA-211 Project: OpenJPA Issue Type: Bug Components: kernel Affects Versions: 0.9.6 Environment: Using OpenJPA (openjpa-all-0.9.6-incubating.jar) in Rational Developer 7 ( Websphere 6.1 test environment ) connected to DB2 V9.1. OS: WinXP SP2 Reporter: david zhang Priority: Blocker Fix For: 0.9.8 Attachments: applicationContext.xml, mytestdata.jar, persistence.xml Hi, if I use the OpenJPA shipped with Spring 2.0.3, I got the following error when start application: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'entityManagerFactory' defined in ServletContext resource [/WEB-INF/applicationContext.xml]: Invocation of init method failed; nested exception is java.lang.VerifyError: class loading constraint violated (class: org/apache/openjpa/kernel/BrokerImpl method: newQueryImpl(Ljava/lang/String;Lorg/apache/openjpa/kernel/StoreQuery;)Lorg/apache/openjpa/kernel/QueryImpl;) at pc: 0 Caused by: java.lang.VerifyError: class loading constraint violated (class: org/apache/openjpa/kernel/BrokerImpl method: newQueryImpl(Ljava/lang/String;Lorg/apache/openjpa/kernel/StoreQuery;)Lorg/apache/openjpa/kernel/QueryImpl;) at pc: 0 at java.lang.J9VMInternals.verifyImpl(Native Method) at java.lang.J9VMInternals.verify(J9VMInternals.java:59) at java.lang.J9VMInternals.initialize(J9VMInternals.java:120) at java.lang.Class.forNameImpl(Native Method) at java.lang.Class.forName(Class.java:131) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.class$(OpenJPAConfigurationImpl.java:65) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:182) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:154) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:145) at org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerImpl.init(PersistenceProviderImpl.java:114) at org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerImpl.init(PersistenceProviderImpl.java:106) at org.apache.openjpa.persistence.PersistenceProviderImpl.createContainerEntityManagerFactory(PersistenceProviderImpl.java:92) at org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:214) at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:251) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1143) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1110) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:431) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:254) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:144) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:251) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:163) at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeansOfType(DefaultListableBeanFactory.java:244) at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeansOfType(DefaultListableBeanFactory.java:233) at org.springframework.beans.factory.BeanFactoryUtils.beansOfTypeIncludingAncestors(BeanFactoryUtils.java:205
[jira] Commented: (OPENJPA-211) CLONE -java.lang.VerifyError on websphere 6.1 with Spring 2.0.3 and OpenJpa 0.96/0.97
[ https://issues.apache.org/jira/browse/OPENJPA-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488379 ] Michael Dick commented on OPENJPA-211: -- Have you started a UserTransaction? That's the only other thing that I can think of that would cause the problem. We're using a WebSphere proprietary API to register for synchronization with the transaction service. The WebSphere API doesn't allow OpenJPA to start a new transaction automatically. I believe Hibernate uses the same API though and suffers the same restrictions. I'm sorry to say I have no experience with Spring. I'll try to reproduce the problem without Spring and see if that sheds any light. Sorry I can't give you a more definite answer right now. CLONE -java.lang.VerifyError on websphere 6.1 with Spring 2.0.3 and OpenJpa 0.96/0.97 - Key: OPENJPA-211 URL: https://issues.apache.org/jira/browse/OPENJPA-211 Project: OpenJPA Issue Type: Bug Components: kernel Affects Versions: 0.9.6 Environment: Using OpenJPA (openjpa-all-0.9.6-incubating.jar) in Rational Developer 7 ( Websphere 6.1 test environment ) connected to DB2 V9.1. OS: WinXP SP2 Reporter: david zhang Priority: Blocker Fix For: 0.9.8 Attachments: applicationContext.xml, applicationContext.xml, mytestdata.jar, persistence.xml, persistence.xml Hi, if I use the OpenJPA shipped with Spring 2.0.3, I got the following error when start application: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'entityManagerFactory' defined in ServletContext resource [/WEB-INF/applicationContext.xml]: Invocation of init method failed; nested exception is java.lang.VerifyError: class loading constraint violated (class: org/apache/openjpa/kernel/BrokerImpl method: newQueryImpl(Ljava/lang/String;Lorg/apache/openjpa/kernel/StoreQuery;)Lorg/apache/openjpa/kernel/QueryImpl;) at pc: 0 Caused by: java.lang.VerifyError: class loading constraint violated (class: org/apache/openjpa/kernel/BrokerImpl method: newQueryImpl(Ljava/lang/String;Lorg/apache/openjpa/kernel/StoreQuery;)Lorg/apache/openjpa/kernel/QueryImpl;) at pc: 0 at java.lang.J9VMInternals.verifyImpl(Native Method) at java.lang.J9VMInternals.verify(J9VMInternals.java:59) at java.lang.J9VMInternals.initialize(J9VMInternals.java:120) at java.lang.Class.forNameImpl(Native Method) at java.lang.Class.forName(Class.java:131) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.class$(OpenJPAConfigurationImpl.java:65) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:182) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:154) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:145) at org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerImpl.init(PersistenceProviderImpl.java:114) at org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerImpl.init(PersistenceProviderImpl.java:106) at org.apache.openjpa.persistence.PersistenceProviderImpl.createContainerEntityManagerFactory(PersistenceProviderImpl.java:92) at org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:214) at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:251) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1143) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1110) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:431) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:254) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:144) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:251) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:163) at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeansOfType(DefaultListableBeanFactory.java:244) at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeansOfType(DefaultListableBeanFactory.java:233
[jira] Commented: (OPENJPA-153) WebSphere and non-jta-data-source and default ManagedRuntime
[ https://issues.apache.org/jira/browse/OPENJPA-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489156 ] Michael Dick commented on OPENJPA-153: -- Confirming Kevin's comments above, support for non-jta-datasources is working and will be included in the next release of the WebSphere EJB3 feature pack. WebSphere and non-jta-data-source and default ManagedRuntime Key: OPENJPA-153 URL: https://issues.apache.org/jira/browse/OPENJPA-153 Project: OpenJPA Issue Type: Improvement Components: jdbc Environment: WebSphere 6.1 Reporter: Patrick Linskey Fix For: 0.9.7 See OPENJPA-144. It would seem that in a WebSphere environment, when specifying a non-jta-data-source, the JDBC connection that OpenJPA looks up does not permit calls to Connection.commit(). This, in conjunction with OPENJPA-149, means that in a default configuration, OpenJPA cannot use non-JTA data sources in a WebSphere environment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-184) use DB2 Diagnostic interface to report extended error diagnostics on SQL Exception
[ https://issues.apache.org/jira/browse/OPENJPA-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dick resolved OPENJPA-184. -- Resolution: Fixed Resolving issue per Ritika's comments on the dev mailing list. use DB2 Diagnostic interface to report extended error diagnostics on SQL Exception -- Key: OPENJPA-184 URL: https://issues.apache.org/jira/browse/OPENJPA-184 Project: OpenJPA Issue Type: New Feature Environment: DB2 database Reporter: David Wisneski When using DB2 database and the SQLException occurs if the SQLException instance supports the DB2Diagnosable interface, extended error information from the SQLCA will be written to the SQL channel. The message format produced by DB2Diagnosable writer is SQLCA OUTPUT[Errp=SQLDMISR, Errd=[-2146893819, 5, 0, 0, -957, 0]] Errp is the name of the DB2 module that detected the error and Errd are 6 integers of diagnostic information, SQLWARN are 6 characters of warning flags.. Often this additional information can be used by an administrator in doing problem determination. This message will be appended to the persistence exception error message already created by OpenJPA and it will be written to SQL logging channel (if active). DB2Dictionary class is modified to use java reflection on the SQLException instance to determine if it supports DB2Diagnosble methods getErrp and if so it invokes the methods to retrieve Errp and Errd fields, formats and logs the error message. Reflection is used so that the DB2Dictionary does not contain any compile time or runtime dependency on the DB2 jdbc driver. If the DB2Diagnosable methods do not exist on the SQLException instance, no extended error information is logged. org.apache.openjpa.jdbc.sql.SQLException class is modified so in the event of an exception if the Dictionary is DB2, to call the Dictionary routines above. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OPENJPA-222) FOR READ ONLY clause getting generated for subselects
[ https://issues.apache.org/jira/browse/OPENJPA-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dick reassigned OPENJPA-222: Assignee: David Wisneski FOR READ ONLY clause getting generated for subselects - Key: OPENJPA-222 URL: https://issues.apache.org/jira/browse/OPENJPA-222 Project: OpenJPA Issue Type: Bug Components: jpa Affects Versions: 0.9.7 Reporter: Ritika Maheshwari Assigned To: David Wisneski Attachments: JIRA182-subselect.patch FOR READ ONLY clause is generated for subselects in DB2. which throws a DB2 Exception -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-213) @Column with precision and scale should result in NUMERIC(precision, scale)
[ https://issues.apache.org/jira/browse/OPENJPA-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494291 ] Michael Dick commented on OPENJPA-213: -- I'm not sure I agree with the description of the problem. I've been basing my assumptions on the conversions tables found at http://java.sun.com/j2se/1.5.0/docs/guide/jdbc/getstart/mapping.html#1004791 The tables there indicate that a java.lang.Double should be mapped to DOUBLE, not NUMERIC or DECIMAL. If NUMERIC or DECIMAL is desired then the entity should use a variable of type java.math.BigDecimal. The way the problem description is worded we'd be changing the rules if precision and scale were specified in an annotation. It becomes a question of which is more important, the type of the variable or the annotations around it. An argument can be made for either side, but I'm inclined to side with the type of the variable trumping the annotations. I believe the language in the spec supports this interpretation too : From section 9.1.5 int precision (Optional) The precision for a decimal (exact0 (Value must be set by numeric) column. (Applies only if a decimal col- developer.) umn is used.) int scale (Optional) The scale for a decimal (exact0 numeric) column. (Applies only if a decimal col- umn is used.) Assuming that is the correct approach, there is still a problem with DB2 and Derby where the mapping tool creates a DOUBLE column for BigDecimals instead of a NUMERIC column. I'll use this JIRA to fix the problem with DB2 and Derby. @Column with precision and scale should result in NUMERIC(precision, scale) --- Key: OPENJPA-213 URL: https://issues.apache.org/jira/browse/OPENJPA-213 Project: OpenJPA Issue Type: Improvement Components: jpa Affects Versions: 0.9.7 Reporter: Jacek Laskowski Assigned To: Michael Dick @Column provides the precision and scale attributes, but there's no (easy) way to figure out how it affects the way OpenJPA works if any. It looks like OpenJPA reads the type of a persistent field and when it's double it maps it to DOUBLE in Derby regardless of the other attributes. When precision and scale are specified, a DDL should use NUMERIC(precision, scale) or its synonim - DECIMAL(precision, scale). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-206) Key column does not cascade multiple joins.
[
https://issues.apache.org/jira/browse/OPENJPA-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12495089
]
Michael Dick commented on OPENJPA-206:
--
For what it's worth I've been able to reproduce the issue with a vanilla
junit test case using the entities provided.
i haven't been able to determine why Department is able to pick up the ID from
Company, but Employee can't pick up the IDs from Department.
I've been able to get it working by persisting Department Company objects
in one transaction, then adding the Employees in later. Is that an acceptable
workaround for what you're trying to do?
Key column does not cascade multiple joins.
---
Key: OPENJPA-206
URL: https://issues.apache.org/jira/browse/OPENJPA-206
Project: OpenJPA
Issue Type: Bug
Affects Versions: 0.9.7
Environment: WebSphere 6.1, DB2 v8.1
Reporter: Matt Anderson
Attachments: FunInheritanceJavaPI.zip
Problem: Parent keys will not cascade beyond one generation. Example:
Company -- Department -- Employee: Company key will not cascade to
Employee.
The following example further describes this issue.
A COMPANY table contains two columns, COMP_ID and NAME. The COMP_ID column
is the primary key.
A DEPARTMENT table contains three columns, COMP_ID, DEPT_ID, and NAME. The
COMP_ID and DEPT_ID columns are the primary key columns. The COMP_ID column
is a foreign key column which references the COMP_ID column in the COMPANY
table.
An EMPLOYEE table contains four columns, COMP_ID, DEPT_ID, EMP_ID, and NAME.
The COMP_ID, DEPT_ID, and EMP_ID columns are the primary key columns. The
COMP_ID and DEPT_ID columns are foreign key columns which reference the
COMP_ID and DEPT_ID columns respectively in the DEPARTMENT table.
An entity exists for each table, Company, Department, and Employee. The
Company entity has three attributes, compId, name, and departments. The
compId attribute maps to the COMP_ID column. The name attribute maps to the
NAME column. The departments attribute maps a one-to-many relationship to
the Department entity.
The Department entity has five attributes, compId, deptId, name, employees,
and company. The compId attribute maps to the COMP_ID column. The deptId
attribute maps to the DEPT_ID column. The name attribute maps to the NAME
column. The employees attribute maps a one-to-many relationship to the
Employee entity. The company attribute maps a many-to-one relationship to
the Company entity, joined by the COMP_ID column.
The Employee entity has five attributes, compId, deptId, empId, name, and
department. The compId attribute maps to the COMP_ID column. The deptId
attribute maps to the DEPT_ID column. The empId attribute maps to the EMP_ID
column. The name attribute maps to the NAME column. The department
attribute maps a many-to-one relationship to the Department entity, joined by
the COMP_ID and DEPT_ID columns.
Below are the eleven steps to re-create this problem.
1. A new Company entity is instantiated.
2. The name attribute on the Company instance is set to company.
3. A new Department entity is instantiated.
4. The name attribute on the Department instance is set to department.
5. The department attribute on the Company instance is set to the Department
instance.
6. A new Employee entity is instantiated.
7. The name attribute on the Employee instance is set to Frank.
8. The employee attribute on the Department instance is set to the Employee
instance.
9. The Employee instance is added to the employees attribute on the
Department instance.
10. The Department instance is added to the departments attribute on the
Company instance.
11. The Company instance is persisted.
The following SQL statements are executed.
INSERT INTO COMPANY (COMP_ID, NAME)
VALUES (?, ?)
[params=(long) 1, (String) company]
INSERT INTO DEPARTMENT (COMP_ID, DEPT_ID, NAME)
VALUES (?, ?, ?)
[params=(long) 1, (long) 1, (String) department]
INSERT INTO EMPLOYEE (DEPT_ID, EMP_ID, NAME)
VALUES (?, ?, ?)
[params=(long) 1, (long) 1, (String) Frank]
A PersistenceException is thrown because of the DB2 error noted below. The
COMP_ID column cascades to the DEPARTMENT table, but does not cascade to the
EMPLOYEE table.
DB2 SQL error: SQLCODE: -407, SQLSTATE: 23502, SQLERRMC: TBSPACEID=2,
TABLEID=4, COLNO=0 {prepstmnt 1256737512
INSERT INTO EMPLOYEE (DEPT_ID, EMP_ID, NAME)
VALUES (?, ?, ?)
[params=(long) 1, (long) 1, (String) Frank]} [code=-407, state=23502]SQLCA
OUTPUT[Errp=SQLDFMT1, Errd=[-2146041828, 28, 0, 0, 0, 0]]
An application is provided to demonstrate the issue. To setup and
unsuccessfully run demonstration with OpenJPA:
1. Add DB provider JAR(s) to the FunInheritanceJava project's build path.
2
