axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Ruby" <>
Subject Re: TypeMappings - lifecycles and locations
Date Sun, 10 Jun 2001 18:25:34 GMT
Glen Daniels wrote:
> This is an interesting tack to take, but I might toss it back by asking
> are we currently doing that makes a MessageContext expensive, and how can
> change that?" instead.

A few general comments - the changes I made in the past week were harder to
make than they needed to be.  Some of the things I would like to see
factored into future iterations:

1) "the bag-o-stuff" approach has several disadvantages.

   1) First, there is some key documentation about the behavior of a class
   that is missing - where an how you find the service registry is a prime

   2) It also means that essentially every property is public.  With no
   ability to intercept the behavior of getters and setters.

   3) It also increases the number of objects created during the processing
   of a request

2) there needs to be more of an attempt to separate out abstract classes
from concrete implementations.  Example: casting the result of a
getProperty to a DefaultServiceRegistry.  Previously, this was also done
with SOAPTypeMappingRegistry, but I have systematically been eliminating

3) The intended lifecycle of objects should also be captured.  I'd
personally like to see as many objects as we can either being (a) stateless
and sharable, or (b) serially reusable and pooled.

In the past, I have not been a great fan of UML diagrams, but I am starting
to see the value...

- Sam Ruby

View raw message