Role of .ser file in WSM

[Daryoush Mehrtash <dm...@bea.com>]

> - the role of the .ser file seems to be to preserve a metadata shape

> that was computed from the JWS file itself.  Since this file available

> at both build and run time, it seems to make sense to recompute

> (once!) at runtime so that the .ser files aren't necessary.  But, I

> don't have the historical background here -- Dims, Ias, Daryoush, can

> you provide some background here?  Is the .ser file really needed or

> can the same data be calculated at runtime when a service is wired-up

> in Axis?

 

.ser file exist for one reason and one reason only.  JSR 181  says that
name of a @WebParam by default is:

 

Name of the parameter as it appears in the argument list.

 

The issue is that this name gets lost after the class is compiled.   The
original WSM was based on Reflection that there was no Serialized file.


 

An alternative solution is to require the JWS files to be compiled with
Debug option which preserves the argument names.    

 

Is it needed?  Well it depends on your preferred method to get the
argument name:  require the user to compile its JWS in debug, or keep
the serialized file.  Is there a third option?

 

Daryoush

 

Re: Role of .ser file in WSM

[Kyle Marvin <ky...@gmail.com>]

On 6/8/05, Daryoush Mehrtash <dm...@bea.com> wrote:
> 
> .ser file exist for one reason and one reason only.  JSR 181  says that
> name of a @WebParam by default is:
> 
> 
> 
> Name of the parameter as it appears in the argument list.
> 
> 
> 
> The issue is that this name gets lost after the class is compiled.   The
> original WSM was based on Reflection that there was no Serialized file.
> 
> 
> 
> 
> An alternative solution is to require the JWS files to be compiled with
> Debug option which preserves the argument names.
> 
> 
> 
> Is it needed?  Well it depends on your preferred method to get the
> argument name:  require the user to compile its JWS in debug, or keep
> the serialized file.  Is there a third option?
> 

The Controls runtime stores method parameter names into generated code
associated with the original interface.   These names are used to
support named argument lookup during extensible method invocation.

Re: Role of .ser file in WSM

[Eddie ONeil <ek...@gmail.com>]

  Yes, I believe that there is a third option.  :)

  Today, we've got two options:

1) require .java source files be built with debug on so that the
parameter names are available
2) use the .ser files which are serialized Java objects of type
BeehiveWsTypeMetadata

The first is pretty good -- it's what Axis requires for this to work.

The second seems a little problematic because it complicates the build
steps and tightly couples the runtime to a build-time artifact --
namely instances of BeehiveWsTypeMetadata.  Part of the issue is that
this file contains a bunch of calculated information which is
grok-able from the JWS source file itself (among other things).  So,
we're repeating most of the information there just to get the
parameter names.

The third option seems to be to add some Beehive WSM-specific XML file
that contains exactly the information we need -- parameter names --
and no more.  It more loosely couples the build-time and run-time and
could be created by a WSM annotation processor at build time.  In
addition, we avoid versioning problems (etc) with requiring serialized
Java class instances.

I'd suggest going with (1) as it's how Axis works today and removes
the .ser files which tightly couple build / runtime and are always
required.  Then, we can add (3) as a solution to mandating the use of
debug.

Thoughts?

On 6/8/05, Daryoush Mehrtash <dm...@bea.com> wrote:
> > - the role of the .ser file seems to be to preserve a metadata shape
> 
> > that was computed from the JWS file itself.  Since this file available
> 
> > at both build and run time, it seems to make sense to recompute
> 
> > (once!) at runtime so that the .ser files aren't necessary.  But, I
> 
> > don't have the historical background here -- Dims, Ias, Daryoush, can
> 
> > you provide some background here?  Is the .ser file really needed or
> 
> > can the same data be calculated at runtime when a service is wired-up
> 
> > in Axis?
> 
> 
> 
> .ser file exist for one reason and one reason only.  JSR 181  says that
> name of a @WebParam by default is:
> 
> 
> 
> Name of the parameter as it appears in the argument list.
> 
> 
> 
> The issue is that this name gets lost after the class is compiled.   The
> original WSM was based on Reflection that there was no Serialized file.
> 
> 
> 
> 
> An alternative solution is to require the JWS files to be compiled with
> Debug option which preserves the argument names.
> 
> 
> 
> Is it needed?  Well it depends on your preferred method to get the
> argument name:  require the user to compile its JWS in debug, or keep
> the serialized file.  Is there a third option?
> 
> 
> 
> Daryoush
> 
> 
> 
> 
>