You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@apache.org> on 2003/04/26 17:35:39 UTC
Re: LUs,DUs,Bundles [Was: [RT] Distilling the requirements for Block
Support]
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.
Jakob Praher wrote:
>hi Peter,
>hi all,
>
>for everyone joining the discussion:
>[LU .. Library Unit]
>[DU .. Deployable Unit]
>
>I distilled our ongoing discussion (which I find very constructive and
>interesting) about DUs and LUs in a new message to decrement the entropy
>level. [;-)]
>
>
>Regarding Bundles (Berin)
>
>I have followed the thread on Bundles with great interest, an am very
>glad that you brought up the discussion. I have looked at CFBundle and
>CFPlugin (which is a lightweight COM spec on top of CFBUndle). In
>Peter's terms CFBundle would be described as DU. [please correct me if I
>am wrong in your opion] - It can contain executable code, library code,
>configuration and resources (localizables and global resources). I think
>we could look at some of the structures (plist especially). I must
>confess I have never used the CFBundle API, but would like to by a
>Titanium, if I had enough money.
>
>
>API Design [Active vs Passive]
>
>If I got that right, you mean that the class represenatatives of LUs and
>DUs should only contain the meta information (merely data), not
>algorithms how to do something with them, except very simple things.
>This is something you do with XxxService or XxxManager clases - right?
>
>
>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.
>Not all DUs provide all the LUs. (which mean contains).
>Should there be a distinction between DUs that are mainly library DUs
>(kind of plugins) and DUs that are apps.
>
Why?
The notion of app is simply a DU that does not expose/export/publish a
service. That's not much of a distinction if you DU model supports
publication of 0..n services.
>
>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).
>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.
>
>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.
>
>* 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.
>* 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.
>* Dependecy information
>
>Where should the LU dependency (which means depending on certain LUs) go
>to?
>
Inside a descriptor - not in the manifest.
>Does it make sense to put it in the DU meta descriptor?
>
Yes.
>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.
>
>* DU usagae scenarios
>
>The question: Who uses as DU, and how?
>
DU can be used by people or applications that are assembly new components.
>In my opinion: Depends on the environment. [As you said]
>
>- ECM Style container environment:
>Most of the time use will stay within the DU itself. The only thing that
>occurs that some LUs are not contained but external used. Or on the
>other hand if the DU itself provides LUs to other DUs. (bidirectional)
>
>Here some kind of micro kernel would make sense.
>DU unloading/loading listeners would also make sense, which other DUs
>can subscribe to. [as you already said]
>
>- Cocoon/Webapp Style container environment:
>The Core framework, for instance Sitemap Processor, will use the DUs to
>satisfy requests.
>If every usage would be bounded to a request/response cycle, everything
>would be find, but: Session state! - Some classes of a DU/LU might get
>stored in a session state.
>
>* Configuration and Meta Data
>
>How should we define profiles/meta data?
>
>
Yes.
>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.
Cheers, SJM.
--
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
Re: LUs,DUs,Bundles [Was: [RT] Distilling the requirements for Block
Support]
Posted by 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
Re: LUs,DUs,Bundles [Was: [RT] Distilling the requirements
for Block Support]
Posted by 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]
Posted by Stephen McConnell <mc...@apache.org>.
Jakob Praher wrote:
>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 ;-)
>
Feedback welcome - I'm famouse for writing things that nobody
understands so feel free to put up suggestions for improvements.
:-)
>
>
>
>>>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
>important.
>
>
I think we can summarise it as:
a) a container is responsible for the deployment of a DU
b) a DU may declare logical and physical dependencies
c) logical dependencies are resolved by a container through
deployment of other DU
d) physical dependencies are resolved by a container based on jar
opional extension dependency declarations
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.
>
>
>>>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 dependency 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
>mimium:
> - 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.
>
I agree.
>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.
>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.
>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!
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).
>
>
>>>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.
>
This is the direction Merlin is heading in.
>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).
>
>
Yep.
>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]
>
>
>
OK
This sounds similar to what David Bernard is working on (see posts on
users@avalon).
>
>
>>>* 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.
>
I don't see a conflict here.
If you take a look at the
sandbox\merlin\merlin-smp\src\tutorial\composition package you will find
an example of the usage of a set of resources in both scenarios.
Assuming you have Merlin installed ...
$ cd tutorial
$ cd composition
$ ant install
This generates a services of jar files:
composition-api-1.0.jar
composition-application-1.0.jar
composition-location-1.0.jar
composition-publisher-1.0.jar
Of the above, composition-api-1.0.jar is a LU (its just a jar file).
The other three are DU but they can also be used as LUs. To see this
all in action as pure LUs, you can execute the following demo:
$ merlin src\config\block2.xml
[INFO ] (sys): initialization: localhost
[INFO ] (sys): commencing block assembly phase
[INFO ] (application): servicing application
[INFO ] (application.locator): location: Paris
[INFO ] (application.publisher): created
[INFO ] (application.publisher):
******************
* Paris
******************
[INFO ] (application): done
[INFO ] (sys): Block hierarchy established.
[INFO ] (sys): commencing decommissioning phase
[INFO ] (application): disposal
[INFO ] (application.locator): disposal
[INFO ] (application.publisher): disposal
[INFO ] (sys): bye
In this case the block2.xml is simply a directive telling Merlin what to
do with these LUs. Here is the content of block2.xml. It simply
declars a classloader (the engine directive) that contains the four jar
files and a single directive to fire up the application component.
<block>
<info>
<name>tutorial</name>
</info>
<implementation>
<engine>
<classpath>
<repository>
<resource id="tutorial:composition-api" version="1.0"/>
<resource id="tutorial:composition-location" version="1.0"/>
<resource id="tutorial:composition-publisher" version="1.0"/>
<resource id="tutorial:composition-application" version="1.0"/>
</repository>
</classpath>
</engine>
<component name="application"
class="tutorial.application.Application" activation="startup"/>
</implementation>
</block>
Compare the above to the following block.xml directive. The difference
is that there is only one LU in the classloader - the rest of the
directives are treating the last jar fiels as DUs,
<block>
<info>
<name>tutorial</name>
</info>
<implementation>
<engine>
<classpath>
<repository>
<resource id="tutorial:composition-api" version="1.0"/>
</repository>
</classpath>
</engine>
<include id="tutorial:composition-publisher" version="1.0"/>
<include id="tutorial:composition-application" version="1.0"/>
<include id="tutorial:composition-location" version="1.0"/>
</implementation>
</block>
The import lines above are the includes -- they are establishing a set
of services and Merlin is doing the work of assembly of the DUs so that
everything makes sense (for example - the application DU has service
dependencies on a location service and a publishing service). Merlin
ensures that these DU are wired together before deployment based on
service level dependency resolution. This is something that hapens
after physical/structural dependecy resoution with respect to a DUs role
as an LU.
Executing the above directive can be done by:
$ merlin src\config\block.xml
[INFO ] (sys): initialization: localhost
[INFO ] (sys): commencing block assembly phase
[INFO ] (sys): Block hierarchy established.
[INFO ] (location-block.location): location: Paris
[INFO ] (location-block): initialization
[INFO ] (publisher-block.publisher): created
[INFO ] (application-block.application): servicing application
[INFO ] (publisher-block): initialization
[INFO ] (publisher-block): initialization
[INFO ] (publisher-block.publisher):
******************
* Paris
******************
[INFO ] (application-block.application): done
[INFO ] (application-block): initialization
In the above example - "publisher-block" is a DU that is providing a
publishing service. Same case for "location-block" - and
"application-block" is hosting "application". All three are DUs. But
as you can see - that function perfectly as LUs as well.
>
>In my view you should be able to throw a DU into a container and work
>with it.
>
>
Absolutely.
>>>* 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
>
Switching to your other email - yes - your interpritation is correct -
just use the optional extension loading mechanism. Anything else should
be stated elsewhere.
>
>
>>>* 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?
>
For an LU, it structural dependecies should be declared in the manifest.
For a DU the dependencies are functional (ie. service dependecies and so
on) and these should be included in a DU descriptor (e.g. block.xml).
>
>
>
>>>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.
>>
>>
>exactly.
>
>
>
>>>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 resolsibility of a DU. A container should 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.
>
Yep. But keep in mind that your dealing with:
(a) type descriptors
(b) servive descriptors
(c) defaults associated with a type
(d) deployment templates
(e) deployment scenarios
(f) overriding configurations
So far, just doing (a-b) with javadioc tags is only OK for the simple
cases (but does cover probably 90% of real world requirements). My own
opinion is that interactive tools are things needed to support (c-f).
>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).
>
Just for reference - there is a tutorial specifically about handling
multiple configuration.
$ cd tutorial
$ cd includes
$ ant install
$ merlin src\config\block.xml
[INFO ] (sys): initialization: localhost
[INFO ] (sys): commencing block assembly phase
[INFO ] (test1): source: config.xml
[INFO ] (sys): Block hierarchy established.
[INFO ] (subcontainer.test2): source: config.xml
[INFO ] (subcontainer): initialization
[INFO ] (subcontainer.composite): initialization
[INFO ] (subcontainer.inclusion.test3): source: config.xml
[INFO ] (subcontainer.inclusion): initialization
[INFO ] (subcontainer.composite.inclusion.test3): source: config.xml
[INFO ] (subcontainer.composite.inclusion): initialization
[INFO ] (subcontainer.composite.test): initialization
[INFO ] (subcontainer.composite.test.inclusion.test3): source:
include-config.xml
[INFO ] (subcontainer.composite.test.inclusion): initialization
[INFO ] (sys): commencing decommissioning phase
[INFO ] (sys): bye
The above block.xml contains directives to use a variety of different
configuration sources - any you can see from the output that the source
of the configration for particular components is being overriden.
>The deployer then should have the means to override the default
>configuration in the DU.
>
Yep.
>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)
>
Yep.
E.g. James admin username and password - you want to package the
standard configuration as a application profile (block.xml) and then
override this with a couple of fragments (in Merlin these are referred
to as override Targets).
>
>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 ;-).
>
>
Agreed.
>But once again, I think the LUs should contain the information, what
>*is* configurable.
>
>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:simpleType>
> <xsd:restrition type="xsd:string">
> <xsd:enumeration value="blue" />
> <xsd:enumeration value="red" />
> <xsd:enumeration value="..." />
> </xsd:restriction>
> </xsd:simpleType>
> </xsd:element>
>
></configuration-schema>
>
>this is just to stress what I mean with configuration templates.
>
>
This is something I would like to see in Merlin - does not exist at the
moment. Merlin provides configuration profile but does not include
configuration meta information - i.e. no information about what is
allowable inside a configuration. It's about the only thing missing on
the (a-f) list mentioned above.
Cheers, Steve.
>
>-- 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
>
>
>
>
>
--
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
Re: LUs,DUs,Bundles [Was: [RT] Distilling the requirements for
Block Support]
Posted by Jakob Praher <jp...@yahoo.de>.
Am Sam, 2003-04-26 um 21.02 schrieb Jakob Praher:
> >
> > >* 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
sorry my answer is plain stupid. But how do you mean "just use the
optional extension mech." - I suppose you it meant that LU info should
use the optional extension mechanism, nothing more. Everything else
should be stated elsewhere?
[so in the DU meta descriptor - ?]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
---------------------------------------------------------------------
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]
Posted by Jakob Praher <jp...@yahoo.de>.
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
important.
>
> >
> >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
mimium:
- 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.
exactly.
>
> >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:simpleType>
<xsd:restrition type="xsd:string">
<xsd:enumeration value="blue" />
<xsd:enumeration value="red" />
<xsd:enumeration value="..." />
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</configuration-schema>
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