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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
