cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Implementing Cocoon Blocks
Date Fri, 19 Sep 2003 13:47:50 GMT

On Thursday, Sep 18, 2003, at 21:09 Europe/Rome, Reinhard Poetz wrote:

> From: Stefano Mazzocchi
> <snip/>
>>   3) persistent service behavior with hot deployment
>> One of the big issues with hot deployment is the potentially
>> inconsistent state of the persistent services contained by one block
>> and used by another when the providing block is redeployed.
>> The issue is easily solvable for block services provided via
>> sitemap by
>> imposing them as stateless services (or REST-like, by passing all the
>> required information every time).
>> The problem appears evident for component instances.
>> It is suggested that blocks don't allow direct classloading between
>> blocks, but that only components exposed in the block deployment
>> descriptor will be made available to other blocks. This way, all the
>> dependencies are known because all the component loading happens thru
>> the Block Manager and the block manager is able disposte and
>> reinstantiate all the blocks that contain instances of
>> components that
>> are in an inconsistent state.
>> While it is possible to write a classloader which is smart
>> enough to do
>> the above even for transparent classloading (say, loading via "new
>> Blah()" instead of via cocoon.getComponent("Blah")), it is
>> suggested to
>> disallow direct classloading to avoid creating hidden
>> contracts between
>> blocks.
> I understand that I can't load a class from another block. My question:
> Is it possible to load classes from "Cocoon core" (whatever we will
> consider as core) from within my block via "new" or are there arguments
> against it?

At least one block will need it: the "block deployer webapp block". 
There could be stuff like "the restarting block" that allows cocoon to 
be restarted from a web page (useful for debugging), or stuff like that.

It is entirely possible to prevent the blocks from having access to 
some classes down under (as bertrand showed) but it might be very hard 
to audit the security of such a scheme.

I'd prefer leave it open and suggest that people use blocks from 
sources they trust. [we will provide digital signing of our blocks to 
avoid trojan problems]

Running a block in a security sandbox is, IMO, way too much, since the 
naked cocoon itself will be sandboxed by the container anyway, so a 
trojan block will not be able to do anything more than a cocoon would 
and the appserver will do the security policy for us.

the only potential issue is for people that run different coocon 
applications in the same cocoon instance and want to isolate them since 
the data flowing in belong to different users (say an ISP) but it would 
be pretty lame if they did so using teh same cocoon instance (people 
normally install different JVM as they don't trust the java security 


View raw message