1 Reply Latest reply on May 18, 2002 8:29 PM by Julian Gosnell

    Developing Using Templates

    Lateef Jackson Newbie

      I am using JBoss3.0RC2 and I am trying to use templates (Velocity probably JPublish (http://www.jpublish.org/)) for development. The problem is whenever I change a template I have to repackage and deploy the war file.
      Is there a way to have an unpacked directory in the JBOSS_HOME/server/default/deploy/mywaredir/?

      Another unrelated question:
      In a year or two we may create a large cluster. Should the servlets use the Local interfaces or Remote. If the servlet servers are running in diffent JVM than we will need to use Remote. With the performance increase I wonder if it would be better to keep JBoss and Jetty in the same JVM and cluster out instead of up?

        • 1. Re: Developing Using Templates
          Julian Gosnell Expert

          you should be able to deploy your war unpacked (e.g. deploy/my.war/...).

          You can then mess with files inside your app without repacking.

          When you have finished 'touch' my.war/WEB-INF/web.xml and JBoss will reload the webapp.

          I don't know how much caching Velocity does, but you may be able to get away without the last step....

          As for the second question, here are my thoughts - this isn't my area, so don't assume they are gospel.

          1. Local interfaces imply colocation of the beans providing and consuming them. This allows app servers to optimise calls across them. I believe that parameters are guranteed to be passed by reference, so you can have in/out params (i.e. parameters which are changed server-side during the call and then used by the client).

          2. Remote interfaces do NOT imply colocation and do NOT support in/out params. Furthermore, params will need to be serialisable (checked at run-time - NOT compile-time) - in case the call is actually remote-ing.

          HOWEVER - JBoss will optimise out serialisation between colocated remote-interface-consumers and providers (I'm not sure whether the check for Serialisable occurs before this optimisation takes place).

          IN CONCLUSION -

          IF you can avoid a need for in/out parameters AND params that are not serialisable THEN I believe that you can continue to use Remote interfaces at no particular runtime overhead (in JBoss), even when colocated. This means less effort if you decide at some later date that you wish to deploy your bean clients remotely from the beans themselves.



          There is another approach. I have seen various patterns talked about by which you abstract away from Local/Remote and write to a new interface, which can then be inherited from whichever you choose - If you can bear the thought of yet another set of bean interfaces washing around inside your app you could go this way.