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]
