avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: LUs,DUs,Bundles [Was: [RT] Distilling the requirements for Block Support]
Date Tue, 29 Apr 2003 14:01:28 GMT


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


Mime
View raw message