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 17:47:14 GMT
  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/
Mime
View raw message