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 Fri, 08 Jul 2005 17:38:18 GMT
Please see below.

On 7/8/05, Daryoush Mehrtash <dmehrtash@gmail.com> wrote:
> I am going to be off camping for a few days (back on Wed)  be happy to
> take shot at this when I come back.   In the mean time:
> 
> •       Where should the XML file be relative to the JWS file?

Same place the .SER was

> •       should this file be optional or required?

Optional

> •       In the XML file how do you propose we identify the JWS methods, keep
> in mind the method overloading (same name, different parameters)?

Keep the signature (remember the asm trick i showed u how to parse the
singature, just reverse it)

> •       Within a method how do you propose we identify the parameters, with
> explicit position, or just use ordered set of elements that
> corresponds to the method parameters?

Upto you.

> •       Beside parameter name should  there be anything else in the XML file?

Anything else you think make sense

> •       Is this a file that a user may want to edit?   (if so we would have
> to design the file with expectation of his skill level which may
> effect how the methods are identified).

Yes, may be.

> •       The current .ser file allow you to address the service by just using
> its service name (without specifying  the package of the jws).  Is
> that something we want to keep?

Sure.

> •       Are you OK with  the model  that  the object model is loaded at run
> time via  Reflection and use the XML file  (if it exist, assuming it
> is optional) for additional information?

Just decide on the order and stick to it (ok with Reflection first,
followed by xml)

> •       If the run time founds this XML file should it require that the file
> contains  parameter name for all method parameters or just the ones
> that should be "over written"?

Ok to contain everything. not just the ones that need to be overwritten.

> •       What if there is a WebParam annotation and it is different from the
> setting in the  XML file, what should happen?

See 2 comments back. decide on the order and document it.

> Daryoush
> 
> On 7/8/05, Eddie ONeil <ekoneil@gmail.com> wrote:
> >   +1
> >
> >   That's the argument that's been made for a while -- now, let's just build it.
> >
> >   :)
> >
> >
> >
> > On 7/8/05, Davanum Srinivas <davanum@gmail.com> wrote:
> > > I agree with Rich. PLEASE use an XML Schema for our model.
> > >
> > > -- dims
> > >
> > > On 7/8/05, Rich Feit <richfeit@gmail.com> wrote:
> > > > Thanks for the info in this and the previous response.  For my part (and
> > > > at this point I'm really just an observer of the WSM codebase), I would
> > > > still go with an XML schema that matches the model you build.  WSDL is
> > > > standard, but it seems like it's a standard for expressing a public
> > > > interface, not a standard for this particular use.
> > > >
> > > > Rich
> > > >
> > > > Daryoush Mehrtash wrote:
> > > >
> > > > >On 7/7/05, Eddie ONeil <ekoneil@gmail.com> wrote:
> > > > >
> > > > >
> > > > >>  Agreed.  A WSM-specific XML file seems like the right way to
go here.
> > > > >>
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >>  Producing a partial WSDL will be weird for the user as it's
just
> > > > >>used as a transport for our own information but we use a name
(wsdl)
> > > > >>that implies more than that.
> > > > >>
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > > >The only thing "partial" about the WSDL that we can generate at APT
> > > > >time is that its  schema types would not be fully defined.  Or at
> > > > >least I don't see how one can determine the  schema types unless you
> > > > >actaully load and run the classes.   Other than schema type the WSDL
> > > > >would be complete.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >>Eddie
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >
> > > > >daryoush
> > > > >
> > > > >
> > > > >>On 7/7/05, Davanum Srinivas <davanum@gmail.com> wrote:
> > > > >>
> > > > >>
> > > > >>>-0 to wsdl. +1 to (XML schema that conforms more to the model)
> > > > >>>
> > > > >>>-- dims
> > > > >>>
> > > > >>>On 7/7/05, Rich Feit <richfeit@gmail.com> wrote:
> > > > >>>
> > > > >>>
> > > > >>>>A few questions about this (again, I'm just trying to
educate myself here):
> > > > >>>>
> > > > >>>>    - If WSDL is the "overwrite" format, then this means
deployment-time
> > > > >>>>overwriting would have to be done through WSDL, right?
> > > > >>>>    - Let's say that *all* the extra information you need
is parameter
> > > > >>>>names.  Can valid WSDL be sparse enough to make sense
for this?
> > > > >>>>    - Why wouldn't it be possible to generate type information
during
> > > > >>>>apt processing?  apt/Mirror gives you a superset of what
you have at
> > > > >>>>runtime.  Or is it just logically impossible to get the
right
> > > > >>>>information during the processing stage?
> > > > >>>>    - At a root level, why is WSDL a better format than
an XML schema
> > > > >>>>that conforms more to the model?
> > > > >>>>
> > > > >>>>Thanks,
> > > > >>>>Rich
> > > > >>>>
> > > > >>>>Daryoush Mehrtash wrote:
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>>An idea from "sleepless night in Seattle" :)
> > > > >>>>>
> > > > >>>>>I think there is an overall agreement that we need
*something* to keep the
> > > > >>>>>missing information form class files. And we all seem
to agree that the
> > > > >>>>>serialized java file is not the right solution.
> > > > >>>>>
> > > > >>>>>Instead of creating yet another XML file, why not
just use a WSDL file to be
> > > > >>>>>the additional information. We can build a WSDL (minus
its type information)
> > > > >>>>>during the APT process. In run time the code would
look something like:
> > > > >>>>>
> > > > >>>>>Load the object model from reflection (java.reflection
or ASM)
> > > > >>>>>
> > > > >>>>>If there is a WSDL file
> > > > >>>>>
> > > > >>>>>To the extend possible use the WSDL information to
over write the JWS
> > > > >>>>>settings
> > > > >>>>>
> > > > >>>>>Make sure there are no conflicts between WSDL and
JWS file
> > > > >>>>>
> > > > >>>>>Run the web service….
> > > > >>>>>
> > > > >>>>>I don't believe it would be possible to generate the
WSDL's type information
> > > > >>>>>during the APT processing. Furthermore, the real WSDL
of the service is
> > > > >>>>>generate by the SOAP stack, and may be different from
the WSDL file that is
> > > > >>>>>generated during the APT processing. Nevertheless
I think the WSDL (or a
> > > > >>>>>subset of a complete WSDL) would be a logical format
to keep the missing
> > > > >>>>>information.
> > > > >>>>>
> > > > >>>>>Thoughts?
> > > > >>>>>
> > > > >>>>>Daryoush
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>On 7/6/05, Daryoush Mehrtash <dmehrtash@gmail.com>
wrote:
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>>Yes. We essentially need some information that
is lost when the JWS
> > > > >>>>>>files are compiled. The curent solution is to
build the complete
> > > > >>>>>>object model during the APT build process. The
model containes all
> > > > >>>>>>that is needed to run the web service (information
on the web
> > > > >>>>>>servicer, every method, parameter etc). Most of
the information is
> > > > >>>>>>available from the class file, so the serialized
information is
> > > > >>>>>>redundant, and as Eddie has said at time the information
is not even
> > > > >>>>>>valid.
> > > > >>>>>>
> > > > >>>>>>For run time I am proposing we build the model
of the web service from
> > > > >>>>>>the JWS class file, but have a file that would
over write the
> > > > >>>>>>information in the class files.
> > > > >>>>>>
> > > > >>>>>>At build time we can save the missing information
to this file. We
> > > > >>>>>>only need the parameter names, but the same mechanisem
could
> > > > >>>>>>potentially be used by a deployer to overwrite
the information in the
> > > > >>>>>>class files.
> > > > >>>>>>
> > > > >>>>>>Right now we are dependent on APT process. But
in my model you can
> > > > >>>>>>also work based on straight Javac. Although with
APT you get a more
> > > > >>>>>>conformant (default parameter names) implementation.
> > > > >>>>>>
> > > > >>>>>>Daryoush
> > > > >>>>>>
> > > > >>>>>>On 7/6/05, Richard Feit <richard.feit@bea.com>
wrote:
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>>Just to make sure I'm clear on this, we're
talking about something that
> > > > >>>>>>>*was* a Serialized object written to a ".ser"
file, but that will no
> > > > >>>>>>>longer have anything to do with Serialization?
The "overwrites" that
> > > > >>>>>>>you're talking about are simply the parameter
names, written to XML?
> > > > >>>>>>>
> > > > >>>>>>>Just trying to understand -- I haven't been
involved in the coding of
> > > > >>>>>>>this piece, so I'm starting from scratch here.
> > > > >>>>>>>
> > > > >>>>>>>Thanks,
> > > > >>>>>>>Rich
> > > > >>>>>>>
> > > > >>>>>>>Daryoush Mehrtash wrote:
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>>Beside the format of the ".ser" file we
also need to reach closure on
> > > > >>>>>>>>its content and its role.
> > > > >>>>>>>>
> > > > >>>>>>>>Right now the .ser file contains the complete
model and is the sole
> > > > >>>>>>>>means to build the object model at run
time. I think we need to change
> > > > >>>>>>>>both aspect of the .ser file.
> > > > >>>>>>>>
> > > > >>>>>>>>My suggestion on this is to always build
the run time object model of
> > > > >>>>>>>>the web service based on Reflection (or
similar class analysis e.g.
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>ASM)
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>>>>and use the ".ser" (in any format you
choose to keep it) to overwrite
> > > > >>>>>>>>the reflection information. The ".ser"
then doesn't have to be a
> > > > >>>>>>>>complete model, rather it would only contain
the overwrites. The
> > > > >>>>>>>>overwrites would take precedence over
the class file annotations and
> > > > >>>>>>>>would be used by the build process, or
deployment process to control
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>the
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>>>>final web service.
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>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
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>--
> > > > >>>>>>Daryoush
> > > > >>>>>>
> > > > >>>>>>Weblog: http://perlustration.blogspot.com/
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>--
> > > > >>>Davanum Srinivas -http://blogs.cocoondev.org/dims/
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Davanum Srinivas -http://blogs.cocoondev.org/dims/
> > >
> >
> 
> 
> --
> Daryoush
> 
> Weblog:  http://perlustration.blogspot.com/
> 


-- 
Davanum Srinivas -http://blogs.cocoondev.org/dims/
Mime
View raw message