From: Scott M S. <Sco...@jb...> - 2002-06-28 18:14:21
|
I'm not following what your calling the exceptional case here. Any remoteable protocol will be providing the transport for the EJB remote interface. The client doesn't know that the call through the RMI interface actually was carried by http. They simply expect a RemoteException as defined by the spec. This applies to any remote method invocation independent of the transport. The transport layer may have to do additional work, but the exception wrapping is common to all. xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx ----- Original Message ----- From: "marc fleury" <mar...@jb...> To: <jbo...@li...> Sent: Friday, June 28, 2002 10:36 AM Subject: RE: [JBoss-dev] Invocation exception handling is wrong > > |Possible Solution: > |Modify the LocalInvoker, JRMPInvoker, etc. to wrap exception correctly. > | This solution is a bigger pain because each Invoker would have to have > |the wrapping code, but it would allow the invoker to have protocol rules > |for exception wrapping. I don't like this solution because it could > |create inconsistencies in expected client exception. > > Actually this is the solution, this is limited to the EJB container and thus > he and only he cares about where the call originated. One solution is to > have the invoker set a flag on the "Invocation" describing the originating > transport mechanism, this is going to be interesting in other scenarios > where we need to have that transport information around. The Log > interceptor (how come we do it there? it is strange the logger is a logger), > I don't care, just have the Log check that the invocation is "remote or > local", with a default behavior (in case the value isn't set i.e. HTTP > invoker) of whatever you want but these 2 (JRMP/Local) will always be around > so let's not make the exception the standard. > > > marcf |