cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Finishing the first phase of block design
Date Fri, 10 Oct 2003 12:02:11 GMT

On Friday, Oct 10, 2003, at 13:42 Europe/Rome, Stephan Michels wrote:

> On Fri, 10 Oct 2003, Stefano Mazzocchi wrote:
>> On Friday, Oct 10, 2003, at 11:04 Europe/Rome, Stephan Michels wrote:
>>>>>> Exposing classes
>>>>>> ----------------
>>>>>> Stephen proposed to separate the classes to expose in a different
>>>>>> jar
>>>>>> and expose that. I like this. It's simple and effective.
>>>>>> But instead of declaring classloaders or classpaths in the 
>>>>>> blocks, I
>>>>>> propose to extend the block FS layout so that we have
>>>>>> for individual classes and resources:
>>>>>>  /classes
>>>>>>  /classes/public
>>>>>>  /classes/private
>>>>>> for jars:
>>>>>>  /lib
>>>>>>  /lib/public
>>>>>>  /lib/private
>>>>> Hmmm.  That is quite different than what one would expect from the
>>>>> WAR
>>>>> paradigm, no?  Would
>>>>> COB-INF/[classes|lib]
>>>>> COB-INF/public/[classes|lib]
>>>>> or
>>>>> COB-INF/private/[classes|lib]
>>>>> COB-INF/public/[classes|lib]
>>>>> be any better?
>>> Could you please explain, why we need to separate the classes and lib
>>> into
>>> private and public. For the developers POV, it will make the
>>> development
>>> more complicated, and doesn't see any benefit.
>> to better isolate classloader and the contracts that are exposed by 
>> the
>> block. make development more complicated but forces people to think of
>> application contracts that can be later reused as global behaviors.
> Your intentions are good, but do you really want to force them.


> And how do you realize this. Do you what to cut the whole source
> path into two separate branches, or using javadoc statement.

it's just a matter of packaging the classes after having compiled them. 
not such a big deal and, after all, a detail that each block developer 
can take care of itself.

if he doensn't like peparation, he can stick everything into the public 
part and forget about it... but shouldn't later come complianing if he 
exposes public methods that were not really meant to be public.

>> think of it as a generalization of a collection of interfaces and data
>> structures that are passed around. like JAXP+Xerces jaxp is public,
>> xerces should not be, otherwise the public methods of the xerces
>> classes can be hooked up and later broken if a new implementation of
>> JAXP comes around.
> I doesn't think that a separation between private and public classes
> is quite easy.

Exactly. It forces to design your contracts. That's a good thing.

>> also reduces the potential problems with hot deployment for
>> classloading dependencies
> You will have the same problem, if you separates them into public and
> private. The classes, which are used by initiated objects, can't
> exchanged.

True, but the public zone will be done with mostly interfaces and data 
models, the functional classes that are likely to change are 
polymorphically managed by the component manager, you shouldn't be 
calling "new object()" anyway, this is just done to expose the classes 
that are created by the components.

remember that we are still forcing the people to use the basic avalon 
component model of polymorphic delegation.


View raw message