Creating of Spring beans takes a long time when the application is deployed through webstart / jnlp with Java 6 and above [SPR-9117]

[spring-projects-issues]

Tom Jahncke opened SPR-9117 and commented

Creating an instance of a Spring bean takes a long time when the application is deployed via webstart and the client of application is accessing the application over the WAN.

If a client of the application is remote, creating a bean can take up to 6 seconds. Between the following two lines 6 seconds of time elapse.
CachedIntrospectionResults | Getting BeanInfo for class [com.gfs.wms.service.vendor.buyer.dao.impl.JdbcBuyerDao]
CachedIntrospectionResults | Caching PropertyDescriptors for class [com.gfs.wms.service.vendor.buyer.dao.impl.JdbcBuyerDao]

If I drop the network connection while the beans are being created they are created quickly (few ms) and no exception is thrown ...

I was puzzled by this until ... I realized webstart caching of resources changed between Java 5 and Java 6

Java 6 and Java 7
DefaultBeanDefinitionDocumentReader | Loading bean definitions
PathMatchingResourcePatternResolver | Looking for matching resources in jar file [http://wmstst. ...

Java 5
DefaultBeanDefinitionDocumentReader | Loading bean definitions
PathMatchingResourcePatternResolver | Looking for matching resources in jar file [file:C:/Users/tjahncke/AppData/LocalLow/Sun/Java/Deployment/cache/javaws/http/Dwmstst.gfs.com/P8000/VworkflowManager-10.0.0.0.rc1.jar/DMdc9/DMwms/RMworkflowManager-10.0.0.0.rc1.jar]

It seems that Spring is looking for the jars on the remote site rather than the local cached copy.

Any assistance on having Spring look at the local cached copy instead of the remote jars would be very appreciated!

Thanks,

Tom

---

Issue Links:

• Classpath scanning fails after hot-deploy of a web-application to a container due to JarURLConnection caching [SPR-4639] #9316 Classpath scanning fails after hot-deploy of a web-application to a container due to JarURLConnection caching

Referenced from: commits fe57f74, 6fd476e

[spring-projects-issues]

Tom Jahncke commented

This issue would probably be resolved if improvement, #13653, is implemented.

This issue is somewhat similar to: #11146

[spring-projects-issues]

Tom Jahncke commented

Here is a summary of the caching changes in Java 6 for webstart:

From, http://www.roseindia.net/java/jdk6/java-web-start.shtml:

JNLP is now an instance of the URLClassLoader - It gives some powerful advantages. First, Jar indexing is now fully supported. If you want to create a jar index of several jar file in the main jar file that indexes all the jar files, and then you can mark each additional jar as lazy, and it can be download only when a resource or class in it is referenced. Second, The JNLPClassLoader was rewritten to extend URLClassLoader. For getting a list of jar elements that are listed in the jnlp files an application can invoke getURLs(). The URL returned for calls to Class Loader.getResource() is proper Jar URL of the item on the net. By extending URLClassLoader, it allows Java Web Start to operate without caching.

[spring-projects-issues]

Tom Jahncke commented

Looking at PathMatchingResourcePatternResolver this may be able to be resolved by allowing the jarCon.useCaches(true) when the con is an instance of JNLPCachedJarURLConnection.

		if (con instanceof JarURLConnection) {
			// Should usually be the case for traditional JAR files.
			JarURLConnection jarCon = (JarURLConnection) con;
			jarCon.setUseCaches(false);
			jarFile = jarCon.getJarFile();
			jarFileUrl = jarCon.getJarFileURL().toExternalForm();
			JarEntry jarEntry = jarCon.getJarEntry();
			rootEntryPath = (jarEntry != null ? jarEntry.getName() : "");
		}

[spring-projects-issues]

Tom Jahncke commented

Thank you!

[spring-projects-issues]

Juergen Hoeller commented

Seems we have conflicting requirements where for web app hot deploy, we need to deactivate the jar cache whereas for JNLP, we need to keep it activated. Unfortunately, JNLP* are Sun-specific implementation classes so we can probably only reflectively check whether jarCon.getClass().getName().startsWith("JNLP") or the like.

Juergen

[spring-projects-issues]

Tom Jahncke commented

Thank you!! Do you know of other places in the spring code base that might refer to JarURLConnection and might have the same issue?

Thanks,

Tom

[spring-projects-issues]

Juergen Hoeller commented

Good point - I have made sure to use the same useCaches behavior in all places where we obtain a URLConnection.

Juergen

[spring-projects-issues]

Tom Jahncke commented

Tested with Spring 3.1.1 and creating the bean still takes a very long time when the resources are sourced from webstart and the network connection is remote.

Excerpt from the log:

2012-02-23 10:27:26:283 | TRACE | AWT-EventQueue-0 | CachedIntrospectionResults | Getting BeanInfo for class [com.gfs.wms.service.vendor.buyer.dao.impl.JdbcBuyerDao]
2012-02-23 10:27:30:392 | TRACE | AWT-EventQueue-0 | CachedIntrospectionResults | Caching PropertyDescriptors for class [com.gfs.wms.service.vendor.buyer.dao.impl.JdbcBuyerDao]

[spring-projects-issues]

Chris Beams commented

Added fixVersion 3.2 M1 just to ensure this reopened issue doesn't get lost in the mix. Juergen can assess from here.

[spring-projects-issues]

Tom Jahncke commented

Thanks!

[spring-projects-issues]

Juergen Hoeller commented

This should be fixed since 3.1.3 and also in the 3.2 line.

Juergen