OpenJPA Folk-
I've added a new "openjpa-examples" top-level module which currently
contains a very simple "hellojpa" application that can be run from
the OpenJPA distribution zip with zero-configuration (well, provided
you have ant installed).
I hope this is the first of a wide variety of
IIRC, the Geronimo jars are compiled with a later version of the JDK.
That does appears to be correct:
[20:44 chance mprudhom]$ java -cp ~/.m2/repository/org/apache/
geronimo/specs/geronimo-jta_1.0.1B_spec/1.0.1/geronimo-
jta_1.0.1B_spec-1.0.1.jar javax.transaction.SystemException
Exception
When can Geronimo ship an upgrade to JTA 1.1 that we can use and
compile with 1.3?
These are "goodness" that I think OpenJPA can use.
Craig
On Oct 27, 2006, at 8:24 PM, David Blevins wrote:
On Oct 27, 2006, at 6:50 PM, Marc Prud'hommeaux wrote:
Anyway, I'm not married to the idea of using
Does anyone have any comments on this point?
The library was compiled with JDK 1.3 so it can be used with any
of the openjpa libraries.
IIRC, the Geronimo jars are compiled with a later version of the JDK.
Craig
Craig Russell
[EMAIL PROTECTED] http://db.apache.org/jdo
smime.p7s
Descrip
On Oct 27, 2006, at 6:50 PM, Marc Prud'hommeaux wrote:
Anyway, I'm not married to the idea of using the, shall we say,
"sanctioned" jars. Your concerns, coupled with David's mention that
Geronimo isn't going to change their dependencies, are sufficient
for me to drop the issue.
Just so y
On Oct 27, 2006, at 6:32 PM, Geir Magnusson Jr. wrote:
Just to drive this point home, would you argue that Kodo is not as
good as the "authoritative" RI for JDO or JPA?
A reference implementation is an example implementation and proof of
concept. Different implementations are encouraged an
Just to drive this point home, would you argue that Kodo is not as good
as the "authoritative" RI for JDO or JPA?
Why are we bothering with OpenJPA when the "authoritative" JPA exists in
Glassfish?
;)
geir
Marc Prud'hommeaux wrote:
On Oct 27, 2006, at 5:09 PM, Geir Magnusson Jr. wrote:
Marc Prud'hommeaux wrote:
On Oct 27, 2006, at 5:09 PM, Geir Magnusson Jr. wrote:
I just gotta ask
Why is one implementation "official" and another isn't if the are both
compatible?
My understanding is that the Geronimo spec jars only exist as a stopgap
measure to allow Geronimo to
On Oct 27, 2006, at 5:51 PM, Marc Prud'hommeaux wrote:
On Oct 27, 2006, at 5:09 PM, Geir Magnusson Jr. wrote:
And why not use something from a sister project to make it better?
I was operating under the assumption that Geronimo itself would
move to use these authoritative jars. Perhaps
On Oct 27, 2006, at 5:09 PM, Geir Magnusson Jr. wrote:
I just gotta ask
Why is one implementation "official" and another isn't if the are
both compatible?
My understanding is that the Geronimo spec jars only exist as a
stopgap measure to allow Geronimo to be built without having to
I just gotta ask
Why is one implementation "official" and another isn't if the are both
compatible?
And why not use something from a sister project to make it better?
geir
Marc Prud'hommeaux wrote:
This is the official JTA 1.1 jar that is available at the java.net
repository.
+1 f
This is the official JTA 1.1 jar that is available at the java.net
repository.
+1 for using the official JTA libraries, rather than the stopgap
Geronimo clones.
I'll update the pom.xml unless anyone objects.
On Oct 26, 2006, at 9:16 PM, Craig L Russell wrote:
Hi,
You might find thi
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 endCon
+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 se
+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 se
+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 someo
[ http://issues.apache.org/jira/browse/OPENJPA-68?page=all ]
Abe White resolved OPENJPA-68.
--
Resolution: Fixed
Thanks, fixed. (FTR, the correct name is
org/apache/openjpa/enhance/PersistenceCapable)
> PCClassFileTransformer.isEnhanced() fails because Per
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
co
[
http://issues.apache.org/jira/browse/OPENJPA-69?page=comments#action_12445222 ]
Marc Prud'hommeaux commented on OPENJPA-69:
---
Can you post the exception message and complete stack trace?
> Null reference from one Entity to other cause
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
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 mov
On 10/27/06, Abe White <[EMAIL PROTECTED]> wrote:
Kodo has additional performance and caching features, so there may be
hotspots in OpenJPA that don't exist in Kodo.
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
[ http://issues.apache.org/jira/browse/OPENJPA-67?page=all ]
Kevin Sutter resolved OPENJPA-67.
-
Resolution: Fixed
Updated the DB2 Dictionary with the proper DB2 statements.
> Bug with creating a named Sequence Generator for DB2
> ---
This was one of the thoughts we had as well. But, I wanted to
check base
with you guys first to see if maybe we just didn't have it tuned
correctly.
Have you pushed any performance runs with Kodo 4.1 yet?
Kodo has additional performance and caching features, so there may be
hotspots in Op
[ http://issues.apache.org/jira/browse/OPENJPA-69?page=all ]
Rusanov Dmitry updated OPENJPA-69:
--
Attachment: sample.zip
> Null reference from one Entity to other causes fault with OpenJPA 0.9.0 and
> Apache Derby 10.1 when byte[] used as identity
> ---
Null reference from one Entity to other causes fault with OpenJPA 0.9.0 and
Apache Derby 10.1 when byte[] used as identity
--
Key: OPENJPA-69
U
In case you hadn't noticed, I screwed up and put the wrong JIRA report
reference in the SVN commit message. It should have been OPENJPA-61 (not
OPENJPA-63). Two questions...
o Is there any way to udpate this SVN commit message? I've looking around,
but haven't found a means of updating it.
o
[
http://issues.apache.org/jira/browse/OPENJPA-63?page=comments#action_12445193 ]
Kevin Sutter commented on OPENJPA-63:
-
After requesting a vote via the dev mailing list, we've determined that we're
not going to worry about supporting the ba
28 matches
Mail list logo
