beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eddie ONeil <ekon...@gmail.com>
Subject Re: Role of .ser file in WSM
Date Wed, 15 Jun 2005 01:32:10 GMT
  Right -- thanks for mentioning that.  That's either the 'default'
behavior we should have or another option for discovering the paramter
names.  Axis does this by processing the bytes in a .class file.

  So, summarizing the options for discovering formal argument names, they are:

1) process the .class file to read param names (or use some utility
providing equivalent functionality)
2) generate a BeanInfo class containing the arg names
3) generate an XML file containing the arg names

These would be used in the absence of @WebParam which can be used to
specify a name and can be read at runtime.

So, it seems like we should pick one of the first three options and
allow override (and support building without debug enabled) with
@WebParam.

Opinions from anyone?

Eddie


On 6/14/05, Daryoush Mehrtash <dmehrtash@gmail.com> wrote:
> Just so all the options are on the table...
>  
>  The third option would be to use of debug flag when compiling the JWS,
> AFAIK, if the debug flag is turned on the resulting .class does have the
> parameter names that we would need.  It  would be nice not to have the extra
> configuration file.   
>  
>  My recommendation is the debug compile option.    I don't believe this
> would be an issue, because: 
>  
>  a) I would expect the JWS file to be the facade to the web service and
> compiling it with debug should not affect the performance of the service
>  b) If you are concern about debug option, you would use the @WebParam
> annotation.
>  
>  Daryoush
> 
>  
>  
> On 6/14/05, Eddie ONeil <ekoneil@gmail.com> wrote:
> >   And, I do believe there is utility in remembering why things have
> > been done as they are.
> > 
> >   :)
> > 
> >   In this case, it seems that we've got two options to provide the
> > functionality that will expose the formal argument names for use in 
> > WSM.  Basically, given something like this:
> > 
> >   foo(SomeType abc, SomeType def)
> > 
> > WSM needs to know "abc" and "def".  Today, this is done via the .ser
> > file.  The options seem to be:
> > 
> > 1) generate the equivalent of a BeanInfo class for the web service
> > that would provide ParameterDescriptor instances from which the
> > parameter names (abc and def) could be obtained
> > 
> > 2) generate an XML file that contained something like: 
> > 
> >   <method name="foo">
> >     <parameter>abc</parameter>
> >     <parameter>def</parameter>
> >   </method>
> > 
> > for a method signature like "foo(SomeType abc, SomeType def)". 
> > 
> > I don't have a strong feeling either way -- (1) would be debuggable,
> > though (2) is almost as  debuggable via a breakpoint in WSM code.  In
> > the absence of any other opinion, I'd probably lean toward (2) as the 
> > BeanInfo provides way more information than is needed in this case and
> > (2) is pretty darn simple.
> > 
> > But, both are an improvement over the long-term problems with
> > serialized metadata.  :)
> > 
> > Any thoughts on either of these options from interested parties? 
> > 
> > Eddie
> > 
> > 
> > 
> > On 6/8/05, Kyle Marvin <kylemarvin@gmail.com> wrote:
> > > On 6/8/05, Daryoush Mehrtash <dmehrtas@bea.com > wrote:
> > > > In WSM we don't generate any source code, so far ".ser" has been our
> > > > only artifact that we generated.
> > > >
> > > > If we want to go the route of generating any file, a XML file might be
> a 
> > > > better option.
> > >
> > > Early (pre-Beehive) versions of the Controls runtime took a similar
> > > path:  a single generic body of code (dynamic proxy-based) that used
> > > metadata/reflection as inputs to the process. 
> > >
> > > The transition to a JavaBean-based architecture made it necessary to
> > > do codegen... JavaBeans are (by definition) classes, not interfaces or
> > > proxies.
> > >
> > > I've found the transition had other side benefits, one of which is 
> > > debugability.  It's much easier to identify issues in generated code
> > > (often just by inspection) than it is bugs in metadata-driven dynamic
> > > behavior.   It's often also going to be more performant since direct 
> > > Java invocation is faster than dynamic proxies/reflection... although
> > > if you put xml marshalling/unmarshalling on either side, this hardly
> > > matters :)
> > >
> > > If you do go the codegen route, a key consideration is to keep the 
> > > codegen as thin as possible (codegen thin classes that customize base
> > > functionality provided in runtime jars), as this will retain your
> > > ability to fix a wider scope of runtime bugs w/out requiring 
> > > re-codegen.
> > >
> > > I know you didn't ask for a history lesson... but maybe useful for
> posterity :)
> > >
> > > -- Kyle
> > >
> > 
> 
> 
> 
> -- 
> Daryoush
> 
> Weblog:   http://perlustration.blogspot.com/

Mime
View raw message