james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Merging plan
Date Thu, 30 Oct 2003 23:45:13 GMT


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:mcconnell@apache.org




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


Mime
View raw message