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:20:31 GMT
  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/
Mime
View raw message