I need to simulate the presence of a Load Balancer (WebSeal) in my local installation of WebSphere 8.5. In detail, when an application is exposed through webseal is added into the URL, before the Application Context Root, the webseal Junction name. For example, an application with context-root "myapp":
Without webseal: localhost:8080/MyApp/......
With webseal: localhost:8080/JunctionName/MyApp/......
So i need to simulate this because i have shared DB with common configuration between my local installation, without webseal, and test installation balanced by webseal.
There is the possibility to configure a common context-root that the AS have to add to the URL of the deployed app in WebSphere 8.5?
I'm not aware of a way for one app to have two context roots, but for your local installation testing purposes you might be able to install two copies of the app, one at each context-root. It's probably a change to application.xml, or if you're deploying through the console UI, I think it's
configurable there.
Related
In IBM Websphere Application Server (WAS) what are the purpose of com.ibm.wsspi.bootstrap.WSPreLauncher and com.ibm.ws.bootstrap.WSLauncher? Every morning we are restarting the Websphere Application Server. So on the stat of WAS it will always be called to load applications war file? Or there are certain action on which these two are used by WAS?
WSPreLauncher and WSLauncher are main entry points in the starting the OSGi framework and server processes. If you look at startServer script, you'll see it invokes the WSLauncher class with a number of additional arguments that are essential to proper server startup. To your question, when using the serverStart script, WSLauncher will be called and as a part of starting all the components of the server, applications, including war files, may be started depending on your specific configuration. You should not invoke either the WSPreLauncher or WSLauncher entry points yourself and instead should use the provided scripts like startServer, startNode, etc.
I am looking for a solution to the problem, which is that having an external Tomcat server with several different applications (war),
I would like to use application Spring Profile (dev, prod) to choose application.properties for a given profile.
To avoid keeping the database configuration in the git repository, I didn't store in the application
application.properties, but I kept them in the $catalina.base directory, where in common.loader
I indicated the path to this directory. This worked until I started deploying several different applications. Then each of them began to use
from the same datasource. One solution is to keep the application.properties in Jenkins and directly in Jobie indicating which one to use,
but I am not sure if this is a good solution.
Option 1: Create a separate instance of tomcat (using same tomcat binary) and place application.properties in instance's classpath. As classpath is separate for every instance, applications don't refer to same application.properties file. Refer to this article to see how to create multiple instances on same tomcat server.
Option 2: Create JNDI datasource on tomcat server and use it in your application to access database. This way, should you choose to, same datasource can be shared across different related applications and/or modules. For more information on how to create JNDI datasource in Tomcat, refer to this link
Our application are built on Spring boot, the app will be packaged to a war file and ran with java -jar xx.war -Dspring.profile=xxx. Generally the latest war package will served by a static web server like nginx.
Now we want to know if we can add auto-update for the application.
I have googled, and people suggested to use the Application server which support hot deployment, however we use spring boot as shown above.
I have thought to start a new thread once my application started, then check update and download the latest package. But I have to terminate the current application to start the new one since they use the same port, and if close the current app, the update thread will be terminated too.
So how to you handle this problem?
In my opinion that should be managed by some higher order dev-ops level orchestration system not by either the app nor its container. The decision to replace an app should not be at the dev-ops level and not the app level
One major advantage of spring-boot is the inversion of the traditional application-web-container to web-app model. As such the web container is usually (and best practice with Spring boot) built within the app itself. Hence it is fully self contained and crucially immutable. It therefore should not be the role of the app-web-container/web-app to replace either part-of or all-of itself.
Of course you can do whatever you like but you might find that the solution is not easy because it is not convention to do it in this way.
We are looking to move our dev+prod WebSphere full profile app to Liberty.
Currently, we build only once (using Ant scripts) and deploy the same package (i.e. EAR) to our functional, UAT and production environments.
Database and MQ connections (and related sensitive data like usernames and passwords) are directly set via the WAS admin console for each environment, so there is no such data in our EAR.
A few non sensitive settings that change per environment (mail server address etc), are kept in a file suffixed with the (e.g configuration_.properties). All these files are bundled within the EAR. Each WebSphere defines a JVM property to specify the environment they are running (prd, uat, fnc, lab etc). When the application starts, it reads the files that is associated with the environment. That works great.
Now with Liberty, the connection/MQ pools, LDAP users etc are defined in server.xml.
Questions:
how to manage the server.xml file(s) that replace the job done via the WAS console by the authorized admins?
how to define the database name/port/host/user/password needed for those access per environnment? keep one server.xml file per environnement?
is there a way to have a "base" server.xml file and "override" the database name/port/host/user/password etc at startup on runtime?
or maybe there are more clever strategies?
We don't know yet if we will run Liberty in a traditional ND/Cluster way or into a docker infrastructure (this is all very new to us..).
How do you handle this?
Thanks in advance.
You can do the same thing in Liberty, just using different methods.
1) in your server.xml files, use variables wherever needed:
${this.style} for referencing system/bootstrap properties or server.xml defined variables, or ${env.ENV_VAR} for referencing Environment variables
2) add in a per-environment server.env file, or use configDropins/overrides to define environment-specific server.xml snippets (this answers one of your questions: yes, you can have a base server.xml and use environment-specific overrides)
More information here: http://www.ibm.com/support/knowledgecenter/SSD28V_8.5.5/com.ibm.websphere.wlp.core.doc/ae/cwlp_config.html?lang=en
And here (specifically includes and dropins):
http://www.ibm.com/support/knowledgecenter/SSD28V_8.5.5/com.ibm.websphere.wlp.core.doc/ae/twlp_setup_basics.html?lang=en
My question is about deployment to a Tomcat server instance which hosts multiple applications and hosts application contexts for Struts, Spring, and Hibernate. I would like to deploy changes to one application without restarting my Tomcat server.
As an example, many times in our firm we have to deploy new applications or versions of applications to our tomcat enviroment and the process could be:
Move class and jsp to the exploded folder then the context reload itself, or
Another scenario is when we have to deploy new features which require
modifications to xml contexts such as struts-config.xml or spring-application-context.xml.
Currently we have to restart the web-server to load new configuration. This would be OK if Tomcat did not have other live applications which we did not want to interrupt and restart. As an example, if I have an application which uses hibernate and struts, then I have to re-deploy it to a Tomcat server with many other applications running, and I deploy the new application and restart the server. This is not ideal.
So the question is when deploying changes to Tomcat, including context changes, do I have to restart? Is there a way to do a hot deploy for only this specific application and maybe re-start only its context without restarting the webserver?
Thanks a lot!!
Best regards
You can set the "autoDeploy" attribute to "true" in server.xml. You can read more detailed information here http://www.mulesoft.com/tomcat-deploy.
Hope this helps.