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.

SoapUI "failed to load url" error when loading WSDL

I keep having some weird problems. The main one is that I keep getting the following error when trying to add a WSDL to a new project:
Error loading [https://.../token?wsdl]: java.lang.Exception: Failed to load url; https://.../token?wsdl, 0 -
Here's the message recorded in the error.log file:
java.lang.Exception: Failed to load url; https://.../token?wsdl, 0 -
at com.eviware.soapui.impl.wsdl.support.wsdl.UrlWsdlLoader.load(UrlWsdlLoader.java:184)
at com.eviware.soapui.impl.wsdl.support.wsdl.WsdlLoader.loadXmlObject(WsdlLoader.java:121)
at com.eviware.soapui.impl.wsdl.support.xsd.SchemaUtils.getDefinitionParts(SchemaUtils.java:535)
at com.eviware.soapui.impl.wsdl.support.xsd.SchemaUtils.getDefinitionParts(SchemaUtils.java:524)
at com.eviware.soapui.impl.support.definition.support.AbstractDefinitionCache.update(AbstractDefinitionCache.java:97)
at com.eviware.soapui.impl.support.definition.support.AbstractDefinitionContext$Loader.construct(AbstractDefinitionContext.java:226)
at com.eviware.soapui.support.swing.SwingWorkerDelegator.construct(SwingWorkerDelegator.java:46)
at com.eviware.soapui.support.swing.SwingWorker$2.run(SwingWorker.java:149)
at java.lang.Thread.run(Unknown Source)
I verified that the application at that URL is up and running, and I can get to the WSDL from a web browser, but I keep getting this error message no matter what. I am using SoapUI 4.5.0 (32-bit) on a Windows 7 box. I've also tried the 64-bit version with the same results. It happens whether I am on VPN or not.
Do you know why I might be getting this error?

I have had the same problem. I resolved it by disabling the proxy in the SoapUI preferences.
(source : http://www.eviware.com/forum/viewtopic.php?f=13&t=12460)

In my case the server were the service was installed was configured only for TLS. SSL was not allowed. So you have to update SoapUI vmoptions file by adding the server TLS version
-Dsoapui.https.protocols=TLSv1.2
You can find vmoptions file under SoapUI installation folder:
C:\Program Files (x86)\SmartBear\SoapUI-5.0.0\bin\soapUI-5.0.0.vmoptions

I have had similar problems and worked around them by saving the WSDL locally. Don't forget to save any XSD files as well. You may need to edit the WSDL to specify an appropriate location for XSDs.

I got this error when trying to load a WebService implemented in MS Dynamics AX. Because I was connecting via VPN to my network, something went wrong with IPv6 settings. After Googling, I found the solution here: http://support.microsoft.com/kb/929852

In my case the
Error loading [https://.../token?wsdl]: java.lang.Exception: Failed to load url; https://.../token?wsdl, 0
was caused by fake certificate.
If you get the following in browser
"There is a problem with this website’s security certificate."
this is the case.
The resolution was to import a certificate to
C:\Program Files (x86)\SmartBear\SoapUI-5.0.0\jre\lib\security\cacerts
Which is default java used by SOAPUI

This could be a problem with IPV6 address SOAP UI picking. Adding the following JVM option fixed it for me:
-Djava.net.preferIPv4Stack=true
I added it here:
C:\Program Files\SmartBear\soapUI-4.5.2\bin\soapUI-4.5.2.vmoptions

Inside the wsdl file look for the import element, which looks like this :
`<import namespace="nameSpaceValue" location="Users/myname/.../targetxsdName.xsd"/>`
Change the location attribute in the above element to the location of your xsd files stored locally, and it should work.

The following solution helped me:
-Djsse.enableSNIExtension=false
In SoapUI-5.3.0.vmoptions.

This error is due to an erroneous schemaLocation in the WSDL file.
Indicate the correct location (either path on the disk or xsd url) of the xsd file in the wsdl file
exp
<xsd:import namespace="http://xyz:8080/" schemaLocation="http://172.17.16.53:9080/auth/authorizationBS?xsd=1"></xsd:import>

I had this issue when trying to use a SOCKS proxy. It appears that SoapUI does not support SOCKS proxys. I am using the Boomerang Chrome app instead.

I had this error and in my case, the problem was that I was using "localhost" in the URL.
I resolved that changing the localhost word for the respective IP, (Windows + R -> cmd -> ipconfig) then read the IP and write it to the URL replacing the "localhost" word

Close and reopen soapui. Probably is a bug of the application

Update SoapUI version to SoapUI 5.5.0. This error causes when I tried to load wsdl, because of old SoapUI version

If you are running your Web Application with the default port of 8080, please try to change the port to some other value and run your application again and trigger again your SOAPUI request. As you might have history projects in your SOAP UI workspace with port number 8080, might create issues.

My solution was to modify the java.security file:
\SoapUI-5.3.0\jre\lib\security\java.security
Comment code syntax:
#jdk.certpath.disabledAlgorithms=MD2, DSA, RSA keySize < 2048
#jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024

For java version above 1.8,
Use below command to setup soapUI jar
java -jar --add-modules java.xml.bind --add-modules java.xml.ws <path for jar file+jar file name.jar>

Accessing MQ with JMS

i am using MQ7 and trying to access a queue with JMS api's. Getting this error.
Has anyone seen it before? How do i resolve this? TIA
Exception in thread "main" com.ibm.msg.client.jms.DetailedJMSException:
JMSFMQ6312: An exception occurred in the Java(tm) MQI. The Java(tm) MQI has thrown an exception describing the problem. See the linked exception for further information.
Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2495;AMQ8568: The native JNI library 'mqjbnd' was not found. [3=mqjbnd]
Caused by: java.lang.UnsatisfiedLinkError: no mqjbnd in java.library.path

Probably a bit late but I had the same problem and found that this can be avoided if you use a different Connection Mode when connecting to a remote Queue. By default the MQConnectionFactory uses WMQ_CM_BINDINGS as it's connection mode. If you change it to WMQ_CM_CLIENT (or whichever connection mode you like that doesn't require native libraries) you should be fine.
#Test
public void testMQConnectionMode() throws JMSException {
MQConnectionFactory cf = new MQConnectionFactory();
assertThat(cf.getIntProperty(CommonConstants.WMQ_CONNECTION_MODE), is(equalTo(CommonConstants.WMQ_CM_BINDINGS)));
cf.setIntProperty(CommonConstants.WMQ_CONNECTION_MODE, CommonConstants.WMQ_CM_CLIENT);
assertThat(cf.getIntProperty(CommonConstants.WMQ_CONNECTION_MODE), is(equalTo(CommonConstants.WMQ_CM_CLIENT)));
}

This is almost always caused by a combination of an incomplete client install and/or a CLASSPATH issue. Many people grab the jar files rather than performing the complete install and do not necessarily get all of them. In addition to insuring all required binaries are present, using the install media provides several additional capabilities such as diagnostics and trace. It also assures that maintenance can be applied. The WMQ client install media are available for free download as SupportPac MQC7. The CLASSPATH setting should be as described in the WebSphere MQ Using Java manual.
If the client install is performed from the IBM media and the environment is set up as per the docs, this fixes nearly all cases such as you have reported here. There are a few Install Verification Test apps (some of those diagnostics installed with the full media that I mentioned) which are described here and which can help determine if a problem is with the installation or with the code.

Agree with Johnam, it happened because the ConnectionFactory set as server by default, it need to be set as client, you said that it works on same machine. Because I also met the same situation, it run when on same machine, in this case because your machine is as WMQ Server so do the program, but when you run on different machine then your program must set as client.
I fix it using set some parameter on ConnectionFactory:
<bean id="mqConnectionFactory" class="com.ibm.mq.jms.MQConnectionFactory">
....
<property name="transportType" value="1" />
<property name="clientReconnectTimeout" value="2" />
<property name="clientReconnectOptions" value="0" />
</bean>

The VM parameter -Djava.library.path=/opt/mqm/java/lib64 works for me. My environment is 64bit Suse with MQ installed and my program is using 'Bindings' transport type

The issue is with Path variable on system properties. Try to run code by specifying MQInstallation Dir :\Lib64 path before MQInstallation Dir :\Lib

Add the below to your tomcat arguments:
-Djava.library.path="C:\Program Files (x86)\IBM\WebSphere MQ\java\lib64"
If the installation directory is different than the above, use the appropriate location.

Migrating To Weblogic From Tomcat

I have a web application running on tomcat. I want to deploy it on a weblogic server but i get some problems.
Error(s) found in module 'BatchMonitoring'. Publish was cancelled. See "Problems" view for details.
Target runtime SpringSource dm Server (Runtime) v1.0 is not defined. at BatchMonitoring
Java compiler level does not match the version of the installed Java project facet. at BatchMonitoring
java.lang.IllegalArgumentException: Cannot find state with id 'displayError' in flow 'admin_main' -- Known state ids are 'array<String>['queryAll', 'mainForm', 'register']'
at org.springframework.webflow.engine.Flow.getStateInstance(Flow.java:348)
at org.springframework.webflow.engine.support.DefaultTargetStateResolver.resolveTargetState(DefaultTargetStateResolver.java:60)
at org.springframework.webflow.engine.Transition.execute(Transition.java:217)
at org.springframework.webflow.engine.impl.FlowExecutionImpl.execute(FlowExecutionImpl.java:391)
at org.springframework.webflow.engine.impl.RequestControlContextImpl.execute(RequestControlContextImpl.java:214)
at org.springframework.webflow.engine.support.TransitionExecutingFlowExecutionExceptionHandler.handle(TransitionExecutingFlowExecutionExceptionHandler.java:110)
at org.springframework.webflow.engine.FlowExecutionExceptionHandlerSet.handleException

Seems like you had problems with Java versions of what Tomcat is using(points to JAVA_HOME) at environmental variable and JDK of Weblogic. Also it would be good if you send some logs and exception messages.

Solaris JMS Client connect to Weblogic 11g t3s security problem

When I try to connect Weblogic t3s protocol in Solaris Server, it shows this error:
java.lang.IllegalStateException: Not enough cryptography available to enable a cipher suite!
at com.certicom.tls.interfaceimpl.TLSSystem.resetCipherSuiteSupport(Unknown Source)
at com.certicom.tls.interfaceimpl.TLSSystem.setCertificateSupport(Unknown Source)
at com.certicom.tls.interfaceimpl.TLSSystem.<init>(Unknown Source)
at com.certicom.tls.interfaceimpl.TLSSystem.<init>(Unknown Source)
at com.certicom.net.ssl.SSLContext.<init>(Unknown Source)
at com.bea.sslplus.CerticomSSLContext.<init>(Unknown Source)
at sun.reflect.GeneratedConstructorAccessor6.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at weblogic.security.utils.SSLSetup.getSSLDelegateInstance(SSLSetup.java:122)
at weblogic.security.utils.SSLContextWrapper.<init>(SSLContextWrapper.java:48)
at weblogic.security.utils.SSLContextWrapper.getInstance(SSLContextWrapper.java:43)
at weblogic.security.utils.SSLSetup.getSSLContext(SSLSetup.java:238)
at weblogic.security.SSL.SSLClientInfo.getSSLSocketFactory(SSLClientInfo.java:101)
at weblogic.socket.ChannelSSLSocketFactory.getSocketFactory(ChannelSSLSocketFactory.java:170)
at weblogic.socket.ChannelSSLSocketFactory.createSocket(ChannelSSLSocketFactory.java:77)
at weblogic.socket.ChannelSSLSocketFactory.createSocket(ChannelSSLSocketFactory.java:114)
at weblogic.socket.BaseAbstractMuxableSocket.createSocket(BaseAbstractMuxableSocket.java:133)
at weblogic.rjvm.t3.MuxableSocketT3.newSocketWithRetry(MuxableSocketT3.java:206)
at weblogic.rjvm.t3.MuxableSocketT3.connect(MuxableSocketT3.java:375)
at weblogic.rjvm.t3.ConnectionFactoryT3S.createConnection(ConnectionFactoryT3S.java:34)
at weblogic.rjvm.ConnectionManager.createConnection(ConnectionManager.java:1773)
at weblogic.rjvm.ConnectionManager.findOrCreateConnection(ConnectionManager.java:1416)
at weblogic.rjvm.ConnectionManager.bootstrap(ConnectionManager.java:437)
at weblogic.rjvm.ConnectionManager.bootstrap(ConnectionManager.java:315)
at weblogic.rjvm.RJVMManager.findOrCreateRemoteInternal(RJVMManager.java:251)
at weblogic.rjvm.RJVMManager.findOrCreate(RJVMManager.java:194)
at weblogic.rjvm.RJVMFinder.findOrCreateRemoteServer(RJVMFinder.java:238)
at weblogic.rjvm.RJVMFinder.findOrCreateInternal(RJVMFinder.java:200)
at weblogic.rjvm.RJVMFinder.findOrCreate(RJVMFinder.java:170)
at weblogic.rjvm.ServerURL.findOrCreateRJVM(ServerURL.java:153)
at weblogic.jndi.WLInitialContextFactoryDelegate$1.run(WLInitialContextFactoryDelegate.java:344)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:147)
at weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext(WLInitialContextFactoryDelegate.java:339)
at weblogic.jndi.Environment.getContext(Environment.java:315)
at weblogic.jndi.Environment.getContext(Environment.java:285)
at weblogic.jndi.WLInitialContextFactory.getInitialContext(WLInitialContextFactory.java:117)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
at javax.naming.InitialContext.init(InitialContext.java:223)
at javax.naming.InitialContext.<init>(InitialContext.java:197)
I have define the following parameters:
-Djava.protocol.handler.pkgs=weblogic.net -Dweblogic.security.SSL.ignoreHostnameVerification=true -Dweblogic.security.TrustKeyStore=CustomTrust -Dweblogic.security.CustomTrustKeyStoreType=JKS -Dweblogic.security.CustomTrustKeyStoreFileName=keystore -Dweblogic.security.CustomTrustKeyStorePassPhrase=passphrase -Dssl.debug=true -Dweblogic.StdoutDebugEnabled=true
How can I fix it? Same source and same parameters is working in Windows.
Thank You.

This solution comes a bit late in the day, but is meant for others having the same problem.
Apparently, the accepted solution of adding webserviceclient+ssl.jar to the classpath works, since the WebLogic Full Client - wlfullclient.jar has references to other JARs in its MANIFEST.MF file. Adding the webservices client JAR resolves the issue, since it appears to have the minimum set of classes required for correct operation of the client when using SSL/TLS. The error is usually encountered when copies of the wlfullclient.jar and wlcipher.jar are made in a different directory, and added to the classpath. The JVM then fails to load other dependent classes from JARs that are referenced from within the MANIFEST file.
The actual solution would be to add the wlfullclient.jar that is generated in the WL_HOME\server\lib directory, to the CLASSPATH. All other dependent JARs would then be picked up via the appropriate classloader, since the manifest references these via relative directory paths.

Are you using the same JVM vendor on both machines?
Most likely the CA used to generate the keystore is available on the Windows truststore but not available on Solaris, the assumption being the keystore was generated in Windows and the CA is not yet shipped with the JRE being used on Solaris. The differences are discussed here.
How to configure the truststore to add a CA

Finally, We got the solution.
Just add webserviceclient+ssl.jar to your classpath will solve the problem.
webserviceclient+ssl.jar not included in wlfullclient.jar.

Are you sure that you keystore file is picked up? Maybe try to use an absolute path when specifying the -Dweblogic.security.CustomTrustKeyStoreFileName option.
Also, are the classpath of the JMS client really identical in both environments?
Try to provide wlserver_10.3/server/lib/wlfullclient.jar (that you create by running the command java -jar wljarbuilder.jar) and wlserver_10.3/server/lib/wlcipher.jar (yeah, wlfullclient.jar is not that full!) on the classpath.

This has been simplified for 10.3.4 and above Weblogic.
Just add the wlthint3client.jar from the /server/lib directory to your client's Classpath
I've only confirmed this works for ejb communication but the docs state
This release supports the following:
Oracle WebLogic's T3/T3S protocol for Remote Method Invocation (RMI), including RMI over HTTP (HTTP tunneling). For more information on WebLogic T3 communication, see "Using WebLogic RMI with T3 Protocol" in Programming RMI for Oracle WebLogic Server.
Access to JMS, JMX, JNDI, and EJB resources available in WebLogic Server.
http://docs.oracle.com/cd/E17904_01/web.1111/e13717/wlthint3client.htm