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 manager)
-- Stefano.
