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 (asf.osuosl.org: domain of michael.merz@gmail.com
 designates 64.233.184.205 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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=e7+T0fr+j5REHKGGr5eeYI8/ul8yExiJBCfaC+8m4nhtIUrxhb2KjpUCmH79+7A1hhbUzw5mCb+apONIIqxcp6XuBoKWMAmGSamtGFMkjOhYCGn8ewjsB48mfBAnYQAljx0yrSQaDxTNZPjdqRJBq/fnOoOdjuzIo9dYHxDs3lg=
Message-ID: <902ca67805070611273a53b612@mail.gmail.com>
Date: Wed, 6 Jul 2005 11:27:46 -0700
From: Michael Merz <michael.merz@gmail.com>
Reply-To: mmerz@acm.org
To: Rich Feit <richfeit@gmail.com>
Subject: Re: Role of .ser file in WSM
Cc: Beehive Developers <beehive-dev@incubator.apache.org>,
	Eddie ONeil <ekoneil@gmail.com>, Eddie O'Neil <ekoneil@bea.com>,
	"Mehrtash, Daryoush" <dmehrtas@bea.com>
In-Reply-To: <42CC17E7.5030006@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <902ca678050706100333a52abc@mail.gmail.com>
	 <e9ac8354050706101274149878@mail.gmail.com>
	 <19e0530f05070610275ea82cec@mail.gmail.com>
	 <42CC17E7.5030006@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

--=20
Michael Merz
mmerz@acm.org

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.
>=20
> Rich
>=20
> Davanum Srinivas wrote:
>=20
> >+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.
> >>>>=3D20
> >>>>If we want to go the route of generating any file, a XML file might b=
e a
> >>>>better option.
> >>>>=3D20
> >>>>daryoush
> >>>>=3D20
> >>>>
> >>>>
> >>>>>-----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 co=
de
> >>>>>associated with the original interface.   These names are used to
> >>>>>support named argument lookup during extensible method invocation.
> >>>>>
> >>>>>
> >>>>=3D20
> >>>>=3D20
> >>>>
> >>>>
> >
> >
> >
> >
>