Re: [Proxool-developer] Why embeed external packages?

[Bill H. <bi...@lo...>]

HI Claudio,

On Wed, 2004-01-07 at 20:47, Claudio Destro wrote:

> I think the problem is in the re-writing of "org.apache.commons.logging.Log" 
> property in "org.logicalcobwebs.logging.Log" (internal JCL does not act the 
> same way as external one).

I understand that. We made the decision to repackage all *internal*
dependencies, but logging is not entirely internal so maybe we need to
make a special case for it. It does handle configuration surprisingly
well and will co-exist with the commons' logging library. But there may
be some specific cases here that we need to deal with.

> So, I understand version problems, but why not simply retain external package 
> original names instead of embeed them into org.logicalcobwebs super-package? 

If we used the same package names then it would not be clear which class
was being used - it would depend on the classpath order. I don't think
that is very satisfactory. Class loader issues are best avoided.

Issues:

1) It's nice that Proxool doesn't have any dependencies at the moment.
Some projects can't avoid them, but as long as we can I'd like to.

2) We don't want different behaviour depending on whether other
libraries get loaded first or not.

3) On the other hand, logging should be transparent. If you setup
Commons' logging in your project then Proxool should react correctly.

Maybe the answer is to fix the precise logging problem you are having. I
have never fully understood that "org.apache.commons.logging.Log"
property. Perhaps it's time I did.

Bill