1

I have been trying to run the archetype example and another project I am trying to upgrade from 6.5 to 7.0.0, but I have failed to do so.

The archetype example runs ok on jetty and the project I was trying to upgrade runs ok both in jetty and was 8.5.5.7, but after changing the dependencies I keep getting the exception below and I am not quite sure if it is a problem with configuration (as everything worked ok with 6.5), with wicket 7.0.0 as the exception comes from inside wicket or from WAS8.5.5.7.

[ERROR ] SRVE0271E: Uncaught init() exception created by servlet [wicket-servlet] in application [blahblah]: javax.servlet.ServletException: java.lang.ClassCastException: com.ibm.ws.artifact.url.internal.WSJarURLStreamHandler$WSJarURLConnectionImpl cannot be cast to java.net.JarURLConnection at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:455) at org.apache.wicket.protocol.http.WicketServlet.init(WicketServlet.java:271) at javax.servlet.GenericServlet.init(GenericServlet.java:244) at com.ibm.ws.webcontainer.servlet.ServletWrapper.init(ServletWrapper.java:332) at [internal classes] Caused by: java.lang.ClassCastException: com.ibm.ws.artifact.url.internal.WSJarURLStreamHandler$WSJarURLConnectionImpl cannot be cast to java.net.JarURLConnection at org.apache.wicket.Application.collectWicketProperties(Application.java:503) at org.apache.wicket.Application.initializeComponents(Application.java:593) at org.apache.wicket.Application.initApplication(Application.java:918) at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:429) ... 4 more [ERROR ] SRVE0315E: An exception occurred: java.lang.Throwable: javax.servlet.ServletException: java.lang.ClassCastException: com.ibm.ws.artifact.url.internal.WSJarURLStreamHandler$WSJarURLConnectionImpl cannot be cast to java.net.JarURLConnection at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:4900) at [internal classes] Caused by: javax.servlet.ServletException: java.lang.ClassCastException: com.ibm.ws.artifact.url.internal.WSJarURLStreamHandler$WSJarURLConnectionImpl cannot be cast to java.net.JarURLConnection at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:455) at org.apache.wicket.protocol.http.WicketServlet.init(WicketServlet.java:271) at javax.servlet.GenericServlet.init(GenericServlet.java:244) at com.ibm.ws.webcontainer.servlet.ServletWrapper.init(ServletWrapper.java:332) ... 1 more Caused by: java.lang.ClassCastException: com.ibm.ws.artifact.url.internal.WSJarURLStreamHandler$WSJarURLConnectionImpl cannot be cast to java.net.JarURLConnection at org.apache.wicket.Application.collectWicketProperties(Application.java:503) at org.apache.wicket.Application.initializeComponents(Application.java:593) at org.apache.wicket.Application.initApplication(Application.java:918) at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:429) ... 4 more

UPDATE------------ as of wicket 7.1.0 there isn't an issue anymore. As mentioned in @klopfdreh answer there was a compatibility issue, I am accepting that answer, because I think the discussion in the comments may have helped the wicket team fix/pinpoint the issue in the 7.1.0 release.

DguezTorresEmmanuel
  • 348
  • 5
  • 10

1 Answers1

1

It is only an assumption, but it appears that the problem seems to be close to this one:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=430180

As of one comment, can you try to set the following options at your "jvm.options":

-Dcom.ibm.websphere.persistence.DisableJpaFormatUrlProtocol=true

To implement it without disable the "wsjar" protocol we need more input about the implementation of "WSJarURLConnectionImpl" - the only method called from the "JarURLConnection" is "getJarFile()", so the question here is: Does "WSJarURLConnectionImpl" also provide this method and returns it a JarFile? Then we may use reflections at this place.

klopfdreh
  • 126
  • 8
  • That property only affects JPA, not ClassLoader.getResources(). WSJarURLConnectionImpl is not API, so no use is supported. The problem is there’s no JarURLConnection.close(), so there's no way to know when the caller is done with the JarFile. That's fine for "jar:", which indefinitely caches JARs, but is not for WSJarURLConnectionImpl, which must deal with open file limits and application undeployments. Libraries like Wicket that try to iterate directories from ClassLoader resources (i.e., META-INF/wicket/*.properties) are inherently fragile and arguably misdesigned. – Brett Kail Oct 11 '15 at 15:20
  • Well there are a lot of other frameworks making use of the META-INF folder - webjars for example - it is an internal folder to not put files in - thats right, but I think every connection implementation should be considert to be an API, because it is used in here and should be able to be read and otherwise throw an exception that tells the entry might be undeployed. – klopfdreh Oct 11 '15 at 17:27
  • There is difference between _reading_ files from META-INF and expecting to be able to _iterate_ files in META-INF. The former is fine, the latter cannot be done portably. – Brett Kail Oct 12 '15 at 02:43
  • So then my question would be - why does the normal JarURLConnection supports this and the websphere integration does not? It would be better to implement the functionality closer to the standard. This would allow frameworks to not take care about so much exceptions, but there are a lot in a websphere environment. – klopfdreh Oct 12 '15 at 08:24
  • For the reason I explained in my first comment, and WebSphere cannot implement that for the reason I explained. It would be helpful for frameworks if there was a standard way to iterate URL directories, but there isn't. Anyway, your suggestion to set the DisableJpaFormatUrlProtocol property will not work. – Brett Kail Oct 12 '15 at 13:50
  • @bkail Will WebSphere would work fine if Wicket use java.util.ServiceLoader? – martin-g Oct 13 '15 at 07:34
  • @martin-g Yes, ServiceLoader would work if Wicket could use it, but my understanding is Wicket allows arbitrarily named META-INF/wicket/*.properties files, which ServiceLoader does not support. If switching to ServiceLoader is possible (e.g., only a small set of extensions needs it, not every application), that would be ideal. Other options would be to add a well-defined file like META-INF/wicket.properties that lists the files under META-INF/wicket/ to read, continue to hardcode a list of supported URL protocols, declare non-support for environments with non-builtin protocols, etc. – Brett Kail Oct 13 '15 at 14:34
  • @bkail We had `/wicket.properties` before 7.0.0 but it had problems with uberjars/shaders. I've decided to use this approach because it works well with WebJars (apparently not many WebSphere users use WebJar) and also because I remember issues with ServiceLoader in OSGi environments. Now an OSGi user says that ServiceLoader is supported in OSGi and due to this bug here I will add support for ServiceLoader and deprecate this method, i.e. log WARNs when `/META-INF/wicket/*.properties` is detected for few(or until 8.0.0?!) releases and then remove it. Thanks for your help here! – martin-g Oct 13 '15 at 19:13