I have two different APIs. They each have their own .war file and are both running on the same tomcat instance.
Strangely, I am able to reach one API with requests like this: https://(ip-address):443/(path1)
but the other responds only to this: http://(ip-address):8090/(path2)
Also complicating things is that, when I deploy the second war to a certain other tomcat instance on another server, it will respond to https 443 requests.
Any idea how this is possible?
This is strange, because at different times either the war or tomcat works as intended (by using https), so it is unclear whether to blame the war or tomcat.
Applications can declare they need confidential connections (HTTPS). Look at the WEB-INF/web.xml inside.
So one of the applications might use both because there is no constraint defined, the other may just respond to https as the container is responsible to ensure secured communication. I'd be more surprised to hear that one of the applications responds to http only.
From https://tomcat.apache.org/tomcat-9.0-doc/config/http.html#Introduction:
One or more such Connectors can be configured as part of a single Service, each forwarding to the associated Engine to perform request processing and create the response.
Check in your server.xml whether you have several services with http and https connectors that are mapping to different engines, and whether the applications are deployed distributed on these different engines. That could explain one application responding to http only, while the other is responding to https only.
Related
I have a Spring application with two controllers. I want to run one controller on localhost:8080 and second controller on localhost:8081.
Am I able to configure Tomcat to serve two ports simultaneously i.e 8080 and 8081? Is it possible? How?
Please note that it is not a Spring Boot application.
It sounds like two completely different applications.
You certainly could configure your Tomcat's server.xml file to have multiple HTTP connectors running on different ports. But you'll find it much easier and hassle-free to deal with two different Tomcat instances.
The App Server (Tomcat, JBoss,Glassfish) run on / watch one port. You can run multiple app servers on a single node (computer) with different port numbers for this reason. They could be the same (Tomcat+Tomcat) or different ones as well (Tomcat+Glassfish)
But in this case you need to split the controllers into 2 different applications and deploy them on the app server instances.
This is the MicroServices architectural desing style. When you run a separate app server for every service. Microservices services most of the cases use REST over HTTP to communicate to each other.
But in case of Tomcat (maybe not by all of the products) it is possible : Running Tomcat server on two different ports
No. spring runs on a specific port and that will be port for both rest controllers . You can have different URLS for them though.
It's not possible.
Spring MVC, as many other web frameworks, is designed around the front
controller pattern where a central Servlet, the DispatcherServlet,
provides a shared algorithm for request processing, while actual work
is performed by configurable delegate components.
https://docs.spring.io/spring/docs/current/spring-framework-reference/web.html
Spring itself doesnot run on any port. It is just a technology to create APIs. Port binds with server (like Tomcat, JBoss, etc). So if you want to use different ports for different controllers, then you need to deploy multiple applications across multiple servers and make those servers listen different ports.
On the application that should be on 8081, in the application.properties file add the following line:
server.port=8081
Then Just run both of them...
Otherwise in the TomcatConfiguration set the port to 8081, and again run both of them.
You can find the perfect example in below link. They use different port for different resources. It uses port binding with embedded tomcat in spring boot. Hope this helps you.
https://tech.asimio.net/2016/12/15/Configuring-Tomcat-to-Listen-on-Multiple-ports-using-Spring-Boot.html
Yes, you can, but they will behave like two separate applications and are independent of each other. However they can share common resources like databases, Password directories etc.
However for a use case such as this I would recommend to look into microservices.
Read more about microservices here
One approach is to create additional org.apache.catalina.connector.Connector and route requests from it with org.springframework.web.servlet.mvc.condition.RequestCondition https://stackoverflow.com/a/69397870/6166627
I have multiple Java web applications deployed on the same server (Wildfly).
They all should use a single WebSocket implementation to send messages (object, not plain text) to the user.
Edit: WebApp1-3 are the applications with the business logic. The only purpose of WebApp4 is to update a Primefaces panel in the browser based on the messages generated by the other WebApps. Sorry for the missleading illustration.
WebApp1
WebApp2 --> ??? --> WebApp4 (WebSocket-Server) --> JS/Browser
WebApp3
Which is the best way/pattern/implementation to make WebApp4 available to the other applications? (RMI, JMS, WebSocket, WebService, ....?)
My advice, for a general way of exposing services, is to expose REST services since they are simpler than SOAP web service and easily allow interoperability (if in the future a PHP or a RUBY webapp needs to consume your services it's much easier with a REST interface than with one base on RMI or JMS). The content of the REST service may vary, I suggest you to look at XML or JSON as a way of transmitting information over http REST services.
If all webapps are in the same server, you should forward requests from one to another. From the point of view of webapps 1-3, they would not need to be aware of whether their incoming requests were coming from webapp 4 or from outside (to which it appears that they are not connected). Of course, you are free to alter requests before forwarding them - or to drop them altogether, for example if authentication fails.
To do this in tomcat: https://stackoverflow.com/a/8951090/15472
When forwarding requests, the external client is completely unaware of the existence of webapps 1-3 -- as far as the client is concerned, it has sent a request to webapp 4, and it will think it is receiving a response from that same server.
You may need to configure your web server to allow these kinds of calls, but I am unfamiliar with WildFly.
I have a system where several (20 or so) web app servers (hosting a website) talk to the same 2 - 4 EJB servers (through a VIP). I'd like to know if it is possible to identify which one of those app servers generated a specific request.
For example: Website example.com works by sending HTTP requests to any of 20 app servers to handle the request. These servers are named (internally) app01 through app20. It is ensured that all requests with the same session ID will be routed to the same app server, thus enabling us to logically track all requests from a single user. Some requests will need some extra data not available directly, for which there is an EJB (2.1) application on another cluster of 3 servers, named ejb01 to ejb03. Connections to the EJB servers are made through a VIP (ejb00), which routes the requests round-robin style to the three EJB serves.
Within the logging (we use Apache Log4J) of the EJB servers, it would be really nice if I could identify which of the 20 app servers a request originated from. The alternative is checking the logs on each server separately - but I don't have a good way to grep through the logs on 20 different boxes.
My question is: is this possible within Standard EJB? I'd be willing to do something non-standard, if there was nothing else, but it's gotta be reliable and work on my system. We use Weblogic 11g, both for the web-app and the EJB servers.
I've seen suggestions to pass the identity of the caller as a parameter, but that would mean an extra parameter for each of 20+ EJB methods, and that's rather unwieldy.
Any solutions, anyone?
There is no standard solution. There was a proposal in JSR 149, but it was withdrawn. Adding an extra parameter to the remote methods is probably your best option. If you're using RMI remote, you might be able to write an ORB interceptor to add a custom context on the client side, receive it on the server side, and set a thread local around the method invocation on the server.
WebSphere Application Server has a non-standard solution called work areas, which does work for remote EJB.
I am not familiar with WebLogic, so I don't know if they have a similar solution. Searching for similar terms finds a WorkContextMap that looks similar, but I don't know if it works for remote EJB since all the examples I can find are for webservices.
My question is simple: is it perfectly safe to have 2 independent Jetty Server instances in one JVM process, listening on different ports with independent URL mappings and SSL/TLS setup? I'm not seeing odd behaviour but before deploying to live, I'd like to get some assurance that what I'm doing is sound. If not, would it be proper to have the same set-up using a single Server instance with somehow separate URL namespaces and security SSL/TLS setup?
Yes, absolutely. We do this in many unit tests throughout Jetty.
I want to expose a Java application via IIS. I found an answer in Running a java web application in IIS that refers to the isapi redirector. However what also seems to work for me is to set up IIS URL rewriting rules. E.g. I have set up a rewrite rule that matches ^java/(.*) and rewrites it to http://localhost:8080/{R:1}
I am a programmer and not a web server administrator, so I do not understand the implications of one versus the other. Which is the preferred approach and why? URL rewriting seems simpler to setup since it involves less 'moving parts' and less configuration.
In my experience I've had to use the ISAPI redirector when the following conditions are met:
Company/System policy doesn't allow to expose another HTTP port on the server (i.e. 8080/tcp), and IIS already owns 80/tcp, so another server can not be bound to this or any HTTP port. In this case IIS and the Java server communicate through the AJP port, and the workers files have to be configured to redirect only to the context of the Java application.
[Optional] For performance reasons, static content (html, js, css, jpg, ...) has to be hosted on IIS and only the dynamic content is left for the Java server. Again this calls for some careful workers configuration and selective deployment of content on each servers.
If you don't have to meet any of these conditions, and if Company/System policy doesn't enforce that all requests go through IIS, then a URL rewriting rule is probably OK.