beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eddie ONeil <ekon...@gmail.com>
Subject Re: changes in wsm
Date Thu, 09 Jun 2005 15:29:10 GMT
  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 <dmehrtas@bea.com> 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:ekoneil@gmail.com]
> > Sent: Tuesday, June 07, 2005 9:38 AM
> > To: Beehive Developers
> > Cc: davanum@gmail.com
> > 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.
> 
> 
>

Mime
View raw message