Re: TestNG vs. JUnit
Hi Marc, Thanks, I'm reading my mail reverse chron and I found your reference. Thanks, Craig On Feb 6, 2007, at 6:01 PM, Marc Prud'hommeaux wrote: Craig- I mentioned an article earlier that I thought gave a pretty good introduction and comparison: http://www-128.ibm.com/developerworks/java/library/j-cq08296/ There's also a slew of other comparison articles listed at: http://testng.org/doc/misc.html I was going to experiment with making some TestNG cases with OpenJPA, but I got sidetracked. I hope to get back to playing around with it tomorrow. Once I've got something working, I'll post my impressions and recommendations on this list. On Feb 6, 2007, at 5:49 PM, Craig L Russell wrote: Just when I thought I knew enough about JUnit to be dangerous (productive) along comes another test framework. Can someone point us to the FAQ? Aside from tests that fail until a bug is fixed, is there a good reason to switch to use TestNG for openjpa? Craig Craig Russell DB PMC [EMAIL PROTECTED] http://db.apache.org/jdo 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! smime.p7s Description: S/MIME cryptographic signature
RE: Exceptions thrown from callbacks
It seems like we've reached consensus around the following behavior at least: 1. if a callback throws an exception during commit(), wrap in RollbackException and roll back the transaction. 2. if a callback throws an exception during some non-commit() operation, do not wrap the exception, and mark the transaction for rollback. It turns out that this is exactly the current behavior. I just checked in some test cases to exercise this, since the CTS has an outage here now. -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: Patrick Linskey > Sent: Thursday, February 01, 2007 3:27 PM > To: open-jpa-dev@incubator.apache.org > Subject: Exceptions thrown from callbacks > > Hi, > > There's a bit of ambiguity in the spec about what should > happen when an > exception is thrown from a callback. > > I propose that we change OpenJPA's behavior to always wrap exceptions > thrown from callbacks in a RollbackException. Additionally, I propose > that if a callback is thrown from a direct flush() call or a find() or > other data load, we should mark the transaction for rollback > instead of > immediately rolling back the transaction. > > > Details: > > Section 3.5 says: > > "Lifecycle callback methods may throw unchecked/runtime exceptions. A > runtime exception thrown by a callback method that executes within a > transaction causes that transaction to be rolled back." > > 3.5.6: > > "Lifecycle callback methods may throw runtime exceptions. A runtime > exception thrown by a callback method that executes within a > transaction > causes that transaction to be rolled back. No further > lifecycle callback > methods will be invoked after a runtime exception is thrown." > > 3.7: > > "The PersistenceException is thrown by the persistence provider when a > problem occurs. [...] All instances of PersistenceException except for > instances of NoResultException and NonUniqueResultException will cause > the current transaction, if one is active, to be marked for rollback." > > ... > > "The RollbackException is thrown by the persistence provider when > EntityTransaction.commit() fails. > > > So in my opinion, this means that if a callback fails during > commit(), the exception thrown by the callback clearly should > be wrapped > in a RollbackException. It is less clear to me what should happen if a > callback fails at some other time, such as during a find() call. In my > opinion, we should be wrapping the user-thrown exceptions in > RollbackExceptions all the time. > > Further, I think that 3.7 trumps 3.5.6, so if an exception is thrown > from a callback during a find(), we should be marking the transaction > for rollback, rather than actually rolling it back. > > I've got changes in place that implement the behavior I just > described. > The CTS tests surrounding this issue have been excluded, due to the > ambiguity in the spec. > > 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: TestNG vs. JUnit
Craig- I mentioned an article earlier that I thought gave a pretty good introduction and comparison: http://www-128.ibm.com/developerworks/java/library/j-cq08296/ There's also a slew of other comparison articles listed at: http://testng.org/doc/misc.html I was going to experiment with making some TestNG cases with OpenJPA, but I got sidetracked. I hope to get back to playing around with it tomorrow. Once I've got something working, I'll post my impressions and recommendations on this list. On Feb 6, 2007, at 5:49 PM, Craig L Russell wrote: Just when I thought I knew enough about JUnit to be dangerous (productive) along comes another test framework. Can someone point us to the FAQ? Aside from tests that fail until a bug is fixed, is there a good reason to switch to use TestNG for openjpa? Craig Craig Russell DB PMC [EMAIL PROTECTED] http://db.apache.org/jdo
TestNG vs. JUnit
Just when I thought I knew enough about JUnit to be dangerous (productive) along comes another test framework. Can someone point us to the FAQ? Aside from tests that fail until a bug is fixed, is there a good reason to switch to use TestNG for openjpa? Craig Craig Russell DB PMC [EMAIL PROTECTED] http://db.apache.org/jdo smime.p7s Description: S/MIME cryptographic signature
Re: Exceptions thrown from callbacks
Ah, the perils of spec-writing... On Feb 1, 2007, at 3:55 PM, Dain Sundstrom wrote: On Feb 1, 2007, at 3:27 PM, Patrick Linskey wrote: 3.5.6: "Lifecycle callback methods may throw runtime exceptions. A runtime exception thrown by a callback method that executes within a transaction causes that transaction to be rolled back. No further lifecycle callback methods will be invoked after a runtime exception is thrown." One other thing to check is if the tx is marked rollback only, should we not call anymore lifecycle events or is that "No Further lifecycle callback" clause supposed to apply to the single entity that failed. More decisions. Is it 1. After a runtime exception is thrown (during any em method call) the tx is marked for rollback and no callbacks are called on any entity for any method 2. After a runtime exception is thrown from a user-defined callback, the tx is marked for rollback and no callbacks are called on any entity for any method 3. After a runtime exception is thrown from a user-defined callback, the tx is marked for rollback and no callbacks are called on the entity that stimulated the exception 4. After a runtime exception is thrown from a user-defined callback, the tx is marked for rollback and no callbacks are called on any entity during the execution of the current entity manager method 5. The provider decides what to do 6. Something else Craig Russell DB PMC [EMAIL PROTECTED] http://db.apache.org/jdo smime.p7s Description: S/MIME cryptographic signature
Re: Exceptions thrown from callbacks
I think if a user throws an exception in a callback outside of a commit operation, we should simply rethrow it to the user after we clean up our internal state. Presumably, the specific runtime exception has meaning to the user's code, and we don't add much value in wrapping the exception. I might think differently if the spec allowed/required us to continue after catching the first exception thrown from a callback, but it explicitly says that the first exception aborts the operation. From 3.5.6, "No further lifecycle callback methods will be invoked after a runtime exception is thrown." I can go either way on it, but I think Craig's reasoning is sound. +1 ___ 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: Exceptions thrown from callbacks
> We should ask that the spec be clarified so applications can be more > portable. I've done this, and have been told that this issue will be included in the JPA 2.0 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 06, 2007 12:12 PM > To: open-jpa-dev@incubator.apache.org > Subject: Re: Exceptions thrown from callbacks > > > On Feb 6, 2007, at 11:27 AM, Patrick Linskey wrote: > > > Out-of-band, Abe pointed out to me that the text about when > > RollbackExceptions are thrown is pretty clear. 3.7 says: > > > > "The RollbackException is thrown by the persistence provider when > > EntityTransaction.commit fails." > > > > So, it would seem that in the case where an EM.find() or some other > > non-commit() call triggers a callback that throws an exception, we > > should not wrap the exception in a RollbackException. Should we just > > throw the raw exception, or should we wrap in some other > > PersistenceException? > > I think if a user throws an exception in a callback outside of a > commit operation, we should simply rethrow it to the user after we > clean up our internal state. Presumably, the specific runtime > exception has meaning to the user's code, and we don't add > much value > in wrapping the exception. > > I might think differently if the spec allowed/required us to > continue > after catching the first exception thrown from a callback, but it > explicitly says that the first exception aborts the operation. From > 3.5.6, "No further lifecycle callback methods will be invoked after > a runtime exception is thrown." > > From that same paragraph, "A runtime exception thrown by a callback > method that executes within a transaction causes that transaction to > be rolled back." But I think it's ok to set RollbackOnly to satisfy > this requirement. And as a matter of design (separation of concerns) > this really is best practice. > > We should ask that the spec be clarified so applications can be more > portable. > > 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: Patrick Linskey [mailto:[EMAIL PROTECTED] > >> Sent: Monday, February 05, 2007 7:14 PM > >> To: open-jpa-dev@incubator.apache.org > >> Subject: RE: Exceptions thrown from callbacks > >> > I don't recall the details about why we made that > >> decision, but I > prefer > wrapping in a RollbackException for consistency. It sucks > >> to have > to do: > >>> > >>> I agree that that sucks. Of course, if they want their > >>> application to > >>> be portable, then they'll need to put in that logic anyway :) > >> > >> Agreed, and we may need to change our behavior later once the > >> spec team > >> clears this up. I'll be lobbying for the spec team to move to the > >> always-wrapped model, though. > >> > Do you have any opinion about the rollback vs. mark-for-rollback > distinction? > >>> > >>> Well, section 3.5 suggests that it should be rolled back > >>> immediately, > >>> but then if we start wrapping in a PersistenceException, then 3.7 > >>> says that it should just be marked for rollback. Tricky. I guess I > >>> favor immediate rollback, just since section 3.5 is so explicit in > >>> saying that it should happen. > >> > >> I think that rolling back directly is pretty evil, and as I > >> recall, the > >> spec team agreed at one point. I think that this one just slipped > >> through the cracks. In any event, this is covered in the area > >> of the CTS > >> that was excluded, for just this reason presumably. > >> > >> -- > >> Patrick Linskey > >> BEA Systems, Inc. > >> > >> __ > >> _ > >> No
Re: Exceptions thrown from callbacks
On Feb 6, 2007, at 11:27 AM, Patrick Linskey wrote: Out-of-band, Abe pointed out to me that the text about when RollbackExceptions are thrown is pretty clear. 3.7 says: "The RollbackException is thrown by the persistence provider when EntityTransaction.commit fails." So, it would seem that in the case where an EM.find() or some other non-commit() call triggers a callback that throws an exception, we should not wrap the exception in a RollbackException. Should we just throw the raw exception, or should we wrap in some other PersistenceException? I think if a user throws an exception in a callback outside of a commit operation, we should simply rethrow it to the user after we clean up our internal state. Presumably, the specific runtime exception has meaning to the user's code, and we don't add much value in wrapping the exception. I might think differently if the spec allowed/required us to continue after catching the first exception thrown from a callback, but it explicitly says that the first exception aborts the operation. From 3.5.6, "No further lifecycle callback methods will be invoked after a runtime exception is thrown." From that same paragraph, "A runtime exception thrown by a callback method that executes within a transaction causes that transaction to be rolled back." But I think it's ok to set RollbackOnly to satisfy this requirement. And as a matter of design (separation of concerns) this really is best practice. We should ask that the spec be clarified so applications can be more portable. 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: Patrick Linskey [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 7:14 PM To: open-jpa-dev@incubator.apache.org Subject: RE: Exceptions thrown from callbacks I don't recall the details about why we made that decision, but I prefer wrapping in a RollbackException for consistency. It sucks to have to do: I agree that that sucks. Of course, if they want their application to be portable, then they'll need to put in that logic anyway :) Agreed, and we may need to change our behavior later once the spec team clears this up. I'll be lobbying for the spec team to move to the always-wrapped model, though. Do you have any opinion about the rollback vs. mark-for-rollback distinction? Well, section 3.5 suggests that it should be rolled back immediately, but then if we start wrapping in a PersistenceException, then 3.7 says that it should just be marked for rollback. Tricky. I guess I favor immediate rollback, just since section 3.5 is so explicit in saying that it should happen. I think that rolling back directly is pretty evil, and as I recall, the spec team agreed at one point. I think that this one just slipped through the cracks. In any event, this is covered in the area of the CTS that was excluded, for just this reason presumably. -- 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: Monday, February 05, 2007 6:49 PM To: open-jpa-dev@incubator.apache.org Subject: Re: Exceptions thrown from callbacks I don't recall the details about why we made that decision, but I prefer wrapping in a RollbackException for consistency. It sucks to have to do: I agree that that sucks. Of course, if they want their application to be portable, then they'll need to put in that logic anyway :) Do you have any opinion about the rollback vs. mark-for-rollback distinction? Well, section 3.5 suggests that it should be rolled back immediately, but then if we start wrapping in a PersistenceException, then 3.7 says that it should just be marked for rollback. Tricky. I guess I favor immediate rollback, just since section 3.5 is so explicit in saying that it should happen. On Feb 5, 2007, at 6:27 PM, Patrick L
RE: Exceptions thrown from callbacks
Out-of-band, Abe pointed out to me that the text about when
RollbackExceptions are thrown is pretty clear. 3.7 says:
"The RollbackException is thrown by the persistence provider when
EntityTransaction.commit fails."
So, it would seem that in the case where an EM.find() or some other
non-commit() call triggers a callback that throws an exception, we
should not wrap the exception in a RollbackException. Should we just
throw the raw exception, or should we wrap in some other
PersistenceException?
-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: Patrick Linskey [mailto:[EMAIL PROTECTED]
> Sent: Monday, February 05, 2007 7:14 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: RE: Exceptions thrown from callbacks
>
> > > I don't recall the details about why we made that
> decision, but I
> > > prefer
> > > wrapping in a RollbackException for consistency. It sucks
> to have
> > > to do:
> >
> > I agree that that sucks. Of course, if they want their
> > application to
> > be portable, then they'll need to put in that logic anyway :)
>
> Agreed, and we may need to change our behavior later once the
> spec team
> clears this up. I'll be lobbying for the spec team to move to the
> always-wrapped model, though.
>
> > > Do you have any opinion about the rollback vs. mark-for-rollback
> > > distinction?
> >
> > Well, section 3.5 suggests that it should be rolled back
> > immediately,
> > but then if we start wrapping in a PersistenceException, then 3.7
> > says that it should just be marked for rollback. Tricky. I guess I
> > favor immediate rollback, just since section 3.5 is so explicit in
> > saying that it should happen.
>
> I think that rolling back directly is pretty evil, and as I
> recall, the
> spec team agreed at one point. I think that this one just slipped
> through the cracks. In any event, this is covered in the area
> of the CTS
> that was excluded, for just this reason presumably.
>
> --
> 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: Monday, February 05, 2007 6:49 PM
> > To: open-jpa-dev@incubator.apache.org
> > Subject: Re: Exceptions thrown from callbacks
> >
> >
> >
> > > I don't recall the details about why we made that
> decision, but I
> > > prefer
> > > wrapping in a RollbackException for consistency. It sucks
> to have
> > > to do:
> >
> > I agree that that sucks. Of course, if they want their
> > application to
> > be portable, then they'll need to put in that logic anyway :)
> >
> > > Do you have any opinion about the rollback vs. mark-for-rollback
> > > distinction?
> >
> > Well, section 3.5 suggests that it should be rolled back
> > immediately,
> > but then if we start wrapping in a PersistenceException, then 3.7
> > says that it should just be marked for rollback. Tricky. I guess I
> > favor immediate rollback, just since section 3.5 is so explicit in
> > saying that it should happen.
> >
> >
> >
> > On Feb 5, 2007, at 6:27 PM, Patrick Linskey wrote:
> >
> > >> As for whether to wrap the exceptions during
> non-flush/commit times
> > >> (e.g., during a find() call), I'm a little less keen on
> it, but not
> > >> really opposed. The reason is that the clause "Lifecycle callback
> > >> methods may throw runtime exceptions" suggests to me (and,
> > >> apparently, to the CTS authors) that they restricted the
> exception
> > >> type to be runtime exceptions because they expect the unmodified
> > >> exception will be thrown straight up the application. Summary: +0
> > >
> > > I don't recall the details about why we made that
> decision, but I
> > > prefer
> > > wrapping in a RollbackException for consistency. It sucks
> to have
> > > to do:
> > >
> > > try {
> > >
JIRA / svn integration
Hi, I just discovered that Apache's JIRA install runs the JIRA / svn integration plugin. Take a look at the svn information towards the bottom of https://issues.apache.org/jira/browse/OPENJPA-119 for an example, and the "Subversion Commits" tab on the browse-project page: https://issues.apache.org/jira/secure/BrowseProject.jspa Neat! -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: Exceptions thrown from callbacks
On Feb 5, 2007, at 7:14 PM, Patrick Linskey wrote:
Do you have any opinion about the rollback vs. mark-for-rollback
distinction?
Well, section 3.5 suggests that it should be rolled back
immediately,
but then if we start wrapping in a PersistenceException, then 3.7
says that it should just be marked for rollback. Tricky. I guess I
favor immediate rollback, just since section 3.5 is so explicit in
saying that it should happen.
I think that rolling back directly is pretty evil, and as I recall,
the
spec team agreed at one point. I think that this one just slipped
through the cracks. In any event, this is covered in the area of
the CTS
that was excluded, for just this reason presumably.
If you get the exception in a commit, then it's appropriate to roll
back immediately. If you get the exception anywhere else, I'm
strongly opposed to an immediate rollback. Mark the transaction for
rollback is the appropriate action.
Craig
--
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: Monday, February 05, 2007 6:49 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Exceptions thrown from callbacks
I don't recall the details about why we made that decision, but I
prefer
wrapping in a RollbackException for consistency. It sucks to have
to do:
I agree that that sucks. Of course, if they want their
application to
be portable, then they'll need to put in that logic anyway :)
Do you have any opinion about the rollback vs. mark-for-rollback
distinction?
Well, section 3.5 suggests that it should be rolled back
immediately,
but then if we start wrapping in a PersistenceException, then 3.7
says that it should just be marked for rollback. Tricky. I guess I
favor immediate rollback, just since section 3.5 is so explicit in
saying that it should happen.
On Feb 5, 2007, at 6:27 PM, Patrick Linskey wrote:
As for whether to wrap the exceptions during non-flush/commit times
(e.g., during a find() call), I'm a little less keen on it, but not
really opposed. The reason is that the clause "Lifecycle callback
methods may throw runtime exceptions" suggests to me (and,
apparently, to the CTS authors) that they restricted the exception
type to be runtime exceptions because they expect the unmodified
exception will be thrown straight up the application. Summary: +0
I don't recall the details about why we made that decision, but I
prefer
wrapping in a RollbackException for consistency. It sucks to have
to do:
try {
em.find(...);
em.commit();
} catch (RollbackException re) {
if (re.getCause() instanceof MySpecialException) {
// custom logic
} else {
throw re;
}
} catch (MySpecialException mse) {
// same custom logic as above
}
Do you have any opinion about the rollback vs. mark-for-rollback
distinction?
-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: Monday, February 05, 2007 6:20 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Exceptions thrown from callbacks
I don't have any strong opinions either way. Wrapping is useful,
because we can usually provide the FailedObject so that
the user can
more easily attempt some recovery. And I do agree that if
a callback
exception occurs during a commit()/flush() operation then we should
wrap it (and it might as well be in a RollbackException).
Summary: +1
As for whether to wrap the exceptions during non-flush/commit times
(e.g., during a find() call), I'm a little less keen on it, but not
really opposed. The reason is that the clause "Lifecycle callback
methods may throw runtime exceptions" suggests to me (and,
apparently, to the CTS authors) that they restricted the exception
type to be runtime exceptions because they expe
Re: [ANN] OpenJPA Maven Plugin 1.0-alpha released
Hi Kevin, For sources: https://svn.codehaus.org/mojo/trunk/mojo/openjpa-maven-plugin The release artifacts are published here (Mojo Codehaus repo): http://repository.codehaus.org/org/codehaus/mojo/openjpa-maven-plugin/1.0-alpha/ Usage example: http://mojo.codehaus.org/openjpa-maven-plugin/usage.html Cheers, Rahul - Original Message - From: "Kevin Sutter" <[EMAIL PROTECTED]> To: Sent: Wednesday, February 07, 2007 3:10 AM Subject: Re: [ANN] OpenJPA Maven Plugin 1.0-alpha released Rahul, Where do I get it? On 2/5/07, Rahul Thakur <[EMAIL PROTECTED]> wrote: Hi, I am pleased to announce the release of OpenJPA Maven Plugin version 1.0-alpha. This release includes: 1) Mojo to invoke OpenJPA PCEnhancer tool on mapped persistable classes. 2) Plugin documentation. Feedback and suggestions are welcome. Cheers, Rahul
Re: JIRA issue types
On Feb 6, 2007, at 6:07 AM, Kevin Sutter wrote: I'd agree with this assessment. New Features are bigger pieces of work -- more design, documentation, marketing, etc. Improvements are smaller bits of work. Still may need some documentation tweaks, but these type of changes would not make a big splash with marketing. +1 Craig On 2/5/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote: I like to reserve New Feature to high level new stuff that should be marketed. Normally, I like to break these down into bite-sized sub tasks. Most other changes are bug fixes or iterative improvements to the code base. -dain On Feb 5, 2007, at 6:52 PM, Patrick Linskey wrote: > Hi, > > Does anyone understand what the difference is between an "Improvement" > and a "New Feature"? My hope is that "Improvement" is a strict > superset > of "New Feature". > > Should we strive to use "Improvement" rarely, only for bits of > functionality that exist but need to be nominally tweaked, and use > "New > Feature" for other things? Maybe "New Feature" is for things that will > need mentioning in docs etc, and "Improvement" is for things that just > need tweaks in code? > > -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. 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! smime.p7s Description: S/MIME cryptographic signature
Re: EntityManager.clear() semantics
So, officially, no new test cases are allowed to be introduced except
via the JCP Change Review process that results in an updated version
of the spec, RI, and TCK. So it's a fairly grand scale process for
something as massive as Java EE 5.
It's a lot less effort to "simply" update the JSR 220 specification
but they might be thinking "need to update the entire JSR 243 stack"
for this change.
Craig
On Feb 6, 2007, at 6:03 AM, Kevin Sutter wrote:
Thanks, Craig. I also asked our CTS rep to present this new
testcase, but I
haven't heard what the result is. I did find out that they
normally do not
introduce new tests during a test cycle (ie. Java EE 5). They only
remove
testcases based on successful challenges. But, they will take note
of new
test requests and possibly include them in the next round. That's
what our
experience has been anyway.
Kevin
On 2/5/07, Craig L Russell <[EMAIL PROTECTED]> wrote:
I've forwarded the new test case to our CTS team here. They will take
a look to see if it can be adapted to the CTS test framework.
Craig
On Jan 31, 2007, at 6:25 AM, Kevin Sutter wrote:
> Craig,
> If anybody would have a channel to the CTS team, I would think it
> would be
> you. :-) I have also passed on this request to our CTS rep to see
> where it
> takes us. Good idea. Thanks.
>
> Kevin
>
> On 1/30/07, Craig L Russell <[EMAIL PROTECTED]> wrote:
>>
>> Hi Kevin,
>>
>> I agree with your analysis.
>>
>> I would also like to see a CTS test made for this case. Do we
have a
>> channel through BEA or IBM for requests for CTS test cases?
>>
>> Another recent example is the EntityManager.getDelegate behavior
>> which surely should be a candidate for a CTS test.
>>
>> Craig
>>
>> On Jan 30, 2007, at 2:32 PM, Kevin Sutter wrote:
>>
>> > Hi,
>> > We've noticed that when EntityManager.clear() is invoked, an
>> implicit
>> > flush() is performed. Although the spec is cloudy in this
area, I
>> > don't
>> > think this processing is correct. The javadoc is as follows for
>> > clear():
>> >
>> > /**
>> > * Clear the persistence context, causing all managed
>> > * entities to become detached. Changes made to entities that
>> > * have not been flushed to the database will not be
>> > * persisted.
>> > */
>> > public void clear();
>> >
>> > This indicates that Entities that have not been flushed will
not be
>> > persisted. Thus, I would say this implies that we should not be
>> > doing an
>> > implicit flush. If the application wanted their Entities to be
>> > flushed
>> > before the clear, then they can call the flush() method before
>> calling
>> > clear(). We shouldn't be doing this for them because then they
>> > have no
>> > choice.
>> >
>> > The Pro EJB3 Java Persistence API book has similar wording on
pages
>> > 138-139:
>> >
>> > "..In many respects [clear] is semantically equivalent to a
>> > transaction
>> > rollback. All entity instances managed by the persistence
context
>> > become
>> > detached with their state left exactly as it was when the
clear()
>> > operation
>> > was invoked..."
>> >
>> > Our current processing for clear() eventually gets to this code:
>> >
>> >public void detachAll(OpCallbacks call) {
>> >beginOperation(true);
>> >try {
>> >if ((_flags & FLAG_FLUSH_REQUIRED) != 0)
>> >flush();
>> >detachAllInternal(call);
>> >} catch (OpenJPAException ke) {
>> >throw ke;
>> >} catch (RuntimeException re) {
>> >throw new GeneralException(re);
>> >} finally {
>> >endOperation();
>> >}
>> >}
>> >
>> > Basically, if we have dirtied the Persistence Context, then do a
>> > flush()
>> > followed by the detachAllInternal(). I don't think the clear()
>> > should be
>> > doing this flush() operation. Any disagreement?
>> >
>> > 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? 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? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
AW: Using OpenJPA within an "old" J2EE1.4 container with managed transactions?
Thank you - I should have guessed that accessing UserTransaction in this configuration is not allowed. What I tried was to "simply" run the "hellojpa" example within our .ear application. I removed the access to UserTransaction in my test method and it seems to work now. Now I get an error message regarding the enhancer, but thats because I did not invoke the enhancer on the testclass yet. So I guess using JOnAS' managed transactions should work now. Thank you! Hans > -Ursprüngliche Nachricht- > Von: Patrick Linskey [mailto:[EMAIL PROTECTED] > Gesendet: Montag, 05. Februar 2007 22:09 > An: open-jpa-dev@incubator.apache.org > Betreff: RE: Using OpenJPA within an "old" J2EE1.4 container with managed > transactions? > > Looking at the trace, it looks like OpenJPA is being deployed correctly > when you used java:comp/UserTransaction: > > > 156 INFO [RMI TCP Connection(7)-192.168.0.6] openjpa.Runtime - > > Starting OpenJPA 0.9.6-incubating > > This means that OpenJPA loaded the configuration and initialized. > > > 359 INFO [RMI TCP Connection(7)-192.168.0.6] openjpa.jdbc.JDBC - > > OpenJPA will now connect to the database to attempt to determine > > what type of database dictionary to use. To prevent this connection > > in the future, set your openjpa.jdbc.DBDictionary configuration > > property to the appropriate value for your database (see the > > documentation for available values). > > 469 INFO [RMI TCP Connection(7)-192.168.0.6] openjpa.jdbc.JDBC - > > Using dictionary class "org.apache.openjpa.jdbc.sql.MySQLDictionary" > > (MySQL 5.0.27-community-nt ,MySQL-AB JDBC Driver mysql-connector- > > java-5.0.4 ( $Date: 2006-10-19 17:47:48 +0200 (Thu, 19 Oct 2006) $, > > $Revision: 5908 $ )). > > This means that we were able to connect to the database and figure out > that you're using MySQL. > > > org.apache.openjpa.persistence.InvalidStateException: > > You cannot access the EntityTransaction when using managed transactions. > >at > org.apache.openjpa.persistence.EntityManagerImpl.getTransaction(EntityMana > gerImpl.java:360) > >at > >com.lbslogics.ims.system.ejb.IMSSystemBean.initializeJPA(IMSSystemBean.ja > va:1102) > >at > com.lbslogics.ims.system.ejb.IMSSystemBean.startup(IMSSystemBean.java:1061 > ) > >at > > > org.objectweb.jonas_gen.com.lbslogics.ims.system.interfaces.JOnASIMSSystem > Bean2005147373Remote.startup(JOnASIMSSystemBean2005147373Remote.java:23 > 4) > > It looks like IMSSystemBean.initializeJPA() is trying to invoked > EntityManager.getTransaction(). Since you're using JTA, you're not allowed > to use getTransaction(); all transaction management must happen through > container-managed transactions or bean-managed transaction code. > > -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: Hans J. Prueller [mailto:[EMAIL PROTECTED] > > Sent: Monday, February 05, 2007 12:54 PM > > To: open-jpa-dev@incubator.apache.org > > Subject: AW: Using OpenJPA within an "old" J2EE1.4 container > > with managed transactions? > > > > >> If that doesn't work, can you post the complete stack trace? > > > > Thank you for your help. Unfortunately it did NOT work. I'm > > not sure what > > the exact problem is, here are the strack-traces: > > > > first case: > > > > openjpa.ManagedRuntime: > > jndi(TransactionManagerName=java:comp/UserTransaction) > > > > 2007-02-05 21:33:32,109 : IMSSystemBean.initializeJPA : > > initializing JPA > > persist > > ence. > > 2007-02-05 21:33:33,796 : IMSSystemBean.initializeJPA : testing JPA > > persistence > > 156 INFO [RMI TCP Connection(7)-192.168.0.6] > > openjpa.Runtime - Starting > > OpenJ > > PA 0.9.6-incubating > > 359 INFO [RMI TCP Connection(7)-192.168.0.6] > > openjpa.jdbc.JDBC - OpenJPA > > will > > now connect to the database to attempt to determine what > > type of database > > dicti > > onary to use. To prevent this connection in the future, set your > > openjpa.jdbc.D > > BDictionary configuration property to the appropriate value for your > > database (s > > ee the documentation for available values). > > 469 INFO [RMI TCP Connection(7)-192.168.0.6] > > openjpa.jdbc.JDBC - Using > > dictio > > nary class "org.apache.openjpa.jdbc.sql.MySQLDictionary" (MySQL > > 5.0.27-community > > -nt ,MySQL-AB JDBC Driver mysql-connector-java-5.0.4 ( $Date:
Re: [ANN] OpenJPA Maven Plugin 1.0-alpha released
Rahul, Where do I get it? On 2/5/07, Rahul Thakur <[EMAIL PROTECTED]> wrote: Hi, I am pleased to announce the release of OpenJPA Maven Plugin version 1.0-alpha. This release includes: 1) Mojo to invoke OpenJPA PCEnhancer tool on mapped persistable classes. 2) Plugin documentation. Feedback and suggestions are welcome. Cheers, Rahul
Re: JIRA issue types
I'd agree with this assessment. New Features are bigger pieces of work -- more design, documentation, marketing, etc. Improvements are smaller bits of work. Still may need some documentation tweaks, but these type of changes would not make a big splash with marketing. On 2/5/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote: I like to reserve New Feature to high level new stuff that should be marketed. Normally, I like to break these down into bite-sized sub tasks. Most other changes are bug fixes or iterative improvements to the code base. -dain On Feb 5, 2007, at 6:52 PM, Patrick Linskey wrote: > Hi, > > Does anyone understand what the difference is between an "Improvement" > and a "New Feature"? My hope is that "Improvement" is a strict > superset > of "New Feature". > > Should we strive to use "Improvement" rarely, only for bits of > functionality that exist but need to be nominally tweaked, and use > "New > Feature" for other things? Maybe "New Feature" is for things that will > need mentioning in docs etc, and "Improvement" is for things that just > need tweaks in code? > > -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: EntityManager.clear() semantics
Thanks, Craig. I also asked our CTS rep to present this new testcase, but I
haven't heard what the result is. I did find out that they normally do not
introduce new tests during a test cycle (ie. Java EE 5). They only remove
testcases based on successful challenges. But, they will take note of new
test requests and possibly include them in the next round. That's what our
experience has been anyway.
Kevin
On 2/5/07, Craig L Russell <[EMAIL PROTECTED]> wrote:
I've forwarded the new test case to our CTS team here. They will take
a look to see if it can be adapted to the CTS test framework.
Craig
On Jan 31, 2007, at 6:25 AM, Kevin Sutter wrote:
> Craig,
> If anybody would have a channel to the CTS team, I would think it
> would be
> you. :-) I have also passed on this request to our CTS rep to see
> where it
> takes us. Good idea. Thanks.
>
> Kevin
>
> On 1/30/07, Craig L Russell <[EMAIL PROTECTED]> wrote:
>>
>> Hi Kevin,
>>
>> I agree with your analysis.
>>
>> I would also like to see a CTS test made for this case. Do we have a
>> channel through BEA or IBM for requests for CTS test cases?
>>
>> Another recent example is the EntityManager.getDelegate behavior
>> which surely should be a candidate for a CTS test.
>>
>> Craig
>>
>> On Jan 30, 2007, at 2:32 PM, Kevin Sutter wrote:
>>
>> > Hi,
>> > We've noticed that when EntityManager.clear() is invoked, an
>> implicit
>> > flush() is performed. Although the spec is cloudy in this area, I
>> > don't
>> > think this processing is correct. The javadoc is as follows for
>> > clear():
>> >
>> > /**
>> > * Clear the persistence context, causing all managed
>> > * entities to become detached. Changes made to entities that
>> > * have not been flushed to the database will not be
>> > * persisted.
>> > */
>> > public void clear();
>> >
>> > This indicates that Entities that have not been flushed will not be
>> > persisted. Thus, I would say this implies that we should not be
>> > doing an
>> > implicit flush. If the application wanted their Entities to be
>> > flushed
>> > before the clear, then they can call the flush() method before
>> calling
>> > clear(). We shouldn't be doing this for them because then they
>> > have no
>> > choice.
>> >
>> > The Pro EJB3 Java Persistence API book has similar wording on pages
>> > 138-139:
>> >
>> > "..In many respects [clear] is semantically equivalent to a
>> > transaction
>> > rollback. All entity instances managed by the persistence context
>> > become
>> > detached with their state left exactly as it was when the clear()
>> > operation
>> > was invoked..."
>> >
>> > Our current processing for clear() eventually gets to this code:
>> >
>> >public void detachAll(OpCallbacks call) {
>> >beginOperation(true);
>> >try {
>> >if ((_flags & FLAG_FLUSH_REQUIRED) != 0)
>> >flush();
>> >detachAllInternal(call);
>> >} catch (OpenJPAException ke) {
>> >throw ke;
>> >} catch (RuntimeException re) {
>> >throw new GeneralException(re);
>> >} finally {
>> >endOperation();
>> >}
>> >}
>> >
>> > Basically, if we have dirtied the Persistence Context, then do a
>> > flush()
>> > followed by the detachAllInternal(). I don't think the clear()
>> > should be
>> > doing this flush() operation. Any disagreement?
>> >
>> > 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? O, Gasp!
