avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@realityforge.org>
Subject Re: [RT] Distilling the requirements for Block Support
Date Fri, 25 Apr 2003 00:21:08 GMT
On Fri, 25 Apr 2003 00:08, Jakob Praher wrote:
> What do you see is the Configuration of a LU?

Essentially I see LUs as not being configurable at all.

> -> I would think that a ceratin amount of configuraiton (for isntance
> default values, ... ) could be counted as LU also?

This is what I have been referring to as templates/profiles. Essentially it is 
data that could be extracted from LU and be used to autocreate a DU.

> So do you think that DUs shouldn't contain code (or at least contain
> glue code?)

I am not sure. Ideally reusable code should be in LUs but several different DU 
standards allow raw code in them. For example .sar files have 
SAR-INF/classes, .wars have WAR-INF/classes etc

> How would this be packaged in practice?
> LU would be a jar files with a manifest that contains:
> 	-> version
> 	-> compatibilty information (in the simple case of the
> major.minor.micro the compaitibilty can be derived from the version )

Actually I would say it declares itself as an optional package. (See 
guide/extensions/versioning.html in jdk1.3+ docs).

> DU would be a wrapper package (like the .war or [wsb]ar files), that
> contains:


> 	-> embedded LUs (you call it contains)
> 	   (these are packaged within the DU, is it exportable then?)

not sure what you mean by "exportable"?

> 	-> linked LUs
> 	-> depency information (something like the plugin mechanism)

> So what I would like to have is a sort of design document, that stays in
> avalon-wiki, where we keep track the discussion. We can have differnent
> versions, but we should somehow document the effort. And I hope to play
> with some code really soon ;-)


> What about the loading mechanics?

Your design is an "active" design which is something I tend to avoid. In 
general I would probably implement it by something like the following (Note 
that Extension defines an optional package - see excalibur-extension package 
for more details on that class). Librarys are fairly easy to model - see the 

class LibraryMetaData
  File getLocation(); //Usually refers to jar but can refer to 
                      //dir or xml descriptor
  Extension getExtension();
  Extension[] getAvailableExtensions(); //extensions we export
  Extension[] getRequiredExtensions(); //extensions we import
  ResourceMetaData[] getResourcess(); //resources we export

class LibraryEntry
  LibraryMetaData getMetaData();
  LibraryEntry[] getImports(); //list of librarys we actually import
  ClassLoader getClassLoader();

interface LibraryLoaderService
  LibraryMetaData loadLibrary( File location );

interface LibraryRepositoryService
  LibraryRealm createRealm();
  LibraryEntry resolveLibrary( LibraryRealm realm, LibraryMetaData library );

Deployable units are much harder to model and I don't really know how to do 
it. I have tried a few approaches but it is hard to get a model that is 
generic enough to satisfy all of our demands. Essentially I think we will 
have to build sepcific deployer/DU Manager for each different DU type (ie cob 
vs maven plugin vs .sar file).

> Only DeployableUnits will be *deployed* (hence their name - or?)


> [LUs will be loaded by the means of DUs - or am I misinterpreting
> something ?]

nope - your on the money. LUs will be loaded as a side-effect of DUs loading.

> How does the container manage updates?

In Phoenix each of the DUs are isolated from other DUs and thus can be 
unloaded and reloaded at will. When you have one DU depending on another DU 
then it is impossible to unload/reload safely unless there is isolation 
between the two DUs. In which case you can sorta get away with it.

The way you get away with it is the following;

* create an interceptor between inter-DU service calls. 
* Consider case where component in DU1 makes call on service in DU2. If DU2 is 
to be reloaded then we tell the interceptor to suspend calls. So any calls to 
DU2 will be suspended until DU2 is reloaded.
* we unload old DU2 and reload new DU2
* we tell DU1 that DU2 is reloaded (if it had registered a listener for that 
* we unsuspend the interceptor and calls continue as usual

> It is very important look at the client side too:
> What the container/its client want is a way to access these resources
> Say Client C wants a reference to Service MyService:
> MyService s = container.lookup( MyService.ROLE );
> the container in turn will look through the registered/available DUs,
> and checks whether someone exports this component.

Again - I think it depends on the particula DU being created because in some 
cases (think .sar or .war) this makes no sense. In others such as osgi or 
Cocoon it does make sense.

> <myview>
> Deployment of Units is more or less a user triggered action, like moving
> the mouse or pressing the keyboard, since the sysamdin or deployer, at
> any given time, choses to update or replace a deployed unit.


> Of course ther is much more to say on this topic. I would really like to
> get a written spec out of these discussions someday ;-).

kool. Feel free to start it in wiki and I will try to add to it when I can.

> > It is sorta ironic that the most advanced and
> > active Avalon container is not built by Avalon peeps.
> But on the other hand shows that Avalon is used and extended by various
> Apache (and of course non Apache) projects, I think thats quite good, as
> long as the changes get merged into Avalon (if they are worth it) [ or
> else we have too much friction in the container landscape ]

I doubt that the container parts will ever get merged back into Avalon 
regardless of merit. But given the path that Avalon is now taking I think you 
will see more friction in the container landscape anyways so I don't think 
thats an issue.


Peter Donald
| "You can't fight in here! This is the war  |
|              room!" -Dr. Strangelove       |

To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message