Develop Reference

Connect Java Mission Control to Wildfly 16

I try to connect Java Mission Control (JMC) with Wildfly 16. Application server lays on Docker.
I successfully connected to wildfly via jconsole, to manage it I followed steps described here.
Unfortunately, I have no luck to connect via JMC. The URL which I use looks like this:
service:jmx:remoting-jmx://192.168.99.100:9990
I tried to set Xbootclasspath to jboss-cli-client.jar as it was described here, but I just get Unable to connect error.
I set the same jars, which are used for jconsole, but still I got Unable to connect.
I gave a try to adding flags on container site, as it was shown here, but with these flags, even wildfly haven't started.
Then, I found here the idea to hardcode some jboss classes to enable connection via remoting-jmx. I changed version of jars, according to these provided by wildfly16 and put it to jmc.ini like this.
-Xbootclasspath/a:"C:/Program Files/Java/jdk-10.0.2/lib/missioncontrol/dropins/jboss-cli-client.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/remoting-jmx/main/remoting-jmx-3.0.1.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/remoting/main/jboss-remoting-5.0.8.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/logging/main/jboss-logging-3.3.2.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/xnio/main/xnio-api-3.6.5.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/xnio/nio/main/xnio-nio-3.6.5.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/marshalling/main/jboss-marshalling-2.0.6.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/marshalling/river/main/jboss-marshalling-river-2.0.6.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/as/cli/main/wildfly-cli-8.0.0.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/staxmapper/main/staxmapper-1.3.0.Final;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/as/protocol/main/wildfly-protocol-8.0.0.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/dmr/main/jboss-dmr-1.5.0.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/as/controller-client/main/wildfly-controller-client-8.0.0.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/threads/main/jboss-threads-2.3.3.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-2.1.7.Final.jar"
After that, finally, I have another error, which is
Could not initialize class org.jboss.remotingjmx.RemotingConnector
I added dependencies of remoting-jmx-3.0.1.Final to Xbootclasspath, but I got still the same error.
My question is, have you got any idea, how to make this connection works ? Maybe someone have done it in different way ?
Any advices how can i debug this problem, will be priceless? Because I'm lack of ideas how to solve it.

In %WILDFLY_HOME%\bin\standalone.conf.bat
put:
set "JAVA_OPTS=%JAVA_OPTS% -XX:+FlightRecorder"
In jmc.ini below -vmargs put
-Xbootclasspath/a:C:\%wildfly_home%\bin\client\jboss-cli-client.jar
(%wildfly_home% is different of course, or just copy jboss-cli-client.jar to another directory and correct the path)
3. Run JMC, then Create New Connection - in Connection Properties pane push the button "Custom JMX service URL", put:
service:jmx:http-remoting-jmx://localhost:9990
In the credentials fields just put user and password, they should be created for Realm Management (e.g. using %wildfly_home%\bin\add-user.bat)
Hope this helps someone.

Solution doesn't work on java 11 for me. Mission control fails on connect to wildfly with error:
Caused by: java.lang.NoClassDefFoundError: org/ietf/jgss/GSSManager
at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
at java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3137)
at java.base/java.lang.Class.getConstructor0(Class.java:3342)
at java.base/java.lang.Class.getConstructor(Class.java:2151)
at java.base/java.security.Provider.newInstanceUtil(Provider.java:152)
at java.base/java.security.Provider$Service.newInstance(Provider.java:1824)
at org.wildfly.security.WildFlyElytronBaseProvider$ProviderService.newInstance(WildFlyElytronBaseProvider.java:218)
at org.wildfly.security.sasl.util.SecurityProviderSaslClientFactory.createSaslClient(SecurityProviderSaslClientFactory.java:94)
at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66)
at org.wildfly.security.sasl.util.ProtocolSaslClientFactory.createSaslClient(ProtocolSaslClientFactory.java:50)
at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66)
at org.wildfly.security.sasl.util.ServerNameSaslClientFactory.createSaslClient(ServerNameSaslClientFactory.java:50)
at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66)
at org.wildfly.security.sasl.util.ServerNameSaslClientFactory.createSaslClient(ServerNameSaslClientFactory.java:50)
at org.wildfly.security.sasl.util.FilterMechanismSaslClientFactory.createSaslClient(FilterMechanismSaslClientFactory.java:102)
at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66)
at org.wildfly.security.sasl.util.LocalPrincipalSaslClientFactory.createSaslClient(LocalPrincipalSaslClientFactory.java:76)
at org.wildfly.security.sasl.util.PrivilegedSaslClientFactory.lambda$createSaslClient$0(PrivilegedSaslClientFactory.java:64)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at org.wildfly.security.sasl.util.PrivilegedSaslClientFactory.createSaslClient(PrivilegedSaslClientFactory.java:64)
at org.wildfly.security.auth.client.AuthenticationConfiguration.createSaslClient(AuthenticationConfiguration.java:1545)
at org.wildfly.security.auth.client.AuthenticationContextConfigurationClient.createSaslClient(AuthenticationContextConfigurationClient.java:430)
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:419)
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:244)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
Besides, jmc that was embedded to jdk 8 isn't able to start flight recording for java 11 process.
So after investigation i found out that this class is loaded with bootstrap classloader. According to https://openjdk.java.net/jeps/261
jdk.security.jgss module isn't defined to bootstrap classloader. But classes in jboss-cli-client.jar(it originates from wildfly-elytron project) need jgss classes in runtime.
So i found out dirty workaround for this problem: bootstrap needed classes from jre 8 in jmc.ini. Full option for linux is:
-vmargs -Xbootclasspath/a:<path_to_wildfly>/jboss-cli-client.jar:<path_to_jdk8>/jre/lib/rt.jar
And for windows:
-vmargs -Xbootclasspath/a:<path_to_wildfly>\jboss-cli-client.jar;<path_to_jdk8>\jre\lib\rt.jar
after this jmc(run on 11 jdk) succesfully connects to wildfly(run on 11 jdk) and can start and analyze flight recordings.

Eclipse MarketPlace not woking

When i try to install new software using Eclispe Market place, I always getting the below error.
The version of eclispe I am using is Eclipse Java EE IDE for Web Developers.
Version: Indigo Service Release 2
MarketplaceDiscoveryStrategy failed with an error
Unable to read repository at http://marketplace.eclipse.org/featured/api/p?product=org.eclipse.epp.package.jee.product&os=win32&java.version=1.8.0_05&client=org.eclipse.epp.mpc.core&product.version=1.4.2.20120131-1457&runtime.version=3.7.0.v20110110&ws=win32&nl=en_US.
Read timed out
I know this problem occurs because of the proxy setting.
When I searched in google and found that we need to set proxy settings in Pereference --> General --> Internet Connection.
Even I tried the other way by setting proxy information in eclipse.ini file
-Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf.provider.filetransfer.httpclient
-Dhttp.proxyPort=****
-Dhttp.proxyHost=proxy.****.com
-Dhttp.proxyUser=******
-Dhttp.proxyPassword=******
-Dhttp.nonProxyHosts=localhost|127.0.0.1
Can I know where I have made a mistake in making the porxy setting in eclispe.
Can any one help me please.

Try to set the proxies to manual AND set it before AND after -vmargs in your eclipse.ini
-Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf.provider.filetransfer.httpclient4
-Dhttp.proxyPort=****
-Dhttp.proxyHost=proxy.****.com
-Dhttp.proxyUser=******
-Dhttp.proxyPassword=******
-vmargs
-Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf.provider.filetransfer.httpclient4
-Dhttp.proxyPort=****
-Dhttp.proxyHost=proxy.****.com
-Dhttp.proxyUser=******
-Dhttp.proxyPassword=******

Gemfire startup with gfsh: ClassNotFound error in gfsh start server

I have the following environment:OS - Windows7
Environment variables set:
CLASSPATH = C:\MyWorkspace\Pivotal_GemFire_800_b48398_Windows\lib\gemfire.jar;C:\MyWorkspace\Pivotal_GemFire_800_b48398_Windows\lib\antlr.jar;C:\MyWorkspace\Pivotal_GemFire_800_b48398_Windows\lib\gfsh-dependencies.jar;C:\MyWorkspace\Pivotal_GemFire_800_b48398_Windows\lib\gfSecurityImpl.jar;C:\MyWorkspace\Pivotal_GemFire_800_b48398_Windows\lib\jackson-core-2.2.0.jar;C:\MyWorkspace\Pivotal_GemFire_800_b48398_Windows\lib\commons-logging-1.1.1.jar;C:\MyWorkspace\Pivotal_GemFire_800_b48398_Windows\lib\tomcat-embed-core.jar;C:\MyWorkspace\Pivotal_GemFire_800_b48398_Windows\lib\tomcat-embed-jasper.jar;C:\MyWorkspace\Pivotal_GemFire_800_b48398_Windows\lib\tomcat-embed-logging-juli.jar;%JAVA_HOME%\lib\tools.jar;C:\MyWorkspace\Repository\org\springframework\data\spring-data-gemfire\1.5.1.RELEASE\spring-data-gemfire-1.5.1.RELEASE.jar;%CLASSPATH%
GEMFIRE = C:\MyWorkspace\Pivotal_GemFire_800_b48398_Windows GF_JAVA = %JAVA_HOME%\bin\java.exe JAVA_HOME = C:\MyWorkspace\JDK8\jdk1.8.0_31 MAVEN_HOME = C:\MyWorkspace\Maven\apache-maven-3.3.1 PATH = %JAVA_HOME%\bin;%ERACOM_HOME%;%Cryptoki%;%WAS_HOME%\bin;%MAVEN_HOME%\bin;C:\Windows\System32;C:\Windows;C:\OtherProgramFiles\nodejs\;%GEMFIRE%\bin;
My Simple Project Files:
cache-xml-file:cache.xml
<cache>
<region name="Apps">
<region-attributes>
<cache-listener>
<class-name>mypackage.listener.TestListener</class-name>
</cache-listener>
</region-attributes>
</region>
<initializer>
<class-name>org.springframework.data.gemfire.support.SpringContextBootstrappingInitializer</class-name>
<parameter name="contextConfigLocations">
<string>spring-application-context.xml</string>
</parameter>
</initializer>
</cache>
mypackage.listener.TestListener
public class TestListener implements CacheListener, Declarable {
#
Override
public void init(Properties arg0) {
System.out.println("Inside TestListener.init()");
}
... //Other Overridden methods . . .
}
spring-application-context.xml: contains a single bean:
<?xml version="1.0" encoding="utf-8" ?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:gfe="http://www.springframework.org/schema/gemfire" xmlns:util="http://www.springframework.org/schema/util" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/gemfire http://www.springframework.org/schema/gemfire/spring-gemfire.xsd
http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util.xsd">
<bean id="myTestCacheLoader" class="mypackage.loader.MyTestCacheLoader">
</bean>
</beans>
**mypackage.loader.MyTestCacheLoader:
public class MyTestCacheLoader implements
CacheLoader, Declarable {
#
Override
public void close() {
}
#
Override
public Object load(LoaderHelper arg0) throws CacheLoaderException {
System.out.println("Inside MyTestCacheLoader.load()");
return null;
}
#
Override
public void init(Properties arg0) {
}
}
Steps:
1. Start gfsh from directory - C:\MyWorkspace\Pivotal_GemFire_800_b48398_Windows
start locator: start locator --name=locator1 --port=10334
start server:
start server --name=server1 --server-port=40411 --cache-xml-file=C:\MyWorkspace\Codebase\ContentServices\content-loaderwriter\src\test\resources\cache-loader-writer.xml --classpath=C:\MyWorkspace\Codebase\ContentServices\content-loaderwriter\target\content-loaderwriter-0.0.1-SNAPSHOT.jar
But its throwing: java.lang.ClassNotFoundException: org.springframework.data.gemfire.support.SpringContextBootstrappingInitializer
I even added the gemfire jars as well as the above spring-data-gemfire jar (from my repo) in CLASSPATH variable. Still getting the exception. It seems not to resolve the maven dependencies/classpath.
If I try to provide multiple jars in classpath in gfsh start server command:
start server --name=server1 --server-port=40411 --cache-xml-file="C:\MyWorkspace\Codebase\ContentServices\content-loaderwriter\src\test\resources\cache-loader-writer.xml" --classpath="C:\MyWorkspace\Repository\org\springframework\data\spring-data-gemfire\1.5.1.RELEASE\spring-data-gemfire-1.5.1.RELEASE.jar:C:\MyWorkspace\Codebase\ContentServices\content-loaderwriter\target\content-loaderwriter-0.0.1-SNAPSHOT.jar"
I still get the ClassNotFoundException. Its not resolving the jars provided in the classpath.
Can anyone please help?

I think the problem is simply that you have ':' as the separator character in your class path. Windows wants a ';' here. You do not need to set the CLASSPATH environment variable in this case.
However, you will most likely need other jars that spring-data-gemfire depends upon. It looks like you are using maven so here is an easy way to get the class path for all of your project dependencies including transitive ones.
In your project directory, run "mvn -DexcludeArtifactIds=gemfire dependency:build-classpath". This will give you all of your dependencies other than gemfire (which is provided automatically). Add your application jar to the resulting classpath and you should have everything you need.
Also, based on what you are doing, you would probably be interested in the "--spring-xml-location" option which was added to the "gfsh start" command in 8.1. This allows you to dispense with "cache.xml" completely and define everything in a spring context file using the "gfe" namespace provided by spring-data-gemfire.

#Suparno Karmakar - Not sure if you were able to resolve this issue yet, but in reviewing your CLASSPATH to the 'start server' command (i.e. the value for the --classpath option), assuming the path is correct, then one thing to keep in mind is that the --classpath option value is read into a String when passed as an argument to 'start server'.
From there, the CLASSPATH value is subsequently passed and appended to the eventual command-line String (java.exe -classpath ... JVM arg) that is used to "fork" the JVM process for the GemFire Server (using the java.lang.ProcessBuilder API).
Java is most likely treating the first forward slash () in the path information as an "escape" character", so you have to escape the escape character as in...
C:\\path\\to\\external\\file.jar
I believe backslashes in Windows will also work, therefore...
C:/path/to/external/file.jar
#Randy May is correct in stating that you can just use the 'start server' command's new '--spring-xml-location' option to indicate that you'd like to bootstrap your the GemFire Server with Spring, assuming you are using GemFire 8.1 of course.
By using this option, the appropriate Spring JARS from $GEMFIRE/lib are automatically appended to the Server's CLASSPATH on start (which otherwise are not used).
Unfortunately, there was a bug identified when using the '--spring-xml-location' option with 'start server' in that Gfsh was looking for the wrong version of the Spring JARS. It was looking for Spring core 3.2.11.RELEASE instead of 3.2.12.RELEASE, SDC 1.9.0.RELEASE instead of 1.9.1.RELEASE and SDG 1.5.1.BUILD-SNAPSHOT instead of 1.5.1.RELEASE.
Simply renaming the Spring JARs in $GEMFIRE/lib resolves this problem.
See https://svn.gemstone.com/trac/gemfire/ticket/51956, though you probably don't have access to see this bug until the release notes for GemFire 8.2 is out (~July).
Here are my bug notes...
Bug Title:
GemFire Shell (Gfsh) throws a
NoClassDefFoundError/ClassNotFoundException on
org/springframework/data/gemfire/support/SpringContextBootstrappingInitializer
when launching a GemFire Server using Gfsh with the 'start server ...
--spring-xml-location' option in GemFire 8.1
Bug Workaround:
When a user tries to launch a GemFire Server using Gfsh with the
'start server' command bootstrapped with Spring by specifying the
'--spring-xml-location' option, GemFire 8.1 (Gfsh) throws a
NoClassDefFoundError caused by a ClassNotFoundException... {{{ The
Cache Server process terminated unexpectedly with exit status 1.
Please refer to the log file in /Users/jblum/vmdev/lab/serverX for
full details. Exception in thread "main"
java.lang.NoClassDefFoundError:
org/springframework/data/gemfire/support/SpringContextBootstrappingInitializer
at
com.gemstone.gemfire.distributed.ServerLauncher.startWithSpring(ServerLauncher.java:764)
at
com.gemstone.gemfire.distributed.ServerLauncher.start(ServerLauncher.java:696)
at
com.gemstone.gemfire.distributed.ServerLauncher.run(ServerLauncher.java:626)
at
com.gemstone.gemfire.distributed.ServerLauncher.main(ServerLauncher.java:200)
Caused by: java.lang.ClassNotFoundException:
org.springframework.data.gemfire.support.SpringContextBootstrappingInitializer
at java.net.URLClassLoader$1.run(URLClassLoader.java:366) at
java.net.URLClassLoader$1.run(URLClassLoader.java:355) at
java.security.AccessController.doPrivileged(Native Method) at
java.net.URLClassLoader.findClass(URLClassLoader.java:354) at
java.lang.ClassLoader.loadClass(ClassLoader.java:425) at
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at
java.lang.ClassLoader.loadClass(ClassLoader.java:358) ... 4 more }}}
GemFire is incorrectly specifying the Spring LIBS as version
3.2.11.RELEASE when GemFire in fact shipped with Spring 3.2.12.RELEASE JAR files. In addition, the Spring Data Commons JAR file is
incorrectly identified as spring-data-commons-1.9.0.RELEASE.jar,
however, GemFire 8.1 shipped with
spring-data-commons-1.9.1.RELEASE.jar. Note that GemFire/Gfsh in 8.1
is correctly specifying the Spring Data GemFire JAR file with
spring-data-gemfire-1.5.1.RELEASE.jar See Bugnote workaround to
resolve this issue.
Bug Workaround:
There are 2 ways to resolve this issue: 1. First, and the tried and
tested procedure is to... 1.1 Download and copy the Spring
3.2.11.RELEASE JAR files into the $GEMFIRE/lib directory. For every Spring 3.2.12.RELEASE JAR file in $GEMFIRE/lib, copy the corresponding
3.2.11.RELEASE JAR into $GEMFIRE/lib. 1.2 Next, download and copy the spring-data-commons-1.9.0.RELEASE.jar file into $GEMFIRE/lib. 1.3
Finally, perform the following... $ cp
$GEMFIRE/lib/spring-data-gemfire-1.5.1.RELEASE.jar
$GEMFIRE/lib/spring-data-gemfire-1.5.1.BUILD-SNAPSHOT.jar --- NOTE:
Unfortunately the bug is that Gfsh is looking for the wrong version of
these particular Spring JAR files. --- 2. The other option, is to
manually specify the Spring JARS and versions yourself using the
'--classpath' option to the 'start server' command. Note, in GemFire
8.1, the '--classpath' option has been changed to a "prepend" option, and therefore, effectively overrides any GemFire lib dependency in the
$GEMFIRE/lib directory. Caution, however care should be taken when
overriding any of the GemFire lib dependencies. NOTE, this "prepend"
behavior does not apply to the 'gemfire.jar' file itself for security
reasons.
Hope this helps! Post back if you still have problems.
Cheers!

Please replace the separator ":" to "\;"
You need to add the escape character before the windows separator. Otherwise, gfsh will treat the ";" as the ending of one command.

RMI Registry Issue: rmiregistry may cause unintended exceptions when binding with codebase using the "file:" URL scheme

Please see the passage "RMI Registry Issue" of this article for the background on Java Update 1.6.0_29 first.
If I understand correctly (I'm german), the update introduces a bug in the rmiregistry which fails to work with the file: pattern in the codebase.
I.E. the following won't work any more with 1.6.0_29:
-Djava.rmi.server.codebase="file:myproject/bin/ ..."
We are currently using the feature of having a codebase with file: syntax. Does anyone know a workaround for making this work?
Note: No, we do not want to start a local webserver or ftp server.
Update:
On Naming.bind this exception is thrown:
java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.lang.ClassNotFoundException: access to class loader denied
at sun.rmi.server.UnicastServerRef.oldDispatch(UnicastServerRef.java:400)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:248)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)

I had the same problem, and can confirm that downgrading JDK to earlier version solves the problem. I know, it's not a solution you're looking for, but at least it makes it to work.

Take running in windows as an example:
Step 1. In C:\Users\Jimmy.java.policy (create it if not exist), append below content:
grant { permission java.security.AllPermission; };
Of course "C:\Users\Jimmy\" is the user home, please change to your home accordingly.
Adding AllPermission is just for quick resolving your issue. you'd better config a more accurate FilePermission here.
Step 2. Start rmiregistry:
C:\JDK\bin>rmiregistry -J-Djava.rmi.server.codebase=file://C:/workspaces/MyLab/target/classes/
(Please note codebase must ended with "/")
Step 3. Run your server and client program.
References:
http://docs.oracle.com/javase/7/docs/technotes/guides/rmi/codebase.html
http://docs.oracle.com/javase/7/docs/technotes/guides/security/spec/security-spec.doc3.html
http://docs.oracle.com/javase/7/docs/technotes/guides/rmi/enhancements-7.html

It looks like there is no workaround because it is a bug, so wait for the fix
See details at
https://bugzilla.redhat.com/show_bug.cgi?id=751203
Code fix
http://icedtea.classpath.org/hg/icedtea6/rev/67df573b0734

If you do not need dynamic code downloading (in which case you can use ftp codebase) the solution is simply to set CLASSPATH environment variable to the path to your jar file:
Windows:
set CLASSPATH="path_to_jarfile"
Linux (batch):
CLASSPATH="path_to_jarfile"
export CLASSPATH
Best place to do it is in some script that invokes the RMI server.
Setting class path in the command line (-cp option) when starting RMI server does not help because it does not affect rmiregistry classpath!

If you start the rmiregistry in the working directory of your project, it works.
So essentially working directory of your project and current directory for rmiregistry should be same.

I recently encountered this issue as well. I can confirm that when using the file: protocol the rmiregistry must either:
be started in the root of the directory containing the shared classes; or
set the classpath to point to the shared classes or shared class jar; or
use a protocol other than file:// (I set up ngnix and served the jar from that).

Maybe not what you want, but you could resolve this with classpath rather than codebase. The client JVM will work fine if you add the required classes to its classpath. If you are using the file: URL scheme, then the classes must already be available on the localhost.

I had the same problem but I couldn't change the JDK version. Turns out you can solve it by running/starting the rmiregistry from the same directory as your code base, which in my case was target/classes. So cd project/target/classes and then run rmiregistry &

Error accessing a Web Service with SSL

I have a program that is supposed to send a file to a web service, which requires an SSL connection. I run the program as follows:
SET JAVA_HOME=C:\Program Files\Java\jre1.6.0_07
SET com.ibm.SSL.ConfigURL=ssl.client.props
"%JAVA_HOME%\bin\java" -cp ".;Test.jar" ca.mypackage.Main
This was works fine, but when I change the first line to
SET JAVA_HOME=C:\Program Files\IBM\SDP\runtimes\base_v7\java\jre
I get the following error:
com.sun.xml.internal.ws.client.ClientTransportException: HTTP transport error: java.net.SocketException: java.lang.ClassNotFoundException: Cannot find the specified class com.ibm.websphere.ssl.protocol.SSLSocketFactory
at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java:119)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:140)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java:86)
at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Fiber.java:593)
at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Fiber.java:552)
at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Fiber.java:537)
at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Fiber.java:434)
at com.sun.xml.internal.ws.client.Stub.process(Stub.java:247)
at com.sun.xml.internal.ws.client.sei.SEIStub.doProcess(SEIStub.java:132)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:242)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:222)
at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:115)
at $Proxy26.fileSubmit(Unknown Source)
at com.testing.TestingSoapProxy.fileSubmit(TestingSoapProxy.java:81)
at ca.mypackage.Main.main(Main.java:63)
Caused by: java.net.SocketException: java.lang.ClassNotFoundException: Cannot find the specified class com.ibm.websphere.ssl.protocol.SSLSocketFactory
at javax.net.ssl.DefaultSSLSocketFactory.a(SSLSocketFactory.java:7)
at javax.net.ssl.DefaultSSLSocketFactory.createSocket(SSLSocketFactory.java:1)
at com.ibm.net.ssl.www2.protocol.https.c.afterConnect(c.java:110)
at com.ibm.net.ssl.www2.protocol.https.d.connect(d.java:14)
at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:902)
at com.ibm.net.ssl.www2.protocol.https.b.getOutputStream(b.java:86)
at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java:107)
... 14 more
Caused by: java.lang.ClassNotFoundException: Cannot find the specified class com.ibm.websphere.ssl.protocol.SSLSocketFactory
at javax.net.ssl.SSLJsseUtil.b(SSLJsseUtil.java:20)
at javax.net.ssl.SSLSocketFactory.getDefault(SSLSocketFactory.java:36)
at javax.net.ssl.HttpsURLConnection.getDefaultSSLSocketFactory(HttpsURLConnection.java:16)
at javax.net.ssl.HttpsURLConnection.<init>(HttpsURLConnection.java:36)
at com.ibm.net.ssl.www2.protocol.https.b.<init>(b.java:1)
at com.ibm.net.ssl.www2.protocol.https.Handler.openConnection(Handler.java:11)
at java.net.URL.openConnection(URL.java:995)
at com.sun.xml.internal.ws.api.EndpointAddress.openConnection(EndpointAddress.java:206)
at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.createHttpConnection(HttpClientTransport.java:277)
at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java:103)
... 14 more
So it seems that this problem would be related to the JRE I'm using, but what doesn't seem to make sense is that the non-IBM JRE works fine, but the IBM JRE does not. Any ideas, or suggestions?

Try adding these two lines somewhere in your setup code:
Security.setProperty("ssl.SocketFactory.provider", "com.ibm.jsse2.SSLSocketFactoryImpl");
Security.setProperty("ssl.ServerSocketFactory.provider", "com.ibm.jsse2.SSLServerSocketFactoryImpl");

Java only allows one SSL connection factory class for a JVM. If you are using a JDK thats shipped with WebSphere Application Server v6x/7x/8x or any other WebSphere server tools in Rational Application Developer, then those require IBM ( com.ibm.websphere.ssl.protocol.SSLSocketFactory ) specific class from WebSphere Application Server runtime.
because the java security file has the JSSE socket factories set like below
# Default JSSE socket factories
#ssl.SocketFactory.provider=com.ibm.jsse2.SSLSocketFactoryImpl
#ssl.ServerSocketFactory.provider=com.ibm.jsse2.SSLServerSocketFactoryImpl
# WebSphere socket factories (in cryptosf.jar)
ssl.SocketFactory.provider=com.ibm.websphere.ssl.protocol.SSLSocketFactory
ssl.ServerSocketFactory.provider=com.ibm.websphere.ssl.protocol.SSLServerSocketFactory
So, If you uncomment the Default JSSE Socket factories and comment out the WebSphere ones then WAS is going to puke.
Better work around would be to have com.ibm.ws.security.crypto.jar file in your class path. This jar file has a dependency on com.ibm.ffdc.jar file so you need that in your class path well. Both these jarfiles are available under <WebSphere_Install_Dirctory>/plugins/

If your non IBM jre is sun, then it already comes with SSL classes implementation packaged along with it.
It seems the IBM jre is not containing SSL implementation classes at all.

One more "solution" which seems to be working for me. Create your own security properties file, my.java.security with contents like:
ssl.SocketFactory.provider=
ssl.ServerSocketFactory.provider=
When calling Java (or in my case maven), add the command line option:
-Djava.security.properties=C:\myfiles\my.java.security
Cribbed from the IBM Liberty documentation: http://www-01.ibm.com/support/knowledgecenter/was_beta_liberty/com.ibm.websphere.wlp.nd.multiplatform.doc/ae/rwlp_trouble.html?lang=en

one may set these properties at WAS_HOME/*/java/jre/lib/security/java.security file by uncomenting the following JSSE props.
Default JSSE socket factories
ssl.SocketFactory.provider=com.ibm.jsse2.SSLSocketFactoryImpl
ssl.ServerSocketFactory.provider=com.ibm.jsse2.SSLServerSocketFactoryImpl

Found this topic while searching for the same error message but found a different solution.
To test a https REST service using the Apache Wink client:
ClientConfig config = new ClientConfig();
config.setBypassHostnameVerification(true);
RestClient client = new RestClient(config);
And set the Factory's empty:
Security.setProperty("ssl.SocketFactory.provider", "");
Security.setProperty("ssl.ServerSocketFactory.provider", "");
My runtime is a standalone Camel test using IBM JRE 1.7 from IBM WebSphere v8.5.5.

I had a similar issue when my Batch application was trying to fetch data from Restful web service using Apache wink. I was using MyEclipse as my dev environment. And was using the jre provided by IBM webSphere 8.5. When I changed to Sun 1.6 jre, the issue got resolved.