I want to programmatically get the servlet containers port that my Java EE application is deployed on. I assumed there would be something in the JMX beans but I can't seem to find anything.
And before anyone says grab the port from the HttpRequest or HttpResponse it should be noted that this process is running behind the servlet and has no interaction with the Requests or Responses.
One possible "hack" would be to parse the server.xml at runtime and identify the port that is configured.
But looks like there is a way to do it using JMX / MBeans as well.
I happened to have a strong need to extract the tomcat port from request. So that I can compare and tell if the servlet request is from tomcat port http://localhost:8080 or from apache port http://localhost/
By doing this, I can make sure the request only be processed by strictly using tomcat port and rejecting by apache port. This may help setup security configuration that the request would not allow outside world access via apache. tomcat port only available within local network.
The method is to create a tomcat valve (assuming you know what it is) implements org.apache.catalina.valves.ValveBase.
This interface provides org.apache.catalina.connector.Request as an argument.
Per request:
using request.getConnector().getPort() which returns 8080. Then say.
if ( request.getServerPort() != request.getConnector().getPort() ) {
response.getWriter().print("<span>access denied</span>");
} else {
getNext().invoke(request, response);
}
Related
Situation:
My client has a Java web application deployed on a JBoss server, it is accessed both via HTTPS and HTTP
The JBoss server is sitting behind a load-balancer that handles the SSL, in other words this load-balancer terminates SSL and sends requests to JBoss as plain HTTP
Problem I need to solve:
The web application deployed on JBoss needs to know what port the load-balancer is using for HTTPS, so that it can direct users to certain HTTPS urls correctly. This cannot be hard-coded because the application will be deployed on multiple clients, each of them have different configurations for the load-balancer.
My approach (which didn't work):
I am defining the port from a jspx page, via ${pageContext.request.serverPort}, but this always returns the port for HTTP because JBoss always gets the request via HTTP.
Thanks in advance. I've looked at this question but was not helpful.
There isn't really a way to determine the port if tomcat is sitting behind a load balancer. As suggested in the comments, exposing the port configuration to your clients would be the best for now.
I am trying to find a solution for a Server Independent WebSocket implementation, Tomcat inbuilt WebSocket API is good but it's not running in Weblogic and other servers .
I found a solution with Tyrus API , but all examples of Tyrus is done with grizzly web server , where it starts a separate server with a new port to accept ws:// request , but it has another option which is ServerContainer, where it will work with any Servlet Container web server and will use the existing Server port only, but unfortunately no example i found .. I am looking forward to any other options also ...
I have a java webservice running on Apache Tomcat 7.0.39. It receives a message from another server on the same network then tries to send an outgoing message back. This outgoing message is being sent to NAProxy instead of the server it's supposed to.
I've turned off proxy settings in IE and the Java control panel. I've tried adding a ProxyServer variable to the cxf-beans file:
<http-conf:conduit name=".*http-conduit">
<http-conf:client ConnectionTimeout="20000" ReceiveTimeout="30000" ProxyServer=""/>
</http-conf:conduit>
but neither of these things work.
IE can reach the destination service from the outgoing server. I can hit the hosted destination service from the server using SOAPUI, so it's just a problem with the apache service, not the box.
It seems it is defaulting to use the proxy instead of a direct connection. Is there a setting somewhere to turn off proxy use?
Proxy can be set also using system properties http.proxyHost and http.proxyPort. I don't know how your application is being started, but maybe somewhere there are JVM parameters -Dhttp.proxyHost=... -Dhttp.proxyPort=...
Since it is Tomcat, maybe you should check startup file.
Tomcat is running in my localhost on standard 8080 port. When tomcat calls a service (soap/rest) running in the same server, I would like to capture it through fiddler.
Basically, any request that tomcat sends out, should be captured through Fiddler. Currently, it sends out request to another service running the same machine and that service in turn calls Amazon AWS, which I would like to capture as well.
Can anyone help? Note that this is opposite of traditional web request through proxy to the server.
I am open to any other alternatives as well.
Please have a look at How to capture SOAP messages from a Tomcat Java app to an external server? for information on setting the proxy for Tomcat.
The correct JVM parameters should look like: -Dhttps.proxyHost=127.0.0.1 -Dhttps.proxyPort=8888 -DproxySet=true -DproxyHost=127.0.0.1 -DproxyPort=8888
I need to retrieve server information like Server IP and Port at server startup.
I am using Spring and hibernet in my project and Glassfish (and tomcat) is the application server.
I know that I can get the IP and Port information from request, but there is no request at server startup.
I found on net after some search that IP address can be retrieved as follows:
InetAddress.getLocalHost().getHostName();
but I did not find any method to retrive the current Port of the server. I am hoping to find API from app server which will provide this information. I am using Spring in my application and thus any indications from Spring API will also be helpful.
Well you should configure port in your web.xml as param and read it out in your code using ServletContext or you can use this poor hack
A server may be listening to multiple ports on multiple names, so you cannot be certain that the one chosen automatically is the one you really want.
Question is what you need it for.
If it is for giving URL backs in requests then use the information in requests.
If it is for logging or announcement with ZeroConf, then consider writing application server specific code asking it about its configuration.
If all else fails, explicitly pass in the information through e.g. system properties or JNDI.