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? Reinhard