axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Melgar" <>
Subject Re: [Architecture Improvement] Handler lifecycle events and undo()
Date Fri, 14 Dec 2001 19:45:12 GMT
I dont have a strong preference on which solution, doesnt seem like a
critical decision..

Overall comment on Axis: I would like to see the project come up with an
overall design/architecture, implement it and at least try to stick to it.
Can build upon it. But Axis often seems to change for the sake of changing.

In this example, a handler just needs to get to its deployment options.
Available in a constructor or init doesnt matter as long as it works and
stays reasonably stable.

I've seen many similar usages of an init() method, so that approach does
not seem unreasonable, just that its not implemented. I would prefer not to
have to do lazy init, its an unnecessary check for every invoke. It doesnt
seem any harder to have Axis invoke the init() method rather than remove

David Melgar
Web Services Toolkit Development
Emerging Technologies

Sam Ruby/Raleigh/IBM@IBMUS on 12/14/2001 02:28:33 PM

Please respond to

Subject:  Re: [Architecture Improvement] Handler lifecycle events and undo

David Melgar wrote:
> I attempted to use the init() method on a handler I wrote several months
> ago, but since it was not really implemented by Axis, I had to find
> way around the problem.
> Back then at least, options that were set during the deployment of the
> handler were not available in the constructor. The init() method would
> been a reasonable place for the handler to initialize itself based on its
> options.
> Since I couldnt do it in the constructor, and wasnt called if I put it in
> the init() method, I ended up maintaining an initialized state variable,
> lazy initialization. If I'm invoked() and havent been init() yet, I
> manually call the init method.

Ouch.  A workaround to a workaround to a workaround.  It shouldn't be this

There are several ways to read this.  For example, one way to read this is
that there is a valid need for init methods that isn't currently being
satisifed.  Another is that since init methods clearly don't work and
haven't for this long, there wouldn't be too many people affected by their

David, I'm interested in your opinion as to how you would prefer this to be

1) Is what you really would have thought would happen, and possibly would
even prefer, is for the deployment information to be available to the

2) Is the init method where you feel that this really should belong, and
that we should not only NOT remove it, but actively work to make it work?

3) Is the initialized state variable in retrospect the most straightforward
way to address this problem?

- Sam Ruby

View raw message