Great; I'm starting to dig in on a bunch of this stuff now. Would love HELP here -- if you're interested in taking a chunk here, please say so and commit / send patches.
:) Eddie On 6/8/05, Daryoush Mehrtash <[EMAIL PROTECTED]> wrote: > 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. > > >
