I have a Glassfish 3 server running with Jersey Rest webservices.
I have a swing app running as a client.
I can do everything I coded the app to do. (Add,delete,edit,view) Everything works as expected.
I want to distribute the swing app with Java Webstart.
In netbeans I run my application with webstart and get the following error:
com.sun.jersey.api.client.ClientHandlerException: A message body reader for Java class java.util.List, and Java type java.util.List<za.co.lunginstitute.restbeans.Patient>, and MIME media type application/json was not found
at com.sun.jersey.api.client.ClientResponse.getEntity(ClientResponse.java:561)
at com.sun.jersey.api.client.ClientResponse.getEntity(ClientResponse.java:535)
at za.co.lunginstitute.restclient.BaseDAO.get(BaseDAO.java:37)
at za.co.lunginstitute.restclient.PatientsDAO.findAll(PatientsDAO.java:39)
at za.co.lunginstitute.gregg.xrays.gui.models.PatientDataModel.loadAll(PatientDataModel.java:37)
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 za.co.lunginstitute.gregg.xrays.workers.BackgroundRunner$BGRunner.doInBackground(BackgroundRunner.java:97)
at javax.swing.SwingWorker$1.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at javax.swing.SwingWorker.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
I ran it under JavaWS 6 and 7. I used the JDK as well as the JRE.
Everything works as long as I stay away from webstart.
I tried running the app from the commandline as a normal java and then as javaws. Java works,but javaws gives me this error.
I did check the classpath, double and triple checked. All the libraries are present.
I used fiddler and everything works as expected. The connection is made, data is returned and then this error - only when using webstart.
Found "solution":
ClientConfig config = new DefaultClientConfig();
config.getClasses().add(JacksonJsonProvider.class);
I did not have the last line in my code. After adding it I don't get the exception anymore.
Weird is that it worked running app as java.exe, but not as javaws.exe.
Now I get this error futher on in the code:
Caused by: org.codehaus.jackson.map.JsonMappingException: Can not construct instance of java.util.Date from String value '1980-01-01 CAT': not a valid representation (error: Can not parse date "1980-01-01 CAT": not compatible with any of standard forms ("yyyy-MM-dd'T'HH:mm:ss.SSSZ", "yyyy-MM-dd'T'HH:mm:ss.SSS'Z'", "EEE, dd MMM yyyy HH:mm:ss zzz", "yyyy-MM-dd"))
at [Source: com.sun.jersey.client.apache.ApacheHttpClientHandler$HttpClientResponseInputStream#140fbd9; line: 1, column: 143] (through reference chain: za.co.lunginstitute.restbeans.Xray["xraydate"])
at org.codehaus.jackson.map.JsonMappingException.from(JsonMappingException.java:163)
at org.codehaus.jackson.map.deser.StdDeserializationContext.weirdStringException(StdDeserializationContext.java:243)
at org.codehaus.jackson.map.deser.std.StdDeserializer._parseDate(StdDeserializer.java:553)
at org.codehaus.jackson.map.deser.std.DateDeserializer.deserialize(DateDeserializer.java:28)
at org.codehaus.jackson.map.deser.std.DateDeserializer.deserialize(DateDeserializer.java:19)
at org.codehaus.jackson.map.deser.SettableBeanProperty.deserialize(SettableBeanProperty.java:299)
at org.codehaus.jackson.map.deser.SettableBeanProperty$MethodProperty.deserializeAndSet(SettableBeanProperty.java:414)
at org.codehaus.jackson.map.deser.BeanDeserializer.deserializeFromObject(BeanDeserializer.java:697)
at org.codehaus.jackson.map.deser.BeanDeserializer.deserialize(BeanDeserializer.java:580)
at org.codehaus.jackson.map.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:217)
at org.codehaus.jackson.map.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:194)
at org.codehaus.jackson.map.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:30)
at org.codehaus.jackson.map.ObjectMapper._readValue(ObjectMapper.java:2695)
at org.codehaus.jackson.map.ObjectMapper.readValue(ObjectMapper.java:1308)
at org.codehaus.jackson.jaxrs.JacksonJsonProvider.readFrom(JacksonJsonProvider.java:419)
at com.sun.jersey.api.client.ClientResponse.getEntity(ClientResponse.java:565)
... 16 more
I do use this:
#XmlJavaTypeAdapter(SimpleDateAdapter.class)
on the get method for the class. Again this works when running as java, not in javaws.
Am I missing something, some Jersey config settings.
Related
I need help negating this stack trace while trying to connect to the database:
java.net.SocketException: Invalid argument: create
at java.base/java.net.Socket.createImpl(Unknown Source)
at java.base/java.net.Socket.connect(Unknown Source)
at com.ibm.db2.jcc.t4.x.run(x.java:49)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at com.ibm.db2.jcc.t4.a0.a(a0.java:436)
at com.ibm.db2.jcc.t4.a0.<init>(a0.java:96)
at com.ibm.db2.jcc.t4.a.b(a.java:366)
at com.ibm.db2.jcc.t4.b.newAgent_(b.java:2164)
at com.ibm.db2.jcc.am.Connection.initConnection(Connection.java:839)
at com.ibm.db2.jcc.am.Connection.<init>(Connection.java:784)
at com.ibm.db2.jcc.t4.b.<init>(b.java:350)
at com.ibm.db2.jcc.DB2SimpleDataSource.getConnection(DB2SimpleDataSource.java:233)
at com.ibm.db2.jcc.DB2SimpleDataSource.getConnection(DB2SimpleDataSource.java:200)
at com.ibm.db2.jcc.DB2Driver.connect(DB2Driver.java:471)
at com.ibm.db2.jcc.DB2Driver.connect(DB2Driver.java:113)
at net.sourceforge.squirrel_sql.fw.sql.SQLDriverManager.getConnection(SQLDriverManager.java:147)
at net.sourceforge.squirrel_sql.client.mainframe.action.OpenConnectionCommand.executeConnect(OpenConnectionCommand.java:148)
at net.sourceforge.squirrel_sql.client.mainframe.action.OpenConnectionCommand.lambda$execute$0(OpenConnectionCommand.java:93)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)
I've tried googling the best I'm capable of, but cannot figure out what is causing this. Tried changing file/folder permissions to remove any write protection. Tried new drivers from IBM as well, for version 11.5, but same error persists. (With both db2jcc.jar and db2jcc4.jar)
The connection works just fine with an older version of Squirrel, relying on Java 1.7. Version 4.0.0 runs with Java 9, starts just fine, but just won't connect to the database.
As of September 2019 Db2 for LUW 11.5 ships with and lists among supported software Java 8, which you should take to mean that Java 9 is not officially supported and should not be used.
My actual problem is a derivation of the title, but the title is the root cause of my issue:
I am developing a java web application at work. The server my application is to be deployed on, only accepts java 6 or lower (WebLogic 10.3.2)
I need to call a web service in my application. My experience in this area is limited. I have been able to make it work, but when I integrated my code into the web application, compiled and tested it, I got this error:
Exception in thread "main" java.lang.ClassCastException: sun.reflect.generics.reflectiveObjects.GenericArrayTypeImpl cannot be cast to java.lang.Class
at com.sun.xml.internal.bind.v2.model.impl.RuntimeModelBuilder.createArrayInfo(Unknown Source)
at com.sun.xml.internal.bind.v2.model.impl.RuntimeModelBuilder.createArrayInfo(Unknown Source)
at com.sun.xml.internal.bind.v2.model.impl.ModelBuilder.getTypeInfo(Unknown Source)
at com.sun.xml.internal.bind.v2.model.impl.ElementInfoImpl.<init>(Unknown Source)
at com.sun.xml.internal.bind.v2.model.impl.RuntimeElementInfoImpl.<init>(Unknown Source)
at com.sun.xml.internal.bind.v2.model.impl.RuntimeModelBuilder.createElementInfo(Unknown Source)
at com.sun.xml.internal.bind.v2.model.impl.RuntimeModelBuilder.createElementInfo(Unknown Source)
at com.sun.xml.internal.bind.v2.model.impl.RegistryInfoImpl.<init>(Unknown Source)
at com.sun.xml.internal.bind.v2.model.impl.ModelBuilder.addRegistry(Unknown Source)
at com.sun.xml.internal.bind.v2.model.impl.ModelBuilder.getTypeInfo(Unknown Source)
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(Unknown Source)
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(Unknown Source)
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(Unknown Source)
at com.sun.xml.internal.bind.v2.ContextFactory.createContext(Unknown Source)
at com.sun.xml.internal.bind.api.JAXBRIContext.newInstance(Unknown Source)
at com.sun.xml.internal.ws.developer.JAXBContextFactory$1.createJAXBContext(Unknown Source)
at com.sun.xml.internal.ws.model.AbstractSEIModelImpl$1.run(Unknown Source)
at com.sun.xml.internal.ws.model.AbstractSEIModelImpl$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.xml.internal.ws.model.AbstractSEIModelImpl.createJAXBContext(Unknown Source)
at com.sun.xml.internal.ws.model.AbstractSEIModelImpl.postProcess(Unknown Source)
at com.sun.xml.internal.ws.model.RuntimeModeler.buildRuntimeModel(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.createSEIPortInfo(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.addSEI(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.getPort(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.getPort(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.getPort(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.getPort(Unknown Source)
at javax.xml.ws.Service.getPort(Unknown Source)
at com.example.mypackage.MyClient.invokeService(MyClient.java:64)
at Test.main(Test.java:7)
I have traced this error back to being a java version issue. It works in 7, but the Exception is thrown on method execution, if I compile in 6, which I have to do for the web app. The line where my exception is thrown, is the one with NotificationRecieverSoapInterface.class below:
NotifikationRecieverSoap service = null;
try {
service = new NotifikationRecieverSoap(new URL("[myURL].svc?wsdl"));
} catch (MalformedURLException e) {
e.printStackTrace();
}
NotificationRecieverSoapInterface notificationService = service.getPort(NotificationRecieverSoapInterface.class);
notifikationService.createNotificationRequest(logHeader, loginModule, parmV, priority, recipients);
The Service.getPort()-method seems identical in the two java versions, so I'm at a loss there. the sun.reflect.generics.reflectiveObjects.GenericArrayTypeImpl are also identical in 6 and 7.
The closest thing I found to a similar problem online, was this: http://forum.spring.io/forum/spring-projects/container/26020-classcastexception-genericarraytypeimpl-cannot-be-cast-to-class. Unfortunately, the solution here was that there is a bug in Spring, which I am not using...
Does anyone know more specifically what my problem is, and if it can be worked around, using only Java 6?
I do have a lot more code to show. I have chosen the parts I think is most relevant to the problem. I can provide jax-ws-generated classes for data structure, or sample xml's as well, on request.
Ok... I used this method to generate the web service classes: http://www.mkyong.com/webservices/jax-ws/jax-ws-wsimport-tool-example/
I realized that I had used a 1.7 JDK when calling the wsimport.exe. This was incompatible with my 1.6 project. After regenerating the classes with the wsimport.exe found in the correct JDK 1.6, the java classes were slightly different, and compatible with my project's setup.
Due to change in server configuration, in my project. We apt to proxy server while calling the webservice which is axis2. But the problem, here is we cannot able to access the the endpoint through the soapui(After configuring the proxy configuration in the preference->proxy setting) but i can access the endpoint through eclipse code after configuring the proxy. Here is the exception i am getting in the soapUI logs
Fri Mar 21 19:09:51 IST 2014:ERROR:java.lang.ClassCastException: org.apache.http.message.BasicHttpRequest cannot be cast to org.apache.http.impl.client.RequestWrapper
java.lang.ClassCastException: org.apache.http.message.BasicHttpRequest cannot be cast to org.apache.http.impl.client.RequestWrapper
at com.eviware.soapui.impl.wsdl.support.http.HeadderRequestInterceptor.process(HeadderRequestInterceptor.java:42)
at org.apache.http.protocol.ImmutableHttpProcessor.process(ImmutableHttpProcessor.java:108)
at org.apache.http.protocol.HttpRequestExecutor.preProcess(HttpRequestExecutor.java:174)
at com.eviware.soapui.impl.wsdl.support.http.HttpClientSupport$SoapUIHttpRequestExecutor.preProcess(HttpClientSupport.java:106)
at org.apache.http.impl.client.DefaultRequestDirector.createTunnelToTarget(DefaultRequestDirector.java:830)
at org.apache.http.impl.client.DefaultRequestDirector.establishRoute(DefaultRequestDirector.java:739)
at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:565)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:415)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:754)
at com.eviware.soapui.impl.wsdl.support.http.HttpClientSupport$Helper.execute(HttpClientSupport.java:236)
at com.eviware.soapui.impl.wsdl.support.http.HttpClientSupport.execute(HttpClientSupport.java:345)
at com.eviware.soapui.impl.wsdl.submit.transports.http.HttpClientRequestTransport.sendRequest(HttpClientRequestTransport.java:241)
at com.eviware.soapui.impl.wsdl.WsdlSubmit.run(WsdlSubmit.java:123)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
I'm using SoapUI 4.5.1 and facing the same exception. I almost spend my entire day in dubgging it and later on I downloaded SoapUI 5.0.0 and tested same webservice and that works.
By reading http://sourceforge.net/p/soapui/bugs/636/ this URL I found that it was a bug in SoapUI 4.5.1 version.
So better always use the new verions of tool if they are available :)
After upgrading to Java 7, when launching remote jnlp, I see the following exception in the Java console:
java.security.KeyStoreException: WIExplorerMy not found
at java.security.KeyStore.getInstance(Unknown Source)
at com.sun.deploy.services.WPlatformService$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.services.WPlatformService.getBrowserClientAuthKeyStore(Unknown Source)
at sun.plugin2.applet.context.InitialJNLPExecutionContext.getBrowserClientAuthKeyStore(Unknown Source)
at sun.plugin2.main.client.DisconnectedExecutionContext.getBrowserClientAuthKeyStore(Unknown Source)
at sun.plugin2.applet.Applet2BrowserService.getBrowserClientAuthKeyStore(Unknown Source)
at com.sun.deploy.security.X509DeployKeyManager.<init>(Unknown Source)
at com.sun.deploy.net.protocol.https.Handler$Initializer$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.net.protocol.https.Handler$Initializer.<clinit>(Unknown Source)
at com.sun.deploy.net.protocol.https.Handler.openConnection(Unknown Source)
at java.net.URL.openConnection(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.createUrlConnection(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.doGetRequestEX(Unknown Source)
at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
at com.sun.deploy.net.DownloadEngine.downloadResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.javaws.LaunchDownload$DownloadTask.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.security.NoSuchAlgorithmException: WIExplorerMy KeyStore not available
at sun.security.jca.GetInstance.getInstance(Unknown Source)
at java.security.Security.getImpl(Unknown Source)
... 26 more
In addition the error screen saying "Error. Click for details" appears for about 2 seconds and disappears afterwards.
Other then that, everything seems to function normally.
With Java 6 everything works as expected.
Ideas how to fix it?
I think some of the latest Java 7 updates have obsoleted some encryption schemes, so that would be a completely normal exception to get if you were using one of these while using Java 6.
See this list of enhancements and changes for Java 7:
Weak cipher suites deprecated
Per RFC 4346, RFC 5246, and RFC 5469, some cipher suites have been made obsolete and should not be used. These obsolete suites are all disabled by default in SunJSSE. For details, consult the cipher suite lists in the documentation about the SunJSSE provider.
That being said, that would explain the NoSuchAlgorithmException, but the error message seems to mention something about a missing keystore, so this may be unrelated and we woud need you to provide a SSCCE or anything close enough to one.
I solved this problem by adding
security.provider.11=com.sun.deploy.security.MSCryptoProvider
to C:\Program Files\Java\jre1.8.0_31\lib\security\java.security
Although the error wasn't fatal for me, it is just the javaws trying to read the local browser key store before falling back to the java keystores that are managed by the control panel. Those files are in C:\Users\USERID\AppData\LocalLow\Sun\Java\Deployment\security
Interestingly there is a security provider that comes pre-wired into the java.security file, and it is
security.provider.10=sun.security.mscapi.SunMSCAPI
This provider can also read the browser keystore, but the store type is windows-my, and not WIExplorerMy
Tarlog, do you have any resolution found yet? I have the same problem, I am suspecting that the first problem with KeyStoreException exception only happens if you are trying secure connection. And that sinister "Error. Click for details" issue happens on any Applet loaded through an jnlp.
I could not find any resolution yet.
Edit: For the KeyStoreException I have realised that the problem occured due to apache certificate files were gone somehow. I have generated ceritificate files and restarted apache. The exception no longer occurs.
The other problem with Error window still exists.
With regard to the Error Click for details issue – I resolved this by adding a class to the source that implements javax.jnlp.DownloadServiceListener (can just be a dummy class) and then specifying that class in your jnlp file (applet-desc/#progress-class="YourClass")
In my application's JNLP file, I specify the PermGenSize in JNLP java-vm-args parameter.
After upgrading Java on my MAC to Java7u13, the JNLP fails to launch with java-vm-args params.
If I remove the java-vm-args parameter everything works fine.
My java-vm-args parameter is java-vm-args="-XX:MaxPermSize=128m"
Is this a Java 7 issue?. I am able reproduce the above problem in solaris also.
During the failure I see the following exception in trace file:
Log started: Tue, 19 Feb 2013 11:02:41 +0530
java.lang.StringIndexOutOfBoundsException: String index out of range: -8
at java.lang.String.substring(String.java:1911)
at com.sun.deploy.util.Property.<init>(Unknown Source)
at com.sun.deploy.util.Property.createProperty(Unknown Source)
at com.sun.deploy.util.JVMParameters$ArgumentSet.addArgument(Unknown Source)
at com.sun.deploy.util.JVMParameters.addArgumentImpl(Unknown Source)
at com.sun.deploy.util.JVMParameters.parseImpl(Unknown Source)
at com.sun.deploy.util.JVMParameters.parseTrustedOptions(Unknown Source)
at com.sun.javaws.Main.initializeExecutionEnvironment(Unknown Source)
at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
at com.sun.javaws.Main.access$000(Unknown Source)
at com.sun.javaws.Main$1.run(Unknown Source)
at java.lang.Thread.run(Thread.java:722)
Permgen is gonna disappear in futher releases. Remove XX:MaxPermSize from your arguments lists and re-run application.