Announcement

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

    WebRoot only detected once with multiple WAR files within a single EAR file

    We are trying to deploy a EAR file with multiple WAR files, but it seem that the "webroot" is only detected once, because when the second WAR file initializes, it says "Isomorphic SmartClient/SmartGWT Framework is already initialized". As a result, the datasource configuration files (*.ds.xml) in the second WAR cannot get loaded because the web root to the second WAR is never detected. It will attempt to load them from the web root of the first WAR.

    SmartGWT Version : v8.3p_2013-01-24/PowerEdition Deployment (2013-01-24)

    We have also created a sample EAR file to illustrate this issue, and deployed it into a Geronimo 3.0 (geronimo-tomcat7-javaee6) application server. The zipped source for the sample EAR has been attached as "demo.txt", please rename it to "demo.zip" and extract it. Below are the logs:

    Code:
    ISC: Configuring log4j from: file:/C:/Temp/G3/repository/com/test/test-ear/1.0/test-ear-1.0.ear/test-war-one-1.0-SNAPSHOT.war/WEB-INF/classes/log4j.is
    c.config.xml
    === 2013-02-09 01:28:41,483 [d-86] INFO  ISCInit - Isomorphic SmartClient/SmartGWT Framework initialization called from com.isomorphic.base.InitListen
    er
    === 2013-02-09 01:28:41,484 [d-86] INFO  ISCInit - Isomorphic SmartClient/SmartGWT Framework - Initializing
    === 2013-02-09 01:28:41,490 [d-86] INFO  ConfigLoader - Attempting to load framework.properties from CLASSPATH
    === 2013-02-09 01:28:41,616 [d-86] INFO  ConfigLoader - Successfully loaded framework.properties from CLASSPATH at location: jar:file:/C:/Temp/G3/repo
    sitory/com/test/test-ear/1.0/test-ear-1.0.ear/test-war-one-1.0-SNAPSHOT.war/WEB-INF/lib/isomorphic-core-rpc-3.1p.jar!/framework.properties
    === 2013-02-09 01:28:41,618 [d-86] INFO  ConfigLoader - Attempting to load project.properties from CLASSPATH
    === 2013-02-09 01:28:41,619 [d-86] INFO  ConfigLoader - Unable to locate project.properties in CLASSPATH
    === 2013-02-09 01:28:41,625 [d-86] INFO  ConfigLoader - Successfully loaded isc_interfaces.properties from CLASSPATH at location: jar:file:/C:/Temp/G3
    /repository/com/test/test-ear/1.0/test-ear-1.0.ear/test-war-one-1.0-SNAPSHOT.war/WEB-INF/lib/isomorphic-core-rpc-3.1p.jar!/isc_interfaces.properties
    === 2013-02-09 01:28:41,627 [d-86] INFO  ConfigLoader - Attempting to load server.properties from CLASSPATH
    === 2013-02-09 01:28:41,629 [d-86] INFO  ConfigLoader - Successfully loaded server.properties from CLASSPATH at location: file:/C:/Temp/G3/repository/
    com/test/test-ear/1.0/test-ear-1.0.ear/test-war-one-1.0-SNAPSHOT.war/WEB-INF/classes/server.properties
    === 2013-02-09 01:28:41,637 [d-86] INFO  Logger - Logging system started.
    === 2013-02-09 01:28:41,639 [d-86] INFO  ISCInit - Isomorphic SmartClient/SmartGWT Framework (v8.3p_2013-01-24/PowerEdition Deployment 2013-01-24) - I
    nitialization Complete
    === 2013-02-09 01:28:41,641 [d-86] INFO  ISCInit - Auto-detected webRoot - using: C:\Temp\G3\repository\com\test\test-ear\1.0\test-ear-1.0.ear\test-wa
    r-one-1.0-SNAPSHOT.war
    === 2013-02-09 01:28:42,791 [d-86] INFO  ISCInit - Isomorphic SmartClient/SmartGWT Framework initialization called from com.isomorphic.base.InitListen
    er
    === 2013-02-09 01:28:42,792 [d-86] INFO  ISCInit - Isomorphic SmartClient/SmartGWT Framework is already initialized
    Attached Files

    #2
    This implies all your .wars share one copy of the server framework classes. You should configure the EAR to have each .war load these classes separately (which might be a matter of putting copies of the .jars in each war's WEB-INF/lib area).

    You could also set things up so there's just one copy of the server framework in memory across all the apps, with a single webroot, and have project.dataSources list out the DataSource directories of each .war. This has a lot of gotchas to it, as obviously features that rely on knowing the webroot (JSP tags, etc) cannot work in this configuration. It also loses the ability to separately re-deploy any single .war, or to have different versions in different .wars. Generally this is not recommended unless you really know what you're doing.

    Comment


      #3
      Hi,

      My requirements are similar to the OP's: we will be deploying multiple wars inside an EAR. Our main motivation in refactoring the jars to the EAR's lib is to minimize redundancy and the EAR size.

      So far we seem to be facing the same problem of only having one webroot detected.

      You mentioned that putting jars in the WEB-INF/lib will fix the problem by loading classes separately. For reference, the web.xml's of the wars share only the following common servlet classes:

      com.isomorphic.servlet.IDACall
      com.isomorphic.servlet.DataSourceLoader
      com.isomorphic.servlet.ScreenLoaderServlet
      com.isomorphic.base.Init
      com.isomorphic.servlet.PreCache
      com.isomorphic.servlet.FileDownload
      com.isomorphic.servlet.RESTHandler

      My question is, what is the minimal set of jars that will need to be replicated to achieve this? Do all the above classes need to be in the multiple wars or maybe just a subset? I'm assuming the jar dependencies (eg commons-*jar, ) of the servlet jars can still remain in the EAR lib. This may be an acceptable approach for us short term.

      Moving forward, we would be more interested in the single webroot approach. The ds search paths are currently separate defined in the server.properties of each war. Is there a way to programatically define the search paths? Maybe something in the lines of extending the DataSourceLoader class?

      Thanks,

      Ech

      Comment


        #4
        At a minimum, all of the isomorphic-specific .jars need to be replicated.

        We couldn't tell you, on a .jar-by-.jar basis, whether some of the other .jars count on the servlet context being uniform.

        Bigger picture, you should take a step back and think through why you would be using .ear deployment. We often find people have settled on .ear deployment without analyzing any of the benefits or drawbacks.

        Comment

        Working...
        X