I have an application running as war in Liberty Server. How do I have the multiple instances of the same run in Liberty Server? Is there a way to get the name of the war inside the java code?
String completePath=getClass().getProtectionDomain().getCodeSource().getLocation().toURI().getPath();
returned .../target/classes. No war file name.
You should be able to specify multiple <webApplication ...> elements in the server.xml with different values for the "id", "name" and "contextRoot" attributes, but specify the same "location" attribute (pointing to the actual WAR file).
As for getting the name of the WAR from the Java code, you could try using the ServletContext APIs like getServletContextName() or getContextPath() to differentiate between the multiple instances. More info in the javadoc here: https://www.openliberty.io/docs/20.0.0.10/reference/javadoc/liberty-javaee8-javadoc.html#javax/servlet/package-summary.html&class=javax/servlet/ServletContext.html&package=allclasses-frame.html
Related
I'm running a .war file in 3 different Servers, but for each server I need a different description in the web.xml file, that will be accessed like:
context.getInitParameter("CompanyKey")
Is there a equivalent for a server file? It's being a pain to change this file at each deploy.
Im currently using GlassFish 4.1
After some search, I found out that GlassFish holds a file called default-web.xml in the config folder.
All variables listed here takes precedence over the variables in the application (war) web.xml.
I just transferred my variables there and it worked!
Some helpful links for those searching about web.xml, context.xml and default-web.xml (it helped me to get to my answer):
https://blogs.oracle.com/alexismp/entry/how_to_use_tomcat_context
http://docs.oracle.com/cd/E19798-01/821-1752/geurd/index.html
How can I share a variable or object between two or more Servlets?
What is the glassfish alternative to context.xml
I'm using Jetty 8 to run some servlets. I have two (or more) applications that share source code, and I want to run them on the same port (i.e., 8080). I have placed two different WAR files into Jetty, one.war and two.war, so that I access them at, for example,
http://localhost:8080/one
http://localhost:8080/two
Both WARS contain an identical common JAR file (common utils). Does each WAR application get its own JVM? Really, I just want to be sure that the common JAR classes are entirely separate, since some of the classes are static and I need the two applications to obviously not share access to the same static class.
This seems obvious, and I seemed to confirm that it is the case that the common classes are loaded separately for each WAR with a simple test scenario (two identical WARs hosted in the same Jetty instance, but at different paths...see above). But I lack written documentation or confirmation that this is the case.
Each WAR file will have its own class loader see http://docs.codehaus.org/display/JETTY/Classloading. So you can safely use static classes.
I have a Java EE web application (WebSphere 7). The code looks up EJBs on the app server by doing JDNI look ups.
In my development environment (Eclipse / IBM RAD), the EAR project is called customerEAR, so the JNDI lookup is like this:
ejblocal:customerEAR.ear/customerEJB.jar/CustomerService#com.mydomain.service.CustomerServiceLocal
But when the EAR is deployed on the production application server, the lookup fails and the log file states that the EJB is available at:
ejblocal:server1-dev-customerEAR.ear/customerEJB.jar/CustomerService#com.mydomain.service.CustomerServiceLocal
It's possible that the guy deploying the EAR to the server is actually renaming the EAR file from customerEAR.ear to server1-dev-customerEAR.jar -- or maybe WebSphere is renaming stuff on deployment? I can't get hold of the deployment guy to find out for sure.
But, regardless, my question is:
Is there a cleaner way to do the lookup of the EJBs? Like, by using a shorter lookup name, or a "relative path" instead of the "full path"?
Any suggestions are greatly appreciated, thanks!
Rob
You can define a name for your remote EJB using annotations in your bean class or define it in ejb-jar.xml.
#Stateless(mappedName = "TestBean")
#Remote(TestBeanRemote.class)
public class TestBean implements TestBeanRemote
{
//...
}
Lookup on client:
TestBeanRemote testBeanRemote = (TestBeanRemote)new InitialContext().lookup("TestBean");
If you don't use "mappedName" some Application Servers add some suffix to your Bean name to autogenerate a name. So better use "mappedName" to define it server independent.
If you want shorter names, create an ibm-ejb-jar-bnd.xml and specify a binding rather than leaving it to the product to generate an unambiguous one. See the section entitled "Binding file Example 1".
Depending on whether or not you have multiple EJBs implementing your interface, you can also use "short form" bindings. See the section entitled "Default binding pattern".
Since the deployment guy insists on renaming my EAR before deploying it, I managed to get this to work, I managed to get it working by shortening this:
ejblocal:customerEAR.ear/customerEJB.jar/CustomerService#com.mydomain.service.CustomerServiceLocal
to this:
ejblocal:com.mydomain.service.CustomerServiceLocal
An application I am working on is encapsulated inside an ear file, which contains a jar (containing EJB files) and a war (having, apart from its normal contents, package hierarchy of action classes, directly inside it). The context-root is specified in both WEB-INF/jboss-web.xml as well as in META-INF/application, and, well... is different in both.
The interesting part is that if I deploy that ear file in JBoss 4.2, I am able to access the application by the context-root given in application.xml, whereas when I deploy it in JBoss-6.1, I can access my application only with the context-root provided in jboss-web.xml. Why is this happening ?
Could there be a rationale for specifying two different context-roots in the 2 xml files ?
I'm working on my first Windows .Net application (as opposed to a .net web app, which I've done a lot of), and I have a question about database connection strings - is there an equivalent to the section in web.config?
I want to be able to have the program run against our test database (which will required a different connection string. What is the "canonical" way to define connection string objects in a Windows .Net application?
Thanks
Rather than write this all down again, here's a good article on this subject:
Storing and Retrieving Connection Strings
Add an "application configuration" file to your project. It will add a file called "app.config" Put your connection in there.
When the app is compiled it will change the name of the config file to match your executable. For example: MyApp.config.
I'm not sure what you mean by "canonical" way to define connection string objects. Name them whatever you want. Sometimes we use the name of the database, sometimes just the name of the project.
With regards to having multiple config files, we use Config Transforms. Which name them app.config, app.debug.config, app.release.config, etc. and use configuration manager to define which one to use based on where it's being deployed.
Non ASP.Net apps simply use app.config instead of web.config. See here.
Connection strings can be stored as key/value pairs in the
connectionStrings section of the configuration element of an
application configuration file.