3 Replies Latest reply on Jun 11, 2007 11:14 AM by Tom Baeyens

    Timer servlet

    David Lloyd Master

      The timer servlet is currently not part of the jBPM web console's web.xml. Should it be added?

      In the long term, this should be separated somehow - if a customer removes the web console because they don't want it, they will be quite surprised when all their timers cease to function.

        • 1. Re: Timer servlet
          Tom Baeyens Master

          yes, it should be added.

          here's some argumentation for this:

          if the job thread servlet and the other servlets are all separate war files as you propose, it's going to be a nightmare for people to get that set up right.

          i want to provide to our users the simplest and best possible evaluation platform out of the box. developers must be able to get up and running quickly.

          that is where i think your proposed solutions differ from my position. from a design standpoint, i think you're right. but has turned out not easy for people to start managing a bunch of deployment files.

          the more artifacts they encounter, the more difficult it gets.

          the suite distribution should be as integrated as possible. then the docs should explain how the different pieces can be decoupled and configured.

          • 2. Re: Timer servlet
            David Lloyd Master

            Here's an idea - since Bill is reevaluating jBPM as a deployer, perhaps the timer service ought to be remade as a SAR inside of the deployer when that happens. The servlet class could still be available as an option in this case. That way, no functionality is lost, but it's still integrated (working right out of the box) from an evaluation platform perspective. And no nasty surprises if/when they remove the console WAR.

            • 3. Re: Timer servlet
              Tom Baeyens Master

              1) a sar is not portable and 2) it doesn't provide an easy evaluation distribution.

              i want 2 distributions out of the box:

              1) a war distribution with configurations for standard java and everything inside this one single jar

              2) a .ear enterprise application with configurations for enterprise java usage and everything inside this one single .ear file.


              there are *lots* of ways on how we could split up things that might potentially be deployed separate. it creates a combinatorial explosion of possibilities, which is not possible to document or maintain. at least not with the resources we have now.

              that is why my focus is first on creating the 2 nice integrated easy-evaluatable packages as mentioned above.

              once we have those and within the constraints sketched above, we should think of how we can make it easier for people to undeploy certain parts or tweak those deployment packages.

              it will never be as easy as just deleting a file. it will always involve updating configuration files (which means unzip/update/re-zip). but that is due to the fact that the java standards are all based on zipping configuration files in the packages. anything else becomes less portable.