axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicholas L Gallardo <nlgal...@us.ibm.com>
Subject Re: [Axis2] JSR 181 support
Date Mon, 14 Aug 2006 05:36:09 GMT
Here's a link to the page that I've started for the JSR-181 discussion. In 
attempting to decompose the note that I sent earlier, I realized that it 
might be easier to just start with the first issue and then work our way 
from there.  I think the direction of the other issues will fall out of 
the decision on this first issue, which I've tried to summarize.

http://wiki.apache.org/ws/FrontPage/Axis2/JAX-WS/JSR-181

Regards,

Nicholas Gallardo
WebSphere  -  WebServices Development
nlgallar@us.ibm.com
Phone: 512-838-1182
Building: 901 / 5G-016



Nicholas L Gallardo/Austin/IBM@IBMUS 
08/09/2006 08:33 AM
Please respond to
axis-dev@ws.apache.org


To
axis-dev@ws.apache.org
cc
axis-dev@ws.apache.org
Subject
Re: [Axis2] JSR 181 support







Hi Rajith, 

I apologize for being a little behind here.  I'll have something up by 
this evening. 

Regards, 

Nicholas Gallardo
WebSphere  -  WebServices Development
nlgallar@us.ibm.com
Phone: 512-838-1182
Building: 901 / 5G-016 


"Rajith Attapattu" <rajith77@gmail.com> 
08/08/2006 01:08 PM 

Please respond to
axis-dev@ws.apache.org


To
axis-dev@ws.apache.org 
cc

Subject
Re: [Axis2] JSR 181 support








Nicholas,

Any updates on wiki page?
Can we start moving the discussion and try to come to some resolution 
about the direction ? :-)

Regards,

Rajith

On 8/3/06, Rajith Attapattu <rajith77@gmail.com> wrote: 
Yes, a summary of the discussion is going to help a lot.
Hopefully we can all come to an agreement on the direction we are going to 
take. 

Rajith 


On 8/3/06, Eddie O'Neil <ekoneil@gmail.com> wrote: 

 +1 -- send along a link when it's posted somewhere and we can continue 
the discussion. 

Eddie 




On 8/3/06, Nicholas L Gallardo < nlgallar@us.ibm.com> wrote: 

Dims, 

Glad I'm not the only one... 

I'll post the link to the list when I have something up. 


Thanks, 

Nicholas Gallardo
WebSphere  -  WebServices Development
nlgallar@us.ibm.com
Phone: 512-838-1182
Building: 901 / 5G-016 


"Davanum Srinivas" <davanum@gmail.com> 
08/03/2006 11:17 AM 


Please respond to
axis-dev@ws.apache.org


To
axis-dev@ws.apache.org 
cc

Subject
Re: [Axis2] JSR 181 support










Nick,

Could you please help by starting a wiki to capture the discussion /
outcome(s)? my head is spinning :)

thanks,
dims

On 8/3/06, Nicholas L Gallardo <nlgallar@us.ibm.com> wrote:
>
>
> Eddie,
>
> Thanks for your weighing in here...  I'll respond to your notes and 
Rajith's at the same time.  I've included Rajith's comments in <RA> blocks 
and Eddie's in <EKO> blocks.  I apologize if the note is a bit unreadable. 
 I couldn't figure out a better way to include all of the comments.
>
>
> ** Exposing the annotated endpoint as either JAX-WS or Axis2 **
> <RA>A) Expose every JSR 181 annotated POJO as Axis2 endpoint as well as 
a JAX-WS endpoint. So we are creating two Axis2 services with one having a 
Suffix as JAXWS.</RA>
>
> I think I understand where you are going with this, but it still leaves 
us with the issue of which service to target as a request is coming in. If 
all we have is the inbound message as the identifier, there's no way to 
tell from just that whether that message should be targeted to the Axis2 
endpoint or the JAX-WS endpoint.  Also, I'm generally uncomfortable with 
configuring a service twice here.  The goal should be to just produce one 
configuration instance to reduce complexity and confusion.
>
> <RA>B) Allow a services.xml approach where we can explicitly specify the 
Message Receiver</RA>
>
> This approach is probably the easiest, but then prevents us from getting 
to the ultimate goal of removing the services.xml completely and just 
deploying with annotations.  I'm ok with using this one as a way to get 
ourselves up and running.
>
> <EKO>How about a metadata driven approach that uses an annotation to 
describe how a service should be exposed?  For example, using something 
like:
>
>
>   @Axis2ServiceBinding(types={ServiceBindingType.NATIVE , 
ServiceBindingType.JAXWS})
>
> </EKO>
>
> This is certainly another solution that makes sense would be relatively 
easy, but I don't believe we'll pass the JAX-WS TCK if we require this 
additional annotation.  Requiring deployment descriptors is not a problem 
since we're not conflicting with anything defined by the spec.
>
>
>
>
> ** What happens to the other (non JSR-181) deployment info **
> <RA>to be honest that's where I think JSR 181 falls short. The spec has 
clearly failed to cater to these scenarios.
>
> They should have some mechanism to enable security, RM, addressing or 
Policy stuff
>
> So again I can think of a few solutions here.
> A) as u mentioned, to introduce axis2 specific annotations
> B) or else once service is deployed, use the admin console to engage the 
modules
> C) Have the services.xml approach to supplement the missing information.
>
> </RA>
>
> <EKO>My $0.02 would be that in the presence of a services.xml file, the 
annotations are ignored and services.xml wins.  I agree with the idea of 
using annotations to wire-up / configure custom functionality in Axis -- 
this metadata could either drive generation of services.xml or be 
processed to wire the service at runtime.</EKO>
>
> Each of Rajith's proposals seem like a suitable way to resolve this.  I 
don't think they are mutually exclusive either.  You would just have to be 
clear about which takes precedence.  I agree with Eddie's comment that in 
the presence of a deployment descriptor, that should win if it overlaps 
with any of the annotation information.  But, there could be annotated 
information that doesn't exist in the in the deployment descriptor should 
not be ignored.
>
>
>
>
> ** The scope of WSMService **
> <EKO>True -- today, the WSMService doesn't support this, though it could 
certainly be extended to do so.  The goal of WSM was to provide a core set 
of functionality in three areas: #1 making it possible to read metadata 
from a variety of sources (Java5, annogen, XDoclet, etc) #2 semantic 
validation of 181 annotations (2) reading annotations from a variety of 
metadata sources #3 supporting generation of resources needed for 
deployment.  All three of these stages were meant to be pluggable.  The 
"checking" phase would require verifying the 181 annotations but could be 
extended to support additional annotations / checks. The code generation 
phase is pluggable and could generate resources for Axis2, JAX-RPC, etc. 
All of this would pass the 181 TCK and still support value-add 
functionality.  FWIW, we're mostly there today. I'll take some time in the 
next day or two to describe this architecture in more detail and send 
along a pointer.</EKO>
>
> I think the pluggability that you are mentioning here is going to be 
key.  We certainly need to read metadata from multiple sources as you 
described.  The tricky part is what we do with that metadata.  I'm a 
little confused as to what the semantic checking is that needs to be done 
with respect to just 181.  I'll plead ignorance here in that I don't 
really know what the 181 TCK will/would test for beyond making sure that 
the particular annotations are located in the right places on the classes? 
 That will certainly be needed and because it's 181 specific, could be 
burned in to WSM.
>
> The plugpoint will need to be exploited when it comes time to handle 
some of the JAX-WS specific validation of those annotations.  My 
interpretation of the 181 spec is that it tries to provide a minimal set 
of rules about how the annotations should be used and points to the 
appropriate spec (JAX-RPC in version 1.0 and JAX-WS in the maintenance 
release) to handle the mapping to a WSDL.  So maybe the processing would 
go something like this:
>
> Note: the flow described below is one that we're looking at for the 
JAX-WS client implementation.
>
> 1. The first thing we are given is a WSDL document.  We need to build 
the metadata based on just that at first since we may not get any 
annotation data at all.  This is done using the 
WSDL11ToAxisServiceBuilder.
>
> 2. Next, we'll be given an annotated Service Endpoint Interface, so we 
need to build a WSMService from an annotated class
>     - WSM uses whatever annotation technology (annogen, java reflection, 
apt) it chooses to read those annotations
>     - While it's building the WSMService from that information, it 
performs the 181 specific validation
>     - Then it calls a plug point to handle the programming model 
specific validation
>
> 3. Once (1) and (2) are complete, we then need to merge the metadata 
collected from the annotations in with the WSDL information.  As of now, 
we'd been thinking of this as a JAX-WS specific piece and not something 
that would be in WSM since it's specific to the current implementation 
(the info being stored in the AxisService tree) and is based completely on 
JAX-WS rules.
>
> So, based on what you mentioned above, I think each of your 1 and 2 
items are still applicable.  The JAX-WS runtime would use items 1 and 2 in 
the scenario I've outlined.   I'm a little unclear though on what item 3 
is.  Does this mean that WSM would generate an actual deployment 
descriptor?
>
>
>
>
> ** The scope of the JSR-181 TCK **
> <EKO>Yep -- we intend to pass the TCK in which case the semantic checks 
for "javax.jws" annotations would remain fixed w.r.t the 
specification.</EKO>
>
> I *think* this should be addressed above.  If my understanding of what's 
being checked is correct, then I agree.
>
>
> I was all over the place there so I hope that makes some amount of 
sense...  Let me know if anything needs clarification.
>
>
> Thanks,
>
> Nicholas Gallardo
>  WebSphere  -  WebServices Development
>  nlgallar@us.ibm.com
>  Phone: 512-838-1182
>  Building: 901 / 5G-016
>
>
>
>
>
>
>
>
> "Eddie O'Neil" <ekoneil@gmail.com>
>
>
> 08/02/2006 10:44 PM
>
>
> Please respond to
>  axis-dev@ws.apache.org
>
>
> To axis-dev@ws.apache.org
>
> cc
>
>
> Subject Re: [Axis2] JSR 181 support
>
>
>
>
>
>
>
>
> Nicholas / Rajith--
>
>    This is a good discussion.  To frame the rest of my comments, I'll 
say that I'm not a JAX-WS expert so if I say something that seems 
incongruous about 181 vs. JAX-WS below, let's talk about it.
>
>    I have been hoping that we could get JSR-181 (WSM) implemented for 
Axis2 (and Axis1), "upgrade" the annotations to support the newest version 
of the specification, and finally pass the TCK.  I'd assumed that this 
would align with JAX-WS.  Additionally, the WSM annotation processors 
should be extensible enough to add support for additional, Axis-specific 
annotations or for the standards.
>
>    We should also discuss the buildtime vs. runtime annotation 
processing requirements.  To date, WSM has focused on the buildtime 
requirements and relied on a web service stack to wire / deploy the 
service.  I'll start a separate thread on this.
>
>    More comments below marked with "[eko]".
>
>  Eddie
>
>
>
>
>  - I don't yet know how we're going to solve the problem of determining 
when an annotated class is intended for JAX-WS deployment vs. Axis2.  Say 
for instance a service implementation bean is annotated with just 
@WebService at the class level and @WebMethod for each of the methods.  As 
the deployment is happening, how will we tell whether this is supposed to 
be an Axis2 endpoint or a JAX-WS endpoint?  We'll need to know the 
difference to determine which message receiver to configure, the 
JAXWSMessageReceiver or the RPCMessageReceiver (I'm guessing that's the 
one that would be used).  Since they are both just annotated beans and 
neither implements an interface, I can't figure out what characteristic 
could be used to distinguish between the two.
>
>  [RA]
>  Very Good question.  I currently use the RPCMessageReceiver and  it's 
exposed as an Axis2 endpoint. (I  was hoping to sync up with you guys to 
work on exposing the service as a JAX-WS endpoint).
>
>  Now we have two possible solutions for this problem
>  A) Expose every JSR 181 annotated POJO as Axis2 endpoint as well as a 
JAX-WS endpoint. So we are creating two Axis2 services with one having a 
Suffix as JAXWS.
>
>  Ex. If we have a Greeting.java POJO annotated with JSR 181, after 
deployment we have to endpoints
>        a) GreetingService (Axis2 endpoint with RPC message receiver)
>        b) GreetingServiceJAXWS (JAXWS endpoint with JAXWS message 
receiver)
>
>  B) Allow a services.xml approach where we can explicitly  specify the 
Message  Receiver
>
>  I prefer option A, but we can definitely make this configurable, so 
there is a lot of flexibility here.
>
>
>  [eko] How about a metadata driven approach that uses an annotation to 
describe how a service should be exposed?  For example, using something 
like:
>
>    @Axis2ServiceBinding(types={ServiceBindingType.NATIVE , 
ServiceBindingType.JAXWS})
>
>  Then, the developer can specify how a service is exposed, and an 
administration infrastructure could override this.
>
>
> - On the topic of deployment, you have a comment in the code 
(DeploymentEngine) that asks whether we can ignore the services.xml if we 
know we have a set of annotated Java classes.  While that's the ultimate 
goal, relying on the JSR-181 annotation data alone will not allow you to 
do this.  If the services.xml is ignored, where does the non-WSDL related 
config information that was in there come from?  For example, what if I 
wanted to specify a few module references to enable WS-Addressing and some 
custom module that I've built.  If the services.xml is ignored, then that 
info is lost.  Unless you defined a way to include that in some custom 
Axis2 annotations as well.  That might just be a limitation of the 
scenario though...
>
>  [RA] to be honest thats where I think JSR 181 falls short. The spec has 
clearly failed to cater to these scenarios.
>  They should have some mechanism to enable security, RM, addressing or 
Policy stuff
>
>  So again I can think of a few solutions here.
>  A) as u mentioned, to introduce axis2 specific annotations
>  B) or else once service is deployed, use the admin console to engage 
the modules
>  C) Have the services.xml approach to supplement the missing 
information.
>
>  [eko] My $0.02 would be that in the presence of a services.xml file, 
the annotations are ignored and services.xml wins.  I agree with the idea 
of using annotations to wire-up / configure custom functionality in Axis 
-- this metadata could either drive generation of services.xml or be 
processed to wire the service at runtime.
>
>
> Some comments from a JAX-WS perspective...
>
>  - While the WSMService provides the abstraction for the JSR-181 view of 
the data, it cannot currently capture the JAX-WS specific annotation data. 
 JAX-WS defines a set of annotations on top of what is included in JSR-181 
that are required for some of the pretty common scenarios.  Example: for a 
doc/lit wrapped pattern service, there are @RequestWrapper and 
@ResponseWrapper annotations that are required for any method that 
implements the wrapped pattern.
>
>  [RA] I see  your point here. Eddie will probably try to answer this 
question from the WSM side.
>
>  [eko] True -- today, the WSMService doesn't support this, though it 
could certainly be extended to do so.  The goal of WSM was to provide a 
core set of functionality in three areas: #1 making it possible to read 
metadata from a variety of sources (Java5, annogen, XDoclet, etc) #2 
semantic validation of 181 annotations (2) reading annotations from a 
variety of metadata sources #3 supporting generation of resources needed 
for deployment.  All three of these stages were meant to be pluggable. The 
"checking" phase would require verifying the 181 annotations but could be 
extended to support additional annotations / checks. The code generation 
phase is pluggable and could generate resources for Axis2, JAX-RPC, etc. 
All of this would pass the 181 TCK and still support value-add 
functionality.  FWIW, we're mostly there today. I'll take some time in the 
next day or two to describe this architecture in more detail and send 
along a pointer.
>
>
> - The WSMServiceFactory has code in it that handles some of the mapping 
rules built in to it.  I didn't dig through in great detail, but noticed a 
few places where it resolves issues between the implementation class 
annotations and the SEI annotations.  My preference would be to have all 
of the rules for JAX-WS built in to our JAX-WS layer.  If we need to make 
changes in there, they become self-contained.  The rules for JAX-WS are 
well-defined and should be strictly maintained.  I would feel a little 
uncomfortable with the possibility that those could change in WSM to 
support a different effort and could break our JAX-WS compliance.
>
>  [RA] Again Eddie from WSM will answer the question.  AFIK they are 
comitted to support and be spec complient to  JSR 181. So I don't think 
they will arbitarily change code without giving due consideration to 
compliance. Also they are fully aware that we are using WSM to build our 
stuff.
>
>  [eko] Yep -- we intend to pass the TCK in which case the semantic 
checks for "javax.jws" annotations would remain fixed w.r.t the 
specification.
>
>
> - The utility that you have for scanning the classes with ASM could be 
leveraged in JAX-WS.  We really just need something to quickly tell us 
whether or not this class has annotations.  The rest of the processing 
could then be done with whatever other tool.
>
>  [RA] ASM is supposed to be a fast approach to reading class info 
without actually loading the class into memory. So yes we could leverage 
that.
>
>  [eko]  That would be very cool.  One point here about buildtime vs. 
runtime annotation processing -- my $0.02 is that it's important to re-use 
the same checking logic for both buildtime and runtime.  Would rather not 
maintain two copies of this code.  :)
>
>
> A bit of background on what we're doing in the JAX-WS layer.  Right now 
the only place we're doing any form of annotations processing is the in 
the client side code that Nikhil has built up for the dynamic proxy.  This 
is all using reflection and just been scaffolding to get us up and runnig. 
 The longer term goal is what was originally called MDQ, but was recently 
renamed as the ServiceDescriptionFactory.  This will be able to take in 
annotated Java and build the JAX-WS runtime model (which uses the 
AxisService and then includes the JAX-WS specific info).  The 
ServiceDescriptionFactory will also eventually be able to merge the Java 
annotation information with the WSDL info that may or may not have already 
existed to produce a single runtime config.  The only problem is that this 
all has to be done keep the JAX-WS specific rules in mind.  It isn't 
generic enough to support a separate model for Axis2.
>
>  [RA] So you are proposing to bring everything under one umbrella 
instead of having different models to provide the annotation (meta-date) 
processing.
>          Again lets wait and see what Dims and others have to say about 
this. (Sorry I am not ducking the question :-) .....)
> Hope that makes sense...
>
>
>  Nicholas Gallardo
>  WebSphere  -  WebServices Development
>  nlgallar@us.ibm.com
>  Phone: 512-838-1182
>  Building: 901 / 5G-016
>
>
>
>
>  "Rajith Attapattu" <rajith77@gmail.com>
>
> 08/01/2006 06:10 PM
>
>
>
>
> Please respond to
>  axis-dev@ws.apache.org
>
>
> To axis-dev@ws.apache.org
>
> cc
>
>
> Subject Re: [Axis2] JSR 181 support
>
>
>
>
>
>
>
>
>
>  Jeff,
>
>  Thanks for your comments on the patch.
>  Yes the validating against an existing WSDL is still outstanding along 
with the following.
>  (WSM does provide some functionality around this and I hope to leverage 
that)
>
>  I have used the WSM code to process all annotations defined in the spec 
and build a WSM Model.
>  However when creating an Axis Service based on the WSM model the 
informaiton provided by the following annotations are still not used.
>  @SOAPBinding
>  @HandlerChain
>  @SOAPMessageHandlers
>
>  Also outstanding
>  ============
>  generating the WSDL if not specified
>  Validating against an existing WSDL (if specified using wsdlLocation)
>
>  Jeff this patch is just the base and a lot more work needs to be done. 
The current patch can do the following.
>  1) use ASM to scan classes marked with @WebService annotation
>  2) Process all the annotations and build a WSM Model.
>  3) Build an Axis2 service based on the WSM model. (Only uses 
information provided by @WebService and @WebMethod and @OneWay
>  4) Deploy the service.
>
>  Hope this helps you to understand the patch more.
>
>  Please feel free to ask more questions.
>
>  Regards,
>
>  Rajith
>
>
>  On 8/1/06, Jeff Barrett <barrettj@us.ibm.com > wrote:
>
>  Hello Rajith,
>
>  From looking at the patch, I was wondering how WSDL and annotations 
will interact with each other.
>
>  It seems to me (from looking at the JSR-181 spec and the JAX-WS spec) 
that annotations might augment information specified in the WSDL. 
Specificaly, from JSR-181 (version 1.0 June 1, 2005) section 2.2.2 "Start 
with WSDL" states: "...JSR-181 annotations supply implementation details 
that are left out of the original WSDL contract, such as binding or 
service location information."
>
>  It seems that building the AxisService from JSR-181 annotations needs 
to also consider (and merge as well as possibly validate against) WSDL if 
there is any.
>
>  Thanks,
>  Jeff
>
>  IBM Software Group - WebSphere Web Services Development
>  Phone: 512-838-4587 or Tie Line 678-4587
>  Internet e-mail and Sametime ID: barrettj@us.ibm.com
>
>
>
>  "Rajith Attapattu" <rajith77@gmail.com >
>
> 07/27/2006 02:45 PM
>
>
>
>
> Please respond to
>  axis-dev@ws.apache.org
>
>
>
>
> To axis-dev@ws.apache.org
>
> cc
>
>
> Subject Re: [Axis2] JSR 181 support
>
>
>
>
>
>
>
>
>
>
>
>  Nicholas,
>
>  So sorry for the late reply, somehow I have missed it :-(
>
>  >>Sorry to jump in the middle here, but can you explain what the meta 
annotation is and from which spec files it would be removed?  I'm assuming 
you're talking >>about the JSR-181 spec annotations declarations, but just 
wanted to make sure.
>  No need to appologize, sorry for not explaining it properly.
>
>  Annogen requires you to add an annotation, which it uses to generate 
the AnnoBeans.
>  @AnnogenInfo(
>  annoBeanClass = 
"org.codehaus.annogen.examples.stored_override.DeploymentInfoAnnoBean"
>  )
>
>  So I used the annotation on the spec files. For example on the 
javax.jws.WebService which describes the @WebService annotation.
>  However it's illegal to modify a spec file without permission, so what 
we did was to remove the annotation after we generated the necessary 
AnnoBeans.
>  The generated AnnoBeans were checked into the main source tree (since 
they never change as the spec files are static)
>
>
>  >>Just for clarity, you are getting those from the WSM jars, correct?
>  Yes they come with the WSM jars. They will most likely be available in 
the repos from today.
>
>  Hope this helps.
>
>  Regards,
>
>  Rajith
>
>  On 7/24/06, Nicholas L Gallardo <nlgallar@us.ibm.com > wrote:
>
>  Rajith,
>
>  Sorry to jump in the middle here, but can you explain what the meta 
annotation is and from which spec files it would be removed?  I'm assuming 
you're talking about the JSR-181 spec annotations declarations, but just 
wanted to make sure.
>
>  Just for clarity, you are getting those from the WSM jars, correct?
>
>  Thanks,
>
>  Nicholas Gallardo
>  WebSphere  -  WebServices Development
>  nlgallar@us.ibm.com
>  Phone: 512-838-1182
>  Building: 901 / 5G-016
>  "Davanum Srinivas" <davanum@gmail.com >
>
> 07/24/2006 04:52 PM
>
>
> Please respond to
>  axis-dev@ws.apache.org
>
>
>
>
> To axis-dev@ws.apache.org
>
> cc
>
>
> Subject Re: [Axis2] JSR 181 support
>
>
>
>
>
>
>
>
>
>
>
>
>
>  Sounds good to me.
>
>  -- dims
>
>  On 7/24/06, Rajith Attapattu <rajith77@gmail.com > wrote:
>  > Dims,
>  >
>  > Eddie was suggesting that we remove the meta annotation from the spec 
files
>  > since we already have the generated code.
>  > Since the spec file is static we can safely include the generated 
AnnoBeans
>  > in the main source tree.
>  >
>  > If we do that approach we can safely avoid the legal issue :-)
>  >
>  > What do u think?
>  >
>  > Regards,
>  >
>  > Rajith
>  >
>  >
>  > On 7/20/06, Rajith Attapattu <rajith77@gmail.com > wrote:
>  > >
>  > > Hi All,
>  > >
>  > > I created a deployment hook which uses ASM to scan a jar file thats 
thrown
>  > into the axis2 repository to identify classes annotated with 
@WebServices.
>  > > Therefore there is no need for a services.xml to be present in the 
jar
>  > file.
>  > >
>  > > Currently support for @SOAPBinding, @HandlerChain, 
@SOAPMessageHandlers
>  > (on Axis2 side, the WSMModel is complete) and generating the WSDL is 
still
>  > outstanding.
>  > >
>  > > Comments/suggestions/reviews are most welcomed.
>  > >
>  > > I will wait for a general nod from the community about the 
direction,
>  > before I start on any further work.
>  > >
>  > > All required patches are attached to AXIS2-883
>  > >
>  > > Regards,
>  > >
>  > >
>  > > Rajith
>  > >
>  > >
>  > >
>  > >
>  > >
>  > > On 7/11/06, Eddie O'Neil <ekoneil@gmail.com > wrote:
>  > > > Rajith--
>  > > >
>  > > >   I'm not super familiar with the Axis2 architecture, but in the
>  > > > absence of both a .aar file and service.xml, is there some 
default
>  > > > binding between a URL and a Java class?  If so, the metadata 
could be
>  > > > checked and processed at runtime to dynamically wire-up a service
>  > > > based on the shape of a web service implementation class (and 
optional
>  > > > service endpoint).
>  > > >
>  > > >   To close the loop on Dennis's question from a while ago, it 
*is*
>  > > > possible to get all of the type declarations that are annotated 
with a
>  > > > specific annotation.  This method is available here:
>  > > >
>  > > >
>  > 
http://java.sun.com/j2se/1.5.0/docs/guide/apt/mirror/com/sun/mirror/apt/AnnotationProcessorEnvironment.html#getDeclarationsAnnotatedWith(com.sun.mirror.declaration.AnnotationTypeDeclaration)

>  > > >
>  > > > and returns a collection of types (classes, fields, parameters) 
that
>  > > > are marked with some annotation.
>  > > >
>  > > >   This doesn't really help us for wiring up web services at 
runtime,
>  > > > but it makes the build time very easy.
>  > > >
>  > > > Eddie
>  > > >
>  > > >
>  > > > On 7/11/06, Rajith Attapattu <rajith77@gmail.com > wrote:
>  > > > > Hi Guillaume,
>  > > > >
>  > > > > if the service deployed as an ".aar" then we know which classes

to
>  > > > > introspect or use ASM.
>  > > > > If there is a service.xml then we can easily figure out what 
the class
>  > is.
>  > > > > The above approach will make life easier.
>  > > > >
>  > > > > But I think the expectation is that service.xml is optional.
>  > > > > Also there maybe an expectation that the annotated POJO's need 
not be
>  > > > > deployed as an ".aar"
>  > > > >
>  > > > > I maybe wrong here, but it would be interesting to know what 
the
>  > expectation
>  > > > > is within the community.
>  > > > > ideas/comments please?
>  > > > >
>  > > > > Regards,
>  > > > >
>  > > > > Rajith
>  > > > >
>  > > > > On 7/11/06, Guillaume Sauthier
>  > > > > < Guillaume.Sauthier@objectweb.org >
>  > > > > wrote:GuilGuillaumelaume
>  > > > > >
>  > > > > Rajith Attapattu wrote:
>  > > > > > Hi Dims,
>  > > > > >
>  > > > >  > I finnaly managed to get an annotated POJO exposed as an 
axis2 web
>  > > > > > service.
>  > > > > > Before I submit the patch I need to clarify a few things.
>  > > > > >
>  > > > > > 1. We need to figure out a way to find the classes marked 
with
>  > > > > > @WebService.
>  > > > > >     Right now I just have my test POJO hard corded in
>  > > > > > WSMToAxis2ServiceBuilder to test things.
>  > > > > >
>  > > > > >    Ideas? suggestions pls?
>  > > > > Hi
>  > > > >
>  > > > > Basically, you have to introspect deployed services to find 
annotated
>  > > > > classes.
>  > > > > Ie : when an aar is deployed (the archive usually with the
>  > service.xml),
>  > > > > you can either look at all the classes with reflection, or use 
ASM to
>  > > > > find annotated classes.
>  > > > > BTW, Is the service.xml optionnal ?
>  > > > >
>  > > > > Regards
>  > > > > Guillaume
>  > > > > >   There was a few disscussion, but can we come to an 
agreement?
>  > > > > >
>  > > > > > 2. Generating Annogen beans for meta data (This is more or

less a
>  > WSM
>  > > > > > problem, will cross post there as well)
>  > > > > >     The annogen task that generates code based on the 
annotated
>  > > > > > classes seems to have bug with inner classes.
>  > > > > >     For example WebParam.Mode gives compilation errors as it

cannot
>  > > > > > the handle the inner class
>  > > > > >     So I eidted the generated source file to get it working.
>  > > > > >
>  > > > > >     This maybe an option since the javax.jws classes are 
static and
>  > > > > > does not need to go through annogen code generation all the

time.
>  > > > > >     But it would be nice if this worked so that I can add a

task in
>  > > > > > wsm to compile the javax.jws classes and generate the 
required
>  > > > > > AnnoBeans without manual intervention.
>  > > > > >
>  > > > > > Regards,
>  > > > >  >
>  > > > > > Rajith
>  > > > > >
>  > > > > >
>  > > > > >
>  > > > > >
>  > > > > >
>  > > > > >
>  > > > > >
>  > > > >
>  > > > >
>  > > > >
>  > > > >
>  > ---------------------------------------------------------------------
>  > > > > To unsubscribe, e-mail:
>  > axis-dev-unsubscribe@ws.apache.org
>  > > > > For additional commands, e-mail: axis-dev-help@ws.apache.org
>  > > > >
>  > > > >
>  > > > >
>  > > > >
>  > > >
>  > > >
>  > ---------------------------------------------------------------------
>  > > > To unsubscribe, e-mail:
>  > axis-dev-unsubscribe@ws.apache.org
>  > > > For additional commands, e-mail: axis-dev-help@ws.apache.org
>  > > >
>  > > >
>  > >
>  > >
>  >
>  >
>
>
>  --
>  Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service 
Developers)
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>  For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
>
>
>
>
>
>
>



-- 
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org 






Mime
View raw message