beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eddie ONeil <ekon...@gmail.com>
Subject wsm sandbox work [was: Re: Role of .ser file in WSM]
Date Thu, 14 Jul 2005 18:10:50 GMT
  One comment here...I've got the WSM architectural work that has been
under discussion for the last month or so pretty rounded-out in the
Beehive sandbox now.  It's to the point where it:

- passes WSM DRTs
- passes service control DRTs
- has the annotation checker split out from the model classes and
independently usable / testable
- implements a factory layer for creating BeehiveWsTypeMetadata
objects based on Mirror type info.  This could be extended for both
XMLBeans and Java reflection -- just haven't done the work yet.
- works with Java source files without requiring .class files
- still writes out the .ser files for use in Axis.

To switch to the XML file being discussed right now would just be a
matter of re-implementing the factory that takes a Mirror
TypeDeclaration and converts it into the BeehiveWsTypeMetadata. 
Though, some of this depends on how BeehiveWsTypeMetadata relates to
the XML file.

  Would it make sense to take a look at this work first and make a
decision about what build-time infrastructure to use when adding the
XML file support?

Eddie




On 7/8/05, Davanum Srinivas <davanum@gmail.com> wrote:
> 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