I agree with the following items. I think the others need more discussion. It would be better to start a new thread for the other issues to reach closure on them independently, Unless there is an objection to it, I will start them later today.
> - 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. Agree. > - the classloaders used to load resources are generally *not* the > context classloader. The fix is to switch classloading of resources > to Thread.currentThread().getContextClassLoader() > Agree > - 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 > Agree. > - switch off of direct use of Log4J for logging and onto commons-logging > Agree. > - many classes expose protected or package protected fields. The fix > would be to convert to private fields where possible. Agree. Daryoush > -----Original Message----- > From: Eddie ONeil [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 07, 2005 9:38 AM > To: Beehive Developers > Cc: [EMAIL PROTECTED] > Subject: changes in wsm > > 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.
