Anyone have any more suggestions on how to debug this?
-Original Message-
From: Phill Moran [mailto:[EMAIL PROTECTED]
Sent: April 26, 2007 11:20 PM
To: open-jpa-dev@incubator.apache.org
Subject: RE: How to debug object retrieveal in JPA?
I don't close it in anyway directly
Hi,
I am on the channel from time to time, but not regularly.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its
Hi guys,
One of our users in ODE is trying to deploy on JBoss. There seems to be some
configuration problems, most probably related to the presence of Hibernate
in the server. He's having the following stacktrace (I trimmed the non
relevant bits):
13:15:29,343 INFO [STDOUT] ERROR -
It looks like this exception is different than the others; it looks like
this exception is actually being thrown, rather than being put into your
result list. Is that correct?
Is this something that you could package up as a test case? Also, I seem
to remember some sort of issue with overly-eager
What happens if you toss
'providerorg.apache.openjpa.persistence.PersistenceProviderImpl/provi
der' into your persistence.xml file?
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email message, together with
It's hard for me to test as this is reported by one of our users but I can
ask him to try that. But wouldn't that result in selecting the Hibernate
implementation instead OpenJPA (which we don't want)?
Thanks,
Matthieu
On 4/30/07, Patrick Linskey [EMAIL PROTECTED] wrote:
What happens if you
As you can see there's a ClassCastException in
javax.persistence.Persistence.createFactory which is a bit
weird. Note that we instantiate the factory using a specific name:
Aah, you had more content in your email. Of course.
And that our persistence.xml *only* references the OpenJPA
I was suggesting to put it into the xml file, not to remove it. At the
time, I had only read the very beginning of your email. It's early still
in my time zone.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This
The standard Apache method of communication is email, as this is the
way that everyone, including people in various time zones, can
participate in the discussion.
It is particularly discouraged to make decisions on such fora as IRC,
as this disallows everyone a voice.
Further, email messages
I upgraded and result stayed the same. Also this is in a spring transaction. In
fact these are all part of JUnit tests.
-Original Message-
From: Patrick Linskey [mailto:[EMAIL PROTECTED]
Sent: April 30, 2007 12:05 PM
To: open-jpa-dev@incubator.apache.org
Subject: RE: How to debug object
Hard to pull this little piece (of a much larger one) and package it. Let me
tool around some more and see if I can uncover more. What is odd is not all my
JPA classes have this problem but all inherit from the same base and are fairly
similar. I will try commenting out parts of it and see if it
Odd indeed. Can you post your named query definition?
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its
Sure here it is and the sql it generates. BTW the SQL works as I can execute it
in MySQL query browser and get the record back I am after. Does it matter that I
am after a single record? I don't specify the single records expected response
(since it could be larger but currently in test it is only
Can you post the current full exception + any nested exceptions and
their nested exceptions and their nested exceptions and so on? I think
that that data is already in this thread, but I just want to confirm
that things are still the same as they were.
-Patrick
--
Patrick Linskey
BEA Systems,
Hi,
I'm happy to announce that OpenJPA 0.9.7 passes the JPA TCK! I'd like to
thank Marc Prud'hommeaux in particular, who made this happen in all
aspects: he worked with Sun to get access to the TCK, set up the
infrastructure to be able to run the TCK in a repeatable manner, made
the appropriate
This is all I get:
0.9.7-incubating nonfatal general error
org.apache.openjpa.persistence.PersistenceException: null
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:857)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:756)
at
So I take it that you're no longer seeing the this result set has been
closed error. What changed in your setup since that error was
happening?
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email message,
Caused by: java.lang.NullPointerException
at java.util.ArrayList.addAll(ArrayList.java:472)
at ca.BidSpec.emall.user.Person.pcsetPhoneNumbers(Person.java:727)
at ca.BidSpec.emall.user.Person.pcClearFields(Person.java)
at
ca.BidSpec.emall.user.Person.pcsetPhoneNumbers(Person.java:727)
I had read this and assumed that it was an OpenJPA-generated method, but
if so, there shouldn't be a line number. Did you reverse-compile your
classes at some point and change the synthetic interception methods?
-Patrick
--
ca.BidSpec.emall.user.Person.pcsetPhoneNumbers(Person.java:727)
I had read this and assumed that it was an OpenJPA-generated
method, but
if so, there shouldn't be a line number. Did you reverse-compile your
classes at some point and change the synthetic interception methods?
That is the
documentation states, the getters and setters used in
property access may appear with a pc prefix in stack traces
under OpenJPA.
Ah yes... I always forget about property access.
Phill: are you using property access? If so, can you post what you're
doing in your business logic in those
That is the original method with a new name. As the
documentation states, the getters and setters used in
property access may appear with a pc prefix in stack traces
under OpenJPA.
What's the rationale behind this? It seems like this will inevitably
make debugging of problems more of a
This looks to be the problem (thanks Abe) It has caused another exception to
come up but let me look into it and see the cause.
You were right though I was issuing a .clear() on a null pointer in the set
method.
-Original Message-
From: Patrick Linskey [mailto:[EMAIL PROTECTED]
Sent:
Hey there,
I'm having a problem merging an entity, here's the simplified structure:
Class A {
@OneToMany(cascade=CascadeType.ALL, mappedBy=parent)
SetB b_set;
...
}
Class B {
@ManyToOne
A parent;
@OneToMany(cascade=CascadeType.ALL, mappedBy=parent)
SetC c_set;
...
}
IMHO, this is a bug in the generated code for pcNewInstance.
I don't understand why the pcNewInstance should ever call
pcClearFields. It just got finished creating a new instance, and it
knows that all fields have been set to their Java default values.
[That's why we require the user to specify
Actually I am doing the clear, once I got rid of it the exception disappeared.
SO IMHO no bug
Phill
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig Russell
Sent: April 30, 2007 5:08 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: How to
Incorrect handling of cascading bidirectional collections during merge/attach
-
Key: OPENJPA-231
URL: https://issues.apache.org/jira/browse/OPENJPA-231
Project: OpenJPA
[
https://issues.apache.org/jira/browse/OPENJPA-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gokhan Ergul updated OPENJPA-231:
-
Attachment: jira-test-case.zip
Attaching test-case to reproduce the issue and suggested patch.
[
https://issues.apache.org/jira/browse/OPENJPA-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492830
]
Gokhan Ergul commented on OPENJPA-231:
--
Note that the patch is developed against a nightly-snapshot of 0.9.7.
Actually I am doing the clear, once I got rid of it the exception disappeared.
SO IMHO no bug
Good to hear, but I think that we could still do some work to make
this easier to debug, at the least.
And I'm still concerned about how you could ever get a list of
exceptions back from a query
30 matches
Mail list logo
