Where to change datasource in Jboss WildFly war file - jboss

My current environment uses Linux, CentOS, WildFly 16. There are multiple datasources and it is all established externally in the standalone.xml. The application(s) in WildFly work just fine.
The issue I am dealing with is when I deploy the war file using command line interface (./bin/jboss-cli.sh) the application will use the existing datasource and I would like to change the datasource. For example App1.war uses MySqlDS1 datasource and App2_test.war uses MySqlDS2 datasource. I plan to overwrite App1.war with App2_test.war. The code will be mv App2_test.war App1.war . At that time the App1.war will be pointed to MySqlDS2 datasource, I believe since it now contains the App2_test code - that is the issue.
I need to change the App2_test.war file to point to MySqlDS1. I need to find the file that associates the URL to the datasource in the standalone.xml - I believe. I looked into web.xml but it does not exist in my war file and may not be provided in releases above EAP 6. I also looked into jboss-web.xml but unable to find file. I only have Manifest.mf in /META-INF and nothing in /WEB-INF/lib.
What file needs to be updated?

Related

Externalizing log4j.xml in JBoss EAP 7.0.3

I have a possibly unique problem. We are using a thirdparty web library that uses log4j to log. Currently, our apps are set up to use the JBoss native logging.(We do this so we can vary the log printouts per environment)
The Thirdparty war file requires us to have a log4j.xml baked into the war its deployed in. Obviously we don't want that.
Here is what I have tried.
I have tried removing it and seeing if it will use the native jboss logger setup.
I have tried setting -Dlog4j.configuration to the path of the log4j.xml file.
I tried setting a system property of the jboss eap in the standalone-full file with the same name.
I dont have access to the source code, but I can decompile.
Any ideas?

Make per-context JNDI variable available to Tomcat in Eclipse

I'm using Tomcat 8.5.6 inside Eclipse 4.6.1. I have my web-app project/context foo, which has a JAX-RS (using RESTEasy 3.1.0.CR3) endpoint of bar, so I can fire up Tomcat inside Eclipse and access:
http://localhost:8080/foo/bar
I have a variable named foobar which I want to access inside my JAX-RS implementation using JNDI:
final String foobar = (String) new InitialContext().lookup("java:comp/env/foobar");
I plan on deploying the produced WAR in production using Tomcat autodeploy. I want to configure the foobar variable for Tomcat externally to the WAR. How can I do that so that I can test it in Eclipse?
After a lot of reading, I found what I thought to be the $CATALINA_HOME of Eclipse: …\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\. So I created a context file for foo at …\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\conf\Catalina\localhost\foo.xml to correspond to my project/context, and put the following inside it:
<?xml version="1.0" encoding="UTF-8"?>
<Context>
<Environment name="foobar" type="java.lang.String" value="123"/>
</Context>
Yes, I know that Eclipse erases this directory whenever I rebuild. But after building, I saved to file at least want to see if it works. It doesn't. I get an error:
javax.naming.NameNotFoundException: Name [foobar] is not bound in this Context. Unable to find [foobar].
I want to at least get it working so I can know how to do this in production, and worry later about the context file deletion thing in Eclipse. So what did I do wrong? Why can't Tomcat in Eclipse find this JNDI variable?
Note: I am not using a web.xml file and have no desire to do so; besides, this variable should be defined outside the WAR in the production deployment.
Update: The good news is that (on Windows 10 Professional Anniversary Edition 64-bit) using the same Tomcat but in standalone mode, I put the same foobar.xml file inside the standalone Tomcat's conf\Catalina\localhost\foo.xml, and my JAX-RS application picked it up just fine. So how can I define a JNDI variable in Tomcat inside Eclipse for testing?
It appears that in order to get Eclipse+Tomcat to recognize the per-module context files, you have to go into the server configuration (double-click on the server) and turn on the Publish module contexts to separate XML files. This way Tomcat will use the specific context XML file you created. Otherwise it apparently puts them in conf/server.xml and ignores the context-specific file you created.
There is still the problem that Eclipse regenerates this file each time you do a rebuild, destroying whatever JNDI variables you placed there. I'm trying to get the workaround in https://stackoverflow.com/a/22380248/421049 to work, but not yet succeeding. Anyone have any better ideas?
At least I'm able to reproduce a production environment now --- albeit temporarily, until the next rebuild.
Your link to Markus' answer on https://stackoverflow.com/a/22380248/1794485 allowed me to get this working, or at least as described in his workaround. But the remaining problem to solve was ordering.
As he said, you can workaround this by having a local copy of the META-INF/context.xml somewhere else, and adding this folder to the Deployment Assembly in the project properties of the Eclipse project.
This didn't pick up for me initially though. It looks like that while the Deployment Assembly in the properties shows as sorted by name, in fact it has an order like any other path. When I then removed the src/main/webapp entry (so the one containing the normal META-INF/context.xml) and added it back in, this effectively moved it down the pecking order. The next Tomcat deploy and startup in Eclipse finally put my preferred copy of META-INF/context.xml in .metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebapps\myapp\META-INF
If in doubt about the true sequence of that Deployment Assembly path, have a look under your Eclipse project on the file system - at .settings\org.eclipse.wst.common.component.

Including the MySql's connector/j as part of an EAR file: Glassfish

We want to simplify the deployment process of an app by including the MySql connector/j jar as part of the EAR. (so we won't need to manually copy it in the /lib folder of our Glassfish servers)
Is it possible?
UPDATE: We have read this is possible using the SAR files in JBoss, but we don't think it's available in Glassfish.
Because of the classloader hierarchy in Glassfish I don't think this is possible. The mysql driver jar needs to be available outside of your application's classloader because the connection pool is globally available.
http://download.oracle.com/docs/cd/E19226-01/820-7695/6niugesfp/index.html#indexterm-28
From what I can find, Glassfish doesn't support anything like .sar files:
http://old.nabble.com/Migrating-From-jboss-4.2.1-to-GlassFish-td18629992.html
Maybe vote for this issue, or create your own for a .sar-like deployment option:
http://java.net/jira/browse/GLASSFISH-16915

jndi.properties in JBoss and GlassFish deployment

Currently an EJB / Web Application project uses a JBoss-specific JNDI configuration file, placed either in the conf directory or in the Jar file (both works fine).
How can I make this project portable between JBoss (4.2.3 or 5) and GlassFish 3? Is there a recommended way to set different JNDI configuration parameters depending on the container?
According to their EJB FAQ, Glassfish developers have put a jndi.properties file within appserv-rt.jar. The JNDI machinery in Java SE automatically detects this file when used in conjunction with no-arg InitialContext() and bootstraps the correct naming provider.
My understanding is that this should work in Glassfish also. Did you try do deploy your application without the jndi.properties file specific to JBoss (and to place it into the conf directory when deploying on JBoss)?

Deployment of Web Application to a Running Tomcat

I would like to collect some best-practices on deployment of a web-application to a running Tomcat. Not long ago I had to describe the deployment process of our web-application and the process appeared rather confusing.
Say, we have an application in a WAR file (foo.war) correctly configured and not requiring additional configuration. In this case, the deployment process is rather easy:
Copy the foo.war file to the $CATALINA_HOME/webapps directory. If the application starts correctly, the application will automatically deploy to $CATALINA_HOME/webapps/foo directory.
To undeploy the application:
Remove the foo.war file from the $CATALINA_HOME/webapps. If the application unloads correctly, it will be unloaded and the $CATALINA_HOME/webapps/foo will be removed.
Now I want to override some context parameters in my running application. Having read the docs, all I need to do:
Create a context.xml file called foo.xml
Copy the file to the $CATALINA_BASE/conf/[enginename]/[hostname]/ directory.
Unfortunately, that did not work: the application would not restart. Empirically, we found out that the only working solution is when the war file is deployed to a location outside the $CATALINA_HOME/webapps.
Besides, the default values of the configurable context parameters in the WAR file should be specified in the web.xml, since context.xml in the WAR file is not read when there is a context.xml outside.
Here is an easy example of the foo.xml:
<?xml version='1.0' encoding='utf-8'?>
<Context docBase="/path-to-deployment-directory/foo.war">
<Parameter name="myparam" value="newvalue" override="false"/>
</Context>
Be sure to specify override=false for the parameter if you want the 'newvalue' to override the value specified in the WAR's web.xml. This was not obvious for us.
Thus, to deploy an aplication to a running Tomcat:
Create a context.xml file called foo.xml
Copy the file to the $CATALINA_BASE/conf/[enginename]/[hostname]/ directory.
Copy the foo.war to the location specified in the docBase of the foo.xml; the application will deploy automatically.
To apply new context parameters:
Add the parameter values to the foo.xml and save the file; the application will re-deploy automatically.
To undeploy the application:
Remove the foo.xml from the $CATALINA_BASE/conf/[enginename]/[hostname]/ directory
Note that removing the foo.war will also work, but will remove the foo.xml as well.
By now, I have the following questions:
Is it a best-practice at all to deploy a web-application without stopping the tomcat? I heard an opinion that deployment to a running tomcat is never needed since people run each application in a separate tomcat.
Is it a good idea to copy WAR files to $CATALINA_HOME/webapps or they should better be kept in a separate location?
How can I configure an application deployed to $CATALINA_HOME/webapps
Why there is no INFO line in the catalina.out for deployment of an application and there is one for undeployment? Is it configurable?
On question (1), Tomcat works great for deploying servlets into a running server. There may be concerns w.r.t. security or possibly D.O.S. or provisioning reasons why you would have separate server instances.
You have the flexibility to do either way, but it is often more convenient to deploy to an already running server. This is a BUILT-IN feature in the servlet architecture. :)
For (2), again it is at your discretion where you you want to put WARs. It sounds like you already have it configured a non-standard (non-default I should say) way. Check your server.xml file for the settings in your server instance(s). Check for attributes like unpackWARs and autoDeploy.
For (3) and (4), plus your (1,2) questions, it might be a good idea to consult the Tomcat docs for your version of Tomcat on its deployment model. You should be able to use the same docs to figure out how your server has been configured.
See Tomcat Web Application Deployment in the Tomcat manual, adjusting for your version of Tomcat.
One solution would be to use the manager application. If you decide that is safe to use it, then you can easily deploy, start, stop and undeploy applications:
http://localhost:8080/manager/deploy?path=[context_path]
http://localhost:8080/manager/start?path=[context_path]
http://localhost:8080/manager/stop?path=[context_path]
http://localhost:8080/manager/undeploy?path=[context_path]
There are ant tasks that can help you with these.
I am guessing, but do not know for sure, that stopping and starting an application will make it reread the context.xml.
Regarding your second question, I believe it is better for maintenance reasons to keep the war files in the webapps directory.