Mailing-List: contact dev-help@beehive.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Beehive Developers" <dev@beehive.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of davanum@gmail.com designates
 64.233.184.234 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=XGZ9crbRuqSvPc1y3KmDy5Lw0OWgbzc+ntZ0CKT7EzUaCBFPoD3xbHROCs3cqQ8bmuBnIPW8DlFGu8p04Fq1hF9n8BNazqzM+DsIiDrjYUgpSzZlMSzw/xwHtm0bA18PQLaDCqhpnrupYtkZ8KltNUXUI7zm4Pu9Pd5eOSYN5xE=
Message-ID: <19e0530f0606131456p54336ffat65db2c09069d4a74@mail.gmail.com>
Date: Tue, 13 Jun 2006 17:56:24 -0400
From: "Davanum Srinivas" <davanum@gmail.com>
Reply-To: dims@apache.org
To: "Beehive Developers" <dev@beehive.apache.org>
Subject: Re: Annotation parsing framework for Axis2 (Re: [wsm] a plan)
Cc: axis-dev@ws.apache.org
In-Reply-To: <f5f5e0730606050757od78175j6609bcb7c5cb0c4b@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <19e0530f0602011624k6d4ccc02x69151d7a9f86ad38@mail.gmail.com>
	 <e9ac83540602051654t312dfb53w3ae6af12d9fa03ad@mail.gmail.com>
	 <f5f5e0730606050757od78175j6609bcb7c5cb0c4b@mail.gmail.com>

Rajith,

I think you need to implement ReflectionWsmServiceFactory first. The
angle of attack i am looking at is deploying a POJO with annotations.
(See AxisService.createService in Axis2 where one can deploy a pojo).
You will have to write a WSMToAxisServiceBuilder (see
WSDL11ToAxisServiceBuilder) to populate the AxisService info from WSM.
WDYT? Once we have this, we can get fancy with codegen etc.

thanks,
dims

On 6/5/06, Rajith Attapattu <rajith77@gmail.com> wrote:
> Hi Dims & Eddie,
>
> So code wise I should be looking at MirrorWsmBuilder and WsmService?
> Any pointers will be helpful.
>
> I am going through the wiki and JSR documentation and will get back with
> questions.
> Meanwhile do we have that seperate jar that bundles all the relevent classes
> for the annotations support?
>
> Regards,
>
> Rajith
>
> On 2/5/06, Eddie O'Neil <ekoneil@gmail.com> wrote:
> >
> > Dims--
> >
> >   Hey; apologies for the delay.  That's basically right -- there is
> > actually one other step in the annotation processing pipeline which is
> > verifying the validity of any annotations on the class.  So, it would
> > be:
> >
> >   annotation checking (Jsr181AnnotationChecker) --> model building
> > (MirrorWsmBuilder)
> >
> > which returns a WsmService object that can be wired up into axis2 stuff.
> >
> >   I can certainly break the Axis 1.x stuff into a separate JAR; my
> > original plan was to just put the Axis 1.x and 2 bits in the same JAR
> > file, but if this is a problem, let me know and I can make three JARs
> > -- generic web service processing code, axis 1, axis 2, etc.
> >
> >   There is one important part of this that isn't done yet, and that's
> > to provide something that can be used inside of a server runtime that
> > abstracts from Sun's Mirror types which are used inside of APT.  Not
> > exactly sure what this looks like yet -- could be reflection or
> > something else that abstracts from Sun's Mirror APIs (used inside of
> > APT).
> >
> >   Do you want to run this from inside of the Axis2 runtime or at
> > build-time on the command line?  I'm assuming the former.
> >
> > Eddie
> >
> >
> > On 2/1/06, Davanum Srinivas <davanum@gmail.com> wrote:
> > > Eddie,
> > >
> > > i was looking at the current codebase and spotted the
> > > MirrorWsmBuilder. Is this what we can use in Axis2 to inspect a given
> > > java class? and one the WsmService object is built, then translate
> > > that to Axis2 thingies? Can we split out the processing framework into
> > > a separate jar (w/o things like Axis1 stuff)? Am i on the right track
> > > with this thinking?
> > >
> > > thanks,
> > > dims
> > >
> > > On 1/3/06, Eddie O'Neil <ekoneil@gmail.com> wrote:
> > > > All--
> > > >
> > > >   Happy New Year!  And, as a way to start the year off on a good foot,
> > > > let's get WSM to 1.0.  Below is a proposal for how we get from here to
> > > > there with some details about where we are and what needs to happen.
> > > >
> > > >   Today, there are two core WSM parts, both of which are tailored to
> > > > the Axis web service stack:
> > > >
> > > >   build-time: This is a generic annotation processing layer that has
> > > > the ability to work against Mirror, reflection, and WSDL to produce a
> > > > WSM JavaBean model that represents a web service.  The build-time
> > > > layer has a plug-point for generating source artifacts to support
> > > > various web service runtimes.  For example, the Axis implementation
> > > > produces a serialized version of the WSM JavaBean model.  This could
> > > > also produce JAX-RPC source / deployment descriptor artifacts, etc.
> > > >
> > > >   runtime: The runtime side of WSM is specifically built to support
> > > > the Axis 1.x runtime.  It loads the serialized JavaBean model
> > > > generated at build time and uses an Axis Handler to configure a
> > > > SOAPService given this information.
> > > >
> > > >   There is another large bunch of code in WSM related to tools:
> > > >
> > > > wsdl2ajava -- this tool supports the top-down web service development
> > > > model and starts with a WSDL to produce an annotated Java source file.
> > > >  This tool requires significant knowledge of WSDL and type mapping for
> > > > a specific web service stack.  For example, the mapping for an XSD
> > > > year is mapped to org.apache.axis.types.Year and something different
> > > > on other web service stacks.  wsdl2java is a non-trivial bunch of code
> > > > to write, but is also a very useful tool.
> > > >
> > > >   In order to finish WSM, one more re-architecting step needs to be
> > > > completed; I'd like to remove the use of a serialized Java object as
> > > > the way to communicate from the build-time to runtime parts of the
> > > > implementation.  This would be replaced with a WSDD like, but WSM
> > > > specific, XML descriptor of the service.  AFAICT, WSDD can't be used
> > > > for this because too closely matches the shape of a Java class (Dims
> > > > and others, feel free to correct me if I'm wrong).  So, we need a
> > > > simple XML file that describes the information captured in a
> > > > WsmService.
> > > >
> > > >   Once this is done, we can start work on passing the JSR-181 TCK.
> > > > This will be done atop Apache Axis 1.x.
> > > >
> > > >   In order to expedite the process of getting from here to TCK
> > > > compliance, I'd like to suggest that we stop stop work on the
> > > > wsdl2ajava tool in order to focus on finishing 1.0 and restart this
> > > > tool immediately post-1.0.
> > > >
> > > >   Post 1.0, there are lots of other things that we could do including:
> > > >
> > > > - JDK 1.4 support
> > > > - drop-in support for WSM in Axis to support iteratively developing an
> > > > annotated web service
> > > > - JAX-RPC support (Ias, still have any interest in working on this?)
> > > > - custom annotations to support container-specific features like type
> > mapping
> > > > - and so on...
> > > >
> > > >   Personally, I'm chomping at the bit to get WSM's 1.0 done and would
> > > > like to narrow scope in order to do that.  I think we're almost ready
> > > > for the TCK; I'll start on the XML file to describe an annotated Axis
> > > > web service shortly.
> > > >
> > > >   Thoughts, comments, and flames welcome.
> > > >
> > > > Eddie
> > > >
> > >
> > >
> > > --
> > > Davanum Srinivas : http://wso2.com/blogs/
> > >
> >
>
>


-- 
Davanum Srinivas : http://wso2.com/blogs/