You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Stephen McConnell <mc...@apache.org> on 2003/10/30 23:45:48 UTC
Re: Merging plan
Danny Angus wrote:
>Serge Knystautas wrote:
>
>>I'm still waiting for the Avalon containers to
>>stabilize basic server features like friendly configuration errors,
>>logging management, stuff like that, and am looking forward to the new
>>releases we'll get with 3.0.
>>
>
>Me too.
>
Harvesting user requirements concerning Avalon containment:
1. enhanced logging management
2. enhanced configuration error handling
3. remotely accessible services (e.g. via JNDI)
Anything else?
Steve.
--
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
Re: Merging plan
Posted by Stephen McConnell <mc...@apache.org>.
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
Re: Merging plan
Posted by Stephen McConnell <mc...@apache.org>.
Danny Angus wrote:
>Steve,
>
>echoing Serge..
>
>
>>>2. enhanced configuration error handling
>>>
>>No repeated stack trace dumps, and tying an error to the line number
>>(and column!) in the configuration file.
>>
>
>This has been a thron in our side for a while, it would be nice to have
>meaningful and concise errors from the container integrated intelligently
>with the errors from the app.
>
I agree. Just for reference - there is a testcase I have which
basically starts up a component and the component requests an attribute
from a configuration where attribute does not exist. There results are
not perfect - some imprevements are still needed - but to give you an
idea where things are today - here is the result of the logger information:
---- start of log ------------------------------------------------
[INFO ] (kernel): installing:
file:/${user.dir}/target/merlin-test-forced-error-1.0.jar
[INFO ] (test.hello): starting
Deployment failure.
---- report -------------------------------------------------------
Exception: org.apache.avalon.activation.appliance.DeploymentException
Message: Composite deployment failure in block: [block:/test]
Cause: org.apache.avalon.activation.lifecycle.LifecycleException
Message: Unable to create a new component instance in appliance
[/test/hello] due to a component deployment failure.
Cause: org.apache.avalon.activation.lifecycle.LifecycleException
Message: Component initiated startup failure.
Cause: org.apache.avalon.framework.configuration.ConfigurationException
Message: No attribute named "fred" is associated with the configuration
element "configuration" at null@<generated>null:
5:63
---- configuration ------------------------------------------------
location: <generated>null:5:63
<configuration/>
-------------------------------------------------------------------
It's the configuration exception message that I don't like
(null@<generated>null:5:63 is not terribly imformative)- but I have some
ideas on how we can resolve this.
>
>>>3. remotely accessible services (e.g. via JNDI)
>>>
>>This is more of a wish list (to me at least).
>>
>
>Me too, for now, but I strongly believe that remote services accessable via
>JNDI could be a massive advantage to James (caveat.. they have to be
>_reasonably_ simple to deploy and lookup, and to a lesser extent build and
>debug).
>It would also provide an alternative to EJB's for other existing and
>potential Avalon clients...
>
It will be.
Based on my own woprk in the area, I was able to achive remoting by
simply tagging a component class as a component to be remoted. E.g.
@avalon.remote protocol="iiop"
(combined with the assumption that the component developer is ensuring
that the component implementation is in fact remotable relative to the
protocol).
Also, in sandbox is an existing lifecycle extension that provides
(today) the ability to export component services using AltRMI. In
addition there is the potential for an Apache IIOP solution in the not
so distant future.
Steve.
>
>
>d.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>For additional commands, e-mail: server-dev-help@james.apache.org
>
>
>
--
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
RE: Merging plan
Posted by Danny Angus <da...@apache.org>.
Steve,
echoing Serge..
> > 2. enhanced configuration error handling
>
> No repeated stack trace dumps, and tying an error to the line number
> (and column!) in the configuration file.
This has been a thron in our side for a while, it would be nice to have
meaningful and concise errors from the container integrated intelligently
with the errors from the app.
>
> > 3. remotely accessible services (e.g. via JNDI)
>
> This is more of a wish list (to me at least).
Me too, for now, but I strongly believe that remote services accessable via
JNDI could be a massive advantage to James (caveat.. they have to be
_reasonably_ simple to deploy and lookup, and to a lesser extent build and
debug).
It would also provide an alternative to EJB's for other existing and
potential Avalon clients...
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Merging plan
Posted by Serge Knystautas <se...@lokitech.com>.
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.
> 2. enhanced configuration error handling
No repeated stack trace dumps, and tying an error to the line number
(and column!) in the configuration file.
> 3. remotely accessible services (e.g. via JNDI)
This is more of a wish list (to me at least).
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.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Merging plan
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > Possibly help for distribution, but I really want the spooler to be
> > that mechanism, and we cannot tie its interface to Avalon.
> I don't really follow the above with respect to the "spooler"
> and "mechamism" - sorry!
The services and pipleline are connected by a spooler. The spooler
interface needs to be portable. If the implementation of the spooler allows
clustering, which is a goal, then we can locate different parts of James on
different JVMs, connected via the spooler. That will probably not be
sufficient, since they will also want to be able to access MailetContext
information, repositories, etc., which we may want to share, but it is a key
piece.
JMS is one technology that we *might* be able to use to implement
distribution. Alternatively, one might use a shared database, a tuple-space
service, or ...
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Merging plan
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>>Harvesting user requirements concerning Avalon containment:
>>1. enhanced logging management
>>2. enhanced configuration error handling
>>3. remotely accessible services (e.g. via JNDI)
>>
>>
>
>JMX.
>
JMX support at the kernel level is already in place, support for
internal manager is in progress. and support for components follows.
There is some engineering in the kernel to be done to enable
container-side components (such as a JMX server or proxy, JMS adapter,
and other facilities that expand or replace container services).
>Possibly help for distribution, but I really want the spooler to be
>that mechanism, and we cannot tie its interface to Avalon.
>
I'm probably exposing an insufficient knowledge of James - but I don't
really follow the above with respect to the "spooler" and "mechamism" -
sorry!
>JMS *might* be a possibility.
>
There is already have a JMS lifecycle extension that is working today.
Components can declare a stage dependency and this gets resolved
automatically. The best person to ask about this is Aaron (over on
Avalon).
Steve.
>
>
> --- Noel
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>For additional commands, e-mail: server-dev-help@james.apache.org
>
>
>
>
--
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
RE: Merging plan
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Harvesting user requirements concerning Avalon containment:
> 1. enhanced logging management
> 2. enhanced configuration error handling
> 3. remotely accessible services (e.g. via JNDI)
JMX. Possibly help for distribution, but I really want the spooler to be
that mechanism, and we cannot tie its interface to Avalon. JMS *might* be a
possibility.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org