beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <dava...@gmail.com>
Subject Re: Role of .ser file in WSM
Date Wed, 06 Jul 2005 17:45:13 GMT
+1

On 7/6/05, Rich Feit <richfeit@gmail.com> wrote:
> +1 from me too... it's the way the Page Flow annotation processor
> communicates this kind of stuff to the runtime, too, FWIW.
> 
> Rich
> 
> Davanum Srinivas wrote:
> 
> >+1 to "XML or a generated BeanInfo".
> >
> >-- dims
> >
> >On 7/6/05, Eddie ONeil <ekoneil@gmail.com> wrote:
> >
> >
> >>  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
> >>>>
> >>>>
> >
> >
> >
> >
> 


-- 
Davanum Srinivas -http://blogs.cocoondev.org/dims/

Mime
View raw message