I have just upgraded to WebSphere 7 (from 6.1), and I am having new class loading conflicts which I didn't have before.
I have looked a lot over the internet but couldn't find directions on how:
1. How to enable class loading trace.
2. Where does the output go to?
Thank you very much.
To enable the classloading information you need to go in application server > server_name > Java and Process Management > Process definition > Java Virtual Machine, there you will find the verbose classloading option. Enable it and restart the application server.
You should then find the classloading informations in the native_stderr.log in the <WAS_install_root>/profiles/<profile>/logs/<server> directory.
To add to Olivier.Roger's response (I don't have the permissions to respond inline), the information is in native_stderr.log.
(late, but for anyone else who finds this thread like I did)
I would recommend the class loader MustGather that is used by IBM support when you open a PMR. Expand the "Collecting data manually" section.
Related
I am able to connect to Db2 on z/OS with the IBM universal JDBC driver file db2jcc4.jar using IBM JDK 1.8 that is bundled with WebSphere 9. Every thing works fine and I can browse the catalog and execute queries. I used Squirrel SQL version 4.0.0.
But when I switch my JDK to the Open JDK 8 or 12 while keeping everything else the same, I get the following error. What should be done to fix this error? What is the difference between IBM JDK and Open JDK, which causes the DB2 connection to work with one JDK and fail with the other?
Here is one of matching articles of your case:
JDBC application may receive error "Security mechanism not supported"
https://www.ibm.com/support/pages/jdbc-application-may-receive-error-security-mechanism-not-supported
Resolving The Problem
Set the following property :
securityMechanism = ENCRYPTED_USER_PASSWORD_AND_DATA_SECURITY (13)
Alternatively you can set property retryWithAlternativeSecurityMechanism to YES(1).
Hope this helps.
According to IBM's documentation for their IBM Data Server Driver for JDBC and SQLJ, error code -4214 is an "Authorization failed" error -- and you know that much. But you can get more specific information about the problem if you call SQLException.getMessage. I think you may have done that already, but it's not entirely clear.
My semi-educated guess is that you haven't yet followed the configuration steps in IBM's driver documentation in the section "Configuring the Java Runtime Environment to Use SSL":
https://www.ibm.com/support/knowledgecenter/SSEPGG_11.5.0/com.ibm.db2.luw.apdv.java.doc/src/tpc/imjcc_t0054066.html
You'll have to apply some common sense knowledge to those instructions to adapt them for the OpenJDK, and this might not be an IBM supported combination depending on what/how you do it. If you can somehow use the IBMJSSE2 Provider, that'd be nice.
I think Mao and Mustaccio probably have the right ideas, and probably you're just missing the server certificate in your truststore. The instructions linked above walk you through how to configure that.
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
I don't have access to a WebSphere console, but I need to check if encryption is enabled between the console and appserver connection. The docs I have come across are almost all console related, and I am unable to find what I need. Where would I be able to find this config file setting?
Thanks
I suppose you are looking for WCInboundAdminSecure : it should be located in :
{WAS_HOME}/config/cells/{your cell}/nodes/{your node}/servers/{your server}/server.xml
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...