Project

General

Profile

Feature #125

SQS-Util ClassURLStreamHandlerFactory cannot be used in web app

Added by Michele Vivoda over 7 years ago. Updated over 7 years ago.

Status:
Assigned
Priority:
medium
Assignee:
-
Category:
Common
Target version:
Start date:
2012-04-26
Due date:
% Done:

0%

Estimated time:

Description

I think that a part of the architecture used for URL resolution cannot be used in a web application,
because it uses a URLStreamHandlerFactory configured in URL.setURLStreamHandlerFactory static method.

the javadoc for URL.setURLStreamHandlerFactory says

Sets an application's URLStreamHandlerFactory. This method can be called at most once in a given Java Virtual Machine.

Since all web apps run in the same VM I am almost sure one cannot influence the others so it should not be allowed,
and in fact in Tomcat does not work, alternatively is probably just not desiderable.

The solution for me to restructure a little the ClassURIResolver and have it resolve the class: pseudo URI without defering to java.net.URL that in turn defers to ClassURLStreamHandlerFactory. To do this I had to isolate some code from ClassURLStreamHandlerFactory in a separate class.

History

#1 Updated by Hiroya Kubo over 7 years ago

I think ClassURLStreamHandlerFactory is required by portable Apache FOP configuration ( http://xmlgraphics.apache.org/fop/1.0/configuration.html ) using JNLP.

In the Apache FOP configuration, several TrueType font files and font metrics files are specified by URLs. Such configuration process of Apache FOP is too much complicated for application users, so it will be a good idea to deploy pre-configured Apache FOP and a set of resource files.

BTW, what URL scheme is used in the Apache FOP configuration file?

The "file:" URL scheme is normally used in most cases. However, there are some problems in JNLP launched applications. First, it is not preferable to access local filesystem by a JNLP-launched application. Second, as for using code signing to allow the application to access local filesystem, it will be heavy and unreliable to expand required files at the startup of the application.

The "http:" URL scheme may be considerable. We can use it within JNLP launched applications with embedded http server like Jetty. However, it will be troublesome because it depends on runtime network environment and proxy configuration.

In conclusion, for the time being, the "class:" URL scheme is used to enable a JNLP application to access to java class resources in JNLP downloaded jar files.

#2 Updated by Hiroya Kubo over 7 years ago

I think two versions of pre-configured Apache FOP may be required:

1. The version using "class:" URL scheme and ClassURLStreamHandlerFactory for JNLP applications.

2. The version using normal "file:" URL scheme for servlet etc.

#3 Updated by Michele Vivoda over 7 years ago

The [class:] scheme is ok for me, also in Spring Framework for example they use [classpath:] with the same semantics.

However the problem was something like this: 1) all those URI in the document (xsl:include) and configuration are asked to the URIResolver (http://xmlgraphics.apache.org/fop/1.0/embedding.html#config-internal) 2) the current implementation of URI resolver, not able itself to solve the class: scheme itself, is defering to ClassURLStreamHandlerFactory but not directly (with some implementation method) but istantiating a new java.net.URL. Since in tomcat the call to register the ClassURLStreamHandlerFactory did not have effect, the URL class says that class:... is a malformed URL.

I changed my version of URIResolver copying a part of the code of ClassURLStreamHandlerFactory.

In substance, is the handling of class: through URL required or a enhanced URIResolver is sufficient ?

I think is sufficient because with my modified version it works, but I am not aware of FOP and other details ;-)

Handling all through URIResolver has also the advantage that one can make a hierarchy of resolvers and place a cache at some stage (I tried for example to include the class: and http: URI and exclude the barcode: pseudo URI)

Once I set up bitbucket I will submit a sample.

#4 Updated by Michele Vivoda over 7 years ago

I saw you accepted the changes, fantastic this bitbucket, casually a week ago I made the account to share some code (about sqs) with Milos, now you use it as well.. I must say it is very nice.

For me the issue is closed, however I have a question:

I made also a "CachedURIResolver" that can be used by a client providing itself the resolver to sqs.
I use it in a hierarchy like this:

- ClassURIResolver
- CachedURIResolver
- BarcodeURIResolver

I then pass BarcodeURIResolver to sqs, this allows the class-resources and http-resources (eg: html:images for pdf) to be cached (in memory) while the Barcode is never cached.

The question is: where do you think is a good place to put it ? in a new package sqs-util.net2.xslt ? Must say that is used only by translator... I originally placed there ... net2.sqs2.translator.support but I am not sure ;-)

#5 Updated by Hiroya Kubo over 7 years ago

Michele Vivoda wrote:

I saw you accepted the changes, fantastic this bitbucket, casually a week ago I made the account to share some code (about sqs) with Milos, now you use it as well.. I must say it is very nice.

:-)

For me the issue is closed, however I have a question:

I made also a "CachedURIResolver" that can be used by a client providing itself the resolver to sqs.
I use it in a hierarchy like this:

- ClassURIResolver
- CachedURIResolver
- BarcodeURIResolver

I then pass BarcodeURIResolver to sqs, this allows the class-resources and http-resources (eg: html:images for pdf) to be cached (in memory) while the Barcode is never cached.

The question is: where do you think is a good place to put it ? in a new package sqs-util.net2.xslt ? Must say that is used only by translator... I originally placed there ... net2.sqs2.translator.support but I am not sure ;-)

I suppose you mean:

  • ClassURIResolver and CachedURIResolver will be placed into sqs-util/src/main/java/net/sqs2/net
  • BarcodeURIResolver will be placed into sqs-translator/src/main/java/net/sqs2/translator/support

I think your design is very reasonable. Please send me your pull request about it.

Thank you.

Also available in: Atom PDF