Muse
  1. Muse
  2. MUSE-117

Initialisaiton fails when service is AAR packaged on WLS 9.2

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.0.0
    • Fix Version/s: 2.0.0
    • Component/s: Deployment - Axis2
    • Labels:
      None
    • Environment:
      Muse 2.0.0RC1
      WebLogic 9.2
      Java 1.5.0_04-b05
      Windows XP SP2

      Description

      When deployment a Muse service pacakged as an AAR archive on Axis 2 1.0.0 on WLS 9.2 an exception is thrown, due to an apparent attempt to access the file directly. As the file is zipped this obviously fails.

      The stack trace is as follows (where jr-ossj.aar is a zipped file):

      java.lang.RuntimeException: C:\projects\ossjobjects\OSSJDeploy\jr-ossj\jr-ossj-ws\WEB-INF\services\jr-ossj.aar\muse.xml (The system cannot find the path specified)
      at org.apache.muse.core.platform.axis2.AxisEnvironment.getDataResourceStream(AxisEnvironment.java:266)
      at org.apache.muse.core.AbstractEnvironment.getDocument(AbstractEnvironment.java:270)
      at org.apache.muse.core.platform.AbstractIsolationLayer.initialize(AbstractIsolationLayer.java:143)
      at org.apache.muse.core.platform.axis2.AxisIsolationLayer.setOperationContext(AxisIsolationLayer.java:138)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:585)
      at org.apache.axis2.engine.DependencyManager.configureBusinessLogicProvider(DependencyManager.java:50)
      at org.apache.axis2.receivers.RawXMLINOutMessageReceiver.invokeBusinessLogic(RawXMLINOutMessageReceiver.java:79)
      at org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.receive(AbstractInOutSyncMessageReceiver.java:37)
      at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:454)
      at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:284)
      at org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:136)
      at javax.servlet.http.HttpServlet.service(HttpServlet.java:763)
      at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
      at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:225)
      at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:127)
      at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:283)
      at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:175)
      at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3214)
      at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
      at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
      at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:1983)
      at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:1890)
      at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1344)
      at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
      at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)
      Caused by: java.io.FileNotFoundException: C:\projects\ossjobjects\OSSJDeploy\jr-ossj\jr-ossj-ws\WEB-INF\services\jr-ossj.aar\muse.xml (The systemcannot find the path specified)
      at java.io.FileInputStream.open(Native Method)
      at java.io.FileInputStream.<init>(FileInputStream.java:106)
      at org.apache.muse.core.platform.axis2.AxisEnvironment.getDataResourceStream(AxisEnvironment.java:261)
      ... 27 more

        Activity

        Hide
        Dan Jemiolo added a comment -

        Can you describe your use case a bit more so we can determine how/when to act on this? Do you want .aar files rather than the exploded .aar that the tooling creates because you want the hot deployment feature? If so, the point may be moot - because of the way the Axis2 service classloader works[1], we had to put a user's custom capability/implementation classes in WEB-INF/lib. Because changing WEB-INF/lib requires an application restart, hot deployment is not currently possible using .aar files - if Axis2 is like Tomcat, you may be able to do hot deployment by adding the service's exploded .aar to the WEB-INF/services directory.

        [1] Details on class loader issue: The code that is loading the user's capability classes via reflection is in WEB-INF/lib, and is given a different classloader than the one that handles the classes in WEB-INF/services/*. Because we want to have one instance of the Muse runtime controlling multiple services (ws-resource types) that communicate amongst each other, we need the Muse classes to be loaded once per application, not per service or service group.Thus, the classes are in WEB-INF/lib, and to load user classes, those classes must also be in WEB-INF/lib.

        Show
        Dan Jemiolo added a comment - Can you describe your use case a bit more so we can determine how/when to act on this? Do you want .aar files rather than the exploded .aar that the tooling creates because you want the hot deployment feature? If so, the point may be moot - because of the way the Axis2 service classloader works [1] , we had to put a user's custom capability/implementation classes in WEB-INF/lib. Because changing WEB-INF/lib requires an application restart, hot deployment is not currently possible using .aar files - if Axis2 is like Tomcat, you may be able to do hot deployment by adding the service's exploded .aar to the WEB-INF/services directory. [1] Details on class loader issue: The code that is loading the user's capability classes via reflection is in WEB-INF/lib, and is given a different classloader than the one that handles the classes in WEB-INF/services/*. Because we want to have one instance of the Muse runtime controlling multiple services (ws-resource types) that communicate amongst each other, we need the Muse classes to be loaded once per application, not per service or service group.Thus, the classes are in WEB-INF/lib, and to load user classes, those classes must also be in WEB-INF/lib.
        Hide
        James Shiell added a comment -

        Given [1] the point is a moot - it would be nice if we could have the AAR part zipped, but given the need to construct the WAR in any case it is at most a convenience, and certainly does not merit more than a trival priority.

        Incidentally, thanks for your fast response.

        Show
        James Shiell added a comment - Given [1] the point is a moot - it would be nice if we could have the AAR part zipped, but given the need to construct the WAR in any case it is at most a convenience, and certainly does not merit more than a trival priority. Incidentally, thanks for your fast response.

          People

          • Assignee:
            Dan Jemiolo
            Reporter:
            James Shiell
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development