I am using WSO2 DSS 3.2.1 and trying to configure an output event trigger with the following event sink URL:
jms:/ MyQueueName?transport.jms.DestinationType=queue&transport.jms.ContentTypeProperty=Content-Type&java.naming.provider.url=tcp://10.11.11.15:61616&java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory&transport.jms.ConnectionFactoryType=queue&transport.jms.ConnectionFactoryJNDIName=QueueConnectionFactory
but unable to make WSO2 DSS work in the way as expected:
TID: [0] [DSS] [2014-10-04 05:33:55,576] INFO {org.apache.axis2.deployment.DeploymentEngine} - Deploying Web service: EventingSample.dbs - file:/C:/WSO2DS~1.1/bin/../repository/deployment/server/dataservices/samples/EventingSample.dbs {org.apache.axis2.deployment.DeploymentEngine}
TID: [0] [DSS] [2014-10-04 05:34:06,371] ERROR {org.apache.axis2.description.ClientUtils} - The system cannot infer the transport information from the jms:/MyQueueName?transport.jms.DestinationType=queue&transport.jms.ContentTypeProperty=Content-Type&java.naming.provider.url=tcp://10.11.11.15:61616&java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory&transport.jms.ConnectionFactoryType=queue&transport.jms.ConnectionFactoryJNDIName=QueueConnectionFactory URL. {org.apache.axis2.description.ClientUtils}
TID: [0] [DSS] [2014-10-04 05:34:06,371] ERROR {org.wso2.carbon.event.ws.internal.notify.WSEventDispatcher} - Unable to send message {org.wso2.carbon.event.ws.internal.notify.WSEventDispatcher}
org.apache.axis2.AxisFault: The system cannot infer the transport information from the jms:/ MyQueueName?transport.jms.DestinationType=queue&transport.jms.ContentTypeProperty=Content-Type&java.naming.provider.url=tcp://10.11.11.15:61616&java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory&transport.jms.ConnectionFactoryType=queue&transport.jms.ConnectionFactoryJNDIName=QueueConnectionFactory URL.
at org.apache.axis2.description.ClientUtils.inferOutTransport(ClientUtils.java:81)
at org.apache.axis2.client.OperationClient.prepareMessageContext(OperationClient.java:288)
at org.apache.axis2.description.OutOnlyAxisOperationClient.executeImpl(OutOnlyAxisOperation.java:249)
at org.apache.axis2.client.OperationClient.execute(OperationClient.java:149)
at org.apache.axis2.client.ServiceClient.fireAndForget(ServiceClient.java:511)
at org.apache.axis2.client.ServiceClient.fireAndForget(ServiceClient.java:488)
at org.wso2.carbon.event.ws.internal.notify.WSEventDispatcher.sendNotification(WSEventDispatcher.java:96)
at org.wso2.carbon.event.ws.internal.notify.WSEventDispatcher.notify(WSEventDispatcher.java:66)
at org.wso2.carbon.event.core.internal.notify.CarbonNotificationManager.sendNotification(CarbonNotificationManager.java:62)
at org.wso2.carbon.event.core.internal.delivery.Worker.run(Worker.java:52)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
I have checked/confirmed that nothing is wrong on the Active MQ side, including ip address, port number, and queue name. And org.apache.axis2.transport.jms.JMSSender is also enabled. Appreciate any help on this issue.
By the way, I also took a working JMS endpoint URI already properly tested with WSO2 ESB but still got the same error with WSO2 DSS. It seems to me that something is wrong with WSO2 DSS JMS transport.
Above error was occurring because you have enabled the org.apache.axis2.transport.jms.JMSSender in the axis2.xml but not the axis2-client.xml. To use jms sender you need to enable the jms transport in axis2_client.xml.
I have retested the same use case with WSO2 DSS 3.2.2 and got the same error again .... a buggy product .... not recommend for a serious usage.
Related
A colleague of mine wants to automate their JBoss (JBoss EAP v7.4.0) deployments.
So far the process they followed manually was:
Shutdown Jboss entirely
Copy the new .war file under /jboss-eap-7.4.0/standalone/deployments directory
Restart the server by executing standalone.sh
This process, although a bit 'dump', manages to deploy the application with no issues.
I on the other hand, tried to make use of JBoss's auto-redeployment feature, so I simply pasted the new .war file under the /jboss-eap-7.4.0/standalone/deployments directory.
JBoss indeed picks up the new .war and automatically starts the redeployment process.
From the server.log file, it seems at first that the application deploys successfully.
However when I try to access it from my browser, it crashes and gives a code 500 response (See error logs at the end of the post). The expected behavior would be to redeploy me to keycloak in order to login.
The exact same error occurs if I try to manually undeploy and deploy the .war from the jboss.cli.
Any hints on the issue?
I can't figure out if the error is on the server or the application side.
It seems a bit odd that it should require a full JBoss server restart in order for the application to be properly deployed.
Thank you in advance.
Server logs:
2022-06-14 17:22:25,850 WARN [org.apache.jcp.xml.dsig.internal.dom.DOMReference] (default task-1) The input bytes to the digest operation are null. This may be due to a problem with the Reference URI or its Transforms.
2022-06-14 17:22:25,879 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /myapplication: java.lang.RuntimeException: Could not create authentication request.
at org.keycloak.keycloak-saml-adapter-core#15.0.2//org.keycloak.adapters.saml.AbstractInitiateLogin.challenge(AbstractInitiateLogin.java:64)
at org.keycloak.keycloak-saml-wildfly-elytron-adapter#15.0.2//org.keycloak.adapters.saml.elytron.ElytronHttpFacade.noAuthenticationInProgress(ElytronHttpFacade.java:123)
at org.keycloak.keycloak-saml-wildfly-elytron-adapter#15.0.2//org.keycloak.adapters.saml.elytron.KeycloakHttpServerAuthenticationMechanism.evaluateRequest(KeycloakHttpServerAuthenticationMechanism.java:125)
at org.wildfly.security.elytron-private#1.15.3.Final-redhat-00001//org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:119)
at org.wildfly.security.elytron-private#1.15.3.Final-redhat-00001//org.wildfly.security.http.util.SocketAddressCallbackServerMechanismFactory$1.evaluateRequest(SocketAddressCallbackServerMechanismFactory.java:82)
at org.wildfly.security.elytron-private#1.15.3.Final-redhat-00001//org.wildfly.security.auth.server.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:85)
at org.wildfly.security.elytron-private#1.15.3.Final-redhat-00001//org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:326)
at org.wildfly.security.elytron-private#1.15.3.Final-redhat-00001//org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$800(HttpAuthenticator.java:301)
at org.wildfly.security.elytron-private#1.15.3.Final-redhat-00001//org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:94)
at org.wildfly.security.elytron-web.undertow-server#1.9.0.Final-redhat-00001//org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:99)
at org.wildfly.security.elytron-web.undertow-server-servlet#1.9.0.Final-redhat-00001//org.wildfly.elytron.web.undertow.server.servlet.ServletSecurityContextImpl.authenticate(ServletSecurityContextImpl.java:115)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at org.wildfly.security.elytron-web.undertow-server-servlet#1.9.0.Final-redhat-00001//org.wildfly.elytron.web.undertow.server.servlet.CleanUpHandler.handleRequest(CleanUpHandler.java:38)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow#7.4.0.GA-redhat-00005//org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow#7.4.0.GA-redhat-00005//org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.SendErrorPageHandler.handleRequest(SendErrorPageHandler.java:52)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow#7.4.0.GA-redhat-00005//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow#7.4.0.GA-redhat-00005//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow#7.4.0.GA-redhat-00005//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow#7.4.0.GA-redhat-00005//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow#7.4.0.GA-redhat-00005//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.server.Connectors.executeRootHandler(Connectors.java:387)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:841)
at org.jboss.threads#2.4.0.Final-redhat-00001//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads#2.4.0.Final-redhat-00001//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
at org.jboss.threads#2.4.0.Final-redhat-00001//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads#2.4.0.Final-redhat-00001//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at org.jboss.xnio#3.8.4.Final-redhat-00001//org.xnio.XnioWorker$WorkerThreadFactory$1$1.run(XnioWorker.java:1280)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: org.apache.xml.serializer.utils.WrappedRuntimeException: class org.apache.xml.serializer.ToXMLSAXHandler cannot be cast to class org.apache.xml.serializer.SerializationHandler (org.apache.xml.serializer.ToXMLSAXHandler is in unnamed module of loader 'deployment.myapplication.war' #15a25903; org.apache.xml.serializer.SerializationHandler is in unnamed module of loader 'deployment.myapplication.war' #68ae4310)
at deployment.myapplication.war//org.apache.xml.serializer.SerializerFactory.getSerializer(SerializerFactory.java:179)
at deployment.myapplication.war//org.apache.xalan.transformer.TransformerIdentityImpl.createResultContentHandler(TransformerIdentityImpl.java:261)
at deployment.myapplication.war//org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:330)
at org.keycloak.keycloak-saml-core#15.0.2//org.keycloak.saml.common.util.DocumentUtil.getNodeAsString(DocumentUtil.java:228)
at org.keycloak.keycloak-saml-core#15.0.2//org.keycloak.saml.common.util.DocumentUtil.getDocumentAsString(DocumentUtil.java:207)
at org.keycloak.keycloak-saml-core#15.0.2//org.keycloak.saml.BaseSAML2BindingBuilder.getSAMLResponse(BaseSAML2BindingBuilder.java:311)
at org.keycloak.keycloak-saml-core#15.0.2//org.keycloak.saml.BaseSAML2BindingBuilder.buildHtmlPostResponse(BaseSAML2BindingBuilder.java:307)
at org.keycloak.keycloak-saml-core#15.0.2//org.keycloak.saml.BaseSAML2BindingBuilder$BasePostBindingBuilder.getHtmlRequest(BaseSAML2BindingBuilder.java:172)
at org.keycloak.keycloak-saml-adapter-core#15.0.2//org.keycloak.adapters.saml.SamlUtil.sendSaml(SamlUtil.java:45)
at org.keycloak.keycloak-saml-adapter-core#15.0.2//org.keycloak.adapters.saml.profile.AbstractSamlAuthenticationHandler$3.sendAuthnRequest(AbstractSamlAuthenticationHandler.java:622)
at org.keycloak.keycloak-saml-adapter-core#15.0.2//org.keycloak.adapters.saml.AbstractInitiateLogin.challenge(AbstractInitiateLogin.java:61)
I am using vert.x java client for connecting solace server. While using SSL certificates for connectivity, receiving below SSL handshake error.I am using settrustall(true) in my code. Could someone help with cause for the error and resolution.
Below is the error:
SEVERE: Unhandled exception
java.lang.IllegalStateException: Bridge was not successfully started
at io.vertx.amqpbridge.impl.AmqpBridgeImpl.createConsumer(AmqpBridgeImpl.java:174)
at com.gtaa.nch.amqp.MyErrorResponse.lambda$2(MyErrorResponse.java:241)
at io.vertx.amqpbridge.impl.AmqpBridgeImpl.lambda$startImpl$5(AmqpBridgeImpl.java:157)
at io.vertx.proton.impl.ProtonClientImpl$ConnectCompletionHandler.handle(ProtonClientImpl.java:122)
at io.vertx.proton.impl.ProtonClientImpl.lambda$connectNetClient$1(ProtonClientImpl.java:97)
at io.vertx.core.net.impl.NetClientImpl.lambda$connect$2(NetClientImpl.java:113)
at io.vertx.core.net.impl.NetClientImpl.doFailed(NetClientImpl.java:268)
at io.vertx.core.net.impl.NetClientImpl.lambda$failed$12(NetClientImpl.java:264)
at io.vertx.core.impl.ContextImpl.lambda$wrapTask$2(ContextImpl.java:337)
at io.vertx.core.impl.ContextImpl.executeFromIO(ContextImpl.java:195)
at io.vertx.core.net.impl.NetClientImpl.failed(NetClientImpl.java:264)
at io.vertx.core.net.impl.NetClientImpl.lambda$null$4(NetClientImpl.java:208)
at io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:507)
at io.netty.util.concurrent.DefaultPromise.notifyListeners0(DefaultPromise.java:500)
at io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:479)
at io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:420)
at io.netty.util.concurrent.DefaultPromise.tryFailure(DefaultPromise.java:122)
at io.netty.handler.ssl.SslHandler.notifyHandshakeFailure(SslHandler.java:1535)
at io.netty.handler.ssl.SslHandler.setHandshakeFailure(SslHandler.java:1521)
at io.netty.handler.ssl.SslHandler.setHandshakeFailure(SslHandler.java:1493)
at io.netty.handler.ssl.SslHandler.handleUnwrapThrowable(SslHandler.java:1186)
at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1165)
at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1194)
at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:489)
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:428)
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:265)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1359)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:935)
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:141)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:645)
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:580)
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:497)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:459)
at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:886)
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.lang.Thread.run(Unknown Source)
This is in all likelihood an SSL configuration problem.
Check your bridge configuration targets the AMQP SSL port on the Solace broker, not the plain text port (defaults are 5671 rather than 5672)
Check the broker SSL configuration is valid (is the AMQP SSL service showing Operational UP?
Use sdkperf_jmsamqp to check that your SSL connection, certificates etc are valid.
i'm new to Mule and i'm trying to use the dropbox connector with my web application. I'm trying to make a flow to authorize the current user to upload a file, however the flow doesn't even run. All i did was set up an http connector, then placed the dropbox connector and set it up. I used the graphic interface but here is the code:
<?xml version="1.0" encoding="UTF-8"?>
<http:listener-config name="HTTP_Listener_Configuration" host="localhost" port="8081" doc:name="HTTP Listener Configuration"/>
<dropbox:config name="Dropbox" appKey="xxxxxxxxxxx" appSecret="xxxxxxxxxxx" doc:name="Dropbox">
<dropbox:oauth-callback-config domain="http://localhost" localPort="8081" path="callback" remotePort="8081"/>
</dropbox:config>
<dropbox:config name="Dropbox1" appKey="xxxxxxxxxxx" appSecret="xxxxxxxxxxx" doc:name="Dropbox">
<dropbox:oauth-callback-config domain="http://localhost" localPort="8081" remotePort="8081" path="callback"/>
</dropbox:config>
<flow name="dropbxFlow">
<http:listener config-ref="HTTP_Listener_Configuration" path="/callback/" doc:name="HTTP"/>
<dropbox:authorize config-ref="Dropbox" doc:name="Dropbox"/>
</flow>
i keep getting this error when i run :
INFO 2015-05-05 16:09:53,688 [Mule.app.deployer.monitor.1.thread.1] org.mule.lifecycle.AbstractLifecycleManager: Starting model: _muleSystemModel
INFO 2015-05-05 16:09:53,688 [Mule.app.deployer.monitor.1.thread.1] org.mule.construct.FlowConstructLifecycleManager: Starting flow: dropbxFlow
INFO 2015-05-05 16:09:53,688 [Mule.app.deployer.monitor.1.thread.1] org.mule.processor.SedaStageLifecycleManager: Starting service: dropbxFlow.stage1
ERROR 2015-05-05 16:09:53,694 [Mule.app.deployer.monitor.1.thread.1] org.mule.modules.dropbox.process.DefaultHttpCallback: Could not find connector with name 'connector.http.mule.default'
INFO 2015-05-05 16:09:53,694 [Mule.app.deployer.monitor.1.thread.1] org.mule.processor.SedaStageLifecycleManager: Stopping service: dropbxFlow.stage1
ERROR 2015-05-05 16:09:53,890 [Mule.app.deployer.monitor.1.thread.1] org.mule.module.launcher.application.DefaultMuleApplication: null
org.mule.api.DefaultMuleException: Could not find connector with name 'connector.http.mule.default'
This only happens when i use the Authorize attribute on the dropbox connector, as it needs a callback uri(which i think it the problem here), the callback http endpoint isn't being set up. Any insight would be greatly appreciated.
These are normal version issues with some of the libraries. I had the same issue while using dropbox connector 3.3.0 so after a lot of R&D I figured out where was actually the problem. I went to pom.xml, there I changed version to 3.3.3 and all was fine and running and no more issue at all.
<dependency>
<groupId>org.mule.modules</groupId>
<artifactId>mule-module-dropbox</artifactId>
<version>3.3.3</version>
</dependency>
And regarding that "no callback uri", you should have same redirect uri in dropbox developer account and in dropbox global element Oauth configuration.
Let's say you have provided "http://localhost:8081/callback" as Redirect URI in Dropbox account so your Oauth configuration should be like as following
Domain : localhost
Local Port : 8081
Remote Port : 8081
Path : callback
I am developing a SOAP client with Apache CXF. One method of the request returns me this stack in the client. With SOAPUI the same request returns me the expected response. Maybe I lost a library in JNLP? Maybe it is a binding problem?
2013-11-08 15:31:16,593 ERROR [es.isoftsanidad.eprescribe.comunclient.paneles.buscadorfarmacos.ListadoPF5Controlador] [setListaObjetos] Error en establecer el listado de los objetos
javax.xml.ws.soap.SOAPFaultException: Couldn't create SOAP message due to exception: Unable to create StAX reader or writer
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:157)
at
.....
Caused by: org.apache.cxf.binding.soap.SoapFault: Couldn't create SOAP message due to exception: Unable to create StAX reader or writer
at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.unmarshalFault(Soap11FaultInInterceptor.java:84)
at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:51)
at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:40)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:113)
at org.apache.cxf.jaxws.handler.soap.SOAPHandlerInterceptor.handleMessage(SOAPHandlerInterceptor.java:140)
at org.apache.cxf.jaxws.handler.soap.SOAPHandlerInterceptor.handleMessage(SOAPHandlerInterceptor.java:71)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:835)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1606)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1502)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1309)
at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:627)
at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:565)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:474)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:377)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:330)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135)
Check the logs on the server side. This is the message that the server is sending back in it's SOAP fault. Thus, something is happening on the server side that needs investigating.
I am using an embedded Jetty server to provide Web Services (using Jetty-JAXWS2-SPI to allow Jetty to serve the requests) and I am seeing the following errors when a connection terminates from my JAX-WS test client (generated by wsimport):
11:32:54.544 [pool-1-thread-5] DEBUG com.mycompany.SomeClass - EOF
org.eclipse.jetty.io.EofException: null
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:321) ~[jetty-http-7.3.1.v20110307.jar:7.3.1.v20110307]
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:214) ~[jetty-http-7.3.1.v20110307.jar:7.3.1.v20110307]
at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:411) ~[jetty-server-7.3.1.v20110307.jar:7.3.1.v20110307]
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:526) ~[jetty-io-7.3.1.v20110307.jar:7.3.1.v20110307]
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:41) [jetty-io-7.3.1.v20110307.jar:7.3.1.v20110307]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [na:1.6.0_24]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [na:1.6.0_24]
at java.lang.Thread.run(Thread.java:662) [na:1.6.0_24]
Even though these are not important errors (logged at DEBUG level) and I only see them from my test client, not from soapUI or the 'real' (.NET client), I would rather not see them at all.
I guess the problem is caused by the socket behavior within the JAX-WS client? Is there any way to influence the socket behavior to avoid this issue?
Other information:
Others have reported this issue on the Jetty mailing list, also when providing Web Services using Jetty-JAXWS2-SPI.
I am using JDK 1.6.0_24 and the JAX-WS implementation it contains.
I am using Jetty 7.3.1-20110307