Serge Knystautas wrote:
Steve,
As long as you're harvesting, just to clarify these... :)
Stephen McConnell wrote:
Harvesting user requirements concerning Avalon containment:
1. enhanced logging management
It seems you have very flexible logging configuration right now, but it is extremely challenging to use. In other servers I might have a rollover be one parameter to specify a file size or time period, I have to nest XML elements and determine a good naming.
Just for reference - the logging system you are using when runnning under Phoenix is the Excalibur Logging package. The Merlin container uses a much simpler logging sub-system which is missing stuff like rollover, etc. IMO there is a need to rework the Excalibur Logging directives (the way xml based configuration of the logging targets is handled), and also - enhance Excalibur Logging to better support system from runtime concerns (e.g. in Merlin you can dynamically introduce new containers and components and this in turn means that the logging substem has to handle more than just a static configuration). There is also the open questions concerning LogKit versus Log4j. If we use Excalibur Logging we are tied in part to LogKit for mainly legacy reasons. Personally I think it is work thinking about a clean cut container logging facility that provides similar level of functionality as Excalibur Logger - but independent of LogKit.
2. enhanced configuration error handling
No repeated stack trace dumps, and tying an error to the line number (and column!) in the configuration file.
There are lots of aspects on this one.
1. The configuration implementation class has to updated to track the "real" last element + a virtual paths. The 4.1.5 update on framework partially address this - but its not the final solution. Bottom line - there is some more work needed on this (not much) at the framework level.
2. Who is responsible? One of the problems your seeing is that application code is duping a log of an error, then throwing the error. The thrown error is captured by the container and logged again. Sorting this out is much more a case of knowing precicely what the container is going to provide - and adjusting logging statements by application so that an [ERROR] is posted (but without the stack trace). Leave the exception handling to the container.
3. Good exception reporting. The exception reporting in Phoenix is basically a muti-chain stack dump - which is not terribly useful. The exception reporting in Merlin is a massively more compact because you get a series of statements that summaries the causal exception, then a single stackdump related to the originating exception. With resolution of point (1), the Merlin error reporting can be improved even further.
3. remotely accessible services (e.g. via JNDI)
This is more of a wish list (to me at least).
You will get this anyway. There are several projects that are embedding Merlin inside things like web-apps and other applications. At least one of these needs to publish services that are established by Merlin via JNDI (the EVE LDAP project that's comming into incuabator).
I think the notion of automated/streamlined component testing is very interesting as I've found it very hard to work out how unit or functional tests would work for James. Maybe this is just a documentation need, and I have yet to read everything in the new website.
I love the new website - so much better than before.
There is a simplistic example of a testcase for a component at the following link:
http://avalon.apache.org/merlin/starting/advanced/unit/index.html
Stephen.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
