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 Thu, 23 Jun 2005 14:57:20 GMT
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/
>

Mime
View raw message