Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    Servlet error in SC 10.1

    SmartClient version: SmartClient_SNAPSHOT_v101d_2015-07-27_Pro

    Hi,

    I've been trying out SC10.1 and I've had a problem.

    If I set unpackWAR="false" in my Tomcat servlet context descriptor then I get the error below during servlet startup.

    This problem does not occur in 10.0 and it does not occur in 10.1 if I set unpackWAR="true".

    It seems that a FileInputStream is being used instead of the ServletContext.getResourceAsStream method.


    Andrew.

    Code:
    2015-07-28 14:04:26,286 WARN localhost-startStop-1
     com.isomorphic.servlet.PreCache.init(PreCache.java:91)
     Problem during PreCache: java.io.FileNotFoundException: /isomorphic/system/schema/DataSource.ds.xml (No such file or directory)
            at java.io.FileInputStream.open0(Native Method)
            at java.io.FileInputStream.open(FileInputStream.java:195)
            at java.io.FileInputStream.<init>(FileInputStream.java:138)
            at com.isomorphic.io.file.ISCNativeFile.getInputStream(ISCNativeFile.java:157)
            at com.isomorphic.io.ISCFile.getInputStream(ISCFile.java:421)
            at com.isomorphic.xml.XML$RecordsFromXMLCache.loadObjectFromFile(XML.java:478)
            at com.isomorphic.store.ProcessedFileCache.getObjectFromFile(ProcessedFileCache.java:141)
            at com.isomorphic.xml.XML.loadCacheableDSRecords(XML.java:493)
            at com.isomorphic.store.DataStructCache.loadInstance(DataStructCache.java:183)
            at com.isomorphic.datasource.DataSource.loadDS(DataSource.java:428)
            at com.isomorphic.datasource.DataSource.forName(DataSource.java:403)
            at com.isomorphic.datasource.PoolableDataSourceFactory.makeUnpooledObject(PoolableDataSourceFactory.java:130)
            at com.isomorphic.datasource.PoolableDataSourceFactory.makeObject(PoolableDataSourceFactory.java:146)
            at org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:1220)
            at com.isomorphic.pool.ISCKeyedObjectPool.borrowObject(ISCKeyedObjectPool.java:106)
            at com.isomorphic.pool.PoolManager.borrowObject(PoolManager.java:90)
            at com.isomorphic.datasource.DataSourceManager.getDataSource(DataSourceManager.java:135)
            at com.isomorphic.datasource.DataSourceManager.getDataSource(DataSourceManager.java:86)
            at com.isomorphic.servlet.PreCache.preLoadDataSources(PreCache.java:142)
            at com.isomorphic.servlet.PreCache.init(PreCache.java:89)
            at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1279)
            at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1192)
            at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087)
            at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5210)
            at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5493)
            at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
            at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
            at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
            at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632)
            at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:670)
            at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1839)
            at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
            at java.util.concurrent.FutureTask.run(FutureTask.java:266)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
            at java.lang.Thread.run(Thread.java:745)

    #2
    The SmartClient server can access files in two ways - either via direct filesystem access or via servlet APIs (called "container I/O mode").

    Logs early in the server startup process indicate which approach was chosen and why. For more information about file access modes and how to control them, see the webroot setting in server.properties.

    So it's normal that the server would use FileInputStream, but abnormal that the files would not be present - it may indicate a skipped installation step.

    Comment


      #3
      I think you are wrong.

      In the scenario I've described, the war file is not expanded, so using a FileInputStream to access an internal resource cannot possibly work. The resource exists only in the war file, not on the filesystem.

      I have always believed that the Servlet specification mandated using the servlet context to access such static resources, but a quick check of the spec didn't reveal anything about it being mandatory.

      In any event, I have lowered the logging level to find the message you mentioned, and attached is the complete log. Line 43 of the log:
      Code:
      Container refusing to provide getRealPath() - assuming WAR context and using container IO
      .

      FileInputStream should not be used in this case.

      regards,
      Andrew

      PS I had to split the log file into 4 parts to overcome the Max Filesize restrictions of the forum.
      Attached Files

      Comment


        #4
        The fact that you exceeded the file size limits is a hint that you are doing something wrong. In this case, if you use the default log settings, you will get a much smaller, more readable log. Note that you don't need to change the default settings to see the relevant logs.

        It was a huge pain to work with the logs in this format (please don't do that again), but we think we've spotted the problem: in your server.properties, you've specified one of the key filesystem paths (such as isomorphicRootRelative) as an absolute path, which means it is no longer assumed to be relative to webroot, so will no longer use container IO.

        If you disagree that this is the cause, please show your server.properties

        Comment


          #5
          I'm sorry about the log format - in future I'll be sure to use your default settings.

          I don't think its the server.properties. The only change I've made there is to add the following lines:
          Code:
          RPCManager.enabledBuiltinMethods: getAvailableScriptEngines
          schema.strict.all:false
          I have attached the server.properties as well as the server log (in your format). If there is anything else I can provide, please let me know.

          This problem only occurs with release 10.1. If I build with release 10.0 then there are no errors.


          regards,
          Andrew
          Attached Files

          Comment


            #6
            Hello,

            I've done some further investigation to try and eliminate my local configuration as the culprit.

            I built a couple of war files directly from the SmartClient_SNAPSHOT_v101d_2015-07-27_Pro distribution. The two war files that I build contain absolutely nothing other than the Isomorphic distribution. I named the war files smartclientRuntime.war and smartclientSDK.war.

            I then configured Tomcat with a servlet descriptor that contained the unpackWAR="false" directive (see the attached smartclientRuntime.xml file).

            I had no error with smartclientSDK.war but I did with smartclientRuntime.war. Please see the attached log.

            You should be able to replicate this if you build a similar war file and place the smartclientRuntime.xml in the Tomcat conf/Catalina/localhost/ directory. You may have to create the Catalina/localhost directory manually.

            I hope this is of some help.


            regards,
            Andrew
            Attached Files

            Comment


              #7
              Thanks - reproduced. This is is definitely our bug and we are working on a fix. Thanks for the context and your patience.

              Comment


                #8
                A fix will be available in tomorrow's (Aug 1) build.

                Comment

                Working...
                X