axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajith Attapattu" <rajit...@gmail.com>
Subject Re: [Axis2] JSR 181 support
Date Thu, 03 Aug 2006 20:42:58 GMT
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)<http://java.sun.com/j2se/1.5.0/docs/guide/apt/mirror/com/sun/mirror/apt/AnnotationProcessorEnvironment.html#getDeclarationsAnnotatedWith%28com.sun.mirror.declaration.AnnotationTypeDeclaration%29>
> > >  > > >
> > >  > > > 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