commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [discovery] URL's, Java 1.2... problem.
Date Wed, 21 Aug 2002 16:44:18 GMT
On Wed, 21 Aug 2002, Richard Sitze wrote:

> BUT...  getResources() is unique to Java 1.2.  We are suppose to be 
> backward compatible with 1.1.8.  An original goal of mine was to use this 
> WITHIN commons-logging LogFactory (supports 1.1.8+).  That means we cannot 

You may notice that getResources() is used in a class ServiceDiscovery12
and there is a mechanism to return a ServiceDiscovery11 if such VM is 

The implementation of getResources() on 1.1 is a bit difficult, but 
possible for most class loaders in common use ( eventually with minimal 
changes ). All you need is access to the classpath - and then some
code ( cut&paste from antclassloader or tomcat SimpleClassLoader for 
example ) to split the classpath and implement getResources. Most 
classloaders for 1.1 support a method to get this, or can do it with 
minimal changes. 

In the worse case the code can fall back to getResources - it'll 
still be able to discover the first driver ( which is what 
jaxp/commons-logging do anyway ). 

That means that discovering resources in 1.1 with a class loader that
doesn't provide access to classpath is not possible. Same is true
for supporting dependencies in MANIFEST, and many other things. We 
don't ( and can't ) change anything.

> use commons-logging internally (and it would be nice to), because we would 
> be introducing a circular dependency.  Note that a dependency ALREADY 
> exists because we use commons-logging in the test code.

If we keep the code simple, we can avoid using logging in our code
( and use exceptions  ). The test code is a separate package / issue - it 
may depend on junit or any other packages, that shouldn't count as 

> I'm thinking that the services already offered by 'discovery' are 
> sufficient for APPLICATION developers looking to pull in pluggable 
> modules.

If the 's' at the end of modules was intentional - I agree.
I don't think discovery is that usefull if it is used to locate 
a single pluggable component - even if this can be used in some
cases ( like jaxp and logging ). And I certainly don't think it 
can/should try to abstract a preference-selection mechanism or
semantics for the discovered resources.

> For more sophisticated tooling and frameworks, your services work is 
> clearly a better direction.

I don't know about 'sophisticated' - I am thinking about ant and tomcat, 
and I'm trying to simplify some things. If it ends up 'sophisticated',
then it's a failure :-)

> So many choice.. buffet today:
> (a) drop 1.1.8 entirely?
-1. Keep it low priority for now ( until we finish the APIs and get things
stable ), but it can and should be done. 

> (b) drop the services work, or find alternatives?

Not sure what you mean.

> (c) cut a release that supports 1.1.8 (that presumes that we can all agree 
> that the service is usable as-is :-) and then move on?

See (a)

> (d) use commons-logging internally or let commons-logging use discovery?

-0 on using commons-logging - +1 on commons-logging using discovery.

If we end up with a circular dependency it'll only mean that discovery and
logging must allways be bundled. Not very nice for those who just don't
want to use commons-logging - but they probably won't use discovery 
either, or if they want they should get involved.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message