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/ >
