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 Tue, 08 Aug 2006 18:08:43 GMT
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.xmlfile, 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