facelets
  1. facelets
  2. FACELETS-329

getAlternativeJarFile() problem for com.sun.facelets.util.Classpath

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.1.14
    • Fix Version/s: 1.1.15
    • Component/s: impl
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      329

      Description

      When we deploy the hangman.war application to Borland AppServer 6.6(BAS), we get
      the following exception:

      2008-09-10 13:01:24,000 INFO - Sep 10, 2008 1:01:24 PM
      com.sun.facelets.compiler.Compiler initialize
      SEVERE: Compiler Initialization Error
      java.util.zip.ZipException: The system cannot find the path specified
      at java.util.zip.ZipFile.open(Native Method)
      at java.util.zip.ZipFile.<init>(ZipFile.java:203)
      at java.util.jar.JarFile.<init>(JarFile.java:132)
      at java.util.jar.JarFile.<init>(JarFile.java:70)
      at com.sun.facelets.util.Classpath.getAlternativeJarFile(Classpath.java:124)
      at com.sun.facelets.util.Classpath.search(Classpath.java:67)
      at
      com.sun.facelets.compiler.TagLibraryConfig.loadImplicit(TagLibraryConfig.java:428)
      at com.sun.facelets.compiler.Compiler.initialize(Compiler.java:87)
      at com.sun.facelets.compiler.Compiler.compile(Compiler.java:104)
      at
      com.sun.facelets.impl.DefaultFaceletFactory.createFacelet(DefaultFaceletFactory.java:197)
      at
      com.sun.facelets.impl.DefaultFaceletFactory.getFacelet(DefaultFaceletFactory.java:144)
      at
      com.sun.facelets.impl.DefaultFaceletFactory.getFacelet(DefaultFaceletFactory.java:95)
      at com.sun.facelets.FaceletViewHandler.buildView(FaceletViewHandler.java:517)
      at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:567)
      at
      com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:109)
      at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
      at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
      at javax.faces.webapp.FacesServlet.service(FacesServlet.java:245)
      at
      org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:253)
      at
      org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
      at
      org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:216)
      at
      org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
      at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
      at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
      at
      org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
      at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
      at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:891)
      at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:783)
      at
      org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:663)
      at
      org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:548)
      at
      org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
      at
      org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
      at java.lang.Thread.run(Thread.java:595)

      This is due to the path of a URL scanned by the com.sun.facelets.util.Classpath:

      The URL scanned is
      "besjar:C%3A/BAS6.6/var/domains/base/configurations/j2eeSample/mos/MyPartition/tmp/tmpbes_33163hangman.war/hangman.war!/META-INF/".
      Therefore, in Classpath.getAlternativeJarFile (line 124),
      the jarFileUrl would be derived as
      "C:/BAS6.6/var/domains/base/configurations/j2eeSample/mos/MyPartition/tmp/tmpbes_33163hangman.war/hangman.war".

      However, an exception (java.util.zip.ZipException: The system cannot find the
      path specified) is thrown
      because the jarFileUrl is pointing to a directory instead of a jar file. This is
      because the war file has been expanded
      and copied to that directory for BAS.

      There is a comment(as indicated below) for the getAlternativeJarFile in the
      Classpath.java source code which mentioned
      that it does not cater for unpack WAR or EAR. Would this be implemented in the
      later release?

      Since it seems that the URLs returned by different AppServers can cause problems
      for the getAlternativeJarFile method,
      would it be possible to provide some kind of extension such that other users can
      write classes to override the default
      implementation of the search mechanism implemented by the Classpath source code,
      rather than changing it. Just a suggestion.

      /** For URLs to JARs that do not use JarURLConnection - allowed by

      • the servlet spec - attempt to produce a JarFile object all the same.
      • Known servlet engines that function like this include Weblogic
      • and OC4J.
      • This is not a full solution, since an unpacked WAR or EAR will not
      • have JAR "files" as such.
        */

        Activity

        There are no comments yet on this issue.

          People

          • Assignee:
            Unassigned
            Reporter:
            sitan
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: