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