• Post Reply Bookmark Topic Watch Topic
  • New Topic

Getting server port number in servlet init method

 
Aidan hughes
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

I have two instances of Tomcat on the same server - one for QA and one for Production running on ports 8082 and 8083.
I'm using quartz to schedule a task within Tomcat.
I want my Quartz task to only run on the Production instance and not on the QA instance.
So - I want to put in a condition that if port is 8083, initialise the task, otherwise do nothing.

My question is - how do I retrieve the port number in the init method.
In a doGet or doPost I would use

but in the init method there is no request object.

Any Ideas?

Thanks in advance !

Aidan

 
Raghavan Muthu
Ranch Hand
Posts: 3381
Mac MySQL Database Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Aidan hughes ,

Welcome to JavaRanch.

You can try with request.getServerPort() as well. But as you said, it is not available in init(), you can have two options of making it available.

  • Setting it in Config -> <init-param> of <servlet> element and getting it via ServletConfig object which is passed to the init(ServletConfig config) method.
  • Setting it globally via application scope -> context -> <context-param> element inside <web-app> directly and getting it via ServletContext object.



  • But you got to set these in the web.xml based on the port number in which your specific Tomcat instance in running.

    Does this help?
     
    Ben Souther
    Sheriff
    Posts: 13411
    Firefox Browser Redhat VI Editor
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Personally, I think you'd be better off switching this on an off via a context init param or by putting it in any other configuration files you might have in your app.

    System administrators should be free to change port numbers and network configuration settings without worrying about breaking an application's functionality.

    If must branch on the port number, at least make that port number configurable so that the administrator, when trying to debug the application that broke when the port number was changed, can find the issue by looking at your configuration files instead of having to go through your source code (if it's even available).
     
    Raghavan Muthu
    Ranch Hand
    Posts: 3381
    Mac MySQL Database Tomcat Server
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Originally posted by Ben Souther:
    System administrators should be free to change port numbers and network configuration settings without worrying about breaking an application's functionality.

    If must branch on the port number, at least make that port number configurable


    Thats very well agreeable. Setting or configuring the same in web.xml may need the restarting of the Application or Web Server as the values are not read again after the Server is started.

    But configuration in the properties file would be a best solution in this manner.
     
    Ben Souther
    Sheriff
    Posts: 13411
    Firefox Browser Redhat VI Editor
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Since this is something that he wants to read when the app is started (init()) then it shouldn't matter that it takes a restart for it to take effect. If fact, it would be preferable.
     
    Raghavan Muthu
    Ranch Hand
    Posts: 3381
    Mac MySQL Database Tomcat Server
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Originally posted by Ben Souther:
    Since this is something that he wants to read when the app is started (init()) then it shouldn't matter that it takes a restart for it to take effect. If fact, it would be preferable.


    Yes. That's correct.

    Whenever the port number is going to be changed, the application should get restarted. So my previous answer also makes sense! Right?
     
    Paul Clapham
    Sheriff
    Posts: 21876
    36
    Eclipse IDE Firefox Browser MySQL Database
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Originally posted by Aidan hughes:
    I want my Quartz task to only run on the Production instance and not on the QA instance.
    So - I want to put in a condition that if port is 8083, initialise the task, otherwise do nothing.
    As the others have already said, you need to use some other configuration attribute to determine if it's production or QA. Suppose the QA system gets moved to a different machine and now both instances use the same port number, for example? You need something that says explicitly "This is Production" and "This is QA".
     
    Raghavan Muthu
    Ranch Hand
    Posts: 3381
    Mac MySQL Database Tomcat Server
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Originally posted by Paul Clapham:
    As the others have already said, you need to use some other configuration attribute to determine if it's production or QA. Suppose the QA system gets moved to a different machine and now both instances use the same port number, for example? You need something that says explicitly "This is Production" and "This is QA".


    Yeah, that indeed looks like an enhanced solution
     
    Aidan hughes
    Greenhorn
    Posts: 10
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Looks like I've started a good debate here!

    Yes - all good points - Thanks for your input.
    Right now I do differentiate by turning this on/off by either including or not including it in a <servlet> element in web.xml (with a <load-on-startup> element to force the init method when the application is started).

    Perhaps I should explain why I want to change this. Whilst it works, it means I have to have two different builds for QA and production. I know this is a very small difference, but our internal QA people get suspicious when I test and validate a build in QA, but then submit a different build for Production. Every time I do a code migration I have to explain the difference, and I'm trying to find a way to make that difference go away.

    Maybe the correct answer is to educate our QA people that the configuration files are just that, and not part of the application. However, the fact that I package web.xml and context.xml in my WAR files makes this difficult.

    One thing I will take on board is that If I do this at all, I will check for server as well as port in case QA and Production are moved to different machines.

    Another possibility I have been considering is to split this particular process into its own seperate web application. This means that the remaining web application would be identical for both QA and Production.

    Does any of these comments change how you would approach this?

    Thanks again for your thoughts so far.

    Aidan.
     
    Ben Souther
    Sheriff
    Posts: 13411
    Firefox Browser Redhat VI Editor
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I still stand by my first assertion.
    Having your app branch on the port to which the server is bound for any reason (but especially to satisfy some odd QA requirement) doesn't sound like a good idea.

    If QA's concern is that they're testing a different app than the one going into production because the config file is different, wouldn't it be equally true that they're testing a different app depending on which port a particular instance is bound? If so, isn't the answer to have the Quartz job running in QA just as it would in production?

    Back to the technical issue...
    I think one fundamental problem you're going to have is that an app server can be configured to listen on more than one port. One example is 80 for non-secure and 443 for secure. Another example would be Tomcat running connected to Apache HTTPD; one port for the standalone and another for the connector.

    This might be the reason that the servlet spec doesn't offer a method that tries to return the port number at start up time. It may only ever plan on knowing the port number when a particular request comes in.
     
    Aidan hughes
    Greenhorn
    Posts: 10
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Ben,

    I take your points - I'm going to abandon this line of attack and stick to starting the process from the config files as discussed.

    Incidentally, the reason I don't want the process running in both instances is that it imports data from other systems and could cause duplicate records if run twice.

    Thanks for your help,

    Aidan.
     
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!