beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daryoush Mehrtash" <dmehr...@bea.com>
Subject RE: [heads up] rearranging wsm/src -- was: Re: changes in wsm
Date Tue, 14 Jun 2005 01:23:07 GMT
I am assuming that you are planning to move the
src/runtime/org/apache/beehive/wsm/axis to the wsm/src and call it axis,
and then rename the runtime to core. Correct?

Were you thinking about doing the same for the DRTs also, they have axis
and core components also which right now is organized similar to the
src.

daryoush 

> -----Original Message-----
> From: Eddie ONeil [mailto:ekoneil@gmail.com]
> Sent: Monday, June 13, 2005 2:44 PM
> To: Beehive Developers
> Subject: [heads up] rearranging wsm/src -- was: Re: changes in wsm
> 
>   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 <ekoneil@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 <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.
> > >
> > >
> > >
> >


--------------------------------------------------------------------------------

Join CEO Alfred Chuang and CTO Mark Carges on June 15 for a unique online 
event, giving you the first look at a new category of enterprise software 
built specifically for Service-Oriented Architecture (SOA).

Register Now.  It's Free!

http://www.bea.com/events/june15

Mime
View raw message