JDK-6215746 : Disable META-INF/* lookup from codebase in applet/plugin classloader
  • Type: Enhancement
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 1.4.2,1.4.2_05,6
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_8,windows_2000,windows_xp
  • CPU: generic,x86
  • Submitted: 2005-01-10
  • Updated: 2017-05-16
  • Resolved: 2005-10-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6
5.0u3Fixed 6 b28Fixed
Related Reports
Duplicate :  
JDK-4889311 - javax.sound SPI extensions from applet's JAR don't work with plugin
Duplicate :  
JDK-6238729 - Unnecessary request for service provider on the webserver
Relates :  
JDK-6212262 - Printing from an applet throws an exception the first time it is tried.
Description
This issue is with an application logging a print error every time the application performs a print, even though the print is successful. This causes a roundtrip back to the server to log a message that needs to be eliminated.  This is shown, it seems, as a bug but no fix is being provided. 
 
Servlet Error: File not found: META-INF/services/javax.print.PrintServiceLookup: javax.servlet.ServletException: File not found: META-INF/services/javax.print.PrintServiceLookup 
            at com.ibm.servlet.engine.srt.WebAppInvoker.handleInvocationHook(WebAppInvoker.java:227) 
            at com.ibm.servlet.engine.invocation.CachedInvocation.handleInvocation(CachedInvocation.java:67) 
            at com.ibm.servlet.engine.invocation.CacheableInvocationContext.invoke(CacheableInvocationContext.java:106) 
            at com.ibm.servlet.engine.srp.ServletRequestProcessor.dispatchByURI(ServletRequestProcessor.java:154) 
            at com.ibm.servlet.engine.oselistener.OSEListenerDispatcher.service(OSEListener.java:315) 
            at com.ibm.servlet.engine.http11.HttpConnection.handleRequest(HttpConnection.java:60) 
            at com.ibm.ws.http.HttpConnection.readAndHandleRequest(HttpConnection.java:332) 
            at com.ibm.ws.http.HttpConnection.run(HttpConnection.java:251) 
            at com.ibm.ws.util.CachedThread.run(ThreadPool.java:144)

Customer is requesting a mechanism to stop this from being logged without having to do any additional work or setup such as the workaround that was proposed.

test case is attached
###@###.### 2005-1-10 18:08:32 GMT
Comments
SUGGESTED FIX Add a method : public static void javax.print.PrintServiceLookup.installedServicesOnly(boolean installedOnly) where an argument of "true" would prevent the lookup. The default (if this API were not called) would be "false" to preserve existing behaviour. ###@###.### 2005-2-07 19:21:12 GMT
07-02-2005
EVALUATION First to re-cap : The Java printing API is specified to allow applications (and applets) to provide PrintService implementations which can be dynamically located at runtime by the JDK. The specific mechanism for this uses the JAR file service provider specification introduced in JDK 1.3 The design specifically allows for these services on the classpath, so I don't believe it will be possible to change the specified behaviour to exclude this capability. It would break applications that use this feature. The most obvious possibility is an API that would have to be called by the applet or application code to request or relax this restriction. Also the description needs clarification one detail: The Java Print API implementation is not doing the logging. The servlet is doing the logging and it is interpreting a request for a file that happens not to exist as an error in the client making the request. It is not in fact an error - its impossible to know of the existence or otherwise of a classpath provided print service without checking. ###@###.### 2005-1-11 00:28:54 GMT After looking into what happens inside the JRE ClassLoader code the request from the client to the server is an HTTP HEAD. Not an HTTP GET. According to the W3C HTTP/1.1 spec, HEAD is useful for a client to check the validity of a URL. So whilst it may be reasonable for a server to treat a GET as an error, it seems that treating HEAD as an error is more questionable. This raises the option that the server be fixed to distinguish these cases. ###@###.### 2005-2-07 19:21:11 GMT Reassign it to Java Plug-in to address the issue directly in the applet/plugin classloader. ###@###.### 2005-03-01 07:27:33 GMT
11-01-2005
WORK AROUND Solution proposed by MDE to resolve issue and to prevent these errors from being thrown in the web server error logs was to do the following. On the server running HTTP server process. %mkdir -p DIR_OF_FILENOTFOUND %touch DIR_OF_FILENOTFOUND/javax.print.PrintserviceLookup Once this was implemented, the errors above were eliminated from the error log. ###@###.### 2005-1-10 18:08:32 GMT ========================================== It ought to be simpler than this, so long as the applet is packaged as a JAR. The same empty file can be created inside the applet's jar and once found I would not expect the service provider implementation to need to make a request to the server. However it turns out that this won't work because the AppletClassLoader always considers codebase to be an element of its classpath and will always go to the server to lookup too. ###@###.### 2005-2-07 19:21:11 GMT
10-01-2005