cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] The block protocol
Date Wed, 06 Apr 2005 16:19:41 GMT
Daniel Fagerstrom wrote:
> Stefano Mazzocchi wrote:
>
>> I disagree. You have a world-wide unique identifier (the URI) and a 
>> local name in a well isolated context,  and a wiring table to glue 
>> these together (using the URIs) that's all you need.
> 
> Consider the following case: One of my applications use a repository 
> block, and this repository block has a db connection with name and 
> password as deplyment parameters. If another application need to use the 
> same repository block, but connected to another db it will have other 
> deployment parameters. In this case we will have two deployed instances 
> of the same block with different deployment parameters. How do we differ 
> between them.

Context.

Here is your problem:

  [ Block A -(requires)-> Block C ] -(named)-> 'database'
  [ Block B -(requires)-> Block C ] -(named)-> 'database'

this is the 'structure' of the dependency, not your actual instance.

When you install Block A, the block deployer (thanks Reinhard for 
correcting me) will look for Block C (let's not dicuss the 'how' of this 
now).

The block will be fetched, unpacked, configured and wired. At this 
point, Block C will become known (to A!) as "database" and from the 
block A, you can call "block:database:/" and that *instance* of block C 
will respond.

Note that since java classloading is already namespaced, you *DO NOT* 
need to provide a block hint for the classloading: if Block C provides a 
class called

  org.myhost.myapp.myblock.Database

you flowscript in block A can call

  cocoon.getComponent("org.myhost.myapp.myblock.Database")

and obtain that *instance*, configured as you wanted at installation 
time (here, you will be asked for username/password/jdbc-url etc.).

Now, later on, you install Block B, which requires an instance of Block 
C. You already have one installed, so the block deployer will ask you if 
you want to reuse that instance or another one.

at this point, if you want to use another instance (keep the code, but 
change the behavior thru different configurations!), the block manager 
(and its internal classloader and sitemap mounter) will make sure that 
if you call block:database:/ from block B, you end up in *another* 
instance, with different configurations and different parameters.

-- 
Stefano.


Mime
View raw message