beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daryoush Mehrtash <dmehrt...@gmail.com>
Subject Re: Role of .ser file in WSM
Date Fri, 08 Jul 2005 15:55:32 GMT
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? 
•	should this file be optional or required?
•	In the XML file how do you propose we identify the JWS methods, keep
in mind the method overloading (same name, different parameters)?
•	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?
•	Beside parameter name should  there be anything else in the XML file?
•	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).
•	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?
•	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?
•	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"?
•	What if there is a WebParam annotation and it is different from the
setting in the  XML file, what should happen?



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/
Mime
View raw message