beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eddie ONeil <ekon...@gmail.com>
Subject Re: [heads up] rearranging wsm/src -- was: Re: changes in wsm
Date Tue, 14 Jun 2005 22:47:09 GMT
  This is complete with SVN 190664 and the wiki has been updated to
reflect the new wsm/ project source paths.

  Let me know if you've got questions or see problems.

Eddie


On 6/13/05, Eddie ONeil <ekoneil@gmail.com> wrote:
>   Yes, your assumption about the src/axis directory is correct.
> 
>   The same thing should happen with the DRTs.  Just haven't done that
> yet, but thanks for reminding me.
> 
>   :)
> 
> Eddie
> 
> On 6/13/05, Daryoush Mehrtash <dmehrtas@bea.com> wrote:
> > 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