You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Kevin Menard <ni...@gmail.com> on 2008/08/16 14:49:07 UTC

Re: svn commit: r686457 - in /cayenne/main/trunk/framework/cayenne-jdk1.5-unpublished/src/main/java/org/apache/cayenne: BaseContext.java access/DataContext.java

Good catch on the message in BaseContext.  But, I intended for the message
not to change in DataContext.  Changing the message thrown is itself a
backwards incompatible change.  Perhaps someone has a logging tool that
greps for that statement or worse, code that looks for it.  In any event, I
think it should still say DataContext from the deprecated method and
ObjectContext from the new one.
-- 
Kevin


>  /**
>  * The most common implementation of {@link ObjectContext}. DataContext is
> an isolated
>  * container of an object graph, in a sense that any uncommitted changes to
> persistent
> @@ -93,12 +126,7 @@
>      * @deprecated since 3.0, replaced by
> BaseContex#getThreadObjectContext().
>      */
>     public static DataContext getThreadDataContext() throws
> IllegalStateException {
> -        try {
> -            return (DataContext) BaseContext.getThreadObjectContext();
> -        }
> -        catch(final IllegalStateException ex) {
> -            throw new IllegalStateException("Current thread has no bound
> DataContext.");
> -        }
> +        return (DataContext) BaseContext.getThreadObjectContext();
>     }
>
>     /**
>
>
>

Re: svn commit: r686457 - in /cayenne/main/trunk/framework/cayenne-jdk1.5-unpublished/src/main/java/org/apache/cayenne: BaseContext.java access/DataContext.java

Posted by Andrus Adamchik <an...@objectstyle.org>.
On Aug 16, 2008, at 3:49 PM, Kevin Menard wrote:

> Changing the message thrown is itself a
> backwards incompatible change.  Perhaps someone has a logging tool  
> that
> greps for that statement or worse, code that looks for it.  In any  
> event, I
> think it should still say DataContext from the deprecated method and
> ObjectContext from the new one.

That's too much to ask from us to preserve exception messages. IMO we  
should be able to change those at any time without notice. So I am -1  
on the idea in general. However in this particular case I don't care  
either way. If you want to undo what I did, please go ahead.

Andrus