[heads up] rearranging wsm/src -- was: Re: changes in wsm

[Eddie ONeil <ek...@gmail.com>]

  I'm about to start re-arranging the src/wsm/* directories so that
we've got this structure:

  wsm/src/
            api/
            core/
            axis/

where the dependencies are axis -> core -> api.  This isn't quite the
end of the restructuring -- we probably need a beehive-wsm-ant.jar a
la axis-ant.jar, but I'm not working on that yet.

  Should be done by tomorrow.  Let me know if anyone has concerns about this.

Thanks!

Eddie


On 6/9/05, Eddie ONeil <ek...@gmail.com> wrote:
>   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 <dm...@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.
> >
> >
> >
>