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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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/
