Hi Daryoush, Well, the TCK won't be available until February 2005. However, since the (current version of the) spec requires "Name of the parameter as it appears in the argument list." (v0.9, p.16) we have little choice here if we want to be 181 compliant. 181-compliance (i.e. passing the TCK) is one of the goals of Beehive WSM.
I agree, it would be nice to have parameter names available from class files; I also agree that this won't happen ;) However, I do not agree that relaxing the 181 spec, especially for that reason, would be a viable solution (although this decision is not ours to make either ;) It's in the spirit of Beehive to simplify Java development. Using the parameter names in the source code for default values is certainly much more intuitive than anything like "in0" -- although equally functional. Moreover, this additional artifact is not meant to be human readable or modifyable. Sure, someone could go ahead and turn it into XML. However, I doubt that us not serializing the object model out would prevent that from happening if there were real demand. Finally, the additional artifact would be "hidden", i.e. somewhere in the WEB-INF directory. Note that there are already all kinds of artifacts in such directories, generated by IDEs and other tools that are required for deploying a webapp to a container. Thus, I think generating the object model once, serializing it out and then using it at deployment time would by far be the cleanest alternative to deliver a 181 compliant WSM stack for Beehive. Furthermore, it lets us detect syntactic and semantic errors at compile/build time rather than at runtime. Cheers, -michael -----Original Message----- From: Daryoush Mehrtash Sent: Monday, December 13, 2004 10:30 AM To: Beehive Developers Subject: RE: [WSM] About Beehive-120 in Jira. My 2 cent... I think Michael's solution of having serialized OM along side the JWS class files would solve the problem of parameter names. But this violates the spirit of the annotations in the java 1.5, at least as I understand them. Sure we can have a java serialized version of the OM, but soon someone wants to have this in XML and we are back in having a class file (with some metadata) and XML file for the rest of metadata. I like the 1.5 model of having all class metadata in the compiled class file. I also like the beehive's current model of generating the object model at run time. This decoupling has a advantage that it doesn't add any new steps to the build (no new files to add to the WAR) and makes the over all system more robust. I think the real solution to this problem is in the specifications. Either the Java class specification should be amended so that class file includes the method parameter name metadata, or more likely, the JSR 181 should be modified to relax the requirement of the default parameter name. In the mean time, I think we should keep the implementation as is unless there is a real use case where the current default parameter names cause problems. Does TCK test for the parameter names? Daryoush -----Original Message----- From: Jonathan Colwell Sent: Monday, December 13, 2004 9:58 AM To: Beehive Developers Subject: RE: [WSM] About Beehive-120 in Jira. Guten Tag Wolfgang, I'm a bit reluctant to insert things into the JWS source since if we had APT doing that, we could just have APT add @WebParam annotations for every parameter. The way I understood Michael describe it, and he is welcome to correct me if I am wrong, is that APT could produce a compiled class file and a file containing the serialized WSM object model. Then, when the reflection WSM annotation processor runs, it can see if a serialized OM is available and not older than the class file. If that is the case, the processor can just load that up using ObjectInputStream instead of reflecting against the class itself. This way there is no re-parsing of the source, param names are retained and we don't mess around with either the JWS source or the resulting class. If we run into situations where the serialized OM gets out of sync with the class, some checks could be made to see if the serialized data matches that of a newly created WSM OM made from reflection against the class. Does that sound reasonable? -jc -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, December 13, 2004 9:24 AM To: Beehive Developers Subject: Re: [WSM] About Beehive-120 in Jira. Hi Jonathan, How about this way ? Get the param names from jws and put a hidden constant pool ( class variable ) holding the names into the jws and makes APT compile it. After the compilation, replaces the modified code with the original one. Here's the example. -------- original jws -------------------------- @WebService public class MyWS { @WebMethod public void WhatIsYourAge(int age){...} @WebMethod public void Add(int myAge, int yourAge){...} } -------- modified jws -------------------------- @WebService public class MyWS { public static Map<String,String> _HIDDEN_CONSTANT_POOL_ = new HashMap<String,String>(); static{ _HIDDEN_CONSTANT_POOL_.add("WhatIsYourAge0","age"); _HIDDEN_CONSTANT_POOL_.add("Add0","myAge,yourAge"); } @WebMethod public void WhatIsYourAge(int age){...} } We have to be careful that the name of the class variable doesn't be doubled in the original code, but this way is really simple and easy. ( Of course, we must think how to match the name of the key in the pool and a method in the jws. ) Thanks in advance. Wolfgang
