On Sun, 2 Sep 2001 06:19, Tom Bradford wrote:
> The next version of dbXML (1.5) will be ported from the Juggernaut
> server framework to Avalon. From a very high level, it looks like it
> should be fairly easy, but I was wondering if anybody has run into any
> gotchas porting between server frameworks.
A month or two back I went and ported all my remaining apps to Avalon or
Avalon/Phoenix and here were the issues I faced.
1. I used to access a lot of objects via singletons like
ChannelManager.getChannelManager() and this was painful to change.
2. I used to have my objects access their own dependents rather than letting
them get passed to it ... also I used to intermix "startup" code all through
my components and this took a while to reorganize into separate stages (ie
logger vs context vs config vs init)
3. I used to have components depend on each other (ie A depends on B which
depends on A) with specific startup ordering issues. I had to rework this by
creating extra interfaces. ie A could depend on B, but A could pass itself to
B via an interface. (See ConnectionManager in Cornerstone for a similar
arrangement). This was a minor but annoying change.
4. I manually implemented a Telnet management component for old code but this
had no equivelent in Avalon/Phoenix. The "proper" way to do this is via JMX
(see below) but in the meantime I left this in but it is relatively unsafe.
5. Modification of Configuration, Logging and Deployments not doable at
runtime (see below) but eventually this will be fixed.
6. Import names are soooo damn long ;)
7. In some cases the number of interfaces to implement is excessive. For
instance one object implemented Loggable, Contextualizable, Configurable,
Initialzable, Startable, Disposable. I fixed this by creating Animatable
interface that extends Initialzable, Startable, Disposable.
8. No way to depend on multiple components with same interface. ie I would
like Block A to depend on 1+ interfaces that implement Service Foo. To work
around this I had to add an extra "Director" block that linked together
blocks using mechanism similar to described in (3). This is a similar pattern
as seen in JAMES.
Many of those faults were due to me not writing the software the "right way"
the first time round. The others are in progress of being "fixed" in
Avalon/Phoenix at the moment.
The only unaddressed issue for my integration is (8) but I have yet to come
up with a good way of solving it. We have discussed it extensively in the
past but with no resolutions.
One other issue that you may come across though I haven't is the innability
for Blocks to be "optionally" loaded (or not). We may address this in the
future.
> My one concern is the configuration system. Avalon's configuration
> interfaces seem to be read-only, but our server needs to maintain its
> own configuration on disk. Are there additional interfaces in Avalon
> for managing 'writable' configurations?
At this current stage there are no writeable configurations. Changing that to
allow modification of Configuration would be relatively simple 10 line
addition to ConfigurationRepository.
The problem is that this is not accessible from normal Server Applications
because it exists inside Kernel ClassLoader. The proper way to "fix" this
problem is to make some of the interfaces in the kernel
(ConfigurationRepository, Application, Deployer, Embeddor) accessible from
outside kernel by exporting it via some managment interface (preferrably JMX).
This is a big TODO but I don't really understand JMX enough to do it yet ...
and I don't need it in any of my apps. It will be done sometime ... if it
ends up holding you up drop us a note and I will try to have a go at it ;)
In the meantime you can continue to use your own Configuration interface to
minimize changes.
> Also, is Tomcat 4 running on top of Avalon? I had heard rumblings to
> this degree, but can't confirm it from looking at the distro.
Nope. Maybe the next Tomcat but not the current one.
--
Cheers,
Pete
--------------------------------
My opinions may have changed,
but not the fact that I am right
--------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
