Deserialization error of CoreJavaScriptResourceReference

[GoogleCodeExporter]

What steps will reproduce the problem?
Hard to reproduce since we don't know exactly when the deserialization process 
occurs. For us, it's half the time restarting the Tomcat 7 server.

What is the expected output? What do you see instead?
expected: no error

What version of the product are you using? On what operating system?
1.2.3

Please provide any additional information below.
Here is the exception:
java.lang.NoClassDefFoundError: Could not initialize class 
org.odlabs.wiquery.core.commons.CoreJavaScriptResourceReference
    at org.odlabs.wiquery.core.commons.listener.JQueryCoreRenderingListener.onRender(JQueryCoreRenderingListener.java:58)
    at org.odlabs.wiquery.core.commons.WiQueryCoreHeaderContributor.renderResponse(WiQueryCoreHeaderContributor.java:192)
    at org.odlabs.wiquery.core.commons.WiQueryCoreHeaderContributor.renderHead(WiQueryCoreHeaderContributor.java:132)
    at org.apache.wicket.behavior.AbstractHeaderContributor.renderHead(AbstractHeaderContributor.java:68)
    at org.apache.wicket.Component.renderHead(Component.java:2772)
    at org.apache.wicket.markup.html.internal.HtmlHeaderContainer$1.component(HtmlHeaderContainer.java:231)
....

And the original one, saying that you can't refer the application when there's 
no.

Caused by: org.apache.wicket.WicketRuntimeException: There is no application 
attached to current thread main
    at org.apache.wicket.Application.get(Application.java:187)
    at org.odlabs.wiquery.core.commons.WiQuerySettings.get(WiQuerySettings.java:58)
    at org.odlabs.wiquery.core.commons.WiQueryJavaScriptResourceReference.isMinifiedJavascript(WiQueryJavaScriptResourceReference.java:49)
    at org.odlabs.wiquery.core.commons.WiQueryJavaScriptResourceReference.processName(WiQueryJavaScriptResourceReference.java:42)
    at org.odlabs.wiquery.core.commons.WiQueryJavaScriptResourceReference.<init>(WiQueryJavaScriptResourceReference.java:38)
    at org.odlabs.wiquery.core.commons.CoreJavaScriptResourceReference.<init>(CoreJavaScriptResourceReference.java:55)
    at org.odlabs.wiquery.core.commons.CoreJavaScriptResourceReference.<clinit>(CoreJavaScriptResourceReference.java:42)

My suggestion: keep a non-static attribute "isMinified", set in constructor via 
WiQuerySettings.get().isMinifiedJavascript()

Original issue reported on code.google.com by guiom.mary@gmail.com on 27 Jun 2011 at 10:37

[GoogleCodeExporter]

CoreJavaScriptResourceReference implements the Serializable interface. This 
means Java should be able to serialize/deserialize it. Most random 
serialize/deserialize errors occur when restarting the the webapplication after 
updating. The wicket work directory is then used to restore sessions. When 
classes have been altered the serialization attempt fails.

I fail to see the relevance of your suggestion to avoid the 
WicketRuntimeException. The value of isMinifiedJavascript() is fetched from a 
non static context.

Will note your problem, but as it is not reproducable and you are the only one 
reporting it at the moment there is nothing we can do. Will tweaks the 
constructor of the resourcereferences as your pointed out.

Original comment by hielke.hoeve on 27 Jun 2011 at 1:56

[GoogleCodeExporter]

Check trunk for changes to the resourcereferences. All references are now 
loaded lazily to prevent premature initialization.

Original comment by hielke.hoeve on 27 Jun 2011 at 3:11

[GoogleCodeExporter]

if you want have singleton of your ResourceReference, you should add 
synchronized keyword (check Google for that).
(And please, add curly brackets to your if/else conditions !)

There's no call to getWiQueryName() (which calls the problematic 
isMinifiedJavaScriptResources()) so the problem is solved since you don't call 
anymore the problematic code...
What is the goal of getWiQueryName() ?

Original comment by guiom.mary@gmail.com on 27 Jun 2011 at 4:18

[GoogleCodeExporter]

Oops doing too many things at once does work, this proves that once more :)

Synchronized is not necessary as we do not alter the variable from multiple 
threads, we only set it the first time. In the highly unlikely event that 2 
threads simultaneously set instance only the first thread will serve a 
different instance of the resource once. Every consecutive call will return the 
last resource. IMO the overhead of making it synchronized counts heavier than 
serving a different instance max 1 time per application launch. The file itself 
will never change :)

I wanted to override getName() but people from Wicket get off at making things 
final so the check is now in the constructor. As all ResourceReferences are 
lazy loaded at first load the WiQuerySettings are initialized and all is well.

Original comment by hielke.hoeve on 28 Jun 2011 at 6:17

• Changed state: Fixed