From: Stephen McConnell [mailto:[EMAIL PROTECTED]
Thats the point: for a very particullar audience who wants to feel using a J2EE like container.
I don't see things in the same light as you do. But let get down the real point your raising. Your depicting Merlin as a J2EE platform. That in my opinion way off the mark because the Merlin development (and the opinions of the people contributing to merlin) go well beyond that reference point - something much better, much cleaner, a complete quality IOC component and service management solution.
Whether it is J2EE or not - this is the problem: I don't have the same goal. Rather, this is my goal:
+ I want a little container that I can start with: MyContainer myContainer = new MyContainer ();
+ give it a logger with: myContainer.enableLogging (logger); or: myContainer.addAspect(new AvalonLogging (logger));
+ configure with: myContainer.configure (config); + or with: ComponentHandler handler = new A4ComponentHandler(SomeClass.class, ...); myContainer.addComponentHandler(handler);
I think we are close to providing the this. Carsten posted an email saying basically the same thing (referencing a 4-5 line embedding scenario). I posted a reply [1] with a description similar to what you are describing above. The email references the tutorial Main file [2] in the platform/tutorials/main directory. Aaron's follow up email [3] describes what is happening behind the scenes in the different steps (which BTW get onto the subject your addressing below).
<snip/>
To drive this to the absurd limit - are you willing to start with a clean slate? Throw away Merlin, and build something new (where you can get bits and pieces from Merlin implemented)?
I think we can make a lot more progress be evolving, improving etc. I think every time a new committer gets engaged and involved we see big improvements to overall system. Should we start on a clean slate? I would have a hard time justifying that without a solid indication that it would be a viable strategy.
I'm not saying that this is even a workable solution, but *I
do want to know just how attached to Merlin you are.* Because
it really influences the ability of others to, well, influence and evolve.
My attachments are at a couple of levels:
Operational stuff like does it build, do the test cases pass, do applications running on Merlin that I have here run properly after a clean build and install.
I've also got attachments in terms of what a service management platform is and what it should be providing - and, I know my view of this are orthogonal to LSDs. I'm still a little fuzzy on this - but I think that there is type of container strategy that is developer oriented, and there is a strategy that is enterprise oriented.
But I don't think that enterprise oriented means "heavy". In fact I rather like the resource management versus IOC separation that is emerging in 3.3. I also *love* the model-driven approach. I figure this could still be improved a lot - but to give you an indication - if you say "X must be thrown away" and ask me if I agree - chances are hight that I won't - on the other hand - if we are improving what exists then it will happen. And if in the process we figure out that incremental isn't an option - then we need to get radical. So far both Alex and Niclas have gone radical without problem - and the results have really great.
If it is "take it or leave it", then I'm not that inclined to pitch in.
If it is a "look, I've come across a lot of problems building Merlin, I have solved them. I don't want to throw away
all that knowledge, and that's why I'm conservative. But I'd
throw away my solutions in an instant if better solutions
appeared" then I'm more up for it.
To give you example - every time the meta package debate comes up - someone dumps an email with the latest greatest idea and no correlation with existing contracts and how that contract are being used - yep, I not going to respond with a good old team player spirit. On the other hand, if someone comes up with a better solution and at least communicates an understanding of how the solution relates to what we have and what the impact is - I'm in.
It's just that statements such as the one above doesn't really read that way for me. Makes me wonder if I'm just free to influence and evolve as long as I influence and evolve the way you want me to.
This is like the question "have you stopped beating your wife"? Your free to influence, evolve and be a part of it. As to me - ask the other, I'm too close to the subject of the question to give an impartial answer. But - there is a little diagram in my head that seems to me identify a number of different things (which I'm only recently getting to grips with).
Now I'm finding this useful because its helping me to understand differences of options and secondly, to try and answer some of the questions your asking, and also to put up some sort of map of the Avalon landscape.
|--------------------------------------------| | pull-based | pull-based | | developer centric | enterprise-centric | | (ECM/Fortress) | ^ | | | | (via facilities | | | discovery services, | | | selection, http facility, | | | etc.) | |-------------------------------|------------| | | | | | push-based | push-based | | developer centric | enterprise-centric | | <----------- (via repo, | | | via aspects?) | | | | | | Merlin | | | | |--------------------------------------------|
Based on Carsten's feedback over the last couple days I've come to a point where I'm viewing the classic ECM versus Phoenix strategies in-terms of service activation as "pull-based" and "push-based". I'm also taking into account "developer" versus "enterprise" focus.
Today the Merlin and related systems are in the "enterprise/push-based" corner and current initiative with repository are extending the coverage to enable more "developer" focused support. Current in Merlin there repository provides the basic framework for resource management. In effect its only a small step away from being a micro-container in its own right. What your describing with respect to Aspect appears to me to me an approach at simplifying the api and adding more control over system profiles. This IMO this is about addressing the interest in making the system more developer friendly/centric, and partly aimed at object model simplification (which is probably based expressed in a third axis).
ECM/Fortress is pull-based in that you trigger service activation as a result of a request. Meeting Cocoon requirements means providing pull-based activation semantics into merlin. This is partly demonstrated in the dynamics tutorial [4] and if you consider Niclas' post on the subject [5] I think he's maybe onto the a germ of the right idea for model consolidation.
the other Leo simply hates the names I give things.
The thing is this: I don't hate the names you give to things. I hate the fact that so many names are needed. It makes me think that there's something fundamentally wrong with the system, since you need to understand so many concepts.
That's not "simply hating the names". Why this complexity?
I don't see this as complex. I see it as being "explicit". It about describing the object model for the component contract instead of depending on marker interfaces and configurations, if about about fully specifying the object model for deployment instead of depending on configurations. It's about a manageable model instead of a re-startable application. And yes - that's all because I'm focsussing on the right side of the above diagram. I happen to belive that the solution is non-trivial. But I also belive we can improve the implementation over an above what I've done, and not break the build in the process.
Cheers, Stephen.
[1] bootstrap procedure http://marc.theaimsgroup.com/?l=avalon-dev&m=107840152111191&w=2 [2] bootstrapping procedure source http://cvs.apache.org/viewcvs.cgi/avalon/merlin/platform/tutorials/main/src/java/tutorial/Main.java [3] what's mappening behind the scenes (Aaron) http://marc.theaimsgroup.com/?l=avalon-dev&m=107841777824457&w=2 [4] dynamic HelloFacility http://cvs.apache.org/viewcvs.cgi/avalon/merlin/platform/tutorials/dynamics/src/java/tutorial/HelloFacility.java [5] MVC twist http://marc.theaimsgroup.com/?l=avalon-dev&m=107841873702288&w=2
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
