Please see below. On 7/8/05, Daryoush Mehrtash <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > I agree with Rich. PLEASE use an XML Schema for our model. > > > > > > -- dims > > > > > > On 7/8/05, Rich Feit <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > > >> > > > > >> > > > > >>>-0 to wsdl. +1 to (XML schema that conforms more to the model) > > > > >>> > > > > >>>-- dims > > > > >>> > > > > >>>On 7/7/05, Rich Feit <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > > > > >>>>>>>>>Sent: Wednesday, July 06, 2005 10:13 AM > > > > >>>>>>>>>To: Beehive Developers; [EMAIL PROTECTED] > > > > >>>>>>>>>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 <[EMAIL PROTECTED]> 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 > > > > >>>>>>>>>>[EMAIL PROTECTED] > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>>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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > > > > >>>>>>>>>>>>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 <[EMAIL PROTECTED]> 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/
