Mailing-List: contact beehive-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Beehive Developers" <beehive-dev@incubator.apache.org>
Received-SPF: pass (hermes.apache.org: domain of ekoneil@gmail.com designates
 64.233.184.200 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=tInWRB4OVVLNPTf3UFUSaT3WvQ3GzAn+vsgImOUQSRVxaS7ylHVo2JTNqD5Aco5ZC3FbUNUQVwAZpG59WPEd/0E1okqxKthhc/V3oHqqMnL4LqpyaVBBYC8gIC0eqz742lJLvILU/1WChoQC7TrirVrzuxDFAGGb6UNR51LycaY=
Message-ID: <e9ac835405061418323f965cbd@mail.gmail.com>
Date: Tue, 14 Jun 2005 19:32:10 -0600
From: Eddie ONeil <ekoneil@gmail.com>
Reply-To: Eddie ONeil <ekoneil@gmail.com>
To: Beehive Developers <beehive-dev@incubator.apache.org>
Subject: Re: Role of .ser file in WSM
In-Reply-To: <e5b8e9790506141744b66aa2f@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <4B2B4C417991364996F035E1EE39E2E1027C26DE@uskiex01.bea.com>
	 <3e7c9d15050608153325f97ee@mail.gmail.com>
	 <e9ac8354050614171759247a29@mail.gmail.com>
	 <e5b8e9790506141744b66aa2f@mail.gmail.com>

  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 a=
re:

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...
> =20
>  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 ex=
tra
> configuration file.  =20
> =20
>  My recommendation is the debug compile option.    I don't believe this
> would be an issue, because:=20
> =20
>  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.
> =20
>  Daryoush
>=20
> =20
> =20
> 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.
> >=20
> >   :)
> >=20
> >   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=20
> > WSM.  Basically, given something like this:
> >=20
> >   foo(SomeType abc, SomeType def)
> >=20
> > WSM needs to know "abc" and "def".  Today, this is done via the .ser
> > file.  The options seem to be:
> >=20
> > 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
> >=20
> > 2) generate an XML file that contained something like:=20
> >=20
> >   <method name=3D"foo">
> >     <parameter>abc</parameter>
> >     <parameter>def</parameter>
> >   </method>
> >=20
> > for a method signature like "foo(SomeType abc, SomeType def)".=20
> >=20
> > 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=
=20
> > BeanInfo provides way more information than is needed in this case and
> > (2) is pretty darn simple.
> >=20
> > But, both are an improvement over the long-term problems with
> > serialized metadata.  :)
> >=20
> > Any thoughts on either of these options from interested parties?=20
> >=20
> > Eddie
> >=20
> >=20
> >=20
> > 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 ou=
r
> > > > only artifact that we generated.
> > > >
> > > > If we want to go the route of generating any file, a XML file might=
 be
> a=20
> > > > 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.=20
> > >
> > > The transition to a JavaBean-based architecture made it necessary to
> > > do codegen... JavaBeans are (by definition) classes, not interfaces o=
r
> > > proxies.
> > >
> > > I've found the transition had other side benefits, one of which is=20
> > > 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=
=20
> > > 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=20
> > > 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=20
> > > re-codegen.
> > >
> > > I know you didn't ask for a history lesson... but maybe useful for
> posterity :)
> > >
> > > -- Kyle
> > >
> >=20
>=20
>=20
>=20
> --=20
> Daryoush
>=20
> Weblog:   http://perlustration.blogspot.com/