Is there any way that we can start Websphere Application Server but not loading any applications installed on it?
Environment: websphere 7.0
I didn't find a command line tool method for doing this, but you can edit the deployment.xml files underneath each WAR/EAR file that you want to stop from auto-starting when Websphere starts up.
These deployment.xml files are located typically here:
/opt/IBM/WebSphere/AppServer/profiles/<my profile>/config/cells/<my cell>/applications/<my .ear>/deployments/<my app>/deployment.xml
Within this file is this XML snippet:
<targetMappings xmi:id="DeploymentTargetMapping_1499739616851" enable="true" target="ServerTarget_1499739616851"/>
Change the enable=true to enable=false for every EAR/WAR that you don't want to auto-start. Once done start WAS as you'd normally do so.
References
http://www-01.ibm.com/support/docview.wss?uid=swg21265381
If you mean not starting installed applications, this is controlled through Administrative Console in Enterprise Applications > your_app > Target specific application status. There you can enable or disable auto start.
Target specific application status
Related
This is an old application and we have trouble to have the application changed.
During the deploy of a CRM like application, migrated from a 6.1.35 environment to a 8.5.5.17 websphere application server environment, the startup time of the application changed from 10 seconds to 12 minutes.
We made sono troubleshooting and we found that the problem is a remote filesystem which has 1.200.000 files. This remote filesystem is "mounted" in a path that is part of the WAR cell. This is done after the deploy of the application.
What make the application startup so slow is that on 8.5.5.17, all the files present in the path of the application are traversed (thus it tries to traverse the 1.200.000 file in the remote filesystem, which takes, as you may guess, 12 minutes...).
Anybody knows if this changed behaviour from WAS 6.1.x to WAS 8.5.5.x is intended?
Is there any workaround to block this?
WebSphere Application Server creates a list of files in the application when starting the application. It's a bit overzealous when creating the list in that it includes files that it does not need to look at during application start. For large applications, the file list can consume a lot of memory and can take a long time to generate. Since it is a Java EE application server, it should only be concerned with files in Java-EE-defined locations when starting the application. The list is not used during application run time. Therefore, the application server should only look in the directories:
/
META-INF/*
WEB-INF
WEB-INF/classes/*
WEB-INF/lib/*
APAR PH09294, included in 8.5.5.16 and 9.5.0.1, provides a way for you to limit the file list to the above locations. You can specify a setting either in the application or in the application server. (If you are using a version prior to 8.5.5.16 or 9.5.0.1, you should look at PM37942, which is a bit more cumbersome but still works.)
To enable the setting in the application, add the following to the MANIFEST.MF of either the EAR or the WAR. (Remember when editing MANIFEST.MF, obey the formatting rules. MANIFEST.MF must end with a blank line.) Adding the setting to a WAR limits the file list for just that WAR. Adding the setting to an EAR limits the file list for all WARs in that EAR.
IBM-Enable-File-List-Include-Filter: true
You can apply the setting to the server by setting a JVM custom property.
The following JVM custom property applies the setting to all applications on the server:
Property: org.eclipse.jst.j2ee.commonarchivecore.EnableFilesListIncludeFilter
Value: true
You can also apply the setting to all servers in a profile by adding the following line to the <WAS_PROFILE_HOME>/properties/amm.filter.properties file:
IBM-Enable-File-List-Include-Filter = true
Finally, to apply the setting to all profiles, add the above line to the <WAS_HOME>/properties/amm.filter.properties
Where should you set it? If you set it in the application, then wherever you deploy the application, the file list will be limited in scope. You do not depend on any setting in the application server. So for any large application, a developer should always include the setting in the application. An administrator might consider applying the setting to the entire WebSphere Application Server installation.
While running the Java EE Batch job through eclipse, it is creating a new instance of it.
I wanted to re-run the failed instance so that it can use checkpoint information to resume from the failed point.
Step 1: Deploy Application into Liberty server.
Step 2: Run the batchManger.bat file from cmd, which can find under bin folder of your local server
.\batchManager.bat restart --batchManager=localhost:9443 --user=admin --password=P#ssw0rd --applicationName=your-app-Name --jobXMLName=XXXX.xml --wait --trustSslCertificates
Another (GUI) approach is to use the Admin Center Java Batch tool, which allows you to restart jobs submitted by other methods. You can reuse, and/or modify the original job execution parameters.
This also provides a rich set of search and filtering capabilities, plus lets you view job logs, and so complements the job submission capability in the Eclipse Java EE Batch tooling.
Start here for complete instructions on using Admin Center. In particular you need to make sure the adminCenter-1.0 feature is installed then configure a userid to be authorized as the administrator.
Then, as the Java Batch tool instructions say, configure your server.xml with features:
adminCenter-1.0
batchManagement-1.0
I have websphere application server v 7 over windows server and I want to generate thread dumps because i have thread hungs, but when I try to get the java cores with wsadmin appears an error, so I want to generate java core files like linux using kill -3 .
Is there something like this in Windows server ?.
Like ObiWanKenobi mentioned, your best bet would probably be through the deployment manager administrative console. From IBM's support site:
Set the com.ibm.websphere.threadmonitor.dump.java property to true:
Application Servers:
From the administrative console, click Servers > Application Servers > server_name.
Under Server Infrastructure, click Administration > Custom Properties.
Click New and add the following property:
Name: com.ibm.websphere.threadmonitor.dump.java
Value: true
Click Apply.
Click OK and save the configuration changes.
Restart the Application Server for the changes to take effect.
Node Agent:
From the administrative console, click System Administration > Node Agents > nodeagent.
Under Additional Properties, click Administration Services
Under Additional Properties, click Custom Properties
Click New and add the following property:
Name: com.ibm.websphere.threadmonitor.dump.java
Value: true
Click Apply.
Click OK and save the configuration changes.
Restart the Node Agent for the changes to take effect.
In short, there is no good answer.
The closest would be to use something like SendSignal. See the Can I send a ctrl-C (SIGINT) to an application on Windows? question for more information. Unfortunately, SendSignal doesn't work reliably on all versions of Windows (see my Send ctrl-break to java process on 64-bit Windows ala sendsignal on 32-bit question).
If you're willing to write some custom code, you could write a Java program that uses the attach API to load a Java agent that calls the Dump API. (I suspect that IBM Support Assistant has this capability built-in, but it's been too long since I tried to be authoritative on this point.)
You can make the JVM to do a thread dump when there are 'hung' threads messages in the SystemOut.log:
Add com.ibm.websphere.threadmonitor.dump.java=true under JVM's Administration > Custom Properties.
I have a problem connecting to oracle from within a java servlet running in Jetty (as part of Eclipse). The identical code runs fine from a standalone java app.
My entire development environment is on a single mac. I am using Eclipse and have included the ojdbc6.jar in the main 'Referenced Libraries' and have also dragged and dropped this file in the war/web-inf/lib folder.
As soon as the line
OracleConnectionPoolDataSource ocpds = new
OracleConnectionPoolDataSource();
is called (within the servlet) I get the exception:
java.security.AccessControlException: access denied
(javax.management.MBeanServerPermission createMBeanServer)
Am I missing some security policy or so? If so, exactly what do I do need to do to rectify this? And where does this BeanServer come in?
Thanks in advance.
Every web container has its own way of defining data sources, and making them available through JNDI. You should do that instead.
The native oracle connection pool seems to be creating an MBeanServer, and this is not probably not allowed by the security manager used by Jetty. See http://wiki.eclipse.org/Jetty/Feature/Secure_Mode and http://wiki.eclipse.org/Jetty/Tutorial/Jetty-Policy.
Worked it out - not entirely clear why but created a new GWT app in Eclipse but this time NOT included the Google App Engine (which is ticked by default). This seems to add some restrictions to the code when it is running in Jetty....
I now have copied the sample code over and all is working well!
I have an old project in WSAD 5.1.2 with a WAS4 server configuration that's in a .wsi-file. If I double click it I get the server configuration editor and on the environment tab there is a System Properties section with some name-value pairs.
Now I have opened the same project in RAD 7.5.1. Where can i input the same name-value pairs for a server in RAD 7.5.1? There's no "environment-tab" if I double-click my server, just an "Overview" tab.
I finally found the proper way of doing it in the admin web interface...
Application servers > myServer > Process definition > Java Virtual Machine > Custom properties
In RAD 7.5.4 JVM name value pair is stored in Servers --> Application Servers --> java and process Management --> process definition --> java virtual machine --> custom properties
here you can create a new name value pair which can be used by Java code using System get properties function.
Apparently IBM started to ship a real application server starting with RAD/RSA6 instead of the test server that comes with WSAD. So to configure the appserver it's just to use the web admin interface as usual.
Thanks to Jeanne Boyarsky for the answer in the forums over at The Java Ranch.
The old app I'm porting needs some properties in the system properties of the JVM set so that they can be retrieved with System.getProperty(...) and I found a dirty way of making it work. So, until I find out how to do it the proper way, if there is a proper way, I came up with this hack:
After doing some "find" and "grep" in the profile directory of the appserver i found a file called:
runtimes\base_v7\profiles\<profilename>\config\cells\<cellname>\nodes\<nodename>\servers\<servername>\server.xml
At the bottom of server.xml there is a <jvmEntries xmi:id="JavaVirtualMachine_.... tag.
Inside it you can add system properties tags on the format:
<systemProperties xmi:id="someId" name="name of your property" value="the value" required="false"/>
Anyone who knows how to to this the proper way and has read all the way down here must be crying by now... :)
But, it seams to work...