unable to hit the webservice using soapUI after proxy setting - java

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 :)

Related

SSLHandshakeException when connecting to Openshift from EclipseIDE... How to solve?

I'm trying to connect to Openshift from Eclipse Mars IDE.
I can very well login to my Openshift account on the web.... Also, going by the error message, I even created new private/public keys and retried connecting but still to no avail. Then I ran a JBossTools update, and tried again, yet no solution.
Here's the closest JBoss Tools BugTrack that I found related to my case, https://issues.jboss.org/browse/JBIDE-14760, but it turns out this is recorded as fixed since JBossTools 4.1.0, whereas I have 4.3.0 on both Mars and Luna
What's even more disturbing is the fact that I've previously been able to make this connection some time ago with Eclipse Luna, then I went back to Luna and tried again but still was unable to make the Openshift connection.
See screenshots of the error messages below;
Eclipse Mars (Error Screenshot below);
Eclipse Luna (Error Screenshot below);
And following is the StackTrace from the logs looks as follows:
!ENTRY org.jboss.tools.openshift.express.ui 4 4 2015-10-09 18:05:58.143
!MESSAGE Could not request https://openshift.redhat.com/broker/rest/api: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No X509TrustManager implementation available
!STACK 0
com.openshift.client.OpenShiftEndpointException: Could not request https://openshift.redhat.com/broker/rest/api: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No X509TrustManager implementation available
at com.openshift.internal.client.RestService.request(RestService.java:120)
at com.openshift.internal.client.RestService.request(RestService.java:92)
at com.openshift.internal.client.AbstractOpenShiftConnectionFactory.getConnection(AbstractOpenShiftConnectionFactory.java:36)
at com.openshift.client.OpenShiftConnectionFactory.getConnection(OpenShiftConnectionFactory.java:198)
at com.openshift.client.OpenShiftConnectionFactory.getConnection(OpenShiftConnectionFactory.java:158)
at com.openshift.client.OpenShiftConnectionFactory.getConnection(OpenShiftConnectionFactory.java:114)
at com.openshift.client.OpenShiftConnectionFactory.getConnection(OpenShiftConnectionFactory.java:103)
at org.jboss.tools.openshift.express.internal.core.connection.Connection.createUser(Connection.java:229)
at org.jboss.tools.openshift.express.internal.core.connection.Connection.connect(Connection.java:205)
at org.jboss.tools.openshift.express.internal.ui.wizard.connection.ConnectionWizardPageModel.connect(ConnectionWizardPageModel.java:247)
at org.jboss.tools.openshift.express.internal.ui.wizard.connection.ConnectionWizardPage$ConnectJob.run(ConnectionWizardPage.java:479)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: com.openshift.internal.client.httpclient.HttpClientException: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No X509TrustManager implementation available
at com.openshift.internal.client.httpclient.UrlConnectionHttpClient.createException(UrlConnectionHttpClient.java:201)
at com.openshift.internal.client.httpclient.UrlConnectionHttpClient.request(UrlConnectionHttpClient.java:161)
at com.openshift.internal.client.httpclient.UrlConnectionHttpClient.request(UrlConnectionHttpClient.java:140)
at com.openshift.internal.client.httpclient.UrlConnectionHttpClient.get(UrlConnectionHttpClient.java:99)
at com.openshift.internal.client.RestService.request(RestService.java:160)
at com.openshift.internal.client.RestService.request(RestService.java:107)
... 11 more
Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No X509TrustManager implementation available
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection$10.run(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection$10.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.net.www.protocol.http.HttpURLConnection.getChainedException(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at java.net.HttpURLConnection.getResponseCode(Unknown Source)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(Unknown Source)
at com.openshift.internal.client.httpclient.UrlConnectionHttpClient.createException(UrlConnectionHttpClient.java:184)
... 16 more
Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No X509TrustManager implementation available
at sun.security.ssl.Alerts.getSSLException(Unknown Source)
at sun.security.ssl.SSLSocketImpl.fatal(Unknown Source)
at sun.security.ssl.Handshaker.fatalSE(Unknown Source)
at sun.security.ssl.Handshaker.fatalSE(Unknown Source)
at sun.security.ssl.ClientHandshaker.serverCertificate(Unknown Source)
at sun.security.ssl.ClientHandshaker.processMessage(Unknown Source)
at sun.security.ssl.Handshaker.processLoop(Unknown Source)
at sun.security.ssl.Handshaker.process_record(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(Unknown Source)
at com.openshift.internal.client.httpclient.UrlConnectionHttpClient.request(UrlConnectionHttpClient.java:157)
... 15 more
Caused by: java.security.cert.CertificateException: No X509TrustManager implementation available
at sun.security.ssl.DummyX509TrustManager.checkServerTrusted(Unknown Source)
... 29 more
Similar SO posts such as this have offered little or no concrete help either.
Thanks.
please make sure you use latest JDK version since older ones had issues with ssh after heartbleed.
if you see something else please report issue in https://jira.jboss.org/jira/browse/JBIDE
Ok here's what I did and afterwards I was able to establish the Openshift connection from Eclipse Mars
I suspect it was an outdated windows installer problem because all I did was just attempt to re-install my Eclipse Mars which i got from here
NOTE - in my previous installation, I did not notice the update option in the installer so I installed without updating. Well, I believe that copy did not contain the Bug Fixes that solved this particular problem
However, when I attempted to re-install, i noticed the update icon at the top right corner (see image below) so I first of all updated before continuing with the installation process. I guess this just downloaded and applied all the bug fixes before installing.
Afterwards, I tried to establish the OpenShift connection from within my Eclipse Mars IDE without changing anything (...when I say 'anything', I mean my public/private key pair), and Voila, the connection got established.
I hope this helps anyone who runs into this problem and bumps into this post.

Runtime error on the exact same code on a different computer

I am working with a relativly unknown API. (ScrumWorks Pro) I am using it to export data into a SQL database. My issue is that I have moved my eclipse project from one computer to another and it stopped working. It continues to run fine on the old computer but I am getting the following error
Exception in thread "main" javax.xml.ws.WebServiceException: Failed to access the WSDL at: http://XXXXXXX:8080/scrumworks-api/api2/scrumworks?wsdl. It failed with:
Got Server returned HTTP response code: 503 for URL: http://XXXXXXXXXX:8080/scrumworks-api/api2/scrumworks?wsdl while opening stream from http://dxzbid01.zhi.com:8080/scrumworks-api/api2/scrumworks?wsdl.
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.tryWithMex(Unknown Source)
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(Unknown Source)
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.parseWSDL(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(Unknown Source)
at com.sun.xml.internal.ws.spi.ProviderImpl.createServiceDelegate(Unknown Source)
at javax.xml.ws.Service.<init>(Unknown Source)
at javax.xml.ws.Service.create(Unknown Source)
at com.danube.scrumworks.api2.ScrumWorksService.getConnection(ScrumWorksService.java:53)
at main.connectAPI(main.java:69)
at main.main(main.java:12)
Caused by: java.io.IOException: Got Server returned HTTP response code: 503 for URL: http://XXXXXXXXX:8080/scrumworks-api/api2/scrumworks?wsdl while opening stream from http://XXXXXXXXXXXXX.com:8080/scrumworks-api/api2/scrumworks?wsdl
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.createReader(Unknown Source)
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.resolveWSDL(Unknown Source)
... 11 more
Caused by: java.io.IOException: Server returned HTTP response code: 503 for URL: http://XXXXXXXXXXX:8080/scrumworks-api/api2/scrumworks?wsdl
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at java.net.URL.openStream(Unknown Source)
... 13 more
It looks like while it's running its failing to connect to the host. But it works completely fine with the exact same credentials on the other computer.
The magic words: Server returned HTTP response code: 503. The answer will be in your server logs.
From https://www.rfc-editor.org/rfc/rfc2616#section-10.5.4:
The server is currently unable to handle the request due to a
temporary overloading or maintenance of the server.
make sure that url
http://XXXXXXXXXX:8080/scrumworks-api/api2/scrumworks?wsdl
is accessible, if not able to access the 8080 port, check your firewall settings in that machine (allow that 8080 port to accessible)
The problem was that the newer computer had a newer version of Java installed which broke parts of the API.

Jersey client not working when run on Java Webstart

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.

NoSuchAlgorithmException when launching JNLP with Java 7

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")

Grails, Tomcat deployment error

I am trying to deploy a war file using tomcat 7 but I get these error.
Feb 26, 2013 3:42:48 PM org.apache.catalina.loader.WebappClassLoader loadClass
INFO: Illegal access: this web application instance has been stopped already. Could not load org.compass.core.lucene.engine.manager.DefaultLuceneSearchEngineIndexManager$11. The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact.
java.lang.IllegalStateException
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1599)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1558)
at org.compass.core.lucene.engine.manager.DefaultLuceneSearchEngineIndexManager.performScheduledTasks(DefaultLuceneSearchEngineIndexManager.java:426)
at org.compass.core.lucene.engine.manager.DefaultLuceneSearchEngineIndexManager$ScheduledIndexManagerRunnable.run(DefaultLuceneSearchEngineIndexManager.java:527)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(Unknown Source)
at java.util.concurrent.FutureTask.runAndReset(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.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)
The same war works fine on other machines but it gives this error on production machine. I tried changing the apache server and also jdk in the machine, but no effect. Can someone please tell me what is this error related to ?
This could be a file system access rights issue. Please make sure that the path exists and that tomcat has 'write' rights on the location where Searchable/Lucene is trying to create the index.

Categories