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. > > If we want to go the route of generating any file, a XML file might be a > better option. > > daryoush > > > -----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. > > >
