You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Fernando Padilla <fe...@interdimensions.com> on 2003/12/29 18:54:05 UTC
Re: Merlin Dynamic Block Un/Loading (fwd)
Hi. I sent this to users@avalon, but thought it might fit better over
here at dev@avalon.
---------- Forwarded message ----------
Date: Mon, 29 Dec 2003 12:41:44 -0500 (EST)
From: Fernando Padilla <fe...@interdimensions.com>
Reply-To: Avalon framework users <us...@avalon.apache.org>
To: Avalon framework users <us...@avalon.apache.org>
Subject: Re: Merlin Dynamic Block Un/Loading
I have some more thoughts I would like to get comments on :)
Should I be posting emails like this to dev@avalon??
---
The model hiearchy in a kernel is defined by the blocks themselves. Like
when I added the hello block to / it created /tutorial/hello. But if I
truly want to manage block loading/unloading, then I can't let blocks
pick their own names, or there might be clashing, etc..
Should there be a way to do, addModel( URL, name )? Or should I segregate
the block I'm loading within a ContainmentModel which I can manage??
---
An example of using ContainmentModel segregation:
I could do:
hellomodel = root.createContainmentModel( "hellomodel" );
hellomodel.addModel( "http:......hello.jar" );
Then when I'm all done with it, I simply remove the ContainmentMoel,
hellomodel:
root.removeModel( "hellomodel" );
---
This way, it could let me ignore the names the loaded block is using.
Right? As long as it exposes the services through its top level
container.. hellomodel should expose those services too?? using the
service proxy? Right? So I could do:
(turorial.Hello) hellomodel.resolve();
---
Is there an easy equivalent to root.createContainmentModel( "name" ) right
now?
---
---
In my neophite (right word?) mind, Blocks are defined and loaded from a
block.xml file ( within jar file, or pointed to directly ). This defines
the structure of the Model, thus the Container/Block Hierarchy. So if I
would like to modify/define the Container/Block Hierarchy I would have to
create my own block.xml in memory, then save it somewhere, then load it
into the kernel. How close am I??
Is there an easier way to programmatically create/define/load a
Container/Block Hierarchy for merlin to run off of?
---
Is there a way to somehow hook a SourceResolver into the addModel method
call? So we can use user defined protocols? - like a protocol to access
in memory block.xml files ;)
---
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@avalon.apache.org
For additional commands, e-mail: users-help@avalon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Merlin Dynamic Block Un/Loading (fwd)
Posted by Stephen McConnell <mc...@apache.org>.
Fernando Padilla wrote:
>The model hiearchy in a kernel is defined by the blocks themselves.
>
Actually the block hiearachy is defined by the model hierchy. You
populate the model and then the model is supplied as a argument to the
establishment of the runtime system. The root block is created using
the root model. The root block then populates subsididary blocks based
on the subsidiary models. Changes to the model should be propergated to
the block runtime environment (not the other way around).
>Like when I added the hello block to / it created /tutorial/hello. But if I
>truly want to manage block loading/unloading, then I can't let blocks
>pick their own names, or there might be clashing, etc..
>
>Should there be a way to do, addModel( URL, name )? Or should I segregate
>the block I'm loading within a ContainmentModel which I can manage??
>
Don't see any problems with including an overriding name. In fact this
is done in the case of block imports (although its hidden away as a
private method). I would suggest digging around in the
DefaultContainmentModel source.
>---
>
>An example of using ContainmentModel segregation:
>
>I could do:
>
>hellomodel = root.createContainmentModel( "hellomodel" );
>hellomodel.addModel( "http:......hello.jar" );
>
>Then when I'm all done with it, I simply remove the ContainmentMoel,
>hellomodel:
>
>root.removeModel( "hellomodel" );
>
I think the first idea of supplying a name is a better approach. Just
about all of the meta-mode classes take the complete set of creation
criteria as constructor aguments and assign value to final variables.
Using a multistep approach introduces a non-final state to the model
which IMO would be a detrimental.
>---
>
>In my neophite (right word?) mind, Blocks are defined and loaded from a
>block.xml file ( within jar file, or pointed to directly ). This defines
>the structure of the Model, thus the Container/Block Hierarchy. So if I
>would like to modify/define the Container/Block Hierarchy I would have to
>create my own block.xml in memory, then save it somewhere, then load it
>into the kernel. How close am I??
>
Umm, sort of close.
You have a deployment descriptor. An example of a deployment descriptor
is a XML file containing <container.../> as the root element. Other
examples include serialized descriptors. A deployment descriptor is
often refered to as a deployment profile (and you do things like package
multiple profiles with components). When Merlin does its stuff - it
creates a root containment model and then adds sub-models to that
model. Each sub-model is created using (a) a deployment descriptor, (b)
a runtime context, (c) metainfo exposed by component types. Merlin
works though the process of building and validaing the model (including
handling of all of the classloader stuff), and then once complete,
iniates the creation of the runtime context - and here is where we kick
in with block and appliance instances that parrallel the model structure.
As far as creating models dynamically is concerned - no problem - you
need to build a profile then apply the profile as an argument when
creating the model - bingo - your in business. If you take a look at
the DefaultContainementModel and DefaultDeploymentModel constructors you
will get an idea of what is required. The api for the creation of
everything are all part of the composition package.
>Is there an easier way to programmatically create/define/load a
>Container/Block Hierarchy for merlin to run off of?
>
Things could be made simpler with some Helper classes - e.g. new
DeploymentProfileHelper - helper.setName( .. ), helper.setConfiguarion(
.. ), helper.newInstance(), etc.
>---
>
>Is there a way to somehow hook a SourceResolver into the addModel method
>call? So we can use user defined protocols? - like a protocol to access
>in memory block.xml files ;)
>
No. But a lot of braiun cells died in the process of ensuring that
different DeploymentModel and ContainmentModel implementations can
coexist and work with each other.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
|------------------------------------------------|
| 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