I have deployed applications in Websphere 8.5, and I want to modify web.xml, but it seems not working. What I am supposed to do?
While there are documented ways of updating enterprise application files, those were conceived for multi-server deployments and partly are legacy of the previous decade of monster application servers. They are inconvenient for making changes to local development server and it wastes a lot of time.
Upon application deployment, WAS creates (copies/updates) deployment descriptors in the config directory. Then web.xml is used from that location.
You are probably changing web.xml in the location where original application files are kept, thus no effect. You should change the one in config\cells\<cell_name>\applications\<ear_name>\deployments\<app_name>\<war_name>\WEB-INF.
WebSphere writes a second file named web_merged.xml. If you only update the web.xml and replace it you will not update the runtime file used by the container.
Best result I had was using the single file upload function provided within the Admin console or to use the wsadmin or jacl cmd.
The proper way is to update application via console/script.
But I'm assuming you are editing file directly (very hard to guess from your description, I've asked you to describe your procedure).
You need to restart the application to pick up changes in web.xml. See the Hot deploy in WAR files
Two ways:
Update web.xml with WebSphere Web Console
Update web_merged.xml at the same time, and also update the two files in config\cells\<cell_name>\applications\<ear_name>\deployments\<app_name>\<war_name>\WEB-INF
Related
How to deploy the application manually:
How to deploy the application.ear manually in the open liberty. Followed the documentation and dropped inside the /liberty/wlp/usr/servers/defaultserver/dropins directory.
From the admin console, it shows two application one in running state and another stopped.
application1.war - Running state
application2.ear - Stopped state (manually dropped in dropins directory)
Note: When perform the start action from admin console on application2. It gives the error message that can't locate the application2.ear defined in server.xml.
Server.xml:
<webapplication location="dropin/application2.ear" contextRoot="/test">
There are a number of things in the question that point to errors.
An ear file is not a Web Application, so the use of the webApplication element with an ear file is likely in error. If you want to deploy an ear file in Liberty via server.xml config you would use enterpriseApplication.
There is a likely typo in the location field where you likely intended dropins rather than dropin which means the application binary wasn't found.
Liberty doesn't support applications configured in server.xml being placed in dropins, we see this as two applications with the same name and won't start the second one.
Any of these symptoms will display in admin center two applications with one being stopped. Simplest thing given your configuration would be to just delete the server.xml configuration.
What creates the profiles under {install_dir}/IBM/WebSphere/Appserver/profiles
I'm working on RHEL. Installed WAS 7 and WebSphere Commerce. All of this is scripted given to me by others.
At some point a folder gets created under profiles. However, I must have done something to mess this up, because on subsequent attempts to repeat this on new servers the folder doesn't get created.
WebSphere application server profiles are created and managed either using IBM Profile Management Tool (PMT) GUI or the command line version, manageProfiles in the bin dir. More general infomation about profiles can be found in this IBM KnowledgeCenter topic.
Found the answer. This is WAS meets Commerce. So the WAS "profile" gets created when Commerce creates what it calls an "instance". On my system, this is performed within the script:
{scripts}/IBM_WCS/instance_Creation.sh
Whether that comes from the vendor or is an invention of my predecessor, I have no idea. But once I got that to run, the profile appeared.
In Windows, I'm looking at JBoss security features, let's say you modified the standalone.xml and defined your security domains and everything is in place, what stops a user on the host where JBoss is running to modify your settings, restart JBoss and have access to everything in your applications?
Ultimately, there is nothing to stop this.
Therefore, you need to:
secure the data
perhaps use version control mechanisms, so you can see what has changed, when it changed and who did it.
Similarly you will need to stop attackers (for example) deploying their own ear files to something untrustworthy
So, I've deployed a Java web application (myapp.war) to a Tomcat 7 server that happens to be running on Amazon EC2. I noticed that, when I do this, it overwrites a similarly-named directory called myapp when I deploy. I further realized that the app is actually being served from that myapp directory and, when I directly make a change to a file in that directory, the changes are served to the client as expected.
My question is does Tomcat do anything to this directory between redeployments? If I make a small change in a file in that directory, will it ever be overwritten before I redeploy again?
It depends.
Changes to class files will probably be ignored.
Changes to JSPs may take effect depending on if the JSP has already been accessed and if the JSP Servlet is configured to check for changes.
Changes to static files will probably take effect but may be delayed by the effects of the static file cache. Normally that delay is only a few seconds but it can be configured to be longer.
Editing web.xml will probably trigger a reload (again this can be disabled with config)
Editing contex.xml will probably trigger a redeploy.
A reload pauses the app, re-reads web.xml and unpauses the app so the user might see a short pause but no 404s. A redploy completely removes the old app and creates a new one. A user may see a 404 in they try accessing it at the wrong time.
As soon as a new WAR file is deployed, all local changes will be lost.
In order to know which revision number the application is built from, we use to give the ears we deploy to Glassfish names like myapp_2012-01-20_rev22123.ear. Then we can simply login to Glassfish and see what version is deployed in the web interface (as the appname is the name of the ear file). A downside of this approach is that we need to do a manual undeploy/redeploy to update the name...
But I would like to script the undeploy/deploy process, and having each version of an ear get a different name is not very suitable to scripting this redeployment process. Glassfish 2 does not support the "list applications" goal that Glassfish 3 has, which I could have used to retrieve the application name to undeploy.
So is there any good strategy that will easily allow us to see what version is deployed of an application, and that does not suffer from the above fault?
It would be preferable if this meant we did not have to change the existing applications (like add a jsp page or something to show the current scm revision), but a change in a Maven build script would be acceptable.
I faced a similar issue, I finally came around it by using maven-buildnumber-plugin and writing a simple servlet to get build information. You can find the details in the blog post I made.
Why not use the built-in GlassFish Server versioning to assign a version number at deploy time? This will also enable you to rollback to prior versions. For example:
asadmin deploy --name MyApplication:2012-01-20_rev22123 MyApplication.ear
There is more information on application versioning here:
http://docs.oracle.com/cd/E18930_01/html/821-2417/gihzx.html#gkhhv
Hope this helps.