xml-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven J. McDowall" <sjmcdow...@uswest.net>
Subject RE: Java Sevlet Implementation - Attachment
Date Mon, 07 Aug 2000 11:54:34 GMT

-----Original Message-----

Steven J. McDowall writes:

>>Note that not all errors are to be returned as SOAP faults; see the
>>spec for details.

Anything we don't return as a Fault, however, gets thrown as an exception
back to the client because it is then "bad XML" to the parser.. So, instead
of the client generating a "clean error message", it throws an exception
a long stack trace in the middle of SAX.

Although allowable my the spec, our implementation actually appears to
"demand" a nice fault code coming back whenever possible.

>> Hopefully this code (and the README text, etc. ) will go into the
>> xml-soap CVS somewhere (with the proper apache disclaimer headers, etc.)
>> as version 1.0, and from there I can fix these up and also approach the
>> synchronization issue..

>I have three drafts of servletifying rpcrouter.jsp: yours, someone else
>who sent it to me direct, and my own. I'm going to try to merge it all
>and commit a version in the next hour or so.

Great!  Hopefully between the three we have exactly what we need
and a little more.. :-)

> Sanjiva or anyone, could someone explain WHAT was the thinking behind
> the various scope, iScope, scopeids, etc. and how that related to
> synch. and how we should approach in a servlet context? :-)

>That's how lifecycle management is done of the object providing the
>service. When you deploy a service the author indicates what scope
>should be used to new the class (unless it is static of course): request,
>page, session or application. The router creates the object under that
>scope and manages it and routes requests to the appropriate instance.
>We cannot just dump that code (as your servlet appears to) unless we
>also remove that logic from the deployment stuff. I don't want to make
>such a change for this version; I'm all for a better way to do
>lifecycle management however because the current model doesn't work
>when the messages are carried over JMS, say.

>How to approach it? Take a look at the servle>t generated by the JSP
>compiler; you'll see exactly how to handle it> ..

Actually, my version does do SOME lifecycle management, just probably
too much. :-) It also creates an object instance under each scope TYPE, but
just keeps it already forever...

I DID look at the compiled code, however, there is some "JSP" magic
being done I am  not familiar (not being JSP inclined..) Specifically
it appears the "caching" technique uses a JSP specific "getAttribute"
and "setAttribute" pageContext method calls.. I assume that somehow
these calls, for each context, is auto handled by "Jasper" or whomever
to manage the "scope"..

Thus, I was asking for a clarification on what is EXACTLY meant for the
of each scope.. I.e. how long do the objects live? This should probably be
documented somewhere anyway since I am sure a lot of people don't know for
what the life of an object is yet..


View raw message