|determine of the call is local or remote, and the Invocation is not |always available.
part of the effort for JBoss 4.0 is exactly that. Get rid of the silly little typed interfaces in the system, typed interfaces in abstract middleware systems are silly, type is good for business applications and even then they like detyped invocation flows for flow engines. anyway, at least giving the "Invocation" a thread local association at the invoker level (in set it out remove it) will help you fly under the typed radar. Typing pipes is retarded and forces us to do silly little tricks like thread local stuff. That being said, "porting" everything to the JBoss ISV base is really making use of that Invocation in ALL the plugins. A plugin should really say "you know what I can really sit in the flow and work on the native Invocation" instead of saying "be sure to send me just that information. There is no way, in an evolving to know that set of information before hand. |In an earlier email, I was trying to find a way to avoid multiple |logging in a deep stack, but the spec does not allow for this. When fuck the spec |ever a system exception is thrown from a local or remote interface the |container is required to log the exception. So we are stuck with |multiple logging. Oh well. marcf | |-- |xxxxxxxxxxxxxxxxxxxxxxxx |Dain Sundstrom |Chief Architect JBossCMP |JBoss Group, LLC |xxxxxxxxxxxxxxxxxxxxxxxx | |Scott M Stark wrote: |> 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" <[EMAIL PROTECTED]> |> To: <[EMAIL PROTECTED]> |> 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 |> |> |> |> |> |> ------------------------------------------------------- |> This sf.net email is sponsored by:ThinkGeek |> Caffeinated soap. No kidding. |> http://thinkgeek.com/sf |> _______________________________________________ |> Jboss-development mailing list |> [EMAIL PROTECTED] |> https://lists.sourceforge.net/lists/listinfo/jboss-development | | | | |------------------------------------------------------- |This sf.net email is sponsored by:ThinkGeek |Caffeinated soap. No kidding. |http://thinkgeek.com/sf |_______________________________________________ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek No, I will not fix your computer. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
