beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Merz" <>
Subject RE: [WSM] About Beehive-120 in Jira.
Date Mon, 13 Dec 2004 20:37:35 GMT
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.



-----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

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

Does TCK test for the parameter names?


-----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?


-----Original Message-----
From: []
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 {
   public void WhatIsYourAge(int age){...}

   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>();

   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.


View raw message