You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stephan Michels <st...@apache.org> on 2003/10/10 13:22:20 UTC
[RT] Component manager, classloader and blocks
Hi,
Since some days I thought about how implement blocks with smallest
amount of work. (small ist beautiful)
Most of the work is already finished, if we look into the 'unreal'
block in the CVS repository. We have
a classes, libs, a sitemap, a xconf file and some custom files.
We could easily pack them into a zip file.
What need:
For every block we need
* a block URI, which identifies it.
* statements about dependecies to other blocks.
* Component manager, for a separate cocoon.xconf
* Sitemap proccessor for the root sitemap of the block
* A classloader for each block, which were exchange if the
the block has changed.
The simplest form to include the information about the block
URI and the dependencies is to use the sitemap for it, for example
<map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">
<map:block uri="http://apache.org/cocoon/block/myblock/1.0">
<map:import block="basic" uri="http://apache.org/cocoon/block/basic/1.0"/>
</map:block>
For the sitemap components we need two component manager for
handling the 'public' and 'private' components.
+---------------+ +---------------+
| myblock | | basic |
| +-----------+ | lookup | +-----------+ |
| | public cm |-+--------+>| public cm | |
| +-----------+ | | +-----------+ |
| ^ | | ^ |
| | lookup | | | lookup |
| | | | | |
| +-----------+ | | +-----------+ |
| | private cm| | | | private cm| |
| +-----------+ | | +-----------+ |
| ^ | | ^ |
| | lookup | | | lookup |
| | | | | |
| +----------+ | | +-----------+ |
| | sitemap | | | | sitemap | |
| +----------+ | | +-----------+ |
| | | |
+---------------+ +---------------+
Another difficult part is about the dependecies of the CMs between
subsitemaps (I doesn't have a solution). I think subsitemaps
are a contrary solution to blocks, perhaps we should rethink the
subsitemaps.
To prevent component name collisions within, we could use prefixes like
<match type="basic:wildcard" pattern="*.html"
<map:generate type="basic:file" src="{1}.xml"/>
<map:transform type="basic:xsl" src="mystyles.xsl"/>
<map:transform type="mytransformer"/>
<map:serialze type="basic:html"/>
If there is no name collision, you can leave out the prefix.
The problem is that the current CM model doesn't support
such a kind of prefix, but it doesn't need to, because
the sitemap processor can resolve the prefix, and know
which CM to ask for.
For the classes and libs itself, I think separate them into public
and private isn't necessary for the first step.
A cheap solution is use following FS within a zip file:
myblock.zip
/COB_INF/classes
/COB-INF/lib
/COB-INF/componts.xconf
/sitemap.xmap
/[whatever]
Every block get his own classloader, and if the block has changes
the classloader will be exchanged. Each depending block has
a parent classloader, which will be consulted if the current
classloader doesn't know the class.
My unsorted braindump, Stephan.
> cat /dev/brain | grep "blocks" | mail dev@cocoon.apache.org
_______________________________________________________________________
Stephan Michels EMail: stephan@apache.org
ICQ: 115535699 Tel: +49-030-314-21583
----+----|----+----|----+----|----+----|----+----|----+----|----+----|-|
Re: [RT] Component manager, classloader and blocks
Posted by Stefano Mazzocchi <st...@apache.org>.
On Sunday, Oct 12, 2003, at 12:21 Europe/Rome, Stephan Michels wrote:
>
>
> On Fri, 10 Oct 2003, Stefano Mazzocchi wrote:
>
>>
>> On Friday, Oct 10, 2003, at 13:22 Europe/Rome, Stephan Michels wrote:
>>
>>> To prevent component name collisions within, we could use prefixes
>>> like
>>>
>>> <match type="basic:wildcard" pattern="*.html"
>>> <map:generate type="basic:file" src="{1}.xml"/>
>>> <map:transform type="basic:xsl" src="mystyles.xsl"/>
>>> <map:transform type="mytransformer"/>
>>> <map:serialze type="basic:html"/>
>>
>> name collision of what? you define the names of the components. those
>> are the prefixes already, the classes are the real names of the
>> components and they are already fully qualified to avoid collisions.
>
> Okay, I think you mean, (for example) if you want to use a generator
> from
> block 'basic', you can write easly
>
> myblock:sitemap.xmap:
> <map:components>
> <map:generators>
> <map:generator name="file" src="basic.BasicGenerator"/>
>
> But in this case you doesn't gain anything more than from avalon block.
> I want to share these components by the @type insteadof the class name.
>
> For example virtual components can only be shared with @name/@type
> names.
>
> Now, if you a block, which depends on block, which shares
> components with the same type, you will have conflict.
>
> One possible solution is to use prefixes, which allow to map names
> to block IDs.
hmm, I don't think these conflicts are a problem since it's *you* that
name the components with hints, not the block that exposes them.
>>> For the classes and libs itself, I think separate them into public
>>> and private isn't necessary for the first step.
>>
>> Either we do this right away or it's going to be painful later on. I
>> would be against such an half-step (also because classloading
>> complexity isn't that much different with the two paths)
>
> Here we do have different opinions. I'm curious about the opinions
> from the others.
>
> One question, separate the avalon block the classes into
> public/private?
>
> Stephan.
>
>
>
--
Stefano.
Re: [RT] Component manager, classloader and blocks
Posted by Stephan Michels <st...@apache.org>.
On Fri, 10 Oct 2003, Stefano Mazzocchi wrote:
>
> On Friday, Oct 10, 2003, at 13:22 Europe/Rome, Stephan Michels wrote:
>
> > To prevent component name collisions within, we could use prefixes like
> >
> > <match type="basic:wildcard" pattern="*.html"
> > <map:generate type="basic:file" src="{1}.xml"/>
> > <map:transform type="basic:xsl" src="mystyles.xsl"/>
> > <map:transform type="mytransformer"/>
> > <map:serialze type="basic:html"/>
>
> name collision of what? you define the names of the components. those
> are the prefixes already, the classes are the real names of the
> components and they are already fully qualified to avoid collisions.
Okay, I think you mean, (for example) if you want to use a generator from
block 'basic', you can write easly
myblock:sitemap.xmap:
<map:components>
<map:generators>
<map:generator name="file" src="basic.BasicGenerator"/>
But in this case you doesn't gain anything more than from avalon block.
I want to share these components by the @type insteadof the class name.
For example virtual components can only be shared with @name/@type
names.
Now, if you a block, which depends on block, which shares
components with the same type, you will have conflict.
One possible solution is to use prefixes, which allow to map names
to block IDs.
> > For the classes and libs itself, I think separate them into public
> > and private isn't necessary for the first step.
>
> Either we do this right away or it's going to be painful later on. I
> would be against such an half-step (also because classloading
> complexity isn't that much different with the two paths)
Here we do have different opinions. I'm curious about the opinions
from the others.
One question, separate the avalon block the classes into public/private?
Stephan.
Re: [RT] Component manager, classloader and blocks
Posted by Stefano Mazzocchi <st...@apache.org>.
On Friday, Oct 10, 2003, at 13:22 Europe/Rome, Stephan Michels wrote:
> Hi,
>
> Since some days I thought about how implement blocks with smallest
> amount of work. (small ist beautiful)
>
> Most of the work is already finished, if we look into the 'unreal'
> block in the CVS repository. We have
> a classes, libs, a sitemap, a xconf file and some custom files.
> We could easily pack them into a zip file.
yes
> What need:
>
> For every block we need
> * a block URI, which identifies it.
yes
> * statements about dependecies to other blocks.
yes
> * Component manager, for a separate cocoon.xconf
well, not sure about this.
> * Sitemap proccessor for the root sitemap of the block
yes
> * A classloader for each block, which were exchange if the
> the block has changed.
Sylvain has an idea on how we can do transparent classloading directly
with a chain on component managers. Sylvain?
> The simplest form to include the information about the block
> URI and the dependencies is to use the sitemap for it, for example
>
> <map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">
> <map:block uri="http://apache.org/cocoon/block/myblock/1.0">
> <map:import block="basic"
> uri="http://apache.org/cocoon/block/basic/1.0"/>
> </map:block>
-1
a block needs a descriptor that contains metadata for the librarian.
> For the sitemap components we need two component manager for
> handling the 'public' and 'private' components.
>
> +---------------+ +---------------+
> | myblock | | basic |
> | +-----------+ | lookup | +-----------+ |
> | | public cm |-+--------+>| public cm | |
> | +-----------+ | | +-----------+ |
> | ^ | | ^ |
> | | lookup | | | lookup |
> | | | | | |
> | +-----------+ | | +-----------+ |
> | | private cm| | | | private cm| |
> | +-----------+ | | +-----------+ |
> | ^ | | ^ |
> | | lookup | | | lookup |
> | | | | | |
> | +----------+ | | +-----------+ |
> | | sitemap | | | | sitemap | |
> | +----------+ | | +-----------+ |
> | | | |
> +---------------+ +---------------+
sounds resonable.
> Another difficult part is about the dependecies of the CMs between
> subsitemaps (I doesn't have a solution). I think subsitemaps
> are a contrary solution to blocks, perhaps we should rethink the
> subsitemaps.
I don't see this, nor I see a problem with subsitemaps, they'd simply
cascade back to the parent sitemap as they normally do.
> To prevent component name collisions within, we could use prefixes like
>
> <match type="basic:wildcard" pattern="*.html"
> <map:generate type="basic:file" src="{1}.xml"/>
> <map:transform type="basic:xsl" src="mystyles.xsl"/>
> <map:transform type="mytransformer"/>
> <map:serialze type="basic:html"/>
name collision of what? you define the names of the components. those
are the prefixes already, the classes are the real names of the
components and they are already fully qualified to avoid collisions.
> If there is no name collision, you can leave out the prefix.
> The problem is that the current CM model doesn't support
> such a kind of prefix, but it doesn't need to, because
> the sitemap processor can resolve the prefix, and know
> which CM to ask for.
I can't see the problem.
> For the classes and libs itself, I think separate them into public
> and private isn't necessary for the first step.
Either we do this right away or it's going to be painful later on. I
would be against such an half-step (also because classloading
complexity isn't that much different with the two paths)
> A cheap solution is use following FS within a zip file:
>
> myblock.zip
> /COB_INF/classes
> /COB-INF/lib
> /COB-INF/componts.xconf
> /sitemap.xmap
> /[whatever]
>
> Every block get his own classloader, and if the block has changes
> the classloader will be exchanged. Each depending block has
> a parent classloader, which will be consulted if the current
> classloader doesn't know the class.
Yes but keep in mind that classloading and component management must go
hand in hand.
--
Stefano.