cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Michels <step...@apache.org>
Subject Re: [RT] Finishing the first phase of block design
Date Fri, 10 Oct 2003 11:42:49 GMT


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.

> 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.

> 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.

Stephan Michels.


Mime
View raw message