Double slash in context path in Websphere Application Server - java

I would like to know if it is possible to put a context path like this when deploying a WAR to Websphere Application Server: /api/v3.1, and another one with the same context path but for another version of the API to be launched in the same WAS.
In my team we want to version the API we are exposing to the clients, we have a monolithic application created with Spring Boot that is deployed into a WAS v8.5.
For that we have in mind the approach of versioning the API putting the version in the URI:
https://example.com/api/v2.1
https://example.com/api/v3.0
It looks like it deployed correctly but when consuming it says that there is no file mapped to those URIs.

Yes. It is possible (and helpful for API versioning with the URI). The issue was to putting '/' (slash) at the end of the context path. It is valid only at the beginning (or when it is empty).

Related

How to deploy services of different version but same EJB name and context-root on Jboss 7.1?

So i am trying to deploy new version of SOAP service with different version.
In jboss-webservices.xml I have configured url to service as:
<context-root>/services/MyService</context/root>
<port-component>
<ejb-name>MyServiceEJB</ejb-name>
<port-component-uri>v1</port-component-uri>
...
</port-component>
When I try to deploy service v2 with <port-component-uri>v2</port-component-uri> it ends up with duplicate deployment error because of same context root.
So I tried it with <context-root>/services/MyService/v2</context-root> and <port-component-uri>/</port-conponent-uri>. This solution actually works. But the wsdl is at location : https://MyServer.com:8443/services/MyService/v2/?wsdl.
Is there any solution to be the wsdl at https://MyServer.com:8443/services/MyService/v2?wsdl ? Without the "/" before the "?wsdl".
Basically I want to have deployed both versions of application, where both has url https://MyServer.com:8443/services/MyService/v1 and second https://MyServer.com:8443/services/MyService/v2, but without touching the context-root element.
Thanks for any tips.

Log4j2 configuration - indentify the webapp

In my webapp I configure Log4j2 with XML file.
The case is there's might be several versions of this webapp deployed on the server (for production purpose). If I don't edit log4j2 configuration, all webapps write logs to the same location.
So I need somehow identify versions of the app and add this identifier to the end of the folder name.
Apps always have different names, so maybe I can use it.
Can anyone please suggests some solution for this?
P. S. I know I could use ${log4j:configParentLocation} or something like this, but this gives me troubles when I deploy the app.
Edit: I don't use Spring boot, just usual Tomcat Servlet webapp with web.xml.

how to add a parameter to spring project before <projectname>/login and after <localhost>:<portnumber> without hardcode?

I'm working on a Spring MVC project. When I run the application the URL is:
http://localhost:8080/insureYou/login
but I want:
http://localhost:8080/contextroot/insureYou/login
Is there any way of doing it without hardcoding?
In a spring-boot project you can set the context-root by specifying the following property in the application.properties file:
server.servlet.context-path=/yourcontextroot
Without spring-boot, it depends on the webserver and Tomcat offers a number of options.
I would personally opt for a META-INF/context.xml file in your war file containing the necessary information but you can also include the information in the server.xml file or in a ROOT.xml file.
See the following links for further guidance:
How to set the context path of a web application in Tomcat 7.0
https://tomcat.apache.org/tomcat-8.0-doc/config/context.html
https://www.baeldung.com/tomcat-root-application
This type of deployment however sometimes is handled separately, through an Apache server reverse-proxy or through URL rewriting.
I recommend you ascertain whether this type of need is already taken care of by your company's deployment procedures, as you may not need to deal with it at all.

Can I have multiple Java webapps with overlapping paths?

I have a large collection of different independent (stateless) web services written in Java and compiled as WAR files. I want to deploy them to a single web application server.
If the URIs handled by the services in each WAR file began with a prefix I could use as a web app name, then this would be easy. I could, for instance, have
SALES WAR FILE: contains code for the following:
GET http://example.com/sales/widgets
POST http://example.com/sales/widgets
GET http://example.com/sales/sky-hooks
MARKETING WAR FILE: contains code for the following:
GET http://example.com/marketing/widgets
PUT http://example.com/marketing/sky-hooks
...in which case I would simply deploy two WAR files under the names "sales" and "marketing". However, I am not that fortunate. Instead, the URI paths handled by the components overlap. Something like this:
SALES WAR FILE: contains code for the following:
GET http://example.com/widgets/sales
POST http://example.com/widgets/sales
GET http://example.com/sky-hooks/sales
MARKETING WAR FILE: contains code for the following:
GET http://example.com/widgets/marketing
PUT http://example.com/sky-hooks/marketing
My question is how (if at all) I can deploy these on a single web application server.
I am open to suggestions that require a significant amount of work. For instance, my best-so-far idea is to build services that expect a component-name prefix before the regular URI path, then pipe all incoming traffic through a different server that knows what component each URI pattern falls into and modifies the URI to add that prefix. The difficulty with this approach is that tools like Swagger that read my source code will have a mistaken idea of what the URIs look like.
Any ideas?
If you're willing to put apache in front of your web container, you can use apache's mod_proxy to forward request to the right place.
One way this could work, would be deploy the separate wars at separate prefixes as in your first case (sales and marketing) and then use ProxyPass to send the requests to the correct place:
ProxyPass /widget/sales http://example.com/sales/widget
ProxyPass /sky-hooks/sales http://example.com/sales/sky-hooks
ProxyPass /widget/marketing http://example.com/marketing/widget
ProxyPass /sky-hooks/marketing http://example.com/marketing/sky-hooks
Its probably a better idea to just refactor your routing though - it might be hard to maintain.
(EDIT: I originally suggested mod_rewrite, but I wanted to make my answer more specific, and it looks like this could be done purely with proxying)
If I understand your question correctly, one of the solutions would be (I am assuming Tomcat is used but this should apply to most of the modern servlet containers):
1) Deploy your sales and marketing wars with different prefixes. I.e., using your example, they should be able to serve the following urls:
GET http://example.com/sales/widgets/sales
POST http://example.com/sales/widgets/sales
GET http://example.com/sales/sky-hooks/sales
GET http://example.com/marketing/widgets/marketing
PUT http://example.com/marketing/sky-hooks/marketing
2) Use UrlRewriteFilter to craft lightweight web application that will be deployed to your servlet container root prefix (for Tomcat it is called ROOT.war) and will rewrite urls in incoming requests to point to relevant web application.
In other words, incoming request like:
/widgets/sales
will be transformed to:
/sales/widgets/sales
... and delivered to sales webapp.
Similarly, in response urls like:
/sales/widgets/sales
will be rewritten to:
/widgets/sales
3) Deploy this war to root of your servlet container.
This approach is somewhat similar to the one suggested by #nont but does not require apache as a frontend as the rewriting functionality will be handled by root web application (UrlRewriteFilter basically implements mod_rewrite functionality).
In other words you'll be able to deploy all your applications (including this rewrite application that is deployed to the root prefix) to single server alleviating need for extra intermediate proxy/rewrite servers.
First, Determine How the Deployments may be Configured
Are you sure the absolute URIs must overlap? The context root will prefix the path supported by each service, unless the absolute path has somehow been coded into the application itself. The first step is to enable direct access to each WAR file, either through unique context roots or application instances.
Option 1: Set the Context Root for each WAR File Explicitly
The context root for a war file is set at deploy time. For some servers, this can be set outside of the web application using an external deployment descriptor. For Tomcat, it may embedded within META-INF/context.xml. See http://tomcat.apache.org/tomcat-7.0-doc/config/context.html for more information.
Option 2: Separate the Context Root Instances using Multiple Containers
Alternatively, deploy each war file to a separate instance of a Java EE servlet container, each running on a different port. This will solve the deployment conflict in the case of a hard-coded absolute path.
Finally, Set up a Virtual Host and Proxy the Requests via Apache and mod_jk
Once the context roots instances have been made uniquely accessible by one of the previous methods, configure an instance of Apache to serve as a reverse-proxy. First, set up a virtual host to handle requests for the externally visible URI. Next, configure mod_jk to route the requests to the correct WAR file deployment. See http://tomcat.apache.org/connectors-doc/webserver_howto/apache.html for more details.
Afterthoughts
The above solution approach is generic for this type of problem and will require some knowledge of Apache and Tomcat configuration, which were chosen as example reverse-proxy and Java EE servlet technologies for its implementation. Additional detail on the deployment constraints would help to determine an optimal solution. In general, identifying the hard constraints on what may be changed versus what may not be changed should guide you quickly to a solution.
The obvious slotuion is to rename the wars, or refactor so that the appropriate mappings are in the correct place.
Anything else is going to be a bit hacky, you can't change the war name, even to soemthing like below :
SALES WAR FILE: contains code for the following:
GET http://example.com/webapp1/widgets/sales
POST http://example.com/webapp1/widgets/sales
GET http://example.com/webapp1/sky-hooks/sales
MARKETING WAR FILE: contains code for the following:
GET http://example.com/webapp2/widgets/marketing
PUT http://example.com/webapp2/sky-hooks/marketing
You could also create another war for routing/filtering, that redirects everything appropriately - but that also relies on altering url somewhat.
This is a use case for Reverse Proxy. If your web server is Apache, as suggested by #nont proxy_mod can be used to create a reverse proxy.
I know that IBM Http Server (IHS) also allows this mod.

Can I change web application root globally in jboss 4.2?

I have following situation of deployment:
application_one.war
application_two.war
application_three.war
When I deploy it in Jboss, I get three url contexts:
http//myserver/application_one/
http//myserver/application_two/
http//myserver/application_three/
Is it possible to change (prepend) globally an additional path to all deployed webapplication in a single setting, so that my new path would look like this?
http//myserver/globalprefix/application_one/
http//myserver/globalprefix/application_two/
http//myserver/globalprefix/application_three/
I do not want to change the war by using jboss-web.xml, but I am looking to do this in a general way on a central position, so even new wars will get this context prepended.
This is slightly off topic, but in a lot of production environments you'd have a web server such as Apache "in front" of your appserver (in this case JBoss), which you would be able to set up with a path (check out mod_rewrite, though don't quote me on that).

Categories

Resources