I wrote a remote service MyremoteImpl.java and used following command after compiled it.
rmic MyRemoteImpl
I learned that this method suppose to create stub class and a skeleton class but I can only see the stub class, why is that?
The other problem I faced after run rmiregistry I started the service but it gives following error, I doubt I get this error as I'm missing skeleton class?
java.net.MalformedURLException: invalid URL String: Remote Hello
at java.rmi.Naming.parseURL(Unknown Source)
at java.rmi.Naming.rebind(Unknown Source)
at RMIservice.MyRemoteImpl.main(MyRemoteImpl.java:22)
Caused by: java.net.URISyntaxException: Illegal character in path at index 6: Remote Hello
at java.net.URI$Parser.fail(Unknown Source)
at java.net.URI$Parser.checkChars(Unknown Source)
at java.net.URI$Parser.parseHierarchical(Unknown Source)
at java.net.URI$Parser.parse(Unknown Source)
at java.net.URI.<init>(Unknown Source)
at java.rmi.Naming.intParseURL(Unknown Source)
... 3 more
Please help me to solve this, Thanx in advance!!!
Don't do this. You don't need it. Skeleton classes haven't been required since 1998.
From rmic 1.2 onwards, Java don't generate skeletion class any more. New JRMP protocol supported for RMI has got rid of the use of skeleton files.
A skeleton for a remote object is a JRMP protocol server-side entity that has a method that dispatches calls to the actual remote object implementation.
Related
I am getting "Failed to negotiate transport Component" in the log. Does anybody have any idea what can be the cause, because it doesn't seem to be any code side issue.
Thanks in advance.
Failed to negotiate a transport component [aes192-cbc] [arcfour] [Unknown cause]
at com.maverick.ssh2.TransportProtocol.B(Unknown Source)
at com.maverick.ssh2.TransportProtocol.C(Unknown Source)
at com.maverick.ssh2.TransportProtocol.processMessage(Unknown Source)
at com.maverick.ssh2.TransportProtocol.startTransportProtocol(Unknown Source)
at com.maverick.ssh2.Ssh2Client.connect(Unknown Source)
at com.maverick.ssh.SshConnector.connect(Unknown Source)
at com.maverick.ssh.SshConnector.connect(Unknown Source)
The server supports "arcfour" cipher only, while your client supports "aes192-cbc" only.
The j2ssh-maverick implements the "arcfour" too. You can enable it by using JCEComponentManager.installArcFourCiphers.
Though note that "arcfour" is a weak cipher and you should avoid it, if possible. Consider upgrading the server.
I am trying the build a SOAP client to access the National Weather Service NDFD SOAP Service. I'm using Axis2 1.6.2 with code generated with wsdl2java.
Every time I try to retrieve data, I receive a AxisFault saying Read timed out.
I have tried to increase the timeout time to up to 500 s, but all that does is make it wait longer before giving the same error.
Exception in thread "main" org.apache.axis2.AxisFault: [was class java.net.SocketTimeoutException] Read timed out
at org.apache.axis2.AxisFault.makeFault(AxisFault.java:430)
at gov.weather.graphical.xml.dwmlgen.wsdl.ndfdxml_wsdl.NdfdXMLStub.fromOM(NdfdXMLStub.java:26499)
at gov.weather.graphical.xml.dwmlgen.wsdl.ndfdxml_wsdl.NdfdXMLStub.nDFDgen(NdfdXMLStub.java:595)
at he.andrew.ndfd.NDFDData.getData(NDFDData.java:47)
at he.andrew.ndfd.NDFDData.main(NDFDData.java:25)
Caused by: java.lang.RuntimeException: [was class java.net.SocketTimeoutException] Read timed out
at com.ctc.wstx.util.ExceptionUtil.throwRuntimeException(ExceptionUtil.java:18)
at com.ctc.wstx.sr.StreamScanner.throwLazyError(StreamScanner.java:731)
at com.ctc.wstx.sr.BasicStreamReader.safeFinishToken(BasicStreamReader.java:3657)
at com.ctc.wstx.sr.BasicStreamReader.getText(BasicStreamReader.java:809)
at com.ctc.wstx.sr.BasicStreamReader.getElementText(BasicStreamReader.java:679)
at org.apache.axiom.util.stax.wrapper.XMLStreamReaderWrapper.getElementText(XMLStreamReaderWrapper.java:100)
at org.apache.axiom.util.stax.wrapper.XMLStreamReaderWrapper.getElementText(XMLStreamReaderWrapper.java:100)
at org.apache.axiom.om.impl.llom.SwitchingWrapper.getElementText(SwitchingWrapper.java:936)
at javax.xml.stream.util.StreamReaderDelegate.getElementText(Unknown Source)
at org.apache.axiom.util.stax.wrapper.XMLStreamReaderWrapper.getElementText(XMLStreamReaderWrapper.java:100)
at org.apache.axiom.util.stax.debug.XMLStreamReaderValidator.getElementText(XMLStreamReaderValidator.java:75)
at gov.weather.graphical.xml.dwmlgen.wsdl.ndfdxml_wsdl.NdfdXMLStub$NDFDgenResponse$Factory.parse(NdfdXMLStub.java:5612)
at gov.weather.graphical.xml.dwmlgen.wsdl.ndfdxml_wsdl.NdfdXMLStub.fromOM(NdfdXMLStub.java:26353)
... 3 more
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(Unknown Source)
at java.net.SocketInputStream.read(Unknown Source)
at java.io.BufferedInputStream.read1(Unknown Source)
at java.io.BufferedInputStream.read(Unknown Source)
at org.apache.commons.httpclient.WireLogInputStream.read(WireLogInputStream.java:69)
at org.apache.commons.httpclient.ChunkedInputStream.read(ChunkedInputStream.java:182)
at java.io.FilterInputStream.read(Unknown Source)
at org.apache.commons.httpclient.AutoCloseInputStream.read(AutoCloseInputStream.java:108)
at java.io.FilterInputStream.read(Unknown Source)
... more not included
The error seems to be the same as the one here: Exception in thread "main" org.apache.axis2.AxisFault: Read timed out. However, I don't quite understand any of the responses to that question.
One final note. In order to avoid a "411 Error: Length Required", I had to turn off the Chunked option. I'm not sure if this is relevant.
Does anyone know what might be the problem?
I ran into this error on a project, and the root cause was a proxy server setting. I had to modify the proxy to allow the communication to the service I was trying to hit. My code was running as part of a custom application that used its own proxy. So this may also be something to try.
Just when I thought I know how RMI works, it comes back and tell me I do not. The following situation:
I have given:
an interface: http://pastebin.com/KxXH1jQ9
an adress where the rmiregistry is runnung
The interface offers cleary 3 getter methods to gain informations about the object. I simply want to lookup the object call the three methods and print out theirs values:
However the following implementation ( http://pastebin.com/d4JS0Wai ) does not do the trick resulting in the following exception:
Exception in thread "main" java.rmi.UnmarshalException: error unmarshalling return; nested exception is:
java.lang.ClassNotFoundException: Article
at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source)
at rmi.ArticleDisplayer.main(ArticleDisplayer.java:21)
Caused by: java.lang.ClassNotFoundException: Article
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
...
Also I don't know why I should need a SecurityManager anyway, as my machine is not executing the code. The code is executed on the machine running the rmiregistry. Anyway this is my policy file: http://pastebin.com/chGEqceA
This problem occurs because you should have the same Article class accessible by both the client and the source applications.
You can do a Jar with the common classes used by the 2 modules (client and server) and use it (I generally give the name "commons" to these type of packages).
Okay, the answer to the problem:
The implementation, as well as the interface are inside the default package. I wrote the program inside my own package: rmi
Also the interfaces I downloaded where in the package rmi. As a matter of fact rmi.Article != Article.
I have a "proof of concept" piece of work that crosses over into some unfamiliar territory.
I'm tasked with connecting an EFTPOS machine to an application running as an applet in a browser on our intranet.
I've ignored the EFTPOS dll for the moment and created a simple JNI decorated DLL in my language of choice (Delphi) that just logs a string to a text file in c:\ and I can call it successfully from a local Java application.
However, when I create an applet to do the same thing, compile it into a .JAR, sign the JAR & try to call the method in the applet via Javascript on a web page it fails.
A senior Java guy I'm working with doesn't think it will be possible to get this to work because it's inherently "evil" to allow an applet to do this.
There is an entry you can put in a java.policy file to allow loadLibrary. as well as allPermission & I've tried a whole host of variations along those lines all to no avail producing the following error trace in the Java Console:
java.lang.ExceptionInInitializerError
at app.TestApplet.LogAString(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.plugin.javascript.JSInvoke.invoke(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.plugin.javascript.JSClassLoader.invoke(Unknown Source)
at sun.plugin.com.MethodDispatcher.invoke(Unknown Source)
at sun.plugin.com.DispatchImpl.invokeImpl(Unknown Source)
at sun.plugin.com.DispatchImpl$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin.com.DispatchImpl.invoke(Unknown Source)
Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.DLoggerImpl)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkLink(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
at app.DLogger.<clinit>(Unknown Source)
... 16 more
java.lang.Exception: java.lang.ExceptionInInitializerError
at sun.plugin.com.DispatchImpl.invokeImpl(Unknown Source)
at sun.plugin.com.DispatchImpl$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin.com.DispatchImpl.invoke(Unknown Source)
The key line seems to be "Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.DLoggerImpl)" which implies a permissions problem. It could be that I'm getting the policy file wrong - or the signing wrong - or stuff like that or it could be that Java is hardwired to not allow those sort of permissions for an Applet because of the security risk.
My question is am I wasting my time? Can it be done & if so, how?
Thanks in anticipation
Mike
You can definitely accomplish this. I have a working applet in production that does exactly this. Even if your applet is signed, you still need to use the Access Controller to access the dll, you cannot just call "loadlibrary". You can add this to the Java policy file however this is not recommended due to 1. You probably do not have access to the users java configuration. 2. Even if this is for your own company use, managing the policy file is a pain as users will download some JRE and your policy file is either overwritten or ignored.
You best bet is to sign your jar, making sure to wrap your load library code in a privileged block of code like this.
try
{
AccessController.doPrivileged(new PrivilegedAction()
{
public Object run()
{
try
{
// privileged code goes here, for example:
System.load("C:/Program Files/.../Mydll.dll");
return null; // nothing to return
}
catch (Exception e)
{
System.out.println("Unable to load Mydll");
return null;
}
}
});
}
catch (Exception e)
{
System.out.println("Unable to load Mydll");
}
You can Also use System.loadlibrary(mydll.dll) but you have to have the dll folder on the path in windows so the applet can find it.
If you need some source samples for calling the JNI functions let me know I can grab that as well.
The only thing I can suggest is taking a look at the source code for that area and trying to decipher if it is not allowing because of lack of permission or because that is not allowed at all. You don't have line numbers unfortunately, so that makes it a little more tricky.
I am pretty sure you cannot load a native library from an Applet unless it is "signed", and then the user will get an acceptance dialog to allow or disallow. That is, assuming you can do JNI at all in an applet... never tried that.
Good luck.
Iam using HTTPClient 4.0 to connect a remote server and transfer file using HTTPS.
When i tried to connect i get the exception "java.net.SocketException: Unconnected sockets not implemented".
Please look at the stack trace
java.net.SocketException: Unconnected sockets not implemented
at java.lang.Throwable.<init>(Throwable.java:196)
at java.lang.Exception.<init>(Exception.java:41)
at java.io.IOException.<init>(IOException.java:40)
at java.net.SocketException.<init>(SocketException.java:29)
at javax.net.SocketFactory.createSocket(SocketFactory.java:2)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.commons.httpclient.protocol.ReflectionSocketFactory.createSocket(Unknown Source)
at org.apache.commons.httpclient.protocol.SSLProtocolSocketFactory.createSocket(Unknown Source)
at org.apache.commons.httpclient.HttpConnection.open(Unknown Source)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(Unknown Source)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(Unknown Source)
at org.apache.commons.httpclient.HttpClient.executeMethod(Unknown Source)
at org.apache.commons.httpclient.HttpClient.executeMethod(Unknown Source)
at co.com.personalsoft.ftpseguro.utilidades.TransmisionHTTP.ejecutarTransmisionHTTP(TransmisionHTTP.java:107)
at co.com.personalsoft.ftpseguro.utilidades.TransmisionFTPNew.ejecutarTransmisionAuto(TransmisionFTPNew.java:483)
at co.com.personalsoft.ftpseguro.utilidades.TransmisionFTPNew.ejecutarTransmision(TransmisionFTPNew.java:1016)
at co.com.personalsoft.ftpautomatico.ConexionThread.run(ConexionThread.java:58)
at java.lang.Thread.run(Thread.java:595)
The same error is found while using HTTP Client 3.1.
My Environment
Application Server : Websphere application server 6.1.0.23
Java : JDK 1.5.0.16
Actually a more complete answer than suppressingfire is
Add com.ibm.ws.admin.client_7.0.0.jar to java build
This solves the java.lang.NoClassDefFoundError: com.ibm.ffdc.Manager error.
Add to setup:
import java.security.Security;
...
Security.setProperty("ssl.SocketFactory.provider", "com.ibm.jsse2.SSLSocketFactoryImpl");
This solves the Cannot find the specified class com.ibm.websphere.ssl.protocol.SSLSocketFactory
When I enabled javax.net.debug, I noticed that there was a missing class com.ibm.websphere.com.ibm.websphere.ssl.protocol.SSLSocketFactory.
I was experiencing trouble in unit tests that invoke httpclient. What I ended up doing was to add this line to my TestClass.setUp()
Security.setProperty("ssl.SocketFactory.provider", "com.ibm.jsse2.SSLSocketFactoryImpl");