beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eddie ONeil <ekon...@gmail.com>
Subject Re: wsm -- handler config file validation
Date Thu, 16 Jun 2005 19:52:46 GMT
  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 <dmehrtash@gmail.com> 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 <ekoneil@gmail.com> 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 <dolander@gmail.com> wrote:
> > > Dev mode...(asserts on)
> > >
> > > On 6/16/05, Eddie ONeil <ekoneil@gmail.com> wrote:
> > > >  What do you mean by "debug"?
> > > >
> > > >
> > > > On 6/16/05, Daryl Olander <dolander@gmail.com> 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 <ekoneil@gmail.com> wrote:
> > > > > >  Note, that should be "build time, run time, or both".
> > > > > >
> > > > > >  :)
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 6/15/05, Eddie ONeil <ekoneil@gmail.com> 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/
>

Mime
View raw message