You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Simons <le...@apache.org> on 2004/01/05 21:29:50 UTC
[merlin] problems plugging in type 3 lifestyle
Hi gang,
since Steve and Niclas been saying how much merlin has evolved, I am
giving it one last chance. Not as a user, but as a co-developer. I
figured I'd have a look at implementing IoC type 3 support (again).
Looking for a short execution path I could digest, I started reading in
AbstractMerlinTestCase. It took some effort, but I finally found the
actual instantiation and lifecycle startup code in
org.apache.avalon.activation.appliance.impl.DefaultAppliance.StandardFactory
So I am guessing all I really want to do is plug in a different Factory
into DefaultAppliance. This, however, is hard-coded (!):
private final Factory m_factory = new StandardFactory();
So the next logical step for a type 3 convert like me is that I need a
new DefaultAppliance constructor:
public DefaultAppliance(
Logger logger, ServiceContext context, DeploymentModel model,
Engine engine, Factory factory )
{
this( logger, context, model, Engine engine);
m_factory = factory;
}
I couldn't quite figure out all the places from where this constructor
is called. IDEA sends me to line 928 (!) of AbstractBlock. The
surrounding code leads me to believe that I need to modify
DeploymentModel and DefaultDeploymentModel. But this means I don't need
my new constructor as my factory will be inside the deployment model. Okay.
Some more searching seems to indicate this DeploymentModel is created
somewhere in the AbstractBlock constructor, where it is extracted from a
ContainmentModel, which is retrieved from a BlockContext (!). The only
place I can find where such a thing is created is line 115 of
AbstractBlock, which is the createRootBlock() method, which is called in
several places, most importantly DefaultFactory (eh? O wait, this is a
different factory), inside the create() method (which is a whopping
579-204=375 lines long). I finally find the code that creates the
containment model:
ContainmentModel system =
new DefaultContainmentModel(
createContainmentContext(
systemContext, systemLogger, m_classloader,
getContainmentProfile(
kernelConfig.getChild( "system" ) ) ) );
It seems that I want to modify the ContainmentProfile. But wait a
minute, the javadocs say about containment context "Implementation of a
system context that exposes a system wide set of parameters". This I
don't want, since I want to use my type 3 factory for some components
and the regular factories for others. Aaaahh!!!
So I will need to modify this 375 lines long create() method and support
methods to support different containment contexts, different containment
models and different containment profiles, probably breaking dozens of
things that don't have test cases to check they are not broken in the
process.
Since this has now taken about an hour and a half, I give up. Who's up
for the challenge? For reference, here's some code that you should be
able to paste in MerlinTestCaseTest and run once this is done:
public void testHelloType3Aquisition() throws Exception
{
Type3Component component =
(Type3Component)super.resolve(
Type3Component.class.getName() );
component.doStuff();
}
public static interface Type3Dependency
{
String getMessage();
}
public static class Type3DependencyImpl implements Type3Dependency
{
public String getMessage()
{
return "Hello IoC world!";
}
}
public static interface Type3Component
{
void doStuff();
}
public static class Type3ComponentImpl implements Type3Component
{
private String m_message;
public Type3ComponentImpl( String message )
{
if( !"Hello IoC world!".equals( message ) )
throw new RuntimeException("Failure!");
m_message = message;
}
public void doStuff()
{
System.out.println( m_message );
}
}
And as far as defining simplicity goes (the code I saw so far in this
exercise does not qualify :D), in my current home-grown container (which
doesn't know anything about type 3 IoC either) I can do
container.addAdapter(
new SingletonComponentAdapter(
new ClassSelector( Type3Component.class ),
new Type3ComponentFactory(
container, Type3Component.class.getName()
)
)
);
In fortress this change is non-trivial either because of the hard-coded
reference (!)
final ComponentFactory componentFactory =
new ComponentFactory( clazz, configuration,
m_serviceManager, m_componentContext,
m_loggerManager, m_extManager );
on line 428 (!) of AbstractContainer. However, its easy to see that what
needs to be done. The configuration fed to the abstract container is
an element directly gotten from DefaultContainer its configure()
parameter. So all that needs to be done is allowing a configuration
element to the component definition to be added (factory="..."), and
then the code around line 428 needs to be made to check for that
parameter and parse it.
The next step would then be to refactor the code a bit more, adding the
factory information to ComponentHandlerMetaData inside the
DefaultContainer.configure() method.
--
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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Where do you want to go?
Posted by Leo Simons <le...@apache.org>.
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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [merlin] problems plugging in type 3 lifestyle
Posted by Leo Simons <le...@apache.org>.
Stephen McConnell wrote:
> Leo Simons wrote:
>
>> Hi gang,
>>
>> since Steve and Niclas been saying how much merlin has evolved, I am
>> giving it one last chance.
>
> Give up while your ahead.
>
> :-)
You sure have mastered those one-liners :P
seriously...here's a few more:
"If this was a competition, I would have *obviously* won by now."
- me
"My attempt to get you to scratch my itch has obviously failed."
- me
"Shoot. And I nearly had Aaron figuring it all out for me."
- me
And that's enough seriousness for tonight. Come and collect on that
whiskey (I am exploring a quite reasonable Glenn Fiddich atm) and I'll
seriously critize everything all night long!
--
g'night,
- LSD, who can't sleep
-----------------------------------------------------------------------
"Everything I say is either meant as a joke or is something I am not so
sure of."
- me
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [merlin] problems plugging in type 3 lifestyle
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
> Hi gang,
>
> since Steve and Niclas been saying how much merlin has evolved, I am
> giving it one last chance.
Give up while your ahead.
:-)
Cheers, Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/ |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org