avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Praher <jpra...@yahoo.de>
Subject Re: LUs,DUs,Bundles [Was: [RT] Distilling the requirements for Block Support]
Date Sat, 26 Apr 2003 19:02:39 GMT
Am Sam, 2003-04-26 um 17.35 schrieb Stephen McConnell:
> Jakob:
> Have been busy on other things and havn't been able to get into this 
> thread too much - but I've been reading everything with interest.  I've 
> included by Saturday afternoon 00.02 euros inline.
> Cheers, Steve.
thanks Steve for joining, I have noticed your new tutorial of block
composition - look forward to reading it ;-)

> >
> >Questions and Design discussion:
> >
> >* Library DUs
> >
> >LUs are loaded by DUs - period.
> >
> Ummmm - LUs basically equate to a jar file and a jar file can contain 
> declaration of dependencies.  As such, the loading of LU1 may imply the 
> loading of LU2, LU3, LUx.

the word loaded was wrong, sorry I meant *deployed* by DUs. And of
course dependent loading (like every good loader/linker does) is

> >
> >Example:
> >the provides and depends would be implemented with the Java Optional
> >Package Manifest entries.
> >
> >  
> >
> <snip manifest content>
> There are problems with putting stuff into manifests - basically there 
> are assumptions made in some of Sun's tools that result in you DU being 
> unusable in ap-plication scenarios.  It's much better to implant the 
> logic into a internal descriptor - for example Merlin blocks (an example 
> of a DU) contain a block.xml descriptor that contains information about 
> dependencies and services but does it in a way that is indepenndent of 
> the manifest (BLOCK-INF/block.xml).

LUs are jar files. Here it makes sence to state the depenency using the
optional package Manifest attributes. One reason why I think this is
important is, that for instance a LU could then be reused that was
packaged using this Specification, which for LUs I think is at least the
	- The Specification and the version which it provides
	- The Implementation Id and the Version
	- Dependecy on other LUs 

On the DU side you are right. I think here an internal descriptor does
make sense.

> >If we don't support library DUs - should the model be that the first DU
> >that contains a needed LU will be used to import/link to that LU?
> >if yes, this probably means that for a DU to be sure it *must* contain
> >all the linked/dependency LUs.
> >
> Using the optional extensions package (or a repository model or 
> combination of both) this is not an issue.  DU and/or LU that embedd jar 
> files within themselves are problamatic because the JDK classloaders do 
> not recognize jar:<filename>!/something url - instead you have to put in 
> place a manual unpacking scheme which means that your model is no longer 
> open.  It is better to avaide inclusion of jar files and instead work 
> with the optional extensions spec.

I also think it is a rule to link not contain LUs.
Perhaps its also a good rule that DUs only contain that LUs that are
specific to that LUs or LUs with which there are conflicts.

We could then say that contained LUs are loaded by a DU specific
classloader, but then again linking to that LUs is problematic, hmmm.
Given that hierarchical class loading model introduced by [Brach98] is a
kind of problem. For instance the jboss people demand for a flat class
loading space. 
But at the other hand DUs should not interfere with one another and
theretically, sharing certain libs is good, but I've also often burned
my fingers when updating certain apps to a certain version of, for
instance xalan ;-)

> >
> >Perhaps we could solve this by using an apt-get like mechanism for
> >fetching certain LUs, when not available locally from somewhere. [when
> >the user deploys the DU and a LU dependency ]. Are those then DUs? And
> >if yes Library DUs?
> >  
> >
> Not really undertanding the above sentence (what is apt-get ?).
> My experience is that you need to have a resolution service that is 
> implememtation independent.  For example - you need a diifferent 
> resolution mechanisms when working in a servlet as compared to working 
> in the scope of an application.

I understand. I have mixed concerns here. All I wanted to say is that
all the deployed DUs together might not provide all the required LUs.

For instance you deploy 2 DUs, A and B.
A contains LU libA and links to libB.
B consains LU libB and links to libC.

Now I thought it would be interesting to keep some kind of repository
where libs that are not provided by any DU might be worth to get from an
open repo.
Plus the linked LUs, I assume, are most of the time libraries that are
not specific to a ceratin AP (like a JAXP or JAXM impl).

apt-get info:
sorry here. apt-get is the debian Application Tree fetcher. You have an
/etc/apt/sources.list which is a repository reference file. When you for
instance want to install my-app, it also automatically updates and or
newly installs all dependent packages:

$ apg-get my-app
my-app depends on "lib-myapp" "lib-xml" "lib-xslt"
want you .... [Y/n]

> >
> >* Dependant DUs
> >I think it would make sense to be able to state that for instance the DU
> >a.du depends on b.du to there. (dependency not only on a lu level)
> >  
> >
> I see DUs as a specialization of LUs.  In that context there are 
> "structural" dependencies at the LU level and "logical" dependencies at 
> the DU level.

I think we gain more if we make them seperate entities. 
Why: LUs are merely code entities with templates that give hints about
their configuration, and DUs are deployable packages that in my view
should be configured and ready to be used. Although the configuration
should be customizable during deployment.

In my view you should be able to throw a DU into a container and work
with it.

> >* Exportable/Unexportable LUs
> >I think the DU should be able to declare whether certain contained LUs
> >should be exportable. If a DU declares a LU to be exportable, other DUs
> >can link to it. (code sharing)
> >  
> >
> I would prefer exportable LU to be maintained seeperate - i.e. just use 
> the optional extension mecahnism. 
I also favor the DU
> >* Dependecy information
> >
> >Where should the LU dependency (which means depending on certain LUs) go
> >to? 
> >
> Inside a descriptor - not in the manifest.
Not using the Optional Package Manifest Attributes?

> >Does it make sense to put it in the DU meta descriptor?
> >
> Yes.
Think so too.

> >If DUs itself contain code (which is probably a hack anyway) yes,
> >otherwise the LU dependency information should go into the LU.
> >
> DU dependency information should about services that are available from 
> another DU.
> LU dependency information is structural and can be handled at the level 
> of extension dependecies.

> >The DU can recursively question all its containing LUs which
> >dependencies they have and so compile a list of depending LU for the
> >whole DU.
> >  
> >
> This should not be the resolvibility of a DU.  A container shouold be 
> taking a DU and/or LU information and resolving everything needed for 
> deployment.  The DU itself should not be concerned as to the mechanisms 
> used to achieve this.
Ok this was a too active approach taken by me. Given the different
container scenarios you are absolutely right here.

> >Configuration: XML Schema/Profile Template language.
> >[Implementation Note] This could get distilled from the @doclet tags.
> >
> Don't think so.
> Defintion of a DU is a a lot more complex than a component type.
Clearly, but a LU must offer some configuration templates, which when
you build a DU, get compiled together to form a configuration meta
information for this DU.
Using this schema the DU packager can then state some configuration
decisions, which go inside a meta descriptor (sth. like a xconf file on
a per DU basis).
The deployer then should have the means to override the default
configuration in the DU.
Plus the packager could leave certain configurations open for the
deployer which at packaging time can not be answered successfully (smtp
host or sth. like this)

GUI/Console UI support here would be great (something like debconf
(debian configuration) mechanism.) It is important to also support
console UI since ssh is a very popular deployment utility ;-).

But once again, I think the LUs should contain the information, what
*is* configuratable.

For instance take a service implemented by MyComponent that resides in
xyz.lu (ending for clarity sake ;-) - should be jar).

class MyComponent implements .. Configurable ..
	public void configure( Configuration conf ) 
		throws ConfigurationExecption 
		/* conf here */


this component should define, in a schema (which format is more or less
a question of preference XSD, Relax, ...), which configuration settings
there are:

<configuration-schema service="x.y.z.SuperService" >
  <xsd:element type="xsd:string" name="smtp-host" />

  <xsd:element name="prefereed-color">
	<xsd:restrition type="xsd:string">
         <xsd:enumeration value="blue" />
	 <xsd:enumeration value="red"  />
	 <xsd:enumeration value="..."  />


this is just to stress what I mean with configuration templates.

-- Jakob

[Bracha98] http://java.sun.com/people/gbracha/classloaders.ps

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

View raw message