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