beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Merz <michael.m...@gmail.com>
Subject RE: Role of .ser file in WSM
Date Wed, 06 Jul 2005 17:03:56 GMT
Hi guys,

Sorry for the late response -- I've been *really* busy for a while ;)

There were reasons for using a .ser file, the most prominent one being
that interfaces will *not* contain the parameter names of methods --
even when compliled with the debug version. A serialized object model
file seemed to be the only way of capturing all information.

I agree that the .ser-file/object model needs some clean-up since it
has "grown". If you'd like to work on it, I would suggest storing all
metadata (as it will be used, i.e. with defaults where applicable) in
a .ser file rather than just select/currently required information and
to stay closer to the way that information is organized in 181.

Cheers,

-michael

-- 
Michael Merz
mmerz@acm.org


  Yeah -- if at all possible, it seems good to avoid generating code
in the WSM case just because we don't need to, though it's a good
point -- I'd forgotten controls did that.

  But, it could definitely work either way.  A source code file seems
easier to deal with than a serialized object for the obvious reasons.

  It's just that the XML file seems sufficient for today's needs...

Eddie



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.
>=20
> If we want to go the route of generating any file, a XML file might be a
> better option.
>=20
> daryoush
>=20
> > -----Original Message-----
> > From: Kyle Marvin [mailto:kylemarvin@gmail.com]
> > Sent: Wednesday, June 08, 2005 2:34 PM
> > To: Beehive Developers
> > Subject: Re: Role of .ser file in WSM
> >
> > On 6/8/05, Daryoush Mehrtash <dmehrtas@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.
>=20
>=20

Mime
View raw message