beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daryoush Mehrtash" <dmehr...@bea.com>
Subject RE: Role of .ser file in WSM
Date Wed, 06 Jul 2005 17:29:30 GMT
This approach would be a little bit complicated; I am just throwing it
out to see if there are any thoughts on this....  Can we use something
like ASM to interject the annotations that are missing from the class
file?

Daryoush

> -----Original Message-----
> From: Eddie ONeil [mailto:ekoneil@gmail.com]
> Sent: Wednesday, July 06, 2005 10:13 AM
> To: Beehive Developers; mmerz@acm.org
> Cc: Eddie O'Neil; Daryoush Mehrtash
> Subject: Re: Role of .ser file in WSM
> 
>   And, again, I can see the value of having *something* that conveys
> this information (the formal argument names), but I disagree with
> using a serialized Java object to convey this information -- the .ser
> file.
> 
>   Seems to me that there are more architecturally flexible / loosely
> coupled ways of conveying this information than serializing the entire
> object model (which includes fully-qualified paths from the build
> environment).  Information like these fully qualified paths shouldn't
> be made available to the runtime side.
> 
>   That's why I was suggesting either XML or a generated BeanInfo file.
> 
>   Hope that's clear...
> 
> Eddie
> 
> 
> 
> On 7/6/05, Michael Merz <michael.merz@gmail.com> wrote:
> > 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