Novice Tomcat design pattern question

Discussion in 'Java' started by TwelveEighty, Dec 1, 2007.

  1. TwelveEighty

    TwelveEighty Guest

    I have a heavy duty java server application that is collecting
    information from computerized sources and processing and archiving
    events in real-time. The configuration on this app is currently done
    through RMI by exposing certain objects as remote objects on which
    clients can invoke actions (add, remove, change, etc.).

    I like to add the ability to communicate with the server application
    via web services, so Tomcat seems like a good "best practice" choice.
    However, from a design perspective, it seems like the Tomcat server
    becomes the main "host" application from which other java classes can
    be "activated" based on requests from clients.

    The only way I currently see to "bolt on" the Tomcat web services is
    to have two virtual machines running, one with my application and the
    other being the Tomcat server. However, that means that all
    communication between the main app and Tomcat needs to go through RMI,
    because there are two VMs. This sounds very inefficient, I much rather
    have the whole application running in a single VM.

    Is there a design possible where I can incorporate my application into
    the same virtual machine that is running Tomcat? More specifically:

    1) Can I "bootstrap" my own java classes inside the Tomcat environment
    during the Tomcat startup process? If so, does all handling need to
    take place in the constructor of my classes, or can I invoke specific
    methods?

    2) Is there a RMI registry created during the Tomcat startup that I
    can register my existing RMI classes with, to keep the existing RMI
    functionality I have today? If so, can I change its port through
    configuration?

    Thanks.
     
    TwelveEighty, Dec 1, 2007
    #1
    1. Advertising

  2. TwelveEighty

    Arne Vajhøj Guest

    TwelveEighty wrote:
    > I have a heavy duty java server application that is collecting
    > information from computerized sources and processing and archiving
    > events in real-time. The configuration on this app is currently done
    > through RMI by exposing certain objects as remote objects on which
    > clients can invoke actions (add, remove, change, etc.).
    >
    > I like to add the ability to communicate with the server application
    > via web services, so Tomcat seems like a good "best practice" choice.
    > However, from a design perspective, it seems like the Tomcat server
    > becomes the main "host" application from which other java classes can
    > be "activated" based on requests from clients.
    >
    > The only way I currently see to "bolt on" the Tomcat web services is
    > to have two virtual machines running, one with my application and the
    > other being the Tomcat server. However, that means that all
    > communication between the main app and Tomcat needs to go through RMI,
    > because there are two VMs. This sounds very inefficient, I much rather
    > have the whole application running in a single VM.
    >
    > Is there a design possible where I can incorporate my application into
    > the same virtual machine that is running Tomcat? More specifically:
    >
    > 1) Can I "bootstrap" my own java classes inside the Tomcat environment
    > during the Tomcat startup process? If so, does all handling need to
    > take place in the constructor of my classes, or can I invoke specific
    > methods?
    >
    > 2) Is there a RMI registry created during the Tomcat startup that I
    > can register my existing RMI classes with, to keep the existing RMI
    > functionality I have today? If so, can I change its port through
    > configuration?


    There are various ways to achieve what you want.

    You could start a thread calling your apps main method in a
    startup servlet.

    If the calling code can get a reference to the app, then they
    can call whatever methods they want.

    Your Java code can create a registry.

    Arne
     
    Arne Vajhøj, Dec 2, 2007
    #2
    1. Advertising

  3. TwelveEighty

    Juha Laiho Guest

    =?ISO-8859-1?Q?Arne_Vajh=F8j?= <> said:
    >TwelveEighty wrote:
    >> I have a heavy duty java server application that is collecting
    >> information from computerized sources and processing and archiving
    >> events in real-time. The configuration on this app is currently done
    >> through RMI by exposing certain objects as remote objects on which
    >> clients can invoke actions (add, remove, change, etc.).

    ....
    >> Is there a design possible where I can incorporate my application into
    >> the same virtual machine that is running Tomcat? More specifically:
    >>
    >> 1) Can I "bootstrap" my own java classes inside the Tomcat environment
    >> during the Tomcat startup process? If so, does all handling need to
    >> take place in the constructor of my classes, or can I invoke specific
    >> methods?

    ....
    >You could start a thread calling your apps main method in a
    >startup servlet.


    Another way to achieve the same would be to write and declare
    a ServletContextListener to handle the startup. This would have
    the added benefit of also being able to shut down the "external"
    server cleanly when Tomcat is being shut down.

    One slight issue with both of these ways is that the "external"
    server is only started up at the point where Tomcat already
    starts accepting requests - so it could be that the first requests
    through Tomcat arrive at a time where the "external" server has not
    yet completed its own startup.

    It might be good to have a way to provide a way for the "external"
    server to tell the Tomcat webapp whether it is ready to process
    requests or not. This could be done for example by setting an attribute
    in Tomcat servlet context, and having the webapp check the existence
    and the value of this attribute.
    --
    Wolf a.k.a. Juha Laiho Espoo, Finland
    (GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
    PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
    "...cancel my subscription to the resurrection!" (Jim Morrison)
     
    Juha Laiho, Dec 2, 2007
    #3
  4. TwelveEighty

    TwelveEighty Guest

    On Dec 2, 12:42 pm, Juha Laiho <> wrote:
    >
    > Another way to achieve the same would be to write and declare
    > a ServletContextListener to handle the startup. This would have
    > the added benefit of also being able to shut down the "external"
    > server cleanly when Tomcat is being shut down.
    >


    After Arne's post, I started looking into this and I noticed that
    there is also an init() and destroy() method on the HttpServlet
    itself. What would be a better approach, to use the
    ServletContextListener, or use the init() and destroy() methods for
    startup and shutdown of the "external" server?
     
    TwelveEighty, Dec 2, 2007
    #4
  5. On 2007-12-02 14:20:53 -0800, TwelveEighty <> said:

    > On Dec 2, 12:42 pm, Juha Laiho <> wrote:
    >>
    >> Another way to achieve the same would be to write and declare
    >> a ServletContextListener to handle the startup. This would have
    >> the added benefit of also being able to shut down the "external"
    >> server cleanly when Tomcat is being shut down.
    >>

    >
    > After Arne's post, I started looking into this and I noticed that
    > there is also an init() and destroy() method on the HttpServlet
    > itself. What would be a better approach, to use the
    > ServletContextListener, or use the init() and destroy() methods for
    > startup and shutdown of the "external" server?


    A ServletContextListener doesn't have to have any code in it to handle
    (or at least actively reject) servlet API calls and has much simpler
    instantiation guarantees ("once", as opposed to "once, unless you
    implement specific marker interfaces or the configuration says
    otherwise"). If all you're doing is reacting to the servlet container
    lifecycle, I'd use a Listener.

    -o
     
    Owen Jacobson, Dec 2, 2007
    #5
  6. TwelveEighty

    Arne Vajhøj Guest

    Juha Laiho wrote:
    > =?ISO-8859-1?Q?Arne_Vajh=F8j?= <> said:
    >> You could start a thread calling your apps main method in a
    >> startup servlet.

    >
    > Another way to achieve the same would be to write and declare
    > a ServletContextListener to handle the startup. This would have
    > the added benefit of also being able to shut down the "external"
    > server cleanly when Tomcat is being shut down.


    Servlet destroy method should work for that as well.

    But yes a context listener was definitely also a way of doing that.

    Arne
     
    Arne Vajhøj, Dec 3, 2007
    #6
  7. TwelveEighty

    Arne Vajhøj Guest

    Owen Jacobson wrote:
    > On 2007-12-02 14:20:53 -0800, TwelveEighty <> said:
    >> On Dec 2, 12:42 pm, Juha Laiho <> wrote:
    >>>
    >>> Another way to achieve the same would be to write and declare
    >>> a ServletContextListener to handle the startup. This would have
    >>> the added benefit of also being able to shut down the "external"
    >>> server cleanly when Tomcat is being shut down.
    >>>

    >>
    >> After Arne's post, I started looking into this and I noticed that
    >> there is also an init() and destroy() method on the HttpServlet
    >> itself. What would be a better approach, to use the
    >> ServletContextListener, or use the init() and destroy() methods for
    >> startup and shutdown of the "external" server?

    >
    > A ServletContextListener doesn't have to have any code in it to handle
    > (or at least actively reject) servlet API calls


    Neither does a startup servlet. It inherits a couple of do nothing
    methods.

    > and has much simpler
    > instantiation guarantees ("once", as opposed to "once, unless you
    > implement specific marker interfaces or the configuration says
    > otherwise").


    Not doing anything special giving the desired effect is not that bad.

    Arne
     
    Arne Vajhøj, Dec 3, 2007
    #7
  8. On Dec 2, 4:18 pm, Arne Vajhøj <> wrote:
    > Owen Jacobson wrote:
    > > On 2007-12-02 14:20:53 -0800, TwelveEighty <> said:
    > >> On Dec 2, 12:42 pm, Juha Laiho <> wrote:

    >
    > >>> Another way to achieve the same would be to write and declare
    > >>> a ServletContextListener to handle the startup. This would have
    > >>> the added benefit of also being able to shut down the "external"
    > >>> server cleanly when Tomcat is being shut down.

    >
    > >> After Arne's post, I started looking into this and I noticed that
    > >> there is also an init() and destroy() method on the HttpServlet
    > >> itself. What would be a better approach, to use the
    > >> ServletContextListener, or use the init() and destroy() methods for
    > >> startup and shutdown of the "external" server?

    >
    > > A ServletContextListener doesn't have to have any code in it to handle
    > > (or at least actively reject) servlet API calls

    >
    > Neither does a startup servlet. It inherits a couple of do nothing
    > methods.
    >
    > > and has much simpler
    > > instantiation guarantees ("once", as opposed to "once, unless you
    > > implement specific marker interfaces or the configuration says
    > > otherwise").

    >
    > Not doing anything special giving the desired effect is not that bad.
    >
    > Arne


    Oh, I agree with you. Doing it from a servlet *works fine*. I just
    find it more cluttered; even if you inherit the default
    implementations of doGet and doPost, your lifecycle servlet still
    exposes them. I'm a big believer in minimal exposed interfaces.
     
    Owen Jacobson, Dec 3, 2007
    #8
  9. TwelveEighty

    Arne Vajhøj Guest

    Owen Jacobson wrote:
    > On Dec 2, 4:18 pm, Arne Vajhøj <> wrote:
    >> Owen Jacobson wrote:
    >>> A ServletContextListener doesn't have to have any code in it to handle
    >>> (or at least actively reject) servlet API calls

    >> Neither does a startup servlet. It inherits a couple of do nothing
    >> methods.

    > Oh, I agree with you. Doing it from a servlet *works fine*. I just
    > find it more cluttered; even if you inherit the default
    > implementations of doGet and doPost, your lifecycle servlet still
    > exposes them. I'm a big believer in minimal exposed interfaces.


    Eventually context listener will probably replace startup servlets.

    Startup servlets really are a hack.

    But they have served me well for many years.

    Arne
     
    Arne Vajhøj, Dec 3, 2007
    #9
  10. TwelveEighty

    Juha Laiho Guest

    TwelveEighty <> said:
    >On Dec 2, 12:42 pm, Juha Laiho <> wrote:
    >>
    >> Another way to achieve the same would be to write and declare
    >> a ServletContextListener to handle the startup. This would have
    >> the added benefit of also being able to shut down the "external"
    >> server cleanly when Tomcat is being shut down.
    >>

    >
    >After Arne's post, I started looking into this and I noticed that
    >there is also an init() and destroy() method on the HttpServlet
    >itself. What would be a better approach, to use the
    >ServletContextListener, or use the init() and destroy() methods for
    >startup and shutdown of the "external" server?


    I took a quick glance at the Servlet Specification, and the language
    lawyer in me found at least one potential issue; the servlet container
    is free to release any servlet that is not currently running, and I
    didn't see any mention about load-on-startup servlets being any
    exception to this. So, a servlet marked load-on-startup will be loaded
    on context startup - and thus, its init() will be called. However,
    unless I missed something, the container is also free to unload the
    servlet on the next second, and at that point would call destroy()
    on it.

    Realistically, I consider the above to be highly unexpected behaviour,
    and haven't seen any container do it. But as long as the spec allows
    it, you should consider it a valid scenario.
    --
    Wolf a.k.a. Juha Laiho Espoo, Finland
    (GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
    PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
    "...cancel my subscription to the resurrection!" (Jim Morrison)
     
    Juha Laiho, Dec 3, 2007
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. sunny
    Replies:
    1
    Views:
    475
    Salt_Peter
    Dec 7, 2006
  2. Pallav singh
    Replies:
    0
    Views:
    392
    Pallav singh
    Jan 22, 2012
  3. Pallav singh
    Replies:
    0
    Views:
    423
    Pallav singh
    Jan 22, 2012
  4. Pallav singh
    Replies:
    1
    Views:
    465
    Peter Remmers
    Jan 22, 2012
  5. Robert Day

    Novice - help with pattern matching needed

    Robert Day, Feb 7, 2004, in forum: Perl Misc
    Replies:
    5
    Views:
    125
    R Day
    Feb 8, 2004
Loading...

Share This Page