Noel J. Bergman wrote:
As I understand it from your previous notes, Merlin is primarily short in the area of log configuration?
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.
Huh? Stephen, read it again. L-O-G, not l-o-N-g. I thought that you had said that Merlin did not yet have the *L-O-G* configurability that Phoenix provides.
Yes, yes - Steve was blind drunk at the time he posted that reply. See the following message for the real response.
http://marc.theaimsgroup.com/?l=avalon-dev&m=106211727608122&w=2
If you can reformulate the question I'll try and give you an answer.
I can reformulate it, or you can clean your monitor. :-p
ROTFL (if you could only see my monitor)
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.
Example?
If your build an application that requires a bunch of different facilities and if you forced to bring together configuration information for all of those facilities into one file - things become non-managable. Imagine a framework composed of six major sub-systems of which one is james. There are two problems here - firstly scalability from a human management point of view, and secondly scalability from a systems point of view.
The human scalability issue can be addressed by breaking out type, deployment, and context aspects of a configuration and associating them with different system artifacts. For example, type related configuration information is normally a developer concerns and can be associated with a release. Its the sort of information that would not normally be modified. Deployment information is characterizing the deployment of a component - this could reflect differences between a file based deployment versus a RDMS based deployment scenarios. These "scenario" related configurations can be presented as deployment profiles and packaged with a release. Finally, the deployment context aspect deals with things like usernames, passwords, host names, DNS entries, etc. - i.e. stuff that really is the subject of the particular context of deployment.
Merlin provides support for all of these aspects and handles the packaging and ultimate integration of these multiple confiuration sources into a consolidated configuration that is applied at runtime. We still have work to do to handle the structural scalability question - namely the ability to provide service management across multiple JVMs. What we do have that is an important ingridient towards this is the notion of virtual components. You can take the "james-system" and declare the publication of specific services (e.g. the Mailet services). This allows James to be viewed as just another component.
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.
Aha! See: "don't have the JMX and L-O-G-G-I-N-G options currently ..." I
did remember it correctly.
Yes you did remember correctly!!
OK, what are the differences for L-O-G-G-I-N-G?
Phoenix provides support for the Excalibur Logging package (all of that logging related XML). Merlin has a much smaller subset in terms of functionality - however the functionality is better seperated in terms of what are container concerns and what are component deployment concerns. It probably would not take a lot effort to upgrade Merlin to provide support for Excalibur Logging but its not terribly high on the list of priorities (things like JMX intelligence are way higher).
We currently disable JMX, so until it is done properly, I don't think that's an issue.
On the JMX side of things - the current thinking inside Merlin development is to provide intelligent management based on the internal Merlin component meta-model. What this will provide is management of any component without the need for the component author to write a single line of code (stuff like reconfiguration, recontextaulization, etc.). Combine that with functionality along the lines of Phoenix JMX support and we will have a really nice management solution. This is one of things I would like to look at following a 3.0 release.
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
All of the above require justification. Good to know, but require
justification.
What sort of justification I you looking for? I can easily provide information about my own experience and the underlying reasons why these features were developed if that what you mean. On the otherhand, if your looking for justification that they actually translate into a value proposition then the best we to address this is to download Merlin and setup a runtime James instance.
http://www.ibiblio.org/merlin/distributions/
I'm actually planning on putting James into deployment as the enterprise messaging solution for "yet-to-be-announced" project - but before doing this, a key aspect will be demonstrating the utility of James as a virtual component. For this I'll be looking for some assistance here ;-). But that's a topic for another thread.
I would be happy if startup and footprint were lighter, so that we could run multiple processes, instead of one monolithic process
Just comparing foootprints ... Phoenix is about 4Mb. Merlin is a bit over 2Mb.
(e.g., separate protocol handling services into separate processes connected
via repositories/spool; and the pipeline processing in its own process,
too).
I'm thinking along the same lines. The solution to this problem is non-trivial. While Merlin can do all of the service deployment within a single JVM, we don't have "standard" mechanisms for remote service resolution or the related service interaction protocols in place (manager to manager). However, this is top-of-the-agenda. What we want is scalable, robust, fault-tolerant deployment and James is a hell of good test case (in fact its been the main testcase for Merlin for the past nine months).
As an optional configuration, it would be helpful. Personally, I am very tempted to do it in my own deployment because it means I could reconfigure & restart the pipeline without having to take down the SMTP and POP3 services.
This is addressed under the JMX related appliance management plans. What we want to be able to do is redeploy a manager (appliance) and have the container handle the automation of the suspension and/or decommissioning of consumers. This works locally but doing this with remote services requires a federated service management protocol. For example, if I have a user repository (identity and credentials) shared by OpenIM and James, and if I need to redeploy that server I need to signal to consumers that a suspension (or switch) is initiated and subsequently resumed (re-swithed) to the updated service provider.
I don't think the System.err output is really relevant - that's just a output target.
I was refering to what Phoenix does.
Sorry - I stopped using Phoneix about 6 months ago and my memory for details is getting rusty already. Maybe I'm just too old!
Should Merlin be seperating these notion (e.g. using one logging channel for verbose dumping of full information and another channel for consolidated reposting)?
Interesting notion. Requires more thought than I have to spare at the moment.
Yep. Cheers, Steve.
--- Noel
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
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]
