You are right this discussion about .ser file is diverging from the original intend of this thread. I think there may be a disconnect here about the .ser file, I start a new thread on this to keep the discussions separate.
Daryoush On 6/16/05, Eddie ONeil <[EMAIL PROTECTED]> wrote: > > Yeah, I can see how the two topics could be related but it seems > best for this discussion to treat them separately. > > The .ser file is an artifact of the fact that the services are > deployed on Axis. Were the annotation processor targeting JAX-RPC > directly, the output of the annotation processor might not use the > .ser file. > > Given that the core annotation processing layer shouldn't care about > the web service container, it seems like validation of the handler > config file should be performed at build time regardless of whether > artifacts are generated. > > Then, it's left to the runtime part of WSM to validate the handler > config file as needed. > > With the Axis implementation and the use of the .ser files, I agree > that there's no need to validate as the .ser file contains the > serialized object model which was created from the validated config > file. > > With an Axis implementation that does not use the .ser file, it's > probably the case that the config file should be validated at runtime. > The question asked below is whether this should be done strictly or > non-strictly. You're right that this doesn't happen until the service > is addressed -- and that's certainly not ideal. Would be great if it > happened at deploy time. Either way, it seems that any validation > issues should still be logged as warnings. > > On your point about the .ser file, I agree that it provides some > degree of insulation because it's binary, but it also introduces its > own set of problems related to serialized Java objects and such. Just > seems significantly easier to perform either code gen or to create an > XML file that contains the data needed to run a JSR 181 web service on > some container. But, as you mentioned, that's covered in another > thread. > > :) > > Eddie > > > > > On 6/16/05, Daryoush Mehrtash <[EMAIL PROTECTED]> wrote: > > There is also another thread about the need for .ser file. It seems > > to me that these two topics are related. If there is a .ser file > > that is generated at the build time, then all validations can be done > > at build time. On the other hand if there are no build time > > artifacts, then we have to do this at run time. The former would give > > you a lot more predictable deploy and run behavior while the latter is > > more flexiable. > > > > The other issue to consider for the run time validation is when that > > validation should happen, and hat should happen if the validation > > fails. Right now a service gets deployed after the first time one of > > its methods are called. So if there is any validation to be performed > > at runtime, it would be after the first method call. Unless we change > > the deployment model, this may be a little too late. > > > > Even though I generally prefer not to have build time artifact and > > work directly from class files at run time, I have to admit that the > > .ser file makes the deployment more predictable. > > > > There has also been some consideration to use a xml file instead of > > .ser file with the idea that this would make the services more > > debug-able. But as this thread is showing the moment you have a > > editable file, you have to worry about its integrity which opens up > > the Pandora box of "what ifs". > > > > > > Daryoush > > > > On 6/16/05, Eddie ONeil <[EMAIL PROTECTED]> wrote: > > > Gotcha. Yeah, it's certainly possible to enable strict validation > > > only when asserts are on. > > > > > > To be clear, currently, there's no reason to validate on the server > > > as the XML file is only parsed at build time and the serialized > > > SOAPHandler objects (which were constructed from a validated document) > > > are used to wire-up the handler chain. So, this discussion is a > > > little academic at this point, but I presume that at some point, we > > > may validate on the server assuming that falls within the guise of the > > > 181 spec. > > > > > > If validation was loose, my concern would be that you'd never know > > > if a handler was ignored because an element name was mis-spelled. > > > More precisely, you'd find out at some point, but it would take > > > failure / unexpected behavior to make that happen. > > > > > > It's definitely an option. > > > > > > Eddie > > > > > > On 6/16/05, Daryl Olander <[EMAIL PROTECTED]> wrote: > > > > Dev mode...(asserts on) > > > > > > > > On 6/16/05, Eddie ONeil <[EMAIL PROTECTED]> wrote: > > > > > What do you mean by "debug"? > > > > > > > > > > > > > > > On 6/16/05, Daryl Olander <[EMAIL PROTECTED]> wrote: > > > > > > I'd at least have an option to turn it off at run time. Can we > run it > > > > > > with debug "on" and not if debug is "off"? > > > > > > > > > > > > On 6/15/05, Eddie ONeil <[EMAIL PROTECTED]> wrote: > > > > > > > Note, that should be "build time, run time, or both". > > > > > > > > > > > > > > :) > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 6/15/05, Eddie ONeil <[EMAIL PROTECTED]> wrote: > > > > > > > > All-- > > > > > > > > > > > > > > > > Soliciting opinions here... > > > > > > > > > > > > > > > > The JSR 181 specification defines (in Appendix B) an XSD for > writing > > > > > > > > XML files which create a handler chain that runs during web > service > > > > > > > > request processing. A valid instance of this file would look > like the > > > > > > > > one at the end of the mail. Currently, the validation is > performed > > > > > > > > strictly at build time and isn't performed at runtime. > > > > > > > > > > > > > > > > Personally, I tend to prefer strict validation and don't > mind > > > > > > > > dealing with the two XML namespaces (see below). > > > > > > > > > > > > > > > > Any thoughts as to whether to validate at build-time, > dev-time, or both? > > > > > > > > > > > > > > > > Eddie > > > > > > > > > > > > > > > > <handler-config xmlns="http://www.bea.com/xml/ns/jws"; > > > > > > > > xmlns:j2ee="http://java.sun.com/xml/ns/j2ee";> > > > > > > > > <handler-chain> > > > > > > > > <handler-chain-name>TestHandlerChain</handler-chain-name> > > > > > > > > <handler> > > > > > > > > <j2ee:handler-name>PrintHandler</j2ee:handler-name> > > > > > > > > <j2ee:handler-class> > org.apache.beehive.test.handlers.PrintHandler</j2ee:handler-class> > > > > > > > > </handler> > > > > > > > > </handler-chain> > > > > > > > > </handler-config> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Daryoush > > > > Weblog: http://perlustration.blogspot.com/ > > > -- Daryoush Weblog: http://perlustration.blogspot.com/
