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.
Related
I created an simple skeletal web application. I created only a simple blank JSF page. Right click and run. Then I got the following message in the Log console.
The Server Instance cannot be started because the Integrated Weblogic domain was not built successfully.
Can anybody suggest me why I am getting this error?
Your question does not provide detailed information.
The best way would be to go to weblogic domain options from start menu and create a new domain.
Then link that domain in jdeveloper and use the same. Delete the integrated domain i.e. base_domain folder.
There were 2 ways this problem can be fixed:
Try starting and fixing any issues with the Integrated weblogic domain. Till that is not starting successfully, JDeveloper cannot do anything on that. For me one time startup of the current domain outside of the Jdeveloper solved the issue. After that it was working fine from JDeveloper too.
Another option is as stated by vijayinani above to create a new domain and link it. But, beware your integrated base_domain is not having anything which you need to preserve if you plan to delete that.
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
I would like to setup Camunda-BPM in a Tomcat 7 running on Jelastic. I followed the instructions.
The problem now is that Jelastic does not allow to add the file bpm-platform.xml into the catalina-home/conf directory. So when I start the tomcat I get
...
Caused by: org.camunda.bpm.engine.ProcessEngineException: /opt/tomcat/conf/bpm-platform.xml does not exist. This file is necessary for deploying the camunda BPM platform
Can someone please give me a hint where I can place bpm-platform.xml so that the BPM engine starts?
The directory you're looking for is labelled as 'server' in the Jelastic dashboard - but sadly you cannot upload new files to this directory via the dashboard (only edit the existing ones).
However, you can write to this directory via FTP (http://docs.jelastic.com/ftp-ftps-support), so you should be able to add the file that way.
If you are just using a trial account at the moment, you may need to seek assistance from your hosting provider to add the file there for you manually from their side (since trial accounts do not have public IP, so can't use FTP).
I am here to get some expert advice on deploying applications to WebLogic Production Server.
Is it a best practice to use Admin Server Console for deploying and redeploying applications in production. Actually I am deploying to a cluster having two managed server instances.
I have encountered this issue while i am redeploying application in the production. When i am deleting existing .ear file and adding updated .ear file will put the updated .ear file into prepared state. I can not make it Active state using Admin Server Console. If i try it will through some exceptions. But after some time it automatically goes in to active state, but i don't know what is happening inside. Sometimes i restart the server to make it active. Could anybody explain me what is the procedure when deploying application and redeploying applications in weblogic
Thanks in advance for any Help...
Generally WLST (WebLogic Scripting Tool) is used to deploy the applications. Administration Console can also be used to deploy/upgrade the applications but if there are many environments that need to be upgraded then WLST (which works like a command line tool) is much better option.
Get an overview of WLST to know how to use it to deploy/undeploy/upgrade applications.
Check out "Understanding WebLogic Server Deployment" and the "Redeploying Applications in a Production Environment". There are different factors that affect redeployment of an application which you might be running into.
http://docs.oracle.com/cd/E23943_01/web.1111/e13702/understanding.htm#i1057116
http://docs.oracle.com/cd/E23943_01/web.1111/e13702/redeploy.htm#g1039635
Additionally, there is a WebLogic Plug-in for Maven in more recent WebLogic releases that you can use for deployments in conjunction with Maven.
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.