soap error when connecting to MS Exchange - java

I'm trying to connect to a MS Exchange server via soap but im getting the error below. This works from another computer with more or less the exakt same environment (minor version differences on eclipse etc) and we im using different AD accounts on the computers. Have anyone seen this before and could give a hint what might be wrong?
Part of the code that is needed for the exchange connection:
#WebServiceClient(name = "ExchangeWebService", targetNamespace = "http://schemas.microsoft.com/exchange/services/2006/messages", wsdlLocation = "mysourceadress/exchange.wsdl")
public class ExchangeWebService
extends Service
{
private final static URL EXCHANGEWEBSERVICE_WSDL_LOCATION;
private final static Logger logger = Logger.getLogger(se.ports.webservices.generatedWSDL.ExchangeWebService.class.getName());
static {
URL url = null;
try {
URL baseUrl = se.ports.webservices.generatedWSDL.ExchangeWebService.class.getResource(".");
url = new URL(baseUrl, "../exchange.wsdl");
} catch (MalformedURLException e) {
logger.warning("Failed to create URL for the wsdl Location:'"+ url +"', retrying as a local file");
logger.warning(e.getMessage());
}
EXCHANGEWEBSERVICE_WSDL_LOCATION = url;
}
public ExchangeWebService(URL wsdlLocation, QName serviceName) {
super(wsdlLocation, serviceName);
}
javax.xml.ws.soap.SOAPFaultException: Can't find input stream in message
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:146)
at $Proxy48.findItem(Unknown Source)
at se.ports.webservices.io.ItemTypeDAO.getFolderItems(ItemTypeDAO.java:44)
at se.ports.webservices.access.ExchangeFacade.getAllEmails(ExchangeFacade.java:38)
at se.ports.webservices.utils.ExchangeFacadeTest.getAllEmails(ExchangeFacadeTest.java:25)
at se.ports.webservices.ExchangeTests.test_single_exchangefacade_try_exchange_connection(ExchangeTests.java:34)
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 org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:699)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:891)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1215)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
at org.testng.TestRunner.privateRun(TestRunner.java:758)
at org.testng.TestRunner.run(TestRunner.java:613)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
at org.testng.SuiteRunner.run(SuiteRunner.java:240)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:87)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1170)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1095)
at org.testng.TestNG.run(TestNG.java:1007)
at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:109)
at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:202)
at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:173)
Caused by: java.lang.RuntimeException: Can't find input stream in message
at org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:116)
at org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:60)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:755)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2330)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:2192)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:2036)
at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:696)
at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:516)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:313)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:265)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
... 29 more
UPDATE:
So after a lot of trial and error testing I'v come to realize that the problem is that one of the computers run with jdk7, this fails, while the others run with jdk6 and that works great (i'v also added jdk7 on the working computers and then they also fail). I tried to solve this by re-running wsimport from jdk7 instead but that still gives the same error for jdk7 and totally breaks for the jdk6 computers. Anyone got a idé how to solve this?
So after a lot of trial and error testing I'v come to realize that the problem is that one of the computers run with jdk7, this fails, while the others run with jdk6 and that works great (i'v also added jdk7 on the working computers and then they also fail). I tried to solve this by re-running wsimport from jdk7 instead but that still gives the same error for jdk7 and totally breaks for the jdk6 computers. Anyone got a idé how to solve this?

Related

Authenticating an Impala JDBC Connection in a Kerberized environment

When trying to launch a Java Action within Oozie (CDH6.3.1) I get a GSS initiate failed. The code in question is pretty straight forward:
String impalaUrl = "jdbc:impala://pxyserver.global.ad:21050/default;SSL=1;AuthMech=1;KrbRealm=GLOBAL.AD;KrbHostFQDN=pxyserver.global.ad;KrbServiceName=Impala;sslTrustStore=/opt/cloudera/security/jks/truststore.jks;trustStorePassword=password";
Properties impalaProperties = new Properties();
impalaProperties.put("user", "svcaccount");
impalaProperties.put("password", "svcpassword");
impalaProperties.put("Driver", "com.cloudera.impala.jdbc41.Driver");
try {
setConnection(DriverManager.getConnection(impalaUrl , impalaProperties));
} catch (SQLException e) {
e.printStackTrace();
}
Running this gives the following stack trace:
java.sql.SQLException: [Cloudera][ImpalaJDBCDriver](500164) Error initialized or created transport for authentication: [Cloudera][ImpalaJDBCDriver](500169) Unable to connect to server: GSS initiate failed.
at com.cloudera.impala.hivecommon.api.HiveServer2ClientFactory.createTransport(Unknown Source)
at com.cloudera.impala.hivecommon.api.ServiceDiscoveryFactory.createClient(Unknown Source)
at com.cloudera.impala.hivecommon.core.HiveJDBCCommonConnection.establishConnection(Unknown Source)
at com.cloudera.impala.impala.core.ImpalaJDBCDSIConnection.establishConnection(Unknown Source)
at com.cloudera.impala.jdbc.core.LoginTimeoutConnection.connect(Unknown Source)
at com.cloudera.impala.jdbc.common.BaseConnectionFactory.doConnect(Unknown Source)
at com.cloudera.impala.jdbc.common.AbstractDriver.connect(Unknown Source)
at java.sql.DriverManager.getConnection(DriverManager.java:664)
at java.sql.DriverManager.getConnection(DriverManager.java:208)
I can fix this by kiniting with a keytab. However in our production environment Oozie runs this on one of many worker nodes and they do not have valid kerberos tickets. What are my options here? If possible I'd rather not kinit every day on each of our 40 worker nodes, is there a parameter I am missing here?
Thanks

Java 7 update 25 makes our java web start application fail with no logging

Since the java 7 update 25 launched by Oracle our application no longer functions.
Initially we got some warning about codebase & sercurity tags missing in the Manifest file, which we fixed.
The problem we now end up with is that in the Console we only get the following lines:
#### Java Web Start Error:
#### null
We also get an application Error dialog with the message: Unable to launch the application.
The details button gives the following details in the Exception:
java.lang.NullPointerException
at com.sun.jnlp.JNLPClassLoader.getPermissions(Unknown Source)
at java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:206)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
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 com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at desktop.DesktopProxySelector.<init>(DesktopProxySelector.java:24) <- code smippet below
at desktop.Main.main(Main.java:139) <- code smippet below
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.sun.javaws.Launcher.executeApplication(Unknown Source)
at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Thread.java:724)
The relevant code parts are:
Desktop.Main.main
/**
* Main method, starts the application
*/
public static void main(String[] args) {
System.setProperty("java.net.useSystemProxies", "true");
//Logger.getLogger("httpclient.wire.header.level").setLevel(Level.FINEST);
//Logger.getLogger("org.apache.commons.httpclient.level").setLevel(Level.FINEST);
java.net.ProxySelector.setDefault(new DesktopProxySelector(java.net.ProxySelector.getDefault()));
(The last line is line number 139)
desktop.DesktopProxySelector:
public class DesktopProxySelector extends ProxySelector {
public DesktopProxySelector(ProxySelector defaultSelector) {
URI httpsUri = new CentralConfigurationService().getCentralLocation();
(The last line is line number 24 where the exception occures)
Can someone give us some clues hints (or better a solution) for this new behaviour of java caused by this 'minor' update.
When we run the application straight from the cli using java -jar Desktop.jar the application wil run file, so the issue has clearly something todo with the changes in java web start.
#trashgod: the error clearly has something to do with the Permissions change in 7u25, since the NullPointerException occurs in com.sun.jnlp.JNLPClassLoader.getPermissions.
Just to explain what I think happens (I am a colleague of Wouter):
desktop.Main instantiates a desktop.DesktopProxySelector (our class),
desktop.DesktopProxySelector instantiates desktop.configuration.CentralConfigurationService
desktop.configuration.CentralConfigurationService instantiates a java.net.URI.
On the first line of the DesktopProxySelector init where the CentralConfigurationService is instantiated the getPermissions method, called by the JNLPClassLoader, throws the NullPointerException. So something is going wrong while loading the CentralConfigurationService class by java webstart with getting the permissions for the class. Could that have anything to do with the fact that a URI class is instantiated, which requires extra permissions (a connection to a remote uri is setup)?
Eventually the problem was solved.
The problem was caused between a mismatch in the included jar files in the main MANIFEST.MF file vs the jar files mentioned in the launch.jnlp.
Apperently it is now required to have all jar files that will be used also be present in the launch.jnlp file.
(In the past it was decided to keep this file manually in sink, which obviously was not always maintained in a propper way. Now this process is automated, so the problem should no longer happen to us.)

Error while initializing metro webservice client

Since few weeks we have some trouble with our external test environment (which is not operated by us). Our webapplication is connected to a soap webservice.
We are using:
metro 2.1.1 for the webservice client
java-1.5.0-ibm-1.5.0.12.4 is installed on the test environment.
tomcat version: 5.5.27
The first time trying to initialize the client on this environment, we are getting the following exception (only on this environment):
java.lang.ExceptionInInitializerError
at java.lang.J9VMInternals.initialize(J9VMInternals.java:218)
at javax.xml.ws.Service.<init>(Service.java:57)
at com.xxx.xxx.xxx.xxxy.client.MyServiceRequestProvider_Service.<init>(MyServiceRequestProvider_Service.java:50)
at com.xxx.xxx.client.MyServiceRequester.<init>(MyServiceRequester.java:63)
at com.xxx.xxx.action.CheckAction.execute(CheckAction.java:120)
at com.xxx.xxx.webservice.validators.ApplicationValidatorImpl.validateCheck(ApplicationValidatorImpl.java:403)
at com.xxx.xxx.webservice.validators.ApplicationValidatorImpl$$EnhancerByGuice$$55e5e7ad.CGLIB$validateCheck$6(<generated>)
at com.xxx.xxx.webservice.validators.ApplicationValidatorImpl$$EnhancerByGuice$$55e5e7ad$$FastClassByGuice$$380e5720.invoke(<generated>)
at com.google.inject.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:187)
at com.google.inject.InterceptorStackCallback$InterceptedMethodInvocation.proceed(InterceptorStackCallback.java:66)
at com.xxx.xxx.webservice.guice.interceptor.ValidationErrorInterceptor.invoke(ValidationErrorInterceptor.java:21)
at com.google.inject.InterceptorStackCallback$InterceptedMethodInvocation.proceed(InterceptorStackCallback.java:66)
at com.xxx.xxx.webservice.guice.interceptor.PersistenzInterceptor.invoke(PersistenzInterceptor.java:35)
at com.google.inject.InterceptorStackCallback$InterceptedMethodInvocation.proceed(InterceptorStackCallback.java:66)
at com.google.inject.InterceptorStackCallback.intercept(InterceptorStackCallback.java:45)
at com.xxx.xxx.webservice.validators.ApplicationValidatorImpl$$EnhancerByGuice$$55e5e7ad.validateCheck(<generated>)
at com.xxx.xxx.webservice.endpoint.xxxWS.order(xxxWS.java:99)
at com.xxx.xxx.webservice.endpoint.xxxWS$$EnhancerByGuice$$3bd5ffaf.CGLIB$order$1(<generated>)
at com.xxx.xxx.webservice.endpoint.xxxWS$$EnhancerByGuice$$3bd5ffaf$$FastClassByGuice$$806bc0a0.invoke(<generated>)
at com.google.inject.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:187)
at com.google.inject.InterceptorStackCallback$InterceptedMethodInvocation.proceed(InterceptorStackCallback.java:66)
at com.xxx.xxx.webservice.guice.interceptor.RsvAgeManipulatorInterceptor.invoke(RsvAgeManipulatorInterceptor.java:95)
at com.google.inject.InterceptorStackCallback$InterceptedMethodInvocation.proceed(InterceptorStackCallback.java:66)
at com.xxx.xxx.webservice.guice.interceptor.ValueConverterInterceptor.invoke(ValueConverterInterceptor.java:101)
at com.google.inject.InterceptorStackCallback$InterceptedMethodInvocation.proceed(InterceptorStackCallback.java:66)
at com.xxx.xxx.webservice.guice.interceptor.DataValidationInterceptor.invoke(DataValidationInterceptor.java:31)
at com.google.inject.InterceptorStackCallback$InterceptedMethodInvocation.proceed(InterceptorStackCallback.java:66)
at com.xxx.xxx.webservice.guice.interceptor.UserValidationInterceptor.invoke(UserValidationInterceptor.java:36)
at com.google.inject.InterceptorStackCallback$InterceptedMethodInvocation.proceed(InterceptorStackCallback.java:66)
at com.xxx.xxx.webservice.guice.interceptor.SessionInitializerInterceptor.invoke(SessionInitializerInterceptor.java:65)
at com.google.inject.InterceptorStackCallback$InterceptedMethodInvocation.proceed(InterceptorStackCallback.java:66)
at com.google.inject.InterceptorStackCallback.intercept(InterceptorStackCallback.java:45)
at com.xxx.xxx.webservice.endpoint.xxxWS$$EnhancerByGuice$$3bd5ffaf.order(<generated>)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:618)
at com.sun.xml.ws.api.server.InstanceResolver$1.invoke(InstanceResolver.java:250)
at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:150)
at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:261)
at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:100)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:641)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:600)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:585)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:482)
at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:314)
at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:608)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:259)
at com.sun.xml.ws.transport.http.servlet.ServletAdapter.invokeAsync(ServletAdapter.java:207)
at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doGet(WSServletDelegate.java:159)
at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doPost(WSServletDelegate.java:194)
at com.sun.xml.ws.transport.http.servlet.WSServlet.doPost(WSServlet.java:80)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:200)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:775)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:704)
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:897)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685)
at java.lang.Thread.run(Thread.java:811)
Caused by: java.lang.SecurityException: java.util.ServiceLoader - protected system package 'java.util'
at java.lang.ClassLoader.checkClassName(ClassLoader.java:213)
at java.lang.ClassLoader.defineClass(ClassLoader.java:255)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:151)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:600)
at java.net.URLClassLoader.access$400(URLClassLoader.java:124)
at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:1055)
at java.security.AccessController.doPrivileged(AccessController.java:274)
at java.net.URLClassLoader.findClass(URLClassLoader.java:492)
at java.lang.ClassLoader.loadClass(ClassLoader.java:640)
at java.lang.ClassLoader.loadClass(ClassLoader.java:632)
at java.lang.ClassLoader.loadClass(ClassLoader.java:606)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1346)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1205)
at java.lang.Class.forNameImpl(Native Method)
at java.lang.Class.forName(Class.java:130)
at javax.xml.ws.spi.Provider.<clinit>(Provider.java:55)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:196)
... 68 more
Further attempts to initialize this client results in:
2012-09-26 11:34:56,016 ERROR [TP-Processor7] com.xxx.xxx.client.MyServiceRequester#<init>(65): Error initialising MyServiceRequestProvider_Service
java.lang.NoClassDefFoundError: javax.xml.ws.spi.Provider (initialization failure)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:134)
at javax.xml.ws.Service.<init>(Service.java:57)
...
It seems that there are some security issues within the metro Provider class.
I think the following snipped of the class javax.xml.ws.spi.Provider of metro is the source of the failure:
static {
Method tLoadMethod = null;
Method tIteratorMethod = null;
try {
Class<?> clazz = Class.forName("java.util.ServiceLoader");
tLoadMethod = clazz.getMethod("load", Class.class);
tIteratorMethod = clazz.getMethod("iterator");
} catch(ClassNotFoundException ce) {
// Running on Java SE 5
} catch(NoSuchMethodException ne) {
// Shouldn't happen
}
loadMethod = tLoadMethod;
iteratorMethod = tIteratorMethod;
}
It seems that instead of throwing an ClassNotFoundException the Classloader throws an SecurityException, which is not catched by the
static initializer.
What can be the cause of this behaviour (some policy settings?) and how can we prevent this. The application is running on our local test environment, and was running on the external environment too. The external provider denies any changes of the environment.
Is this behaviour IBM-JDK specific ?
EDIT:
I found the following in the JDK 5.0 API class java.security.SecureClassLoader :
SecurityException - if an attempt is made to add this class to a
package that contains classes that were signed by a different set of
certificates than this class, or if the class name begins with
"java.".
But souldn't this happen to all Metro clients running on tomcat ?
EDIT:
Thanks a lot for the advice! There is actually the path of a JDK 1.6 rt.jar in the classpath. And therefore the ServiceLoader class is found but not allowed to load within the Provider.
Thanks to Sean,
There actually was the path of a JDK 1.6 rt.jar in the classpath. And therefore the ServiceLoader class is found but not allowed to load within the Provider.

App Engine URLFetch service called from Clojure gives AccessControlException

I'm trying to build a simple web widget in Clojure which should fetch a Picasa feed, retrieve the thumbnail URLs from there, and return HTML which will be inserted into a page (using JQuery AJAX call). The Picasa feed has a https://... url.
Everything works when I run it in a local Jetty instance using mvn jetty:run ; however when I try to run in a local GAE instance (mvn gae:run) it fails with an AccessControlException.
I've read the GAE documentation, but this states that for URLFetch from Java one should just use the normal Java URLConnection class where Google will provide their own implementation. As far as I can see I'm following their example to the letter, only using Clojure/Java interop.
Google example code looks like this:
import java.net.URL;
// (other imports omitted)
try {
URL url = new URL("http://www.example.com/atom.xml");
BufferedReader reader = new BufferedReader(new InputStreamReader(url.openStream()));
String line;
while ((line = reader.readLine()) != null) {
// ...
}
Interestingly this is calling openStream directly on the URL although elsewhere the documentation mentions to use UrlConnection. I've tried both, but the result is the same.
My corresponding Clojure code, using openConnection:
(if (.startsWith str-url "https://picasaweb.google.com")
(let [feed-url (java.net.URL. str-url)
connection (.openConnection feed-url)
xmltags (xml-seq (parse (.openStream connection)))]
; ...
When I run this in GAE I get the following stack trace (truncated)
java.lang.ExceptionInInitializerError
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
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 org.mortbay.jetty.servlet.Holder.newInstance(Holder.java:153)
at org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:428)
at org.mortbay.jetty.servlet.ServletHolder.getServlet(ServletHolder.java:339)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166)
at com.google.appengine.tools.development.HeaderVerificationFilter.doFilter(HeaderVerificationFilter.java:35)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at com.google.appengine.api.blobstore.dev.ServeBlobFilter.doFilter(ServeBlobFilter.java:60)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter(TransactionCleanupFilter.java:43)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at com.google.appengine.tools.development.StaticFileFilter.doFilter(StaticFileFilter.java:122)
And finally at the bottom:
Caused by: java.security.AccessControlException: access denied (java.security.SecurityPermission getProperty.ssl.KeyManagerFactory.algorithm)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:374)
at java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at com.google.appengine.tools.development.DevAppServerFactory$CustomSecurityManager.checkPermission(DevAppServerFactory.java:252)
at java.security.Security.getProperty(Security.java:725)
at org.eclipse.jetty.util.ssl.SslContextFactory.<clinit>(SslContextFactory.java:92)
... 74 more
I have been Googling to see if there is any setting I should add in appengine-web.xml or somewhere else, but I see nothing. Everything I read tells me this should "just work", but it doesn't.
Any advice is most welcome; I can post full source or a full stacktrace if desired, although I think the above is pretty much the pertinent bits.
openStream() is shorthand for openConnection().getInputStream(), where openConnection() returns URLConnection.

Axis 1.4 AxisFault Premature end of file

I get this error when I use my autogenerated ServiceBindingStub.java. WebService side is working ok, so this error must be in code, but code is autogenerated, so I cannot know why it doesn't work. Some other calls work fine, but this doesn't. This call included updating, while other working calls are just fetching data from WebService.
AxisFault
faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
faultSubcode:
faultString: org.xml.sax.SAXParseException: Premature end of file.
faultActor:
faultNode:
faultDetail:
{http://xml.apache.org/axis/}stackTrace:org.xml.sax.SAXParseException: Premature end of file.
at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source)
at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at org.apache.xerces.impl.XMLVersionDetector.determineDocVersion(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at javax.xml.parsers.SAXParser.parse(Unknown Source)
at org.apache.axis.encoding.DeserializationContext.parse(DeserializationContext.java:227)
at org.apache.axis.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:696)
at org.apache.axis.Message.getSOAPEnvelope(Message.java:435)
at org.apache.axis.handlers.soap.MustUnderstandChecker.invoke(MustUnderstandChecker.java:62)
at org.apache.axis.client.AxisClient.invoke(AxisClient.java:206)
at org.apache.axis.client.Call.invokeEngine(Call.java:2784)
at org.apache.axis.client.Call.invoke(Call.java:2767)
at org.apache.axis.client.Call.invoke(Call.java:2443)
at org.apache.axis.client.Call.invoke(Call.java:2366)
at org.apache.axis.client.Call.invoke(Call.java:1812)
This happens when service you are connecting to does not return SOAP response, but some text or HTML. Try opening the URL in the browser or use some SOAP debugger like SOAP UI to see what is returned from the service.
I once had the same problem. In my case, I received messages with 'binary data' between tags (imagery). Axis used a fixed size buffer to read the data, once the buffer was full it just proceeded and ran out of sync.
In fact, you should be able to find the tag or part in the xml file by debugging the stub code step by step. No guarantee, that the issue will can be solved easily but it might give you a hint that the (a) stub is not generated correctly or (b) the xml file is just not well-formed or valid against the schema that has been used to generate the stub.
Good luck! (I didn't solve my issue..)
I just had (and solved) this problem, following Superfilin's answer. In the end, the problem turned out to be that I hadn't added a <beanMapping> for one of the classes I was returning in my deployment.wsdd file. Any time the response would have included that class, I'd get a completely empty message body instead.
Even we have faced the same issue. But there are some special characters in the content. We removed those special characters and it worked fine.

Categories