portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sami Leino" <sami.le...@netorek.fi>
Subject Re: [JETSPEED 2] Service framework progress
Date Mon, 16 Feb 2004 17:00:58 GMT
> What is your experience with Spring and how would it
> enable events + AOP around service invocation?  Why
> would you use Spring AOP?

Very little (see my previous posting). I have used my own component
framework so far, but this is the time when I need to decide if I continue
its development or adopt some other framework. Before I can make this
decision, I have to get a test-ride with the available candidates.

>> 4) Have you been able to set up a component
>> acquire/release policy already?
> Not explored at this point.  Some suggestions?

Well, most of the frameworks require you to always release the obtained
component, or to never release it. Those who only support lookup
operations without release limit the framework's applicability severely.
But if the framework always requires you to release, writing client code
will become tedious because of those try {} finally {} blocks.

I have considered this issue to some extent, but I haven't yet found a
good solution. Automatic releasing is problematic because you might put
the acquired object to a long lifecycly container such as HTTP session, so
it's hard to resolve if the instance could be released or not.

The current solution I utilize is to define two alternative lookup
signatures, get(String key) and getAndHold(String key). The first one will
only allow you to obtain components that need not to be released, and the
latter one will provide you with components that should be manually

I have defined two factory exception classes, FactoryException and
CheckedFactoryException. FactoryException is a subclass of
RuntimeException, so the client does not need to check it if she doesn't
want to.

In my solution, getAndHold(String key) throws a CheckedFactoryException.
This ensures that the client cannot obtain such a component without
writing the try{} finally{} block or propagating the exception further. On
the other hand, if the client tries to acquire a pooled component using
the get(String key) signature, a FactoryException will be thrown to inform
the client that the requested component is something that must be released

Since the FactoryException class extends RuntimeException, the client
doesn't need to catch it. Therefore, I can write methods like these ("Off"
stands for "Object Factory Framework"):

    public void doSomething()
        SomeSingletonComponent ssc =

    public void doSomethingElse()
        SomePooledComponent spc = null;

            spc = (SomePooledComponent)Off.getAndHold("/services/spc");

The following method, on the other hand, would result in FactoryException
to fall through to the upper layer:

    public void doSomethingIllegal()
        SomePooledComponent spc =

The drawback of this solution is that in order to use the first signature
(get(String key)), the client needs to make on assumption about the
configuration. I don't like it, but I haven't yet found a better way to
deal with it.

The ideal solution would be if there was some kind of automatic releasing
of acquired objects, but I'm not sure how it could be done without AOP.

I'm very interested in hearing your ideas concerning this problem.



Sami Leino
Software Developer
Netorek Oy

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

View raw message