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
