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/ > > > -- Daryoush Weblog: http://perlustration.blogspot.com/
