Bugs item #850152, was opened at 2003-11-27 10:57 Message generated for change (Comment added) made by drmlipp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=850152&group_id=22866
Category: JBossServer Group: v3.2 Status: Open Resolution: None Priority: 8 Submitted By: Michael Lipp (drmlipp) Assigned to: Nobody/Anonymous (nobody) Summary: ServerException thrown too often Initial Comment: EntityHandleImpl.getEJBObject maps all Exceptions to java.rmi.ServerException. It must not do this as ServerException has a very special meaning (see JDK API doc). As all exceptions are mapped to ServerExceptions, the client cannot know if the RemoteException is temporary (e.g. one node in a cluster failed) or permanent (e.g. the object that is referred to in the handle does not exist anymode). However, an EJB client must be able to obtain this information in order to react appropriately. E.g. the object not being found should be mapped to a java.rmi.noSuchObjectException (this is what we usually get when calling a method an a remote interface that refers to an EJB that does not exist any more). - Michael ---------------------------------------------------------------------- >Comment By: Michael Lipp (drmlipp) Date: 2004-03-24 09:19 Message: Logged In: YES user_id=731113 I'm sorry, but what kind of argument is this? Because some developer might not implement the container/EJB contract correctly, JBoss is entitled to violate the client/container contract? You acknowledge that the client must act differently depending on the kind of problem that has caused the exception. Of course, I have implemented looking at the cause as a workaround. But this is highly JBoss specific (and really, while looking at an exception's cause may help to decide what to do next in some cases, this is clearly a situation where you should be able to distinguish the problem cause "first-hand", i.e. without having to dig down). We maintain an application for both JBoss and Bea WLS here and WLS acts exactly as I had excpected (i.e. throws java.rmi.noSuchObjectException) while JBoss throws an exception that -- from the documentation -- is simply not appropriate. Why should I have to implement workarounds when using JBoss just because some developer cannot implement his finder methods properly? ---------------------------------------------------------------------- Comment By: Wes Gere (wesgere) Date: 2004-03-23 20:03 Message: Logged In: YES user_id=690357 EntityHandleImpl.getEJBObject just calls the home's findByPrimaryKey method, which is supposed to throw a FinderException if the object doesn't exist anymore, so you should be able to detect this by checking the type of the Exception returned by RemoteException.getCause. The reason EntityHandleImpl.getEJBObject does not specifically detect a "not found" condition may be that it must rely on the bean developer (the home implementation) to detect the condition, and cannot be sure that the home will actually throw a FinderException if this happens. Because of this, there would be a possibility of inconsistent behavior. The current implementation makes it more obvious that any inconsistency here is in the finder implementation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=850152&group_id=22866 ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
