Which silly typed interfaces do you speak of? --jason
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:jboss- > [EMAIL PROTECTED]] On Behalf Of marc fleury > Sent: Saturday, June 29, 2002 7:11 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Invocation exception handling is wrong > > |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 ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
