Re: LUs,DUs,Bundles [Was: [RT] Distilling the requirements for Block Support]

[Jakob Praher <jp...@yahoo.de>]

As I've written in a previos mail, I would like to write a proposal in
avalon wiki, concerning:

* Deployment Techniques in Avalon Containers
[ DUs, LUs, Bundles, Blocks, ... ]

* Usage scenarios for DeployableUnits in container environemnts 
[ DUs in App-Containers, Cocoon, ... ]

I hope that this pages document the efforts for dynamic loadable and
adaptive DU support in containers.

I will post more on this as soon as I have written something.

Question: What's the best term to denote the features we are discussing
regarding DUs:

- Hot deployable [ this is probably to weak ]
- Runtime Adaptable Containers  [ is adaptable or adaptive the right
term here? ]
- ? 



Am Sam, 2003-04-26 um 23.25 schrieb Stephen McConnell: 
> Jakob Praher wrote:
> 
> >Am Sam, 2003-04-26 um 17.35 schrieb Stephen McConnell:
> >


> 
> Feedback welcome - I'm famouse for writing things that nobody 
> understands so feel free to put up suggestions for improvements.
> :-)

For me it was well written. Allthough I have to get to know some of the
concepts and I hope to go through the example, at least I have
successfully done a

$ maven merlin-install

and am now ready to do some testing with merlin. - I will use your block
tutorial for getting started - so look out for my questions ;-) 

<personal-interest>
I noticed that earlier versions that you migrated towards maven - how
tough was it - since its already a bigger project and you probably had
to do some maven customization ... .
</personal-interest>

> >
> >  
> >
> >>>Questions and Design discussion:
> 
> 
> I think we can summarise it as:
> 
>    a) a container is responsible for the deployment of a DU
yup.
>    b) a DU may declare logical and physical dependencies
>    c) logical dependencies are resolved by a container through 
> deployment of other DU
yup.

>    d) physical dependencies are resolved by a container based on jar 
> opional extension dependency declarations
exactly.
> 
> I.e. the distinction between a DU and an LU is that a DU should be 
> viewed as a computation unit whereas a LU is simply a physical artifact.
> 

Ok this sounds good. I will try to work it into the wiki-draft.
Allthough apps get deployed by the means of DUs the container 
loads services from LUs.
I think hiding too much of LUs from the container makes the API too active
again - What do you think?

And there are many questions, how inter DU relationship should be modelled,
as there are so many different scenarios - I will address these issues in 
another mail.

> 
> 
> >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.
> >  
> >
> 
> Maybe (but I have reervations).  I do think there is scope for an 
> application bundle which can be condiered as a source for LUs and DUs - 
> for example, if I want to deploy James as a DU and lets imagine that 
> James has logical dependecies on a couple of Cornerstone DUs and 
> structural dependencies on a bunch of Excalibur LUs (jar files).  It is 
> convinient if there is a application model that I can reference from 
> which I can get any unresolved Dus or LUs.  Part of this is driven by 
> liucensing requirements - for example I can bundle the Java Mail API in 
> a James application bundle and I can deploy a James DU by pulling out 
> the Java Mail jar from the application bundle and I'm 100% legal.

Perhaps we could do some meta tagging of DUs, that is left to interpretation
for the container. For instance the packager could add his 
"intention" or packaging "strategy" like avoid licensing problems.
Perhaps that makes sense. 
I will think about it more thoroghly. The question we have to ask here is 
what we gain by this packaging strategy. I can imagine in certain 
environments that this could be helpful.

Dealing with base apis like javamail api or jaxp or sth like that deserves its own
thoughts. hmmm.


> 
> >We could then say that contained LUs are loaded by a DU specific
> >classloader, but then again linking to that LUs is problematic, hmmm.
> >
> 
> Why problamatic? Having a classloader load LU physical dependencies is 
> not a problem.  This is exactly the approach taken in the Assembly 
> package.   A classloader is associated with a classpath (LUs) and the 
> classloader handles expansion of the LU[] to include all of the 
> dependent LUs. Once the classloader is established, the DU[] is 
> established and the assembly process kicks in.

I thik it is ideal as long as DUs are kind of islands.
As soon as inter DU usage is needed this could become a little bit problematic.

If we divide the LUs in specs and impls and load the specs in a common class loader
and the impl in the DU class loader would perhaps work out - whats your opinion on that?
[since the spec has its own version, we'd only had to reload the specs when a new spec 
version is introduced ] - spec version incompatibilites are another story though. In this 
case we should establish another spec class loader.

> 
> >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. 
> >
> 
> JBoss can improve!
you couldn't bee more right, but I threw it up since they had lots of 
IllegalAccessExceptions because of the class loader model.
Especially inter DU relationsships could be a pain here - since then you 
have several class loader sub-trees.

> 
> The hierarchical class loading modelis fine providing you overlay on 
> that a service model that is not subject to the same restrictions.  For 
> example - in a classloader hierachy A-B-C, you may have a component in C 
> that is producing a service that can be used in A or B.  That's 
> orthoginal to the notion of isolation which typically addresses 
> implementation classes.  However - to do this sort of thing you really 
> need to get your impl/inferface seperation sorted - and this isn't a 
> general practice.
> 
> >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 ;-)
> >  
> >
> 
> Yep.
> 
> In effect you need a mechanism (maybe just a the DU level) that lets you 
> override jar dependency information.  This is achivable if you have 
> control over the extension source within a particular classloader.  For 
> example, I can declare a classloader that is associated with a set of 
> extension locations - these locations get searched before location in 
> the parent classloader.  This lets me put in place an alternative LU 
> resolution to handle those cases where you need a special version of the 
> same version (I you know what I mean).
> 
> >
> >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.
> >
> 
> This is the direction Merlin is heading in.
> 
great.
> 
> 
> OK
> This sounds similar to what David Bernard is working on (see posts on 
> users@avalon).

sounds interesting. Will check it out. 
Is the info solely in the mail-archive? (or something in cvs already)
> 
> 
> 

<big-snip /> 
I'll try to answer the rest of our conversation tomorrow.
(looking forward to ;-) )

-- Jakob
> 
> >  
> >


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

Re: LUs,DUs,Bundles [Was: [RT] Distilling the requirements for Block Support]

[Stephen McConnell <mc...@apache.org>]

Jakob Praher wrote:

>As I've written in a previos mail, I would like to write a proposal in
>avalon wiki, concerning:
>
>* Deployment Techniques in Avalon Containers
>[ DUs, LUs, Bundles, Blocks, ... ]
>
>* Usage scenarios for DeployableUnits in container environemnts 
>[ DUs in App-Containers, Cocoon, ... ]
>
>I hope that this pages document the efforts for dynamic loadable and
>adaptive DU support in containers.
>
>I will post more on this as soon as I have written something.
>
>Question: What's the best term to denote the features we are discussing
>regarding DUs:
>
>- Hot deployable [ this is probably to weak ]
>- Runtime Adaptable Containers  [ is adaptable or adaptive the right
>term here? ]
>

     ...."Adaptive Containment"

Cheers, Steve.

>- ? 
>
>
>
>Am Sam, 2003-04-26 um 23.25 schrieb Stephen McConnell: 
>  
>
>>Jakob Praher wrote:
>>
>>    
>>
>>>Am Sam, 2003-04-26 um 17.35 schrieb Stephen McConnell:
>>>
>>>      
>>>
>
>
>  
>
>>Feedback welcome - I'm famouse for writing things that nobody 
>>understands so feel free to put up suggestions for improvements.
>>:-)
>>    
>>
>
>For me it was well written. Allthough I have to get to know some of the
>concepts and I hope to go through the example, at least I have
>successfully done a
>
>$ maven merlin-install
>
>and am now ready to do some testing with merlin. - I will use your block
>tutorial for getting started - so look out for my questions ;-) 
>
><personal-interest>
>I noticed that earlier versions that you migrated towards maven - how
>tough was it - since its already a bigger project and you probably had
>to do some maven customization ... .
></personal-interest>
>
>  
>
>>> 
>>>
>>>      
>>>
>>>>>Questions and Design discussion:
>>>>>          
>>>>>
>>I think we can summarise it as:
>>
>>   a) a container is responsible for the deployment of a DU
>>    
>>
>yup.
>  
>
>>   b) a DU may declare logical and physical dependencies
>>   c) logical dependencies are resolved by a container through 
>>deployment of other DU
>>    
>>
>yup.
>
>  
>
>>   d) physical dependencies are resolved by a container based on jar 
>>opional extension dependency declarations
>>    
>>
>exactly.
>  
>
>>I.e. the distinction between a DU and an LU is that a DU should be 
>>viewed as a computation unit whereas a LU is simply a physical artifact.
>>
>>    
>>
>
>Ok this sounds good. I will try to work it into the wiki-draft.
>Allthough apps get deployed by the means of DUs the container 
>loads services from LUs.
>I think hiding too much of LUs from the container makes the API too active
>again - What do you think?
>
>And there are many questions, how inter DU relationship should be modelled,
>as there are so many different scenarios - I will address these issues in 
>another mail.
>
>  
>
>>    
>>
>>>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.
>>> 
>>>
>>>      
>>>
>>Maybe (but I have reervations).  I do think there is scope for an 
>>application bundle which can be condiered as a source for LUs and DUs - 
>>for example, if I want to deploy James as a DU and lets imagine that 
>>James has logical dependecies on a couple of Cornerstone DUs and 
>>structural dependencies on a bunch of Excalibur LUs (jar files).  It is 
>>convinient if there is a application model that I can reference from 
>>which I can get any unresolved Dus or LUs.  Part of this is driven by 
>>liucensing requirements - for example I can bundle the Java Mail API in 
>>a James application bundle and I can deploy a James DU by pulling out 
>>the Java Mail jar from the application bundle and I'm 100% legal.
>>    
>>
>
>Perhaps we could do some meta tagging of DUs, that is left to interpretation
>for the container. For instance the packager could add his 
>"intention" or packaging "strategy" like avoid licensing problems.
>Perhaps that makes sense. 
>I will think about it more thoroghly. The question we have to ask here is 
>what we gain by this packaging strategy. I can imagine in certain 
>environments that this could be helpful.
>
>Dealing with base apis like javamail api or jaxp or sth like that deserves its own
>thoughts. hmmm.
>
>
>  
>
>>>We could then say that contained LUs are loaded by a DU specific
>>>classloader, but then again linking to that LUs is problematic, hmmm.
>>>
>>>      
>>>
>>Why problamatic? Having a classloader load LU physical dependencies is 
>>not a problem.  This is exactly the approach taken in the Assembly 
>>package.   A classloader is associated with a classpath (LUs) and the 
>>classloader handles expansion of the LU[] to include all of the 
>>dependent LUs. Once the classloader is established, the DU[] is 
>>established and the assembly process kicks in.
>>    
>>
>
>I thik it is ideal as long as DUs are kind of islands.
>As soon as inter DU usage is needed this could become a little bit problematic.
>
>If we divide the LUs in specs and impls and load the specs in a common class loader
>and the impl in the DU class loader would perhaps work out - whats your opinion on that?
>[since the spec has its own version, we'd only had to reload the specs when a new spec 
>version is introduced ] - spec version incompatibilites are another story though. In this 
>case we should establish another spec class loader.
>
>  
>
>>>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. 
>>>
>>>      
>>>
>>JBoss can improve!
>>    
>>
>you couldn't bee more right, but I threw it up since they had lots of 
>IllegalAccessExceptions because of the class loader model.
>Especially inter DU relationsships could be a pain here - since then you 
>have several class loader sub-trees.
>
>  
>
>>The hierarchical class loading modelis fine providing you overlay on 
>>that a service model that is not subject to the same restrictions.  For 
>>example - in a classloader hierachy A-B-C, you may have a component in C 
>>that is producing a service that can be used in A or B.  That's 
>>orthoginal to the notion of isolation which typically addresses 
>>implementation classes.  However - to do this sort of thing you really 
>>need to get your impl/inferface seperation sorted - and this isn't a 
>>general practice.
>>
>>    
>>
>>>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 ;-)
>>> 
>>>
>>>      
>>>
>>Yep.
>>
>>In effect you need a mechanism (maybe just a the DU level) that lets you 
>>override jar dependency information.  This is achivable if you have 
>>control over the extension source within a particular classloader.  For 
>>example, I can declare a classloader that is associated with a set of 
>>extension locations - these locations get searched before location in 
>>the parent classloader.  This lets me put in place an alternative LU 
>>resolution to handle those cases where you need a special version of the 
>>same version (I you know what I mean).
>>
>>    
>>
>>>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.
>>>
>>>      
>>>
>>This is the direction Merlin is heading in.
>>
>>    
>>
>great.
>  
>
>>OK
>>This sounds similar to what David Bernard is working on (see posts on 
>>users@avalon).
>>    
>>
>
>sounds interesting. Will check it out. 
>Is the info solely in the mail-archive? (or something in cvs already)
>  
>
>>
>>    
>>
>
><big-snip /> 
>I'll try to answer the rest of our conversation tomorrow.
>(looking forward to ;-) )
>
>-- Jakob
>  
>
>>> 
>>>
>>>      
>>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>  
>

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.



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