I posted a "feeler" question to the PMC group today just to get some initial feedback. Considering the support from all parties, and the concerns that I personally have, I would now like to get a bigger picture of the whole Avalon developers group.
I have a feeling that Avalon, and specifically Merlin is focusing too much on the enterprise. I know that the enterprise features are necessary for some folks, but others simply do not need it. It never really had simplicity, and to be honest I can't tell what it does and does not do. I know of a couple of people who are
concerned (and will remain nameless until they choose not to be).
I could talk about a couple of nameless multi-nationals that are building commercial product on Avalon Framework, Avalon Utilities, Avalon Repository, and Avalon Merlin. My point is that "nameless" individuals don't mean anything - just as my nameless multinationals don't mean anything. What does matter are the opinions expressed publicly - for the benefit of the community and in the spirit of contribution.
Moving on to more concrete topics ...
To be honest, I am not in a situation where I need enterprise level architecture anymore. I just need something simple.
The current Fortress does fit my needs, and I am almost scared to try Merlin.
There are two important questions here:
(a) why does Fortress not meet your needs? (b) why is Merlin scary?
I can can speculate about the first, but I don't understand about the second. Feedback I'm getting is that Merlin is *really* easy to use - in fact more than a few people have commented that it is the easiest container they have used (within and external to Avalon).
My guess is that your probably thinking about "how do I make Merlin internals do what I want" - and yes - that could be scary. But the solution here is rather simple - take a step back and separate out the following:
(a) bootstrapping, this is all 100% avalon-repository stuff
(same pattern could/should be applied to logging subsystem
establishment, Fortress embedding, in fact any embedding
scenario) - this means that the entry point is standard
Factory model. (b) model creation, this is inside Merlin's DefaultFactory
where a root system and a root application meta-model
are created. (c) followed by creation of the runtime root system and
application blocks that are handled based on supplied
parametersFrom here you should stop looking at the code and start looking at the composition package. The entire package is about parameterization of what happens at runtime. If you cannot change something though the meta model API than its not changeable.
For example, Leo wants to switch in handling of Type 3 components. Well, based on the meta-model contract as it stands, he can't because this isn't an exposed parameterizable aspect under version 3.2.
What I'm saying is - focus on understanding the meta-model defined by the composition package and from that everything falls into place. Remember, its not code driven, it model driven.
To be fair, I should declare what I mean by simple. By simple,
I mean that I have a set of components I need, but I don't need security, proxying, etc. Granted, I do need to extend the lifecycle, but that is another topic entirely.
This may not make a lot of sense but the feature profile your looking for will probably arrive with Merlin 3.4 - i.e. scaling to "not much". As Merlin moves forward it becomes less and less and enabling more and more.
I.e. you have more choice in terms of what is is you want your container to be. On my machine here I have a full HTTP server running inside the Merlin kernel (i.e. under the internal system SPI classloader) and capable of monitoring and interacting with the entire meta-model. I am probably a few full on developer days away from having component == servlet with the http server directing request to the component instance.
But what is import here is that this is not feature extension - its just a component that happens to be running internally (it could be a logging system, a JMX server, a JMS adapter, an ORB, whatever). In fact the entire HTTP stuff is two lines of XML inside the kernel.xml (one for the server and one for the model listener). The more this sort of internal facility handling evolves, the smaller Merlin gets.
I am not really for a cease and desist type of action, but I really want to know if my needs are truly that distinct from where Avalon is going. For a long time we have talked about something that would
be easy to modify or easy to extend.
Start of with understanding what Merlin is (and isn't) and from there you will get an idea of which playground your in - either its parameterization of the platform to do things, or, your looking at platform customization. If its the later - a little experience in using the platform will go a long way to understanding what the process is to introduce change (because its not just adding a configurable classname at line 122 - its about declaring the aspect formally in the meta model, expressing that aspect in the model readers and writers, and implementing the corresponding model level validation and runtime associations.
Yes, it sounds complicated but its the same process every time.
Many of us can prove that it can be done--but noone is interested in a complete rebuild or new work. I don't blame them. I feel the need for simplicity is being drowned out by the need for features.
I strong disagree with you on this point. If you take a look at the requirements from the James project - they need additional features but this is translated into activities related to pluggable feature handling. The same is true for the requirements coming from Turbine, the OpenIM project, and other external projects.
Instead of looking at solving all of these feature enhancement requests - the approach is to (a) refactor aspect of the kernel or meta model to better handle custom solution requirements, and (b) where necessary, expose an appropriate parameterization point in the meta-model.
Another thing that scares me is the rate of mutation for Merlin. You may know what it does this week, but come back to it a couple weeks
later and everything is different. There are hundreds of commit messages that go by all the time, and it is difficult for me to try to keep up with what is really going on.
On the Merlin system there are three separate considerations with respect to change:
1. changes to the XML type and block contract 2. changes to the kernel and model API 3. changes to the model and runtime implementation
As far as (1) is concerned - Merlin has remained rock-solid in support for the component meta-data and meta-info contracts.
Concerning the embedded API (2), things are evolving and interfaces are chainging (but nothing radical and nothing that has caused a problem with people actually coding against this stuff). In fact I think it is fair to say that the recent changes (3.0-2) have been a big plus for anyone working on a embedded container scenarios. Yes, there will be evolution here - the work on the 3.4 branch (which has a lot of commit messages is dealing with refactoring of the assembly aspects - basically moving assembly logic from runtime layer to the model). But irrespective of the fun and excitement under the 3.4, the actual commits related to 3.2 are almost all implementation enhancements (which is definely safe territory for change and evolution) which bring me to point (3).
Item (3) is and will remain open territory for change because Merlin (implementation) is about change, evolution, development, it about identifying what can be separated out, what is and is not a facility, what are the extensions points, what is the containment contract? No apologies for hundreds of commits - they reflect interest and engagement. Think of it this way - every commit is making Merlin smaller and smaller, less and less, and at the end of the day Avalon will have a rock solid containment architecture and reference implementation.
The questions I have are this (for those who have not seen this earlier):
1) Am I alone in my concerns?
No, but I don't share the same concerns. I more aligned with Hammets comment ...
>> My only "critic" to merlin is a better isolation of features, after >> that it will rule the world.
And feature isolation is being addressed under the 3.4 branch. In fact there is a real possibility that the entire assembly package will become a plug replaceable extension - leaving only composition and merlin core as the "real" system facilities. Again, I cannot emphasis enough, spend some time looking at the composition package, understand the meta model, then start exploring.
2) If not, how should we start refactoring Merlin to make it what we all need?
* please note that development should be able to continue while refactoring
occurs.
1. understand what exists and the architecture of the system
2. identify what it is that you think that we all need
3. identify where that need plays into the Merlin platform - is is a system configuration question, is is a parameterizable aspect that needs to be exposed?
On completion of the above you have everything you need to in order to fulfill whatever it is the "we all need".
3) What about the guy with simple needs? What are we going to do for him?
Merlin 3.0 is handling simple needs for hundred of users.
4) What about extensibility? We need this if we are to survive. Right now I get the feeling that Merlin is an all or nothing approach. Not
a pick and choose the feature set approach.
From Niclas' email to the PMC, he summarized extensibility features either in place or in progress:
a. application deployment via repository system b. ability to select and alternative kernel on the command line c. ability to add custom facilities inside the kernel d. ability to add containment listeners e. customizable context handlers f. customizable lifecycle stage handlers g. ability to handle custom model implementations h. custom component instance factory i. custom deployment handler j. pluggable <element> handlers in meta info and meta data description k. customizable serialization factories l. customizable service factories (i.e. not just local components) m. embeddable codebase level security (on/off) n. pluggable subject level security
Items a-e are already in-place and the majority of the rest will probably make it within 3.4 with breaking the client component usage contract.
What this all means is that Merlin is progressively moving to a shell within which you put the features you need (via your components) - and you decide if you customizing the platform or the application. But I need to restate the point that this is "a model-driven solution".
Cheers, Stephen.
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/ | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
