Stephen McConnell wrote:
Noel J. Bergman wrote:
Stephen,
His message was archived at
<snip note="got that replied etc."/>
As I understand it from your previous notes, Merlin is primarily short in
the area of log configuration?
Noel:
Just a note - the text in my reply assumed that you said "Merlin is primarily short in the area of lo[n]g configuration[s]" - ok - its late and that's the excuse I'm sticking with!
:-)
Cheers, Steve.
It's the reverse - well almost. The reverse would suggest that Merlin is long in the area of short configurations which doesn't really man anything to me. It just simpler to say that merlin is what you want it to be for whatever your configuration requirements are. Phoenix style "put it all together solution" - no problem (except that it doesn't scale). Merlin style - break out the different logical usage abstractions and package them accordingly - and your starting to move towards something scalable.
Is that the primary Phoenix ability that James uses and Merlin lacks?
This is sort of like asking someone is they has stopped beating their wife! In effect - there are no primary Phoenix abilities that James uses and Merlin lacks. Primary Phoenix abilities leveraged by James related to reliable server deployment - with a system focus. Merlin will provide probably a higher level of deployment relability, but less frills at that system level of abstraction (e.g. you don't have the JMX and logging options currently available in Phonenix at this time) - but you do have more frills on finner grain abstractions such as ... component reuse.
Is that right?
If you can reformulate the question I'll try and give you an answer.
;-)
Or does running James on Merlin involve more changes?
Running James on Merlin means:
1. massive simplification of the system configuration 2. greater reliability during deployment 3. better error handling 4. ability to reuse James with other components 5. simplification of the development process 6. development time testing and validation of deployment 7. all expences paid trips to Paris for select individuals 8. fun and excitement you only dreamed about
As for the exception reporting, I'm not a fan of the System.err output, but
at the least, it could use what it claims to do: put the summary on the
console, and the details in the log. Perhaps reporting should be
configurable in the container configuration. Sometimes you need the volume,
other times the volume is just noise hiding the signal.
I don't think the System.err output is really relevant - that's just a output target.
However, the difference between logging and reporting is an interesting distinction. What Merlin is doing is more aligned with reporting in that it is doing the distilling process on an error. There is a valid argument that the process of distilling is removed information necessary to resolve and issue. Should Merlin be seperating these notion (e.g. using one logging channel for verbose dumping of full information and another channel for consolidated reposting)?
Stephen.
--- Noel
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
