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/ >
