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

    Conceptual question regarding SmartGWT jars deployment

    Hi Isomorphic,

    I'm testing SmartGWT for quite a time now and plan to do a B2B webapp. While doing so I started with the BuiltInDS example added Oracle and Relogin support, switched from Dev To SuperDev and am now playing around with the declarative security.

    All the time I was wondering if its possible to shorten the undeploy-build-war-deploy cycle. Today I found out that Tomcat has shared libs for all apps it hosts. I already put my ODBC driver there but didn't think of that I could also put my smartgwt jars there.
    Today I tried it with the following line in my
    I changed my ANT targets for clean and lib to clean there and copy the needed files there, as well as my war-target to ignore the apps WEB-INF/lib-files I copied (resulting in an empty WEB-INF/lib dir).

    So far this works like a charm, the app's war-file is way smaller than it used to be and the war is build and deployed faster.

    Do you know if this approach (resulting in shared SmartGWT jars if I might run more than one app sometime) has any downsides (with respect to shared instances, not with the "jar hell", I'm aware of these)?
    I'm aware that this question is not really SmartGWT question, so I'm also fine with trial and error if you can't say anything here.

    Best regards,

    PS: I also saw today and will look into it to reduce my jar-footprint. Your framework is REALLY impressive.

    The drawback is just that, with those .jars on the container classpath, it's no longer possible to deploy multiple SmartGWT apps which use different versions of the server framework.

    Well, in theory this *is* still possible, by placing additional copies of the SmartGWT server .jars into the WEB-INF directory of the particular app that needs to use a different version. But in practice, every container we've seen fails in one way or another when this is attempted.


      Hi Isomorphic,

      thanks for the answer. The drawback you described is what I meant by "jar hell".
      So for now while testing the framework with many undeploy-build-war-deploy cycles this is OK, but that will not be the case in production.
      I have to think of other ways to improve war-speed then.
      I could copy the jars by an ant task, which is way faster than war'ing the jars and deploying them.
      Nevertheless in production one will most likely use the full-app wars, as it is more easy then to versionize the packaged app as "installer" then.

      Best regards,


        Originally posted by Blama View Post
        ...with respect to shared instances.
        By that I meant if any errors can arise from the fact that these jars are shared (just like the shared-across-all-instances class variables of a servlet).
        But from your answer I get that this is not the case.

        Thanks again,