Steve wrote: > 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.
but that factory is criteria-driven, and its not easy to figure out what the criteria are, should be, or what the design behind them is.
> (b) model creation, this is inside Merlin's DefaultFactory > where a root system and a root application meta-model > are created.
but the model is scary as well. I know about MDA and MDD but the composition model simply does not map to the composition model I want to use.
> (c) followed by creation of the runtime root system and > application blocks that are handled based on supplied > parameters
and some hard-coded decisions.
I've spent about two full developer days inside the merlin internals and it does not look simple to me at all. If the solution to that were simple I would have implemented it months ago.
> From 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.
Can you draw
- the conceptual decomposition of a typical merlin system? - the mapping of that decomposition onto the composition model? - the mapping of the configuration onto the composition model?
Can you desribe
- what entities are responsible for both of the mappings above? - where and how they're implemented? - the contract between the runtime system and the model fed to it? - the conceptual relationship between the model and the merlin tool support? - the conceptual relationship between the configuration and the merlin tool support? - how to apply the conceptual seperation of component type/style in my decomposition to the composition model? - the mapping of a typical phoenix decomposition onto the merlin composition model?
You probably can. But I can't.
In order to develop on a container productively, I need to have the answer to all of those questions, and many more, all in memory. This "wrapping my head around" merlin is what I find so difficult.
Being male, I blame the object of my frustration and not myself.
> 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.
I have a basic understanding of all of the above. What I want is a platform that can be customized in more radical ways without doing all of the above.
I assert Merlin does not offer me that at the moment, nor do I know how to make it so without breaking many things.
Failing that, I would like a platform that can be customized based on that basic understanding coupled to my several years of experience with IoC/COP development.
I assert that Merlin does not offer me that either at the moment.
Note the consistent use of the words "I" and "me".
>> 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.
Okay, how about this: I need a simpler model; a more straightforward decomposition strategy and hence easier customizability. Contrast against Niclas' list:
"Many extension points are in-progress of taking form in Merlin;
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 contaiment listeners
e. customizable context handlers
f. customizable lifecyle stage handlers
g. ability to handle custom model implementations
h. custom component instance factory
i. custom deployment handler (deployment handler)
j. plugable <element> handlers in meta info and meta data description
k. customizable serialization factories
l. customizable service factories (i.e. not just local components)
m. enablable codebase level security (on/off)
n. pluggable subject level security
Just about every interface in Merlin is soon to be allowed to be exhanged with a custom implementation."
Each of those is about adding flexibility to a complex model so that features are pluggable. But it is not likely going to make the model any simpler.
None of this is actually bad at all. But it does reaffirm my preliminary conclusion that where the currently most active merlin developers want to go is not where I want to go. That is not bad either.
But it does force me to rethink my relationship to the avalon project, simply because merlin really *should* be the future for avalon. Here's what that looks like:
Summary ------- 1) merlin is great for users; 2) there's a lot of development going on surrounding merlin; 3) merlin is not so great for some developers, like me; 4) merlin is not so great for some use cases, like mine; 5) I myself am not capable of changing #3 an #4 without impacting #1 and #2; 6) I believe merlin needs to be the future for avalon, and active or radical new development around fortress or any other codebase would be bad for avalon as a community.
"This inevitably leads to the logical conclusion that" there is no way for me to help build the container I want in the way I want without causing negative side-effects to the avalon development and user community (and thus the ASF as a whole).
This is not anyone's fault but my own, and no-one is to blame but myself. But I don't have to like it.
-- cheers,
- Leo Simons
----------------------------------------------------------------------- Weblog -- http://leosimons.com/ IoC Component Glue -- http://jicarilla.org/ Articles & Opinions -- http://lsd.student.utwente.nl/jicarilla/Articles ----------------------------------------------------------------------- "We started off trying to set up a small anarchist community, but people wouldn't obey the rules." -- Alan Bennett
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
