You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beehive.apache.org by Michael Merz <mi...@gmail.com> on 2005/07/06 19:03:56 UTC
RE: Role of .ser file in WSM
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 <dm...@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 <dm...@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
Re: Role of .ser file in WSM
Posted by Davanum Srinivas <da...@gmail.com>.
+1
On 7/6/05, Rich Feit <ri...@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 <ek...@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 <mi...@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 <dm...@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 <dm...@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/
Re: Role of .ser file in WSM
Posted by Michael Merz <mi...@gmail.com>.
That would be nice to do -- from a project perspective. However, I
believe that we had discussed that earliler and there were objections
from the user-community towards modifying compiled byte code.
Btw, by "serialized", I did not mean to imply that it had to be a
serialized Java object -- XML or BeanInfo would be fine, of course. I
personally would prefer XML.
+1 from me, too.
-michael
--
Michael Merz
mmerz@acm.org
On 7/6/05, Rich Feit <ri...@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 <ek...@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 <mi...@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 <dm...@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 <dm...@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
> >>>>
> >>>>
> >
> >
> >
> >
>
Re: Role of .ser file in WSM
Posted by Rich Feit <ri...@gmail.com>.
+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 <ek...@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 <mi...@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 <dm...@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 <dm...@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
>>>>
>>>>
>
>
>
>
Re: Role of .ser file in WSM
Posted by Davanum Srinivas <da...@gmail.com>.
+1 to "XML or a generated BeanInfo".
-- dims
On 7/6/05, Eddie ONeil <ek...@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 <mi...@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 <dm...@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 <dm...@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/
Re: Role of .ser file in WSM
Posted by Eddie ONeil <ek...@gmail.com>.
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 <mi...@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 <dm...@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 <dm...@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
>