beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eddie ONeil <ekon...@gmail.com>
Subject Re: .ser files in WSM
Date Fri, 24 Jun 2005 18:14:54 GMT
  Gotcha.  It actually doesn't need to force this compile.  :)

  Part of the beauty of APT is that annotation processing can run
against .java source files -- the .class files aren't required.  APT
is able to parse .java files and expose parsed type information as
ClassDeclaration / FieldDeclaration / etc types.

  So, a project like:

src/
    FooService.java
    BarBase.java
    Bar.java

could be annotation checked without having built any .java files into
.class files.

  There are circumstances where this isn't true, but projects similar
to that above are buildable with "apt" and Mirror running only against
source files.

Eddie




On 6/24/05, Daryoush Mehrtash <dmehrtash@gmail.com> wrote:
> Here is the scenario I am wondering about...
>  
>  APT processor is processing FooService in the example below, it sees that
> the Bar.class  is not in the classpath,  can it foce a compile of the Bar to
> a class file and then continue (or even restart) the APT processing of the
> FooService class?
> 
>  
>  Daryoush
>  
>  
> 
> On 6/24/05, Eddie ONeil <ekoneil@gmail.com> wrote:
> >   Depends on what you mean by "force compile of a class"?
> > 
> >   If the "apt" executable doesn't receive the "-nocompile" option,
> > source files will be built into .class files.
> > 
> > Eddie 
> > 
> > 
> > On 6/24/05, Daryoush Mehrtash <dmehrtash@gmail.com> wrote:
> > > One more question... :)
> > >
> > >  Do you know of a  way for APT processor to force a compile of a class (
> say 
> > > in this case Bar)?
> > >
> > >
> > >  Daryoush
> > >
> > > On 6/24/05, Eddie ONeil <ekoneil@gmail.com> wrote:
> > > >   Definitely -- to get this info, you'd use: 
> > > >
> > > >   ClassDeclaration classDecl = ... some ClassDeclaration instance from
> > > > Mirror ...;
> > > >   Collection<FieldDeclaration> fields = classDecl.getFields();
> > > >
> > > > And, you can walk classDecl.getSuperclass() to get each super class
> > > > and find its fields.
> > > >
> > > >   Each FieldDeclaration has accessors for getting the field's
> > > > protection, type, and name via: 
> > > >
> > > > fieldDecl.getModifiers()
> > > > fieldDecl.getType ()
> > > > fieldDecl.getSimpleName()
> > > >
> > > >   Hope that helps...
> > > >
> > > > Eddie
> > > >
> > > > 
> > > >
> > > >
> > > > On 6/24/05, Daryoush Mehrtash <dmehrtash@gmail.com> wrote:
> > > > >
> > > > >
> > > > > I am curious to know how you solve this issue. 
> > > > >
> > > > > Lets say I have the following webservice
> > > > >
> > > > >
> > > > >  @WebService
> > > > >  Public class FooService {
> > > > >
> > > > >             @WebMethod 
> > > > >                  public Bar doFoo() {
> > > > >                       return new Bar();
> > > > >           }
> > > > >  }
> > > > >
> > > > > And my type as:
> > > > >
> > > > > Public class Bar extends BarBase {
> > > > >             String x; 
> > > > >              String y;
> > > > >
> > > > >
> > > > >             public get-er/set-er for x and y
> > > > >
> > > > >
> > > > > }
> > > > >
> > > > > Public class BarBase { 
> > > > >             int a;
> > > > >             public get-er/set-er for a
> > > > >
> > > > >
> > > > > }
> > > > >
> > > > > Assuming that the Bar class is not compiled when the APT of the 
> > > FooService
> > > > > runs,  my question is:   Is there a way in the APT processing to
> find
> > > out
> > > > > that Bar is comprised of "x", "y" as strings, and an integer "a". 
> > > Thanks,
> > > > >
> > > > >  Daryoush
> > > > >
> > > > >
> > > > > On 6/24/05, Eddie ONeil <ekoneil@gmail.com> wrote:
> > > > > > Daryoush-- 
> > > > > >
> > > > > >   At this point, it seems best to throw some code at the virtual
> > > > > > whiteboard and see what sticks.  Hopefully this will help answer
> some
> > > > > > of the questions you posed below. 
> > > > > >
> > > > > >   :)
> > > > > >
> > > > > >   Unfortunately, I don't expect to have lots of time to put into
> this
> > > > > > over the next week or so, but I'll continue to do incremental work
> in 
> > > > > > the sandbox in an attempt to take the implementation to feature
> parity
> > > > > > with trunk/.
> > > > > >
> > > > > >   My goals for this prototyping are listed below; I think the 
> > > > > > rationale for these has been explained earlier in the thread
> though if
> > > > > > anything is unclear, let me know.
> > > > > >
> > > > > >   Feedback welcome on the code in sandbox/ekoneil/wsm/. 
> > > > > >
> > > > > > Cheers,
> > > > > > Eddie
> > > > > >
> > > > > > Goals:
> > > > > > - support annotation processing in the spirit of APT by not
> requiring 
> > > > > > .class files for types available in source code.
> > > > > > - support full build-time checking of annotated web services and
> > > > > > related resources.
> > > > > > - support pluggable code generation 
> > > > > > - make it possible to support reflection based annotation
> validation
> > > > > > and model construction (note, this isn't supported in the tools /
> > > > > > runtime today)
> > > > > > - make it possible to add support for validating a WSDL referenced
> via
> > > > > > @WebService.schemaLocation against an annotated web service
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 6/23/05, Daryoush Mehrtash <dmehrtash@gmail.com> wrote:
> > > > > > > Comments below.
> > > > > > >
> > > > > > >
> > > > > > >  >  Hm.  I sort of disagree with the characterization that the
> > > current
> > > > > > > > implementation is Mirror/Reflection agnostic.  The WSM
> annotation 
> > > > > > > > processor uses the JavaTypeInfo interface and MirrorTypeInfo
> > > > > > > > implementation (and the related classes) in an attempt to
> achieve
> > > this
> > > > > > > > agnosticism. 
> > > > > > >
> > > > > > > Exactly,   the current design is based on  IOC  pattern to
> abstract
> > > out
> > > > > the
> > > > > > > underlying processors (annotation processor, or reflection 
> > > processor)
> > > > > from
> > > > > > > the model creation/validation logic.  It would allow us to reuse
> the
> > > > > model
> > > > > > > creation/validation logic across APT and Reflection (and
> potentially 
> > > > > > > xdoclet).  Why do you think this separation is wrong?
> > > > > > >
> > > > > > > >   As far as supporting both Mirror and Reflection, the latter
> > > could be 
> > > > > > > > an interesting thing to do longer term, but I don't think we
> have
> > > a
> > > > > > > > use case for this today.  Correct?  That being said, the model
> > > objects 
> > > > > > > > could be constructed from reflection data simply by writing a
> new
> > > > > > > > model factory.
> > > > > > >
> > > > > > >
> > > > > > > I see reflection use case as important use case.  It would make
> our 
> > > code
> > > > > > > usable without requiring the source code.   To me that is a
> valid
> > > and
> > > > > strong
> > > > > > > use case to support.   This wouldn't make much sense in NetUI,
> and 
> > > > > Controls
> > > > > > > as they both require extensive code generation.  The WSM,
> however,
> > > can
> > > > > work
> > > > > > > just fine with class files.
> > > > > > > 
> > > > > > > In your terminology, I want to make sure the creation/validation
> > > logic
> > > > > is
> > > > > > > shared between reflection and APT factories.    Right now this
> is 
> > > done
> > > > > with
> > > > > > > IOC, if there are other alternatives I am open to that.  I want
> to
> > > make
> > > > > sure
> > > > > > > this is a requirement for any changes in the design. 
> > > > > > >
> > > > > > >
> > > > > > > >   But, these Java*Info classes use java.lang.Class instances
> for
> > > both
> > > > > > > > parameter types and method return types.  This is problematic 
> > > given a
> > > > > > > > project structured as:
> > > > > > > >
> > > > > > > > src/
> > > > > > > >     AccountService.java (an annotated web service) 
> > > > > > > >     Account.java            (a complex type returned by some
> web
> > > > > service
> > > > > > > > method)
> > > > > > > >
> > > > > > > > This project won't currently build with the WSM annotation 
> > > processor
> > > > > > > > which  can only handle Account.java as .class file meaning
> that
> > > must
> > > > > > > > be compiled first.  Ultimately, this means that the annotation
> > > > > > > > processor does not cleanly separate Mirror and Reflection and
> that
> > > the
> > > > > > > > project structure must be:
> > > > > > > >
> > > > > > > > src/ 
> > > > > > > >     Account.java
> > > > > > > > src-ws/
> > > > > > > >     AccountService.java
> > > > > > > >
> > > > > > > > where src/ builds first in order to make .class files
> available 
> > > for
> > > > > > > > the annotation processing.  Were there a way to use *just*
> Mirror,
> > > the
> > > > > > > > first project model would be buildable and the Java*Info
> > > interfaces 
> > > > > > > > would return TypeDeclarations instead of Class types for
> method
> > > > > > > > signature metadata.
> > > > > > >
> > > > > > >
> > > > > > > I don't believe this is by product of the APT processing model; 
> > > rather
> > > > > it is
> > > > > > > based on our perceived requirements and potentially our lack of
> > > > > knowledge on
> > > > > > > other ways to solve the problem.  Let me explain…. 
> > > > > > >
> > > > > > > The model as you pointed out does keep the class of the
> parameter
> > > and
> > > > > return
> > > > > > > type for every method in the JWS.    I break down your concern
> in 
> > > two
> > > > > > > questions:
> > > > > > >
> > > > > > >
> > > > > > > 1) Does the model really need the class or can it live with just
> the
> > > > > name of 
> > > > > > > the types?
> > > > > > >  2) If the does need the class, is there any way to get it from
> APT
> > > so
> > > > > as
> > > > > > > not to require the compilation? 
> > > > > > >
> > > > > > > If the model doesn't really need the class of the return and
> > > parameters
> > > > > then
> > > > > > > there is a very easy fix to the src/src-ws issue.   The solution
> > > would
> > > > > be to
> > > > > > > change the model so that it only keeps the class name that is
> > > readily
> > > > > > > available at APT and won't require the Reflection.  This would
> solve 
> > > the
> > > > > > > problem right?
> > > > > > >
> > > > > > > But I think to do validation (which we need to do during the
> APT)
> > > the
> > > > > class
> > > > > > > information is needed.  To do a complete validation we would
> need to 
> > > do
> > > > > > > introspection on the method parameters/returns/faults  (we don't
> > > right
> > > > > now,
> > > > > > > but that is our validation logic isn't complete).
> > > > > > >
> > > > > > > Here is a use case,  with @WebService annotation you can specify
> > > > > > > wsdlLocation.  If there is a wsdl associated with the JWS file,
> then
> > > the 
> > > > > > > validation should verify the  validity of the WSDL vs the JWS.
> > > This
> > > > > would
> > > > > > > mean you would have to introspect all your parameters, returns,
> and 
> > > > > faults
> > > > > > > classes (also  handlers, and service end point interfaces also).
> > > The
> > > > > > > validation needs make sure the type schema matches the WSDL
> > > definitions.
> > > > > > > Bottom line is that we would need to introspect classes at the
> APT
> > > > > check()
> > > > > > > and generate().
> > > > > > >
> > > > > > > 
> > > > > > > If we assume we do need the class, then  we are to the second
> > > question,
> > > > > > > namely can I get it from APT without requiring reflection.   
> There
> > > may
> > > > > be a 
> > > > > > > way; we didn't know how to do it.
> > > > > > >
> > > > > > > We would need to get the APT to do the type introspection for
> us, or
> > > > > > > alternatively, force APT to compile the class for us.   We
> didn't 
> > > know
> > > > > how
> > > > > > > to do either of them.  But if there someone out there that knows
> how
> > > to
> > > > > > > solve this problem then the need for additional compile step
> goes 
> > > away.
> > > > > > >
> > > > > > >
> > > > > > > So to summarize:
> > > > > > >
> > > > > > >
> > > > > > > 1) It seems to me there are use cases where we do need to know 
> > > detail
> > > > > type
> > > > > > > information,
> > > > > > >  2) I don't know how I can get that information without having
> the
> > > > > classes
> > > > > > > compiled  and available on the classpath before running APT. 
> > > > > > >
> > > > > > > I think at one time there was another solution to the src/src-ws
> > > that
> > > > > may be
> > > > > > > a good transparent alternative to the current src/src-ws model. 
> If 
> > > JWS
> > > > > > > files and types files are all in the same source directory,
> wouldn't
> > > a
> > > > > Java
> > > > > > > compile followed by APT compile of the source code satisfy all
> the 
> > > > > issues?
> > > > > > > Meaning we wont need src/src-ws separation and the additional
> steps
> > > are
> > > > > > > abstracted out in ANT macros.
> > > > > > >
> > > > > > > >   IMHO, we should be making progress toward getting WSM
> structured
> > > > > > > > well to pass the TCK and to have a firm foundation upon which
> to
> > > add
> > > > > > > 
> > > > > > >
> > > > > > >
> > > > > > > As far as passing TCK, I don't believe the current
> implementation
> > > would
> > > > > have
> > > > > > > problems in annotation processing.  We have been running this
> system 
> > > for
> > > > > a
> > > > > > > while and I am not aware of any issues with the annotation
> > > processing.
> > > > > > > Sure, TCK may find a problem here to there, but I don't think
> there 
> > > is
> > > > > > > anything in the current annotation processing model that would
> > > prevent
> > > > > us
> > > > > > > from passing TCK.
> > > > > > >
> > > > > > > 
> > > > > > > > new features.  Some of these features could include:
> > > > > > > >
> > > > > > >
> > > > > > > > - validating metadata and building the WSM model from
> reflection 
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > This is the functionality was in the Alpha release of the WSM, 
> the
> > > IOC
> > > > > > > model was definitely designed so that this would be possible. 
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > - support for Axis-specific security annotations
> > > > > > > > - providing extensibility models for code generation to
> perhaps 
> > > > > > > > support JAX-WS (etc)
> > > > > > > > - and so on...
> > > > > > >
> > > > > > >
> > > > > > >  I believe the features you have listed are all possible and 
> > > straight
> > > > > > > forward with the current system.
> > > > > > >
> > > > > > > In particular let me talk to the JAX-WS that you mentioned. 
> Chapter
> > > 8
> > > > > in 
> > > > > > > the Jsr 181 specification describes the mapping between the
> JSR181
> > > and
> > > > > 109
> > > > > > > specification artifacts.
> > > > > > >
> > > > > > > With the current implementation I think you can do this by a) 
> > > extending
> > > > > our
> > > > > > > WSM Apt processor, or alternatively  b) by writing a standalone
> tool
> > > > > that
> > > > > > > converts the object model to 109 artifacts.  I would recommend
> the 
> > > > > second
> > > > > > > approach because:
> > > > > > >
> > > > > > >
> > > > > > > a) The tool would be more universal as it would only require
> class 
> > > > > files.
> > > > > > >  b) we also need to generate the WSDL, this would require the
> Axis
> > > run
> > > > > time
> > > > > > > (as we do in test cases), which even though do-able, would be
> rather 
> > > > > strange
> > > > > > > to run Axis runtime inside APT.
> > > > > > >
> > > > > > > But if you really like to do the 109 artifacts in APT, you can
> still
> > > do 
> > > > > this
> > > > > > > by sub classing the WSM annotation processor and overwrite the
> > > > > generate()
> > > > > > > method.  The generate() method can take advantage of the model
> that 
> > > is
> > > > > > > created in check().  Why would either of these solutions be
> > > problematic?
> > > > > > >
> > > > > > >
> > > > > > > Having said that, we all know that open source is about the
> constant 
> > > > > > > evolution of the code.   I am all for that as long as we are not
> > > losing
> > > > > > > functionality.
> > > > > > >
> > > > > > >
> > > > > > > As I pointed out in my previous posting, looking at our APT 
> > > processing
> > > > > and
> > > > > > > the Sun's model (in documentation and their apis) my main
> concern is
> > > > > that we
> > > > > > > are not based on the Visitor pattern.      So if we are changing
> the 
> > > > > > > processing model, I think we should make sure this is inline
> with
> > > the
> > > > > Sun's
> > > > > > > model (or at least a good reason why it should not be done as
> > > Visitors)
> > > > > > > while keeping the two phase annotation, and APT agnostic
> factories.
> > > > > > >
> > > > > > >
> > > > > > >  Daryoush
> > > > > > > 
> > > > > > >
> > > > > > > On 6/23/05, Eddie ONeil < ekoneil@gmail.com> wrote:
> > > > > > > > Daryoush--
> > > > > > > > 
> > > > > > > >   Hm.  I sort of disagree with the characterization that the
> > > current
> > > > > > >  > implementation is Mirror/Reflection agnostic.  The WSM
> annotation
> > > > > > > > processor uses the JavaTypeInfo interface and MirrorTypeInfo 
> > > > > > > > implementation (and the related classes) in an attempt to
> achieve
> > > this
> > > > > > >  > agnosticism.
> > > > > > > >
> > > > > > > >   But, these Java*Info classes use java.lang.Class instances
> for
> > > both
> > > > > > > > parameter types and method return types.  This is problematic
> > > given a
> > > > > > > > project structured as:
> > > > > > > > 
> > > > > > > > src/
> > > > > > > >     AccountService.java (an annotated web service)
> > > > > > > >     Account.java            (a complex type returned by some
> web
> > > > > service
> > > > > > > method)
> > > > > > > >
> > > > > > > > This project won't currently build with the WSM annotation 
> > > processor
> > > > > > > > which  can only handle Account.java as .class file meaning
> that
> > > must
> > > > > > > > be compiled first.  Ultimately, this means that the annotation
> > > > > > > > processor does not cleanly separate Mirror and Reflection and
> that
> > > the
> > > > > > > > project structure must be:
> > > > > > > >
> > > > > > > > src/ 
> > > > > > > >     Account.java
> > > > > > > > src-ws/
> > > > > > > >     AccountService.java
> > > > > > > >
> > > > > > >  > where src/ builds first in order to make .class files
> available 
> > > for
> > > > > > > > the annotation processing.  Were there a way to use *just*
> Mirror,
> > > the
> > > > > > > > first project model would be buildable and the Java*Info
> > > interfaces 
> > > > > > > > would return TypeDeclarations instead of Class types for
> method
> > > > > > > > signature metadata.
> > > > > > > >
> > > > > > > >   Fortunately, I don't think we're very far away from fixing
> this 
> > > > > > > > problem and cleaning up the build-time part of WSM, and
> neither
> > > the
> > > > > > > > Java*Info nor the Mirror*Info classes are even needed.  :)
> > > > > > > > 
> > > > > > > >   WSM currently has the following:
> > > > > > > >
> > > > > > > > - BeehiveWs* abstract classes -- thees build up the model of a
> web
> > > > > service 
> > > > > > > > - Default*Impl classes -- these extend and fully implement the
> > > > > > > > BeehiveWs* base classes
> > > > > > > > - Jsr181*Impl classes -- these extend the Default*Impl classes
> and 
> > > > > > > > have constructors that act as 1) annotation checkers and 2)
> model
> > > > > > > > factories
> > > > > > > >
> > > > > > > > If WSM was to break the Jsr181*Impl classes into two pieces --
> > > > > > > > annotation checking and model factories, I think we'd achieve
> the
> > > > > > > > goals proposed in a previous mail about loosely coupling the
> > > > > > > > annotation checking, model construction, and model objects. 
> And, 
> > > > > > >  > because the model construction just works on a
> TypeDeclaration or
> > > a
> > > > > > > > Class, the Java*Info/Mirror*Info layer isn't needed.
> > > > > > > > 
> > > > > > > >   As far as supporting both Mirror and Reflection, the latter
> > > could be
> > > > > > > > an interesting thing to do longer term, but I don't think we
> have
> > > a 
> > > > > > > > use case for this today.  Correct?  That being said, the model
> > > objects
> > > > > > > > could be constructed from reflection data simply by writing a
> new
> > > > > > > > model factory. 
> > > > > > > >
> > > > > > > >   IMHO, we should be making progress toward getting WSM
> structured
> > > > > > > > well to pass the TCK and to have a firm foundation upon which
> to 
> > > add
> > > > > > > > new features.  Some of these features could include:
> > > > > > > >
> > > > > > > > - validating metadata and building the WSM model from
> reflection 
> > > > > > > > - support for Axis-specific security annotations
> > > > > > > > - providing extensibility models for code generation to
> perhaps
> > > > > > > > support JAX-WS (etc) 
> > > > > > > > - and so on...
> > > > > > > >
> > > > > > > >   Thoughts on any of this?
> > > > > > > >
> > > > > > > > Eddie
> > > > > > > > 
> > > > > > > > ps -- as far as supporting XDoclet / Javadoc style metadata,
> that
> > > > > > > > would be possible if there was a set of APIs similar to
> Mirror's
> > > > > > > > TypeDeclaration interface that can be backed by both a Mirror
> and 
> > > > > > > > XDoclet implementation.  JPF has something similar to this in
> its
> > > > > > > > compiler layer.  Then, the JSR 181 annotation checker can be
> > > written
> > > > > > > > to work against this abstraction to support both Java 5 and 
> > > Javadoc
> > > > > > > > based metadata.  My $0.02 there.  :)
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On 6/22/05, Daryoush Mehrtash < dmehrtash@gmail.com> wrote:
> > > > > > > > > I agree with Eddie, that .ser file is an orthogonal issue. 
> We
> > > need
> > > > > to
> > > > > > > > > start a new thread on it to evaluate the merits of the .ser
> file 
> > > for
> > > > > > > > > the run time.
> > > > > > > > >
> > > > > > > > > I think one useful feature in the current implementation is
> that
> > > the
> > > > > > > > > model creation process is APT/Reflection agnostic
> (potentially
> > > we
> > > > > can
> > > > > > > > > even get annotation from as xdoclets also).   I think we
> should 
> > > > > > > > > preserve this feature. Meaning I can build the model form 
> APT
> > > or
> > > > > > > > > Reflection and share common code in defaults and rule
> checking.
> > > > > > > > > 
> > > > > > > > > There is a concern Eddie's post as to why we are generating
> an
> > > > > > > > > artifact in the check() phase (.ser file) as oppose to the
> > > > > generate(). 
> > > > > > > > >  I think this is done because a) to perform the validation
> you
> > > need
> > > > > > > > > the model,  b) the model can be used by a sub class of the
> WSM
> > > > > > > > > annotation processor to do additional check() and
> generate(). 
> > > For
> > > > > > > > > instance you can sub class the WSM annotation processor and
> > > generate
> > > > > > > > > 109 artifact knowing that the base class has created the
> model 
> > > at
> > > > > > > > > check().
> > > > > > > > >
> > > > > > > > > As far as I am concern, if we can make the changes in the
> APT
> > > > > package 
> > > > > > > > > that would preserve the agnostic Reflection/APT behavior of
> the
> > > > > model,
> > > > > > > > > and improves the code structure I am all for that.  It would
> be 
> > > nice
> > > > > > > > > if we can get some code on this to compare the two
> > > implementations.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On that note,  I have started looking at the APT  processing
> > > model
> > > > > > > > > that Sun seems to be promoting, namely using Visitors,  see
> "A
> > > > > Simple
> > > > > > > > > Sample Annotation Processor" section in 
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> http://java.sun.com/j2se/1.5.0/docs/guide/apt/GettingStarted.html
> > > > > > > > >
> > > > > > > > > My expectation is that the Visitor model would be the
> preferred
> > > > > model
> > > > > > > > > for others to extend the annotation processor.  It seems to
> me 
> > > our
> > > > > > > > > changes should somehow marry the Visitor model into the
> > > > > check/generate
> > > > > > > > > model of the two phase  Annotation processing. 
> > > > > > > > >
> > > > > > > > > I know we don't use the Visitor pattern in WSM, may be I
> missed
> > > > > > > > > something, but I don't see us using the Visitor Pattern in
> the 
> > > other
> > > > > > > > > APT (NetUI and Controls)  processors either.   If we want to
> > > rework
> > > > > > > > > the APT processor shouldn't we look closer at the Sun's
> model? 
> > > > > > > > >
> > > > > > > > > >   As a holistic solution to all of the above, it seems
> like
> > > there
> > > > > are
> > > > > > > > > > four components that participate in the end-to-end WSM 
> > > annotation
> > > > > > > > > > processing:
> > > > > > > > > >
> > > > > > > > > > 1) a Jsr181AnnotationChecker -- just validates annotations
> > > > > > > > > > 2) model objects (a la the BeehiveWs* classes today)
> > > implemented
> > > > > as
> > > > > > > > > > JavaBeans
> > > > > > > > > > 3) a factory layer used to create instances of the model 
> > > objects
> > > > > > > > > > 4) a generation abstraction.  In today's use case, this
> would
> > > > > create
> > > > > > > > > > the .ser file from the model objects in (2) 
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > As part of patch that gave to  Beehive-801 I think we have
> > > separated
> > > > > > > > > the model and annotation checking.  Eddie has a good point
> about 
> > > the
> > > > > > > > > builder being done in the constructor of the JSR181 classes,
> A
> > > > > factory
> > > > > > > > > layer might be more appropriate.
> > > > > > > > > 
> > > > > > > > > I would just be concern that we need to keep the
> Reflection/APT
> > > > > > > > > agnostic.  Also that validation is not on just in individual
> > > > > > > > > annotation rather it is across annotations, JWS class 
> > > information,
> > > > > > > > > service endpoint interface, types that are used in the
> service,
> > > and
> > > > > > > > > WSDL file.  So the annotation checker would need model and
> host 
> > > of
> > > > > > > > > other information for it to do the validation.
> > > > > > > > >
> > > > > > > > > My suggestion is that if we are going down this lets route
> make 
> > > the
> > > > > > > > > new  factory and the validation "layer" as Visitors.  Also
> lets
> > > do
> > > > > > > > > some prototypes and see how we can improve the APT
> processing. 
> > > > > > > > >
> > > > > > > > > Daryoush
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On 6/17/05, Rich Feit < richfeit@gmail.com> wrote:
> > > > > > > > > > I think this is a good summary/breakdown of the issues,
> and
> > > for my
> > > > > > > part, 
> > > > > > > > > > I agree with the responsibilities of the annotation
> processor
> > > (vs.
> > > > > the
> > > > > > > > > > runtime) that you've laid out here, as well as where the
> right 
> > > > > plug
> > > > > > > > > > points would live for supporting deployment to JAX-RPC,
> etc.
> > > > > > > > > >
> > > > > > > > > > Rich
> > > > > > > > > >
> > > > > > > > > > Eddie ONeil wrote:
> > > > > > > > > >
> > > > > > > > > > >  I think two issues are being mixed here -- annotation 
> > > > > processing
> > > > > > > and
> > > > > > > > > > >the .ser files.  IMHO, these two are orthogonal.  Here's
> why:
> > > > > > > > > > >
> > > > > > > > > > >  The purpose of an annotation processors is twofold:
> > > > > > > > > > >
> > > > > > > > > > >1) perform build-time checking of annotations (this is
> the 
> > > > > "check"
> > > > > > > phase)
> > > > > > > > > > >2) provide an opportunity to generate additional
> information
> > > / do
> > > > > > > work 
> > > > > > > > > > >based on the annotations.  This could include generating
> Java
> > > > > > > sources,
> > > > > > > > > > >deployment descriptors, XML files, etc (this is the 
> > > "generate"
> > > > > phase)
> > > > > > > > > > >
> > > > > > > > > > >  A generic JSR 181 annotation processor might include
> these
> > > > > steps: 
> > > > > > > > > > >
> > > > > > > > > > >1) check the JSR 181 annotations
> > > > > > > > > > >2) create a model representing valid annotations 
> > > > > > > > > > >3) do some generation to support a web service deployment
> > > > > environment
> > > > > > > > > > >
> > > > > > > > > > >Mapping this to the current WSM implementation, steps 1
> and 2 
> > > are
> > > > > > > > > > >performed inside of a Jsr181TypeMetadataImpl constructor,
> and
> > > > > step 3
> > > > > > > > > > >is performed at the end of the "check" phase and produces
> the 
> > > > > .ser
> > > > > > > > > > >file, which is a serialized Jsr181TypeMetadataImpl.  The
> > > latter
> > > > > steps
> > > > > > > > > > >is necessary because the Axis + WSM implementation of the
> web 
> > > > > > > > > > >service's deployment environment uses the .ser to create
> a
> > > > > > > > > > >SOAPService.
> > > > > > > > > > >
> > > > > > > > > > >  The point here is that step (3) above might be
> different 
> > > > > depending
> > > > > > > > > > >on whether one is targeting Axis, JAX-RPC, etc.  For
> example,
> > > > > check
> > > > > > > > > > >out this article about JAX-RPC 2.0 and specifically step
> (2)
> > > of
> > > > > the
> > > > > > > > > > >development process which talks about generating a WSDL
> from
> > > the
> > > > > > > > > > >annotated Java file: 
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > >
> > > http://www.artima.com/lejava/articles/threeminutes.html
> > > > > > > > > > >
> > > > > > > > > > >In this case, the "generate" step of annotation
> processing
> > > might
> > > > > > > > > > >produce the WSDL (among other stuff) and not the ".ser"
> file. 
> > > > > So, as
> > > > > > > > > > >step (3) varies, the need for a .ser file seems like it
> would
> > > > > also
> > > > > > > > > > >vary.  If the web service runtime doesn't require the
> .ser 
> > > file,
> > > > > > > > > > >there's no need to produce it.  That's why I called .ser
> > > files an
> > > > > > > > > > >implementation detail of using Axis as a web service
> runtime 
> > > and
> > > > > for
> > > > > > > > > > >this reason that it seems like annotation (metadata)
> > > processing
> > > > > and
> > > > > > > > > > >the .ser file are orthogonal since the ".ser" file is 
> > > optional
> > > > > but
> > > > > > > JSR
> > > > > > > > > > >181 annotation checking isn't.
> > > > > > > > > > >
> > > > > > > > > > >  :) 
> > > > > > > > > > >
> > > > > > > > > > >  Before going on here, I want to make clear that the
> > > user-model
> > > > > for
> > > > > > > > > > >authoring JSR 181 based web services used on Axis is
> *great* 
> > > --
> > > > > > > build,
> > > > > > > > > > >deploy, run, and any suggestions below are not meant to
> > > change
> > > > > this
> > > > > > > > > > >model in any way.  And, features such as XMLBean handling
> and 
> > > the
> > > > > > > > > > >"from WSDL" case are not affected.  In fact, hopefully
> they
> > > can
> > > > > > > > > > >enhance it by providing an easier way of doing drop-in 
> > > annotation
> > > > > > > > > > >checking / deployment if there is interest in that. 
> So...
> > > > > > > > > > >
> > > > > > > > > > >  To address your points about annotation processing vs. 
> > > > > reflection,
> > > > > > > > > > >it should be possible to create a JSR 181 annotation
> checker
> > > that
> > > > > can
> > > > > > > > > > >work on type metadata that comes from Mirror (via APT) or
> > > from
> > > > > > > > > > >reflection.  This would be a matter of implementing an
> > > annotation
> > > > > > > > > > >checker that can operation on a set of type abstraction 
> > > classes
> > > > > that
> > > > > > > > > > >can be backed by Mirror or reflection.  The Page Flow
> > > compiler
> > > > > has a
> > > > > > > > > > >layer similar to this today -- see: 
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > >
> > > > >
> > >
> trunk/netui/src/compiler-core/org/apache/beehive/netui/compiler/typesystem/...
> > > > > > > > > > >
> > > > > > > > > > >While not a trivial amount of code, it's not
> significantly
> > > > > > > complicated
> > > > > > > > > > >either.  Using such a layer, the JSR 181 checker can be 
> > > > > implemented
> > > > > > > to
> > > > > > > > > > >handle either Mirror, reflection, or some other arbitrary
> > > > > > > > > > >implementation of the TypeDeclaration-style APIs used by
> the 
> > > JPF
> > > > > > > > > > >compiler.  I think that this would facilitate your #2 and
> #3
> > > > > models
> > > > > > > > > > >for building web services.
> > > > > > > > > > >
> > > > > > > > > > >  As a holistic solution to all of the above, it seems
> like
> > > there
> > > > > are
> > > > > > > > > > >four components that participate in the end-to-end WSM 
> > > annotation
> > > > > > > > > > >processing:
> > > > > > > > > > >
> > > > > > > > > > >1) a Jsr181AnnotationChecker -- just validates
> annotations 
> > > > > > > > > > >2) model objects (a la the BeehiveWs* classes today)
> > > implemented
> > > > > as
> > > > > > > JavaBeans
> > > > > > > > > > >3) a factory layer used to create instances of the model 
> > > objects
> > > > > > > > > > >4) a generation abstraction.  In today's use case, this
> would
> > > > > create
> > > > > > > > > > >the .ser file from the model objects in (2) 
> > > > > > > > > > >
> > > > > > > > > > >  The resulting framework would give WSM more flexibility
> to
> > > be
> > > > > > > > > > >generally tested and to be extended by varying 
> > > implementations of
> > > > > the
> > > > > > > > > > >above participants.  And, the "from WSDL" case is handled
> by
> > > > > building
> > > > > > > > > > >a different factory (3) to provide the model in (2).  The
> > > parts
> > > > > above
> > > > > > > > > > >could be used to allow for:
> > > > > > > > > > >
> > > > > > > > > > >- plugging in additional annotations to support web
> service 
> > > > > runtime
> > > > > > > > > > >specific features such as security, buffering, etc
> > > > > > > > > > >- building a reflection-based Axis runtime for WSM that
> skips 
> > > the
> > > > > > > > > > >build-time step
> > > > > > > > > > >
> > > > > > > > > > >And so on.
> > > > > > > > > > > 
> > > > > > > > > > >  Finally, on the point about the use of build-time
> checks,
> > > when
> > > > > > > using
> > > > > > > > > > >the annotation processor (to check annotations or some
> other 
> > > > > metadata
> > > > > > > > > > >format), if the annotation checking fails the build fails
> and
> > > no
> > > > > > > > > > >.class files are produced.  If the build succeeds and 
> > > produces
> > > > > > > > > > >classes, presumably the annotations are correct.  It
> doesn't
> > > seem
> > > > > > > that
> > > > > > > > > > >WSM suffers from any more problems of possibly missing or
> > > invalid
> > > > > > > > > > >classes than any other Java enterprise application.
> > > > > > > > > > >
> > > > > > > > > > >  It's a long winded explanation to the annotation
> processor 
> > > /
> > > > > .ser
> > > > > > > > > > >questions.  If you've kept reading this long, thanks!
> > > > > > > > > > >
> > > > > > > > > > >  Hope it was helpful.  :) 
> > > > > > > > > > >
> > > > > > > > > > >Eddie
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >On 6/16/05, Daryoush Mehrtash <dmehrtash@gmail.com>
> wrote:
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > >  > > > >>>  For example, if the WSM annotation processor
> produced a
> > > JSR
> > > > > 101
> > > > > > > /
> > > > > > > > > > >>>109 deployable unit (or the source files / descriptors
> for
> > > such
> > > > > a 
> > > > > > > > > > >>>unit), it might include enough information that the
> .ser
> > > file
> > > > > > > wouldn't
> > > > > > > > > > >>>be needed.  In this case, Beehive WSM only runs at
> build 
> > > time
> > > > > and
> > > > > > > > > > >>>doesn't have a runtime component.
> > > > > > > > > > >>>
> > > > > > > > > > >>> 
> > > > > > > > > > >>In the ".ser" mode of thinking the deployment descriptor
> for
> > > > > say
> > > > > > > 109
> > > > > > > > > > >>would be generated from the .ser file.  The  idea is
> that 
> > > 109
> > > > > > > > > > >>translator would not have to worry about any of the
> > > validation
> > > > > and
> > > > > > > > > > >>defaults, it has a valid .ser file that it can work off.
>   I 
> > > am
> > > > > not
> > > > > > > > > > >>sure where the spec is going on this, but it seems to me
> > > once
> > > > > you
> > > > > > > have
> > > > > > > > > > >>annotations the idea of 109 descriptor is  rather
> obsolete. 
> > > You
> > > > > > > would
> > > > > > > > > > >> think the container can figure most (if not all) of the
> > > > > information
> > > > > > > > > > >>from the annotations that are in the class files. 
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >>I see  your concern, and far as WSM is concern, my
> personal
> > > view 
> > > > > is
> > > > > > > > > > >>that having a configuration file  (.ser) defeats the
> purpose
> > > of
> > > > > the
> > > > > > > > > > >>annotations.  I also feel that even if you do all the 
> > > validation
> > > > > at
> > > > > > > > > > >>build time, the classes that the run time sees may not
> be
> > > valid
> > > > > > > (e.g.
> > > > > > > > > > >>missing classes).  So even though you want the build
> time 
> > > > > validation
> > > > > > > > > > >>we can't avoid having the runtime validation.
> > > > > > > > > > >>
> > > > > > > > > > >>I think what is missing from the current system, or
> where we 
> > > > > went
> > > > > > > > > > >>wrong,  is that we dropped the ability to build the
> service
> > > > > model
> > > > > > > from
> > > > > > > > > > >>class files and started to only rely on the build time 
> > > > > artifacts.
> > > > > > > In
> > > > > > > > > > >>our Alpha (also in Beta I think) release of the WSM we
> only
> > > did
> > > > > the
> > > > > > > > > > >>runtime deployment from class files, and it all worked
> fine 
> > > > > (well
> > > > > > > > > > >>except the default parameter names).
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >> I see three ways of building the web service object
> model: 
> > > > > > > > > > >>
> > > > > > > > > > >>a)      from WSDL,
> > > > > > > > > > >>b)      from mirror events,
> > > > > > > > > > >>c)      from class files. 
> > > > > > > > > > >>
> > > > > > > > > > >>The (a) case would be used by the "from wsdl" use case
> in
> > > WSM
> > > > > and
> > > > > > > > > > >>service control.  (b) Would be used by IDEs or build 
> > > process,
> > > > > (c)
> > > > > > > > > > >>would be used by run time environments (also 109 type
> > > descriptor
> > > > > > > > > > >>generator tool that would run during the build process).
> > > The
> > > > > (b)
> > > > > > > and
> > > > > > > > > > >>(c) differ in the way the annotation information is
> > > collected
> > > > > from
> > > > > > > the 
> > > > > > > > > > >>files, but they both use the same underlying
> implementation
> > > to
> > > > > > > enforce
> > > > > > > > > > >>the Jsr 181 rules and defaults.  The (a) case would use
> a 
> > > > > different
> > > > > > > > > > >>implementation where XML-Java rules are enforced.
> > > > > > > > > > >>
> > > > > > > > > > >> 
> > > > > > > > > > >>Make snese?
> > > > > > > > > > >>
> > > > > > > > > > >>Daryoush
> > > > > > > > > > >> 
> > > > > > > > > > >>
> > > > > > > > > > >>On 6/16/05, Eddie ONeil < ekoneil@gmail.com> wrote:
> > > > > > > > > > >> 
> > > > > > > > > > >>
> > > > > > > > > > >>>  Sure...
> > > > > > > > > > >>>
> > > > > > > > > > >>>  So, today, the WSM annotation processor produces .ser
> > > files
> > > > > in
> > > > > > > order
> > > > > > > > > > >>>to allow a web service stack (Axis 1.2 today) to
> discover
> > > the
> > > > > > > formal 
> > > > > > > > > > >>>argument names of methods exposed as @WebMethod.
> > > > > > > > > > >>>
> > > > > > > > > > >>>  I was speculating -- which perhaps I shouldn't do :)
> -- 
> > > that
> > > > > if
> > > > > > > WSM
> > > > > > > > > > >>>were to target a web service technology in addition to
> Axis
> > > > > that
> > > > > > > the 
> > > > > > > > > > >>>.ser file wouldn't necessarily be needed.
> > > > > > > > > > >>>
> > > > > > > > > > >>>  For example, if the WSM annotation processor produced
> a 
> > > JSR
> > > > > 101 /
> > > > > > > > > > >>>109 deployable unit (or the source files / descriptors
> for
> > > such
> > > > > a
> > > > > > > > > > >>>unit), it might include enough information that the
> .ser 
> > > file
> > > > > > > wouldn't
> > > > > > > > > > >>>be needed.  In this case, Beehive WSM only runs at
> build
> > > time
> > > > > and
> > > > > > > > > > >>>doesn't have a runtime component. 
> > > > > > > > > > >>>
> > > > > > > > > > >>>  I agree that there is nothing Axis specific in the
> .ser
> > > file
> > > > > and
> > > > > > > was 
> > > > > > > > > > >>>just making the point that the .ser file might not be
> > > needed
> > > > > > > depending
> > > > > > > > > > >>>on how WSM is integrated into Axis or if / when WSM
> targets 
> > > > > > > additional
> > > > > > > > > > >>>web service stacks / standards.
> > > > > > > > > > >>>
> > > > > > > > > > >>>  I'm not a web service expert by any means (clearly!),
> but 
> > > it
> > > > > > > seems
> > > > > > > > > > >>>like generation / use of the .ser file should be a
> *choice*
> > > and
> > > > > not
> > > > > > > a 
> > > > > > > > > > >>>requirement.
> > > > > > > > > > >>>
> > > > > > > > > > >>>  Does that make more sense?
> > > > > > > > > > >>> 
> > > > > > > > > > >>>Eddie
> > > > > > > > > > >>>
> > > > > > > > > > >>>
> > > > > > > > > > >>> 
> > > > > > > > > > >>>
> > > > > > > > > > >>>On 6/16/05, Daryoush Mehrtash < dmehrtash@gmail.com>
> wrote:
> > > > > > > > > > >>>
> > > > > > > > > > >>>
> > > > > > > > > > >>>>Eddie in the previous thread you said:
> > > > > > > > > > >>>> 
> > > > > > > > > > >>>> The .ser file is an artifact of the fact that the
> > > services
> > > > > are
> > > > > > > > > > >>>>deployed on Axis. Were the annotation processor
> targeting 
> > > > > JAX-RPC
> > > > > > > > > > >>>>directly, the output of the annotation processor might
> not
> > > use
> > > > > the
> > > > > > > > > > >>>>.ser file. 
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>I am not sure I follow your point here. As I said in
> the 
> > > > > previous
> > > > > > > thread on
> > > > > > > > > > >>>>the .ser file, the original of this was to solve the
> > > parameter
> > > > > > > name default. 
> > > > > > > > > > >>>>We started off in WSM by deploying source and compile
> at
> > > > > runtime
> > > > > > > (similar to
> > > > > > > > > > >>>>the drop in deployment model in Axis), then evolved
> into 
> > > > > having
> > > > > > > seperate
> > > > > > > > > > >>>>build time and run time phases that deployed services
> by
> > > doing
> > > > > > > reflection on 
> > > > > > >  > > > >>>>.class files, to the current iteration that uses the
> .ser
> > > > > file
> > > > > > > which means
> > > > > > > > > > >>>>all the work is done at build time.. 
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>You have looked at the .ser file more closely
> recently,
> > > but
> > > > > AFAIK,
> > > > > > > there is 
> > > > > > > > > > >>>>nothing Axis specifc in it. It is essentially the 3rd
> > > > > itteration
> > > > > > > of the
> > > > > > > > > > >>>>model we are using to deploy services. It is true that
> our 
> > > > > Axis
> > > > > > > > > > >>>>implementation understands the .ser file, but if we
> were
> > > say
> > > > > to
> > > > > > > port the WSM
> > > > > > > > > > >>>>to XYZ stack, our apprach would be to write an
> extension 
> > > in
> > > > > the
> > > > > > > XYZ stack
> > > > > > > > > > >>>>that would understand the .ser file.
> > > > > > > > > > >>>> 
> > > > > > > > > > >>>>I don't follow what you mean when you say if we were
> > > > > "targeting
> > > > > > > JAX-RPC
> > > > > > > > > > >>>>directly....". Can you please be more specific here. 
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>-- 
> > > > > > > > > > >>>>Daryoush
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>Weblog:
> > > http://perlustration.blogspot.com/
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>--
> > > > > > > > > > >>Daryoush
> > > > > > > > > > >> 
> > > > > > > > > > >>Weblog:
> > > http://perlustration.blogspot.com/
> > > > > > > > > > >>
> > > > > > > > > > >> 
> > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Daryoush
> > > > > > > > >
> > > > > > > > > Weblog:  
> http://perlustration.blogspot.com/
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > > --
> > > > > > >
> > > > > > > Daryoush
> > > > > > >
> > > > > > > Weblog:  http://perlustration.blogspot.com/ 
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Daryoush
> > > > >
> > > > > Weblog:   http://perlustration.blogspot.com/
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > Daryoush
> > >
> > > Weblog:  http://perlustration.blogspot.com/
> > 
> 
> 
> 
> -- 
> 
> Daryoush
> 
> Weblog:  http://perlustration.blogspot.com/
Mime
View raw message