beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daryoush Mehrtash <dmehrt...@gmail.com>
Subject Re: Role of .ser file in WSM
Date Wed, 15 Jun 2005 00:44:45 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message