Bug 52607 - It is not well defined how "Dependencies on extensions" mechanism can be used in Tomcat
It is not well defined how "Dependencies on extensions" mechanism can be used...
Status: RESOLVED FIXED
Product: Tomcat 7
Classification: Unclassified
Component: Catalina
7.0.25
All All
: P2 normal (vote)
: ---
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2012-02-05 22:19 UTC by Violeta Georgieva
Modified: 2012-02-08 21:19 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Violeta Georgieva 2012-02-05 22:19:35 UTC
Hi,

As a result of the mail thread [1] I'm opening a bug.

In short it is not clear how exactly "Dependencies on extensions" mechanism can be used.

I have two proposals:

1. Tomcat can continue to use in its implementation a separate property ("catalina.ext.dirs") that provides extensions' location. But its value should be added by default to the Tomcat's classpath directories (e.g. "shared.loader").
- Pros: Tomcat users will know that this property specifies the directory for their extensions and only the files located there will be scanned during ExtensionValidator.validateApplication invocation.
- Cons: Additional configuration that has to be maintained.

2. Tomcat can remove this separate property ("catalina.ext.dirs") and start searching for such extensions in the Tomcat's classpath directories (e.g. shared.loader).
- Pros: No additional configuration is needed. One can specify the shared libraries and the extensions with one and the same property.
- Cons: During ExtensionValidator.validateApplication, it may appear that a lot of files are scanned which might be not necessary.

I'm willing to provide a patch once we agree on the solution. My favourite is the first proposal.

I'm looking forward to your comments.
Thanks in advance.

Regards,
Violeta Georgieva

[1] http://marc.info/?t=132827584600009&r=1&w=2
Comment 1 Mark Thomas 2012-02-08 17:29:01 UTC
I'm tempted by 2 (I like the easy life) but I'll take a look at 1 and see if there is a way to add the directories defined by catalina.ext.dirs to the shared class loader.
Comment 2 Mark Thomas 2012-02-08 20:14:22 UTC
I've done some svn archaeology and r302820 is most enlightening.

Originally, only java.ext.dirs was supported. r302820 was the start of exposing the common and shared class loaders to the validation mechanism.

I don't see any intention of providing a separate directory. Given that the spec says that extensions have to be loaded by the shared class loader, I also don't see any benefit in having an additional system property. It is simpler for users just to modify the class path for the shared (or common - it meets the requirements of the spec too) class loader.

However, the problem remains that the ExtensionValidator will not find the JARs in the shared or common class loaders. That certainly needs to be fixed.

I guess that is the long way of saying I think 2 is the way to go.
Comment 3 Mark Thomas 2012-02-08 21:19:39 UTC
This has been fixed in trunk and 7.0.x and will be included in 7.0.26 onwards.

JARs need to be visible to the common or shared class loader. If you want to use a separate directory us this in catalina.properties:
shared.loader=${catalina.base}/ext/*.jar