All-- I've been taking a look through the WSM code in the last few days and suggest that we fix a few issues that exist in the code base which are listed below.
If anyone disagrees with any of this work / wants to help (which would be great!), let me know and we'll address / coordinate. Eddie ::::: Issues: - the role of the .ser file seems to be to preserve a metadata shape that was computed from the JWS file itself. Since this file available at both build and run time, it seems to make sense to recompute (once!) at runtime so that the .ser files aren't necessary. But, I don't have the historical background here -- Dims, Ias, Daryoush, can you provide some background here? Is the .ser file really needed or can the same data be calculated at runtime when a service is wired-up in Axis? - tight coupling between the build-time and run-time classes. The result is that the build-time is not correctly coupled to Sun's Mirror APIs for annotation processing. And, the runtime code is coupled to some annotation processing classes such as AnnotationProcessorEnvironment. The fix is to rearrange some classes to provide a clean separation between the build time and runtime artifacts; given the current architecture, there will still be shared code but it will (hopefully!) simply consist of JavaBeans. Part of this fix could ultimately lead to a couple of new JARs: beehive-wsm-compiler.jar beehive-wsm-ant.jar Part of this would fix JIRA 752. - the classloaders used to load resources are generally *not* the context classloader. The fix is to switch classloading of resources to Thread.currentThread().getContextClassLoader() - lots of exception handlers do no logging, and some catch Throwable. The fix would be to add commons-logging based messages and catches for Exception or specific Exception types where applicable - switch off of direct use of Log4J for logging and onto commons-logging - many classes expose protected or package protected fields. The fix would be to convert to private fields where possible. - remove the unused classes HandlerHandler, AxisTypeRegistrar, AxisTypeMappingUtil, DebugPrintMessageHandler, WSDLProcessor, InvalidFileType, XmlBeanTypeMappingUtil, Questions: - does anyone know the status of XMLBean type handling in WSM? - does anyone know the status of security integration in WSM? Seems that this was removed from the JSR 181 spec 0.9.2; given that it's not used anywhere, should we remove it until after we've passed the TCK? Could definitely make sense to re-add Axis-specific Java 5 annotations once WSM is stable.