6 Replies Latest reply on Jan 28, 2015 8:27 AM by shane_k

    Issues running modeshape-web-explorer [4.1.0.Final] on Tomcat 7

    shane_k
    shane_k Jan 26, 2015 1:32 PM

      Hi Folks,

       

      I'm in the process of developing a web application which will likely incorporate Modeshape 4.1.0.Final (or later). I've been able to create a simple Spring 4.x web application (lets call it 'MyWebApp'), deploy it as a WAR onto my Tomcat 7 server and call a few test controllers which add some test nodes, attach binaries, list existing nodes etc - and this works fine. As I was reading through the Modeshape documentation I came across the following article:

       

      Repository Web Explorer - ModeShape 4 - Project Documentation Editor

       

      which describes how to configure and deploy the Modeshape (Repository) Web Explorer WAR and use my browser to navigate around the repository created by my application. After what seemed like partial success, I've hit a few issues. I feel like I'm tantalisingly close to getting it working, which makes it all the more frustrating that I just can't quite find the right combination of configuration. Here are the steps I followed:

       

      1. Deployed both MyWebApp.war and modeshape-web-explorer.war onto the same Tomcat 7 application server.

      2. Both MyWebApp and modeshape-web-explorer are accessible from the browser.

      3. Repository configuration is stored as a JSON file within the WEB-INF/classes/configuration/repository-config.json file within MyWebApp

      4. I updated the web.xml file of the modeshape-web-explorer application to add the following:

       

      <context-param>

         <param-name>connector-class</param-name>

         <param-value>org.modeshape.web.server.impl.JsonConfigConnectorImpl</param-value>

      </context-param>

       

      <context-param>      

      <param-name>config-url</param-name>

      <param-value>/WEB-INF/classes/configuration/repository-config.json</param-value>

      </context-param>

       

      5. When I restarted Tomcat and tried to access the modeshape-web-explorer app in my browser I obtained the following error dialog:

       

      The url argument may not be null

       

      6. I assumed that this meant that for whatever reason, the repository-config.json file was not found by the modeshape-web-explorer application - there didn't appear to be any error messages relating to this during server startup. The documentation seems to suggest that the config-url will be matched against the context roots of all web applications deployed on the application server - so I'm guessing it should eventually check MyWebApp/WEB-INF/classes/configuration/repository-config.json - which does exist.

       

      7. As a quick test, I updated the modeshape-web-explorer application to add the repository-config.json file under modeshape-web-explorer/WEB-INF/classes/configuration/repository-config.json - and then I restarted tomcat.

       

      8. In this instance, when I accessed the modeshape-web-explorer application my browser, I was presented with a similar user interface to that illustrated in the documentation - however, it wasn't possible to add new nodes or view any existing nodes which had been added by MyWebApp. Simply accessing the repository page (where it attempts to retrieve a list of workspaces - it does not show the 'default' workspace in the dropdown list - it is empty) produces the following error stack trace:

       

      SEVERE: Exception while dispatching incoming RPC call

      com.google.gwt.user.server.rpc.UnexpectedException: Service method 'public abstract java.lang.String[] org.modeshape.web.client.JcrService.getWorkspaces(java.lang.String) throws org.modeshape.web.client.RemoteException' threw an unexpected exception: java.lang.IllegalArgumentException: 1 parameter supplied, but 0 parameters required: "Could not start repository myRepository" => ""

        at com.google.gwt.user.server.rpc.RPC.encodeResponseForFailure(RPC.java:389)

        at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:579)

        at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:208)

        at com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:248)

        at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62)

        at javax.servlet.http.HttpServlet.service(HttpServlet.java:646)

        at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)

        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)

        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)

        at org.modeshape.web.AuthFilter.doFilter(AuthFilter.java:61)

        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)

        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)

        at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)

        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)

        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)

        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)

        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)

        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:503)

        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:170)

        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)

        at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950)

        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)

        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:421)

        at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1070)

        at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:611)

        at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)

        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

        at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

        at java.lang.Thread.run(Unknown Source)

      Caused by: java.lang.IllegalArgumentException: 1 parameter supplied, but 0 parameters required: "Could not start repository myRepository" => ""

        at org.modeshape.common.util.StringUtil.createString(StringUtil.java:187)

        at org.modeshape.common.logging.jdk.JdkLoggerImpl.debug(JdkLoggerImpl.java:90)

        at org.modeshape.web.server.impl.JsonConfigConnectorImpl.find(JsonConfigConnectorImpl.java:131)

        at org.modeshape.web.server.JcrServiceImpl.getWorkspaces(JcrServiceImpl.java:139)

        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)

        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

        at java.lang.reflect.Method.invoke(Unknown Source)

        at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:561)

        ... 28 more

       

      I receive similar stack traces if I try to access the Node Types, Descriptor or Query tabs.

       

      Here is a copy of my repository-config.json file for reference:

      {

          "name" : "myRepository",

          "jndiName" : "",

          "monitoring" : {

              "enabled" : true

          },

          "storage" : {

              "cacheName" : "myRepository",

              "cacheConfiguration" : "configuration/infinispan-config.xml",

              "binaryStorage" : {

                  "type" : "file",

                  "directory": "${java.io.tmpdir}/modeshape_spring_sample/binaries",

                  "minimumBinarySizeInBytes" : 40

              }

          },

          "workspaces" : {

              "default" : "default",

              "allowCreation" : true

          },

          "security" : {

              "anonymous" : {

                  "roles" : ["readonly","readwrite","admin"],

                  "useOnFailedLogin" : false

              }

          }

      }

       

      I am assuming that it should not be necessary to place the repository-config.json inside the modeshape-web-explorer app - and that it should get picked up from the modeshape host application (MyWebApp in this instance) - for some reason it does not appear to be able to discover the JSON configuration file. As a further test, I also updated the config-url context parameter to prefix 'MyWebApp' at the start - e.g.:

       

      <context-param>      

      <param-name>config-url</param-name>

      <param-value>/MyWebApp/WEB-INF/classes/configuration/repository-config.json</param-value>

      </context-param>

       

      However this was not successful either.

       

      Any ideas - I suspect it is something rather simple in the end, but I haven't managed to crack it myself yet.

       

      Regards,

       

      Shane

      • 637 Views
      • Tags:
        • 1. Re: Issues running modeshape-web-explorer [4.1.0.Final] on Tomcat 7
          hchiorean
          hchiorean Jan 27, 2015 2:39 AM (in response to shane_k)
          The documentation seems to suggest that the config-url will be matched against the context roots of all web applications deployed on the application server - so I'm guessing it should eventually check MyWebApp/WEB-INF/classes/configuration/repository-config.json - which does exist

          The documentation is/was wrong (and I've corrected it): the resource is resolved via getClass().getClassLoader().getResource(config-url), relative to the JsonConnectorImpl class. AFAIK this will not work (on most containers) across different web contexts/web apps.

          One thing you can try in the case of Tomcat is bind the repository in JNDI from one webapp and try accessing it (via JNDI) from the web explorer. See Using ModeShape - ModeShape 4 - Project Documentation Editor on how to deploy a repo as a Resource in Tomcat.

          1 of 1 people found this helpful
            • Actions
          • 2. Re: Issues running modeshape-web-explorer [4.1.0.Final] on Tomcat 7
            shane_k
            shane_k Jan 27, 2015 5:03 AM (in response to hchiorean)

            Horia,

             

            Thanks for your prompt response - I did wonder if I was missing something. I was aware of the JNDI approach, although had initially ruled it out since I believe J2EE app JNDI contexts in Tomcat are isolated from each other and read-only (so the JNDI context from one app cannot be seen from another, and a deployed app cannot modify its JNDI context) - although on further reading it looks like it is possible to bind 'global' JNDI resources - and the documentation link you've provided seems to describe as much - so I'll have a look at that and see how it goes...

             

            Regards,

             

            Shane

              • Actions
            • 3. Re: Issues running modeshape-web-explorer [4.1.0.Final] on Tomcat 7
              hchiorean
              hchiorean Jan 27, 2015 5:19 AM (in response to shane_k)

              It's always possible to "configure" (read - hack) Tomcat's CLs to make resources visible from one webapp to the other - e.g. using the Common CL - but this would be a hack. So ideally you should try JNDI. If for some reason that doesn't work, the only other option is to "embed" everything in one webapp.

                • Actions
              • 4. Re: Re: Issues running modeshape-web-explorer [4.1.0.Final] on Tomcat 7
                shane_k
                shane_k Jan 28, 2015 5:27 AM (in response to hchiorean)

                I haven't had a chance to try the JNDI approach yet, but I did try embedding modeshape-web-explorer within MyWebApp as suggested and:

                 

                (a) initially hit a dependency issue with the modeshape-web-explorer-4.1.0.Final POM

                 

                ...

                 

                        <dependency>

                            <groupId>smartgwt</groupId>

                            <artifactId>smartgwt</artifactId>

                        </dependency>

                 

                 

                        <dependency>

                            <groupId>com.smartgwt</groupId>

                            <artifactId>smartgwt-skins</artifactId>

                        </dependency>

                 

                ...

                 

                I believe the groupId should be com.smartgwt in this instance (as it is with smartgwt-skins). I had to exclude this dependency in my build, and manually override it with my own to use com.smartgwt (2.4). I also went back to modeshape-web-explorer 4.0.0.Final to check and it had the same dependency issue.

                 

                (b) when I resolved the dependency issue I could access the web explorer UI in my browser, but it exhibited the same behaviour and exceptions as before.....

                 

                Regards,

                 

                Shane

                  • Actions
                • 5. Re: Re: Issues running modeshape-web-explorer [4.1.0.Final] on Tomcat 7
                  hchiorean
                  hchiorean Jan 28, 2015 6:07 AM (in response to shane_k)

                  Yes, it's weird we're using this dependency (which is available in the public JBoss Nexus: Sonatype Nexus Professional) but the official one (based on Maven Central) should be the one with com.smartgwt in the groupId. We'll fix this for 4.2.

                    • Actions
                  • 6. Re: Re: Issues running modeshape-web-explorer [4.1.0.Final] on Tomcat 7
                    shane_k
                    shane_k Jan 28, 2015 8:27 AM (in response to hchiorean)

                    Okay - after a few false starts, it looks like I'm finally making some headway. I think I may have had some old configuration (or an old version of my WAR file deployed on the Tomcat server) resulting in the same exception messages I was seeing first time around. I rebuilt my WAR and redeployed it, the 'default' workspace is now selected and I can see the contents of my repository, add/delete nodes etc. The only other issue I had was with respect to duplicate JMX domains, i.e.

                     

                    Error while starting 'myRepository' repository: Domain already registered org.infinispan when trying to register: type=CacheManager,name="DefaultCacheManager"

                     

                    which I resolved by adding:

                     

                    <global>

                        <globalJmxStatistics enabled="false" allowDuplicateDomains="true"/>

                    </global>

                     

                    to my infinispan-config.xml (as per the modeshape-spring-example sample app)

                     

                    Thanks for your assistance Horia - much appreciated.

                     

                    Regards,

                     

                    Shane

                      • Actions