Re: getResourceAsStream in OSGi bundle not working with Camel 2.19

[rsteppac2]

rsteppac2 wrote
> What I could do, I guess, is to wrap the library's factory code in my own
> and set the context classloader of the current thread to the application
> context class loader before delegating to the actual factory.

This worked. Though instead of the application classloader I used the
classloader of the factory class. 


Ralf



--
View this message in context: 
http://camel.465427.n5.nabble.com/getResourceAsStream-in-OSGi-bundle-not-working-with-Camel-2-19-tp5807017p5807197.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: getResourceAsStream in OSGi bundle not working with Camel 2.19

[rsteppac2]

Hello Claus,

thanks for your suggestions!

it is 3rd party library code, so I cannot just change it. What I could do, I
guess, is to wrap the library's factory code in my own and set the context
classloader of the current thread to the application context class loader
before delegating to the actual factory.

What I do not quite understand is why the code works consistently with Camel
versions < 2.19.0 and consistently not with >= 2.19.0. 
And why would the classloader of the thread that builds the blueprint
context based on the XML in my bundle not have access to a resource that is
at the root of that very same bundle? 


Thanks again.
Ralf



--
View this message in context: 
http://camel.465427.n5.nabble.com/getResourceAsStream-in-OSGi-bundle-not-working-with-Camel-2-19-tp5807017p5807021.html
Sent from the Camel - Users mailing list archive at Nabble.com.

getResourceAsStream in OSGi bundle not working with Camel 2.19

[rsteppac2]

Hello all,

I am trying to migrate to Camel 2.19 and came across an in issue where
loading resources from an OSGi bundle stopped working. The issue is not
reproducible with versions 2.18.4 and lower. I tried Karaf 4.0.9 and 4.1.1;
the Karaf version does not appear to matter.

In my case the resource is at the root of the bundle that has the code
trying to load it as a stream. The calling code is in a library embed in the
bundle JAR. Whether I inline the library or not does not seem to matter. The
call that now returns null instead of a stream instance is: 

Thread.currentThread().getContextClassLoader().getResourceAsStream("httl.properties");

The resource is loaded as part of the factory triggered via Blueprint: 



Am I possibly hitting https://issues.apache.org/jira/browse/CAMEL-5223? 
Is there a known workaround?


Thanks!
Ralf



--
View this message in context: 
http://camel.465427.n5.nabble.com/getResourceAsStream-in-OSGi-bundle-not-working-with-Camel-2-19-tp5807017.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Sending/Receiving active-mq with transferExchange silently removes Exchange headers

[rsteppac2]

I was too rash. The exception stated in my first message is raised due to the
body of the exchange in-message, which is of type Map. I
worked around the problem by marshalling the map to JSON.

Irrespective of whether I use "transferExchange" or not I am loosing a
header of type Set. No exception or warning gets logged.



--
View this message in context: 
http://camel.465427.n5.nabble.com/Sending-Receiving-active-mq-with-transferExchange-silently-removes-Exchange-headers-tp5794278p5794292.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Concurrent modification of DefaultExchange

[rsteppac2]

Hello Claus,


Claus Ibsen-2 wrote
> If you want an volatile exception member then provide a github PR

Personally I think that for almost all integrators it makes sense for the
DefaultExchange to not be thread safe. Incurring the cost of volatile member
access for everyone, whether they need it or not, seems unnecessary to me.
A more generic solution to allow integrators to choose whether they would
like to pay the cost of synchronization if wanted and needed would be
better. I think. 


Ralf



--
View this message in context: 
http://camel.465427.n5.nabble.com/Concurrent-modification-of-DefaultExchange-tp5793968p5794279.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Sending/Receiving active-mq with transferExchange silently removes Exchange headers

[rsteppac2]

Hello all,

I tried to migrate a route from using the "direct" endpoint to using the
ActiveMQ endpoint. I ran into an issue with exchange headers that contain
arrays of Strings. They get rejected with a MessageFormatException:

Failed delivery for (MessageId:
ID-Ralfs-MacBook-Pro-local-56776-1487752967901-2-233 on ExchangeId:
ID-Ralfs-MacBook-Pro-local-56776-1487752967901-2-234). Exhausted after
delivery attempt: 1 caught: org.springframework.jms.MessageFormatException:
Only objectified primitive objects, String, Map and List types are allowed
but was: [Ljava.lang.String;@51b56ff5 type: class [Ljava.lang.String;;
nested exception is javax.jms.MessageFormatException: Only objectified
primitive objects, String, Map and List types are allowed but was:
[Ljava.lang.String;@51b56ff5 type: class [Ljava.lang.String;

The way I read the documentation of the "transferExchange" property on the
camel-jms page I thought it would take care of this issue. The documentation
claims all serializable headers would be transferred. However, while the
exception is not thrown anymore, the string array headers get stripped from
the Exchange during the amq transport step. Is this the expected behavior or
should I raise an issue?


Thanks!
Ralf



--
View this message in context: 
http://camel.465427.n5.nabble.com/Sending-Receiving-active-mq-with-transferExchange-silently-removes-Exchange-headers-tp5794278.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Concurrent modification of DefaultExchange

[rsteppac2]

Hello all,

I have to ensure that the thread that runs a route (and the error handler)
is guaranteed to see an exception set on the exchange instance if that
instance is shared by many threads and the exception is set by one of those
threads.

I have a route step that massages the data in an input stream (jetty
endpoint) before proxying to the actual web server. For the stream data
manipulation I use stream pipelines (PipedInputStream/PipedOutputStream)
which need to run in their own thread per pipeline element. Each pipeline
element holds a reference to the exchange and if an error is encountered the
exception is set on the exchange.
This appears to work alright. But I don't think it is guaranteed to work as
"exception" is not a volatile member of DefaultExchange. Thus the main
thread is not guaranteed to see an exception set on the exchange by a worker
thread. The worker threads themselves all use a ReentrantLock I provide as
an exchange property (the property map is a ConcurrentHashMap) to
synchronize their access to the exchange. So data visibility between the
worker threads should not be an issue. 
But how to do it for the main thread?

I had a look at the Splitter implementation and how it deals with parallel
execution and aggregation. As far as I understand it the Splitter enforces
visibility by returning an AtomicReference of an exchange that the main
thread has never seen before. The exchange referenced by the atomic
reference is treated as read-only after it is set on the atomic reference.
So a get() on the atomic reference in the main thread is guaranteed to see
the latest version of the referenced exchange instance.

I cannot apply this approach as it requires the main thread to wait for the
workers to finish processing. If I block the main thread my workers would be
blocked as well as the main thread is responsible for consuming the modified
input stream contents from the last PipedInputStream element and forwarding
it to the web server. 

I also could not find a factory mechanism that would allow me to tell Camel
to instantiate my own implementation of the Exchange interface (with a
volatile member "exception").
(DefaultException was also not written with sub-classing in mind, it
appears. E.g. DefaultException::isFailed() uses the private member
"exception" instead of DefaultException::getException() for the answer. But
that's a separate issue.)

Does anyone have any other ideas?



Thanks!
Ralf



--
View this message in context: 
http://camel.465427.n5.nabble.com/Concurrent-modification-of-DefaultExchange-tp5793968.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: allowUseOriginalMessage="false" with useOriginalMessage="true" - new camel.breadcrumbId value

[rsteppac2]

Claus Ibsen-2 wrote
> From Camel 2.18 onwards you will get an exception if you attempt to
> access the original message and it was not allowed.

Thanks Claus for clarifying.

Ralf




--
View this message in context: 
http://camel.465427.n5.nabble.com/allowUseOriginalMessage-false-with-useOriginalMessage-true-new-camel-breadcrumbId-value-tp5793194p5793202.html
Sent from the Camel - Users mailing list archive at Nabble.com.

allowUseOriginalMessage="false" with useOriginalMessage="true" - new camel.breadcrumbId value

[rsteppac2]

Hello all,

I stumbled across a misconfiguration in one of my routes where the context
did not allow the use of the original message:



But by accident one of the routes had an onCompletion handler set to use the
original message:



I don't think the onCompletion handler acutally got the original message.
Unless the exchange property map is not a new instance and changes to the
map during route processing are also reflected in the "original" message.
But what happened was that a new camel.breadcrumbId was generated for the
exchange in the onCompletion handler.

Would that be a bug or a feature? If it is a feature, then why? 
I would have expected a warning or even an exception due to the
configuration inconsistency.

I am using Camel 2.16.3. I saw that
https://issues.apache.org/jira/browse/CAMEL-9250 changes the default setting
of the Camel context for 2.18x. Has the behavior changed with 2.18? (I
cannot test 2.18 due to AMQ incompatibilities.)


Thanks!
Ralf



--
View this message in context: 
http://camel.465427.n5.nabble.com/allowUseOriginalMessage-false-with-useOriginalMessage-true-new-camel-breadcrumbId-value-tp5793194.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Uninstalling Blueprint bundle using ActiveMQ PooledConnectionFactory causes javax.jms.IllegalStateException: The Consumer is closed

[rsteppac2]

I am using Camel (tried 2.15.2 and 2.16.3) and the activemq-camel (tried
5.12.1 and 5.13.3) component to hook up the routes in my bundle to an
external ActiveMQ server. The bundle is deployed in Karaf (tried 3.0.5 and
4.0.5) and started via a Blueprint context (containing the Camel context).
The bundle in question only contains an amq producer.

As long as no messages were exchanged there is no issue with
uninstalling/restarting the bundle. But any time after the first message
exchange I receive a javax.jms.IllegalStateException when uninstalling the
bundle:

2016-05-30 17:12:51,937 | WARN  | V.XACML.REQUEST] |
TemporaryQueueReplyManager   | 75 - org.apache.camel.camel-jms -
2.16.3 | ID-Ralfs-MacBook-Pro-local-59456-1464621134397-7-2 | Exception
inside the DMLC for Temporary ReplyTo Queue for destination
DEV.XACML.REQUEST, refreshing ReplyTo destination
javax.jms.IllegalStateException: The Consumer is closed
at
org.apache.activemq.ActiveMQMessageConsumer.checkClosed(ActiveMQMessageConsumer.java:880)[64:org.apache.activemq.activemq-osgi:5.13.3]
at
org.apache.activemq.ActiveMQMessageConsumer.receive(ActiveMQMessageConsumer.java:641)[64:org.apache.activemq.activemq-osgi:5.13.3]
at
org.apache.activemq.jms.pool.PooledMessageConsumer.receive(PooledMessageConsumer.java:67)[64:org.apache.activemq.activemq-osgi:5.13.3]
at
org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveMessage(AbstractPollingMessageListenerContainer.java:430)[106:org.apache.servicemix.bundles.spring-jms:3.2.14.RELEASE_1]
at
org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:310)[106:org.apache.servicemix.bundles.spring-jms:3.2.14.RELEASE_1]
at
org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:263)[106:org.apache.servicemix.bundles.spring-jms:3.2.14.RELEASE_1]
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1103)[106:org.apache.servicemix.bundles.spring-jms:3.2.14.RELEASE_1]
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageListenerContainer.java:1095)[106:org.apache.servicemix.bundles.spring-jms:3.2.14.RELEASE_1]
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:992)[106:org.apache.servicemix.bundles.spring-jms:3.2.14.RELEASE_1]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_77]

This then causes an infinite re-try to connect back to the temporary queue:

2016-05-30 17:12:51,940 | WARN  | V.XACML.REQUEST] |
faultJmsMessageListenerContainer | 106 -
org.apache.servicemix.bundles.spring-jms - 3.2.14.RELEASE_1 |
ID-Ralfs-MacBook-Pro-local-59456-1464621134397-7-2 | Setup of JMS message
listener invoker failed for destination 'temporary' - trying to recover.
Cause: The Consumer is closed
2016-05-30 17:12:51,941 | INFO  | V.XACML.REQUEST] | PooledConnection   
 
| 64 - org.apache.activemq.activemq-osgi - 5.13.3 |
ID-Ralfs-MacBook-Pro-local-59456-1464621134397-7-2 | failed to delete
Temporary Queue
"temp-queue://ID:Ralfs-MacBook-Pro.local-59467-1464621151437-1:2:1" on
closing pooled connection: The connection is already closed
2016-05-30 17:12:51,943 | ERROR | V.XACML.REQUEST] |
faultJmsMessageListenerContainer | 106 -
org.apache.servicemix.bundles.spring-jms - 3.2.14.RELEASE_1 |
ID-Ralfs-MacBook-Pro-local-59456-1464621134397-7-2 | Could not refresh JMS
Connection for destination 'temporary' - retrying in 5000 ms. Cause: null
[rest of component shutdown logs...]
2016-05-30 17:12:56,944 | ERROR | V.XACML.REQUEST] |
faultJmsMessageListenerContainer | 106 -
org.apache.servicemix.bundles.spring-jms - 3.2.14.RELEASE_1 |  | Could not
refresh JMS Connection for destination 'temporary' - retrying in 5000 ms.
Cause: null
2016-05-30 17:13:01,948 | ERROR | V.XACML.REQUEST] |
faultJmsMessageListenerContainer | 106 -
org.apache.servicemix.bundles.spring-jms - 3.2.14.RELEASE_1 |  | Could not
refresh JMS Connection for destination 'temporary' - retrying in 5000 ms.
Cause: null
2016-05-30 17:13:06,953 | ERROR | V.XACML.REQUEST] |
faultJmsMessageListenerContainer | 106 -
org.apache.servicemix.bundles.spring-jms - 3.2.14.RELEASE_1 |  | Could not
refresh JMS Connection for destination 'temporary' - retrying in 5000 ms.
Cause: null
2016-05-30 17:13:11,956 | ERROR | V.XACML.REQUEST] |
faultJmsMessageListenerContainer | 106 -
org.apache.servicemix.bundles.spring-jms - 3.2.14.RELEASE_1 |  | Could not
refresh JMS Connection for destination 'temporary' - retrying in 5000 ms.
Cause: null
[...]

How would I have to set up my context in order to support bundle re-starts
and still use temporary queues for request-reply messaging?

My current configuration looks like 

Re: Simple expression not evaluated in Spring DSL setProperty

[rsteppac2]

Claus, thanks for clarifying.

Ralf



--
View this message in context: 
http://camel.465427.n5.nabble.com/Simple-expression-not-evaluated-in-Spring-DSL-setProperty-tp5765820p5765847.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Simple expression not evaluated in Spring DSL setProperty

[rsteppac2]

Hello all,

is this supposed to work?

setProperty
propertyName=$simple{type:my.domain.StringConstants.EXCHANGE_PROP_TX_FAILED}
simple${type:java.lang.Boolean.TRUE}/simple
/setProperty

StringConstants.EXCHANGE_PROP_TX_FAILED := exchange_prop_tx_failed

The property name is not evaluated to the string exchange_prop_tx_failed.
Instead the expression is used verbatim as the property name. 
The property value is evaluated to Boolean.TRUE as expected.

Using log
message=$simple{type:my.domain.StringConstants.EXCHANGE_PROP_TX_FAILED}...
prints the expected value exchange_prop_tx_failed to the log.


Ralf



--
View this message in context: 
http://camel.465427.n5.nabble.com/Simple-expression-not-evaluated-in-Spring-DSL-setProperty-tp5765820.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: breadcrumbId does not survive http call

[rsteppac2]

Hello Claus,

I have logged https://issues.apache.org/jira/browse/CAMEL-8351.


Thanks!
Ralf


Claus Ibsen-2 wrote
 You are welcome to log a JIRA. I think spring-ws has some ways of telling
 it to include HTTP headers too.





--
View this message in context: 
http://camel.465427.n5.nabble.com/breadcrumbId-does-not-survive-http-call-tp5762528p5762704.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: breadcrumbId does not survive http call

[rsteppac2]

I absolutely require a log correlation ID that never changes for a request
across all our components. The breadcrumb looked like a good fit for that.



James Carman wrote
 Do you absolutely require that the breadcrumb's match between the proxy
 and your web service?





--
View this message in context: 
http://camel.465427.n5.nabble.com/breadcrumbId-does-not-survive-http-call-tp5762528p5762701.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: breadcrumbId does not survive http call

[rsteppac2]

James,

sorry, I did not want to make the impression of lightheartedly dismissing
your hint with the BasicMessageFilter. I have extended from it and have
overridden the  method to not filter any headers. As suspected this is too
late in the chain. By the time the filter is called the route has already
been processed.

I tried to find a hook where I could jump in and make the breadcrumbId from
the HTTP headers available. But I am stuck.

The spring-ws endpoint (SpringWebserviceConsumer) does not care at all about
HTTP headers, only about SOAP headers and properties of the
org.springframework.ws.context.MessageContext. SOAP headers get converted
into exchange headers while message context properties get converted into
exchange properties. Properties could be added by using a
org.springframework.ws.server.EndpointInterceptor.

A breadcrumbId property is not picked up. Instead the
org.apache.camel.impl.DefaultUnitOfWork creates a new breadcrumbId because
it only checks the in-message headers, not the exchange properties.
A SOAPHeader breadcrumbId is copied over to the in-message headers and
actually picked up by the DefaultUnitOfWork, but it is of type
org.springframework.ws.soap.saaj.SaajSoapHeaderElement, which has no
toString() implementation.

So far so inconvenient...

Ralf

PS: I am back in the office on Friday



--
View this message in context: 
http://camel.465427.n5.nabble.com/breadcrumbId-does-not-survive-http-call-tp5762528p5762572.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: breadcrumbId does not survive http call

[rsteppac2]

Hi James,

this is how the route looks like I used as an example:



Ralf



--
View this message in context: 
http://camel.465427.n5.nabble.com/breadcrumbId-does-not-survive-http-call-tp5762528p5762530.html
Sent from the Camel - Users mailing list archive at Nabble.com.

breadcrumbId does not survive http call

[rsteppac2]

Hello all,

I am using Camel (2.14.1) to proxy calls to a web service and for the web
service implementation itself (camel-spring-ws). I expected the breadcrumbId
to be the same in my proxy route as well as the web service route. The proxy
sends the breadcrumb as an HTTP header, but the web service route does not
seem to pick it up.

These are the headers that go over the wire:



However, the MDC logging shows two separate breadcrumbIds. The proxy uses
the one that is forwarded in the http header, but the web service still
created a new one:



The proxy and web service routes run in separate bundles inside the same
Karaf server.
Is there anything else I need to configure for the ws route to pick up the
breadcrumbId? Or is this a bug?


Thanks in advance,
Ralf



--
View this message in context: 
http://camel.465427.n5.nabble.com/breadcrumbId-does-not-survive-http-call-tp5762528.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: breadcrumbId does not survive http call

[rsteppac2]

James,

thanks for your answer. However, I don't think the BasicMessageFilter is
responsible for the breadcrumbId not being picked up. The filter is about
populating the SOAP header element from exchange headers, not the other way
round. 
My proxy does not use spring-ws, but works on plain http. The proxy does
some inspection of the raw SOAP XML and SAML header and on success forwards
the request. The breadcrumbId is set as an HTTP header as expected on the
forward.  But it is not unmarshalled as an exchange header in my web service
route. The documentation page for MDC logging claims that the header
survives across an HTTP transport. Though might be I am expecting too much
and the claim to support HTTP transport does not include X over HTTP. But
really just plain HTTP endpoints.

This is my proxy route:




Ralf



--
View this message in context: 
http://camel.465427.n5.nabble.com/breadcrumbId-does-not-survive-http-call-tp5762528p5762566.html
Sent from the Camel - Users mailing list archive at Nabble.com.

spring-ws does not marshal response message without @XmlRootElement

[rsteppac2]

Dear all,

I am trying to get a spring-ws route (Camel 2.14.0) to populate the SOAP
body of the response without annotating the response class with
@XmlRootElement. I was hoping that by placing an instance of JAXBElement as
the message body this could be done, but no luck.
Unless the @XmlRootElement annotation is present the type conversion in
org.apache.camel.component.spring.ws.SpringWebserviceConsumer::invoke(MessageContext)
fails and returns null. Line 66 ff:

Message responseMessage = exchange.getOut(Message.class);
..
// responseBody is null unless @XmlRootElement is present;
// Source is javax.xml.transform.Source.
Source responseBody = responseMessage.getBody(Source.class); 

I am looking for a way to return raw values and generic list types where I
do not even have a class that I could annotate with @XmlRootElement. A
sample ObjectFactory method generated by xjc looks like this:

@XmlElementDecl(namespace = http://some.org/my/namespace;, name =
addDelegationResponse)
public JAXBElementInteger createAddDelegationResponse(Integer value) {
return new JAXBElementInteger(_AddDelegationResponse_QNAME,
Integer.class, null, value);
}

My route looks like this:

route id=addDelegation
from
uri=spring-ws:soapaction:http://some.org/my/namespace/addDelegation?endpointMapping=#endpointMapping;
/
setExchangePattern pattern=InOut /
unmarshal ref=jaxb /
bean beanType=ch.vivates.ams.ws.domain.RequestFactory
method=getDelegation /
enrich uri=vm:pas-put /
lt;!-- ResponseFactory uses ObjectFactory to create JAXBElement --gt;
bean beanType=ch.vivates.ams.ws.domain.ResponseFactory
method=addDelegationResponse /
lt;!-- Response has empty SOAP body because type conversion fails
--gt;
/route

Is there another way to do this with spring-ws?
Changing the WSDL is not really an option for me at this point.


Thanks!
Ralf



--
View this message in context: 
http://camel.465427.n5.nabble.com/spring-ws-does-not-marshal-response-message-without-XmlRootElement-tp5759215.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: spring-ws does not marshal response message without @XmlRootElement

[rsteppac2]

Never mind. An explicit marshal step at the end of the route fixed the
issue for the JAXBElement in the message body.



--
View this message in context: 
http://camel.465427.n5.nabble.com/spring-ws-does-not-marshal-response-message-without-XmlRootElement-tp5759215p5759234.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Bundle using camel-spring-ws failes to deploy in Karaf

[rsteppac2]

Hello Willem,

there is no Spring 4 involved. Unless you add camel-test-spring 2.14.0 as a
dependency, which I have not done at this point in time. camel-spring 2.14.0
pulls in Spring 3.2.11.RELEASE as its dependency.

Same with the Karaf features. Installing my feature with the descriptor
above leads to the following features to be installed:

karaf@root() feature:list -i |grep -i spring
spring-dm | 1.2.1| x | spring-3.0.2|
Spring DM support
spring| 3.2.11.RELEASE_1 | x | spring-3.0.2|
Spring 3.2.x support
spring-jms| 3.2.11.RELEASE_1 | x | spring-3.0.2|
Spring 3.2.x JMS support
spring-oxm| 3.2.11.RELEASE_1 | x | spring-3.0.2|
Spring 3.2.x OXM support
spring-tx | 3.2.11.RELEASE_1 | x | spring-3.0.2|
Spring 3.2.x Transaction (TX) support
spring-web| 3.2.11.RELEASE_1 | x | spring-3.0.2|
Spring 3.2.x Web support
camel-spring  | 2.14.0   | x | camel-2.14.0|
camel-spring-ws   | 2.14.0   | x | camel-2.14.0|

karaf@root() bundle:list |grep -i spring
 88 | Active   |  50 | 2.14.0 | camel-spring
114 | Active   |  50 | 2.1.4.RELEASE  | Spring XML
115 | Active   |  50 | 2.1.4.RELEASE  | Spring Web Services Core, Fragments:
116
116 | Resolved |  50 | 2.1.4.RELEASE  | Spring Web Services Support, Hosts:
115
117 | Active   |  50 | 2.14.0 | camel-spring-ws

For now I have settled for deploying a spring context instead of blueprint.
However, that deployment is far from straight forward, too. I had to add
additional system parameters to the Karaf start script.

-Djavax.xml.soap.MessageFactory=com.sun.xml.internal.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl
 
-Djavax.xml.soap.MetaFactory=com.sun.xml.internal.messaging.saaj.soap.SAAJMetaFactoryImpl
 
-Djavax.xml.soap.SOAPFactory=com.sun.xml.internal.messaging.saaj.soap.ver1_1.SOAPFactory1_1Impl

Plus a dynamic import header in the manifest of my bundle: 

DynamicImport-Package: *

Without those additions I end up with this in the log:

Caused by: javax.xml.soap.SOAPException: Unable to create MessageFactory:
Provider for javax.xml.soap.MessageFactory cannot be found
at
javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:90)[:2.4.0]
at
org.springframework.ws.soap.saaj.SaajSoapMessageFactory.afterPropertiesSet(SaajSoapMessageFactory.java:147)[115:org.springframework.ws:2.1.4.RELEASE]
... 16 more

The original exception, which is only visible in the debugger, sais:

javax.xml.soap.SOAPException: Provider
org.apache.axis2.saaj.SAAJMetaFactoryImpl not found


Ralf



--
View this message in context: 
http://camel.465427.n5.nabble.com/Bundle-using-camel-spring-ws-failes-to-deploy-in-Karaf-tp5758291p5758358.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Bundle using camel-spring-ws failes to deploy in Karaf

[rsteppac2]

Hi all,

I have a small test project that uses camel-spring-ws (2.14.0). It runs just
fine in a Spring context and the WS client calls are acted on by my routes.
Now I want to convert it to blueprints to deploy it in Karaf (3.0.2).
However, the deployment of the bundle fails with:

   waiting for namespace handlers
[http://www.springframework.org/schema/web-services]

Can anyone tell me which bundle/feature is supposed to contribute this
namespace handler? The feature descriptor I am using to deploy the bundle
(pas-webservice-hp) looks like this:

features xmlns=http://karaf.apache.org/xmlns/features/v1.2.1;
name=ams-feature
feature name=pas-webservice-hp version=3.0.0-SNAPSHOT
description=PAS Webservice for HPs
feature version=2.14.0camel-core/feature
feature version=2.14.0camel-spring/feature
feature version=2.14.0camel-blueprint/feature
feature version=2.14.0camel-spring-ws/feature
bundle
dependency=truemvn:ch.vivates.ams/base/3.0.0-SNAPSHOT/bundle
bundlemvn:ch.vivates.ams/pas-webservice-hp/3.0.0-SNAPSHOT/bundle
/feature
/features

The offending part of the blueprints descriptor is this:

sws:static-wsdl id=ams_hp_ws location=wsdl/v1/ams_hp_ws.wsdl /

which is required by this:

bean id=wsdlHandler
class=org.springframework.ws.transport.http.WsdlDefinitionHttpHandler
property name=definition ref=ams_hp_ws /
/bean

Might be I am going about it the wrong way altogether... In the Spring
context descriptor I used the JDK HTTP server as described  here
http://docs.spring.io/spring-ws/docs/2.2.0.RELEASE/reference/htmlsingle/#d4e1003
  
to avoid having to run a servlet container. I copied the same configuration
over to the blueprint descriptor to get started. Is this approach going to
work at all when deploying to Karaf?
The WsdlDefinitionHttpHandler is specific to using the embedded HTTP server,
but using the dispatcher servlet in a container still requires me to provide
the WSDL I want to expose with a sws:static-wsdl .. tag.


Thanks for your help!
Ralf 

PS.: This is a resend with slightly modified subject because the first
message was rejected due to a too high spam score. If both make it to the
list, my apologies!



--
View this message in context: 
http://camel.465427.n5.nabble.com/Bundle-using-camel-spring-ws-failes-to-deploy-in-Karaf-tp5758291.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Jetty continuation timeout ignored in Karaf

[rsteppac2]

Claus,


Claus Ibsen-2 wrote
 Have you tried outside Karaf first, eg just a plain java standalone.

thank you for asking the obvious question. It did not work outside Karaf
either. For the simple fact that I forgot to make it an async route by means
of the threads-DSL.

Sorry for the noise!

Ralf





--
View this message in context: 
http://camel.465427.n5.nabble.com/Jetty-continuation-timeout-ignored-in-Karaf-tp5756690p5756734.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Jetty continuation timeout ignored in Karaf

[rsteppac2]

Hello all,

I am experimenting with Camel (2.13.2) routes using Karaf (2.3.7) as the
runtime. I encountered a problem with Jetty continuation timeouts. They seem
to get ignored. It does not matter whether I explicitly set the timeout or
leave the default. During deployment of the bundle containing the route I
get different log output, but in neither case does the timeout fire.

Endpoint with default for continuation timeout:
camel:endpoint id=jetty.http.server
uri=jetty:http://0.0.0.0:1978/my/frontend?disableStreamCache=true; /

Karaf log:
2014-09-18 11:04:04,799 | INFO  | ExtenderThread-2 | JettyHttpComponent 
 
| mponent.jetty.JettyHttpComponent  946 | 102 - org.apache.camel.camel-jetty
- 2.13.2 | Using default Jetty continuation timeout for:
Endpoint[http://0.0.0.0:1978/my/frontend?disableStreamCache=true]


Endpoint with continuation timeout set to 1s:
camel:endpoint id=jetty.http.server
uri=jetty:http://0.0.0.0:1978/my/frontend?disableStreamCache=trueamp;continuationTimeout=1000;
/

Karaf log:
2014-09-18 14:05:00,895 | INFO  | ExtenderThread-2 | JettyHttpComponent 
 
| mponent.jetty.JettyHttpComponent  943 | 102 - org.apache.camel.camel-jetty
- 2.13.2 | Using Jetty continuation timeout: 1000 millis for:
Endpoint[http://0.0.0.0:1978/my/frontend?disableStreamCache=true]

My $KARAF_HOME/etc/jetty.xml is lock stock and does not contain a connector
configuration for port 1978.

I am testing this by POSTing a file to the route with curl, then inspecting
the file with a bean in the route. In the bean I set a breakpoint and just
wait. Outside Karaf the client is returned an error after the continuation
timeout period and the timeout is logged by Camel. Doing this in Karaf just
waits forever.

Is this expected behavior? If it is, why?

Thanks!
Ralf



--
View this message in context: 
http://camel.465427.n5.nabble.com/Jetty-continuation-timeout-ignored-in-Karaf-tp5756690.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Stream-only reverse proxy with minimal memory footprint

[rsteppac2]

I am trying to implement a memory efficient http reverse proxy that is
working on streams only to handle large HTTP requests and responses. This
should be as easy as described here:

http://camel.apache.org/how-to-use-camel-as-a-http-proxy-between-a-client-and-server.html
 

The Jetty consumer places the socket input stream with the http POST body
into the exchange and I can hook it up with a producer to forward the
request. No problem here.

The problem is the response. All http producers that I am aware of (Jetty,
http4, netty-http) read the response stream into a byte-array,wrap it in an
InputStream and place that in the exchange body. Thus a large http response
blows my proxy out of the water. None of the producers seem to offer an
option to make them put the original socket input stream into the exchange,
just as the Jetty consumer does.

http4: Everything happens in
org.apache.camel.component.http4.HttpProducer::process() -
populateResponse(..) - extractResponseBody(..) -
doExtractResponseBodyAsStream(); here the original stream is copied into an
instance of CachedOutputStream, backed by a byte-array.

Jetty: org.eclipse.jetty.client.AsyncHttpConnection::handle() -
org.eclipse.jetty.http.HttpParser::parseNext() will fill a byte-array in
org.eclipse.jetty.client.ContentExchange which is a CachedExchange which is
a HttpExchange.

netty-http: Builds a pipeline that assembles the HttpResponse content as a
composite ChannelBuffer. The wrapped channel buffers make up the complete
response stream.

Is there a way to configure any of the clients to place the socket input
stream into the exchange body?

This thread describes the same problem and proposes a patch, which I think
has not made it into the Camel code base as of yet:
http://camel.465427.n5.nabble.com/Chunking-issue-with-http-producer-td5735075.html

The question is how to close the socket stream of the client. If I should
have to replicate the suggested patch, would a Synchronization call-back
registered with the exchange via Exchange::addOnCompletion(Synchronization)
be the correct place to do it? I have tried with a FileInputStream and that
seems to work. I.e. the call-back is triggered after the stream contents
have been written out to the socket.


Thanks!
Ralf



--
View this message in context: 
http://camel.465427.n5.nabble.com/Stream-only-reverse-proxy-with-minimal-memory-footprint-tp5754424.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Stream-only reverse proxy with minimal memory footprint

[rsteppac2]

Willem,

thanks for taking this up.

Ralf

On 25.07.14 10:30, Willem.Jiang [via Camel] wrote:
 Hi,

 You just bring up an interesting topic of avoiding extra copy of 
 response input stream.
 It could save us lots of the memory and time if the response is a big 
 and chunked message.
 I just created a JIRA[1] to track this issue. We may create some sub 
 tasks as we need to work on five different http client implement at 
 the time.

 I prefer to avoid close the input stream in a Synchronization 
 callback. It could be OK in a proxy route, as the input stream can be 
 consumed when the exchange int the route is completed. But if the 
 input stream is used in the other route, it’s hard for camel to know 
 if the stream is in use unless we have a reference count for it.

 [1]https://issues.apache.org/jira/browse/CAMEL-7638

 -- 
 Willem Jiang

 Red Hat, Inc.
 Web: http://www.redhat.com
 Blog: http://willemjiang.blogspot.com (English)
 http://jnn.iteye.com (Chinese)
 Twitter: willemjiang
 Weibo: 姜宁willem



 On July 25, 2014 at 2:36:14 PM, rsteppac2 ([hidden email] 
 /user/SendEmail.jtp?type=nodenode=5754438i=0) wrote:

  I am trying to implement a memory efficient http reverse proxy that is
  working on streams only to handle large HTTP requests and responses. 
 This
  should be as easy as described here:
 
  
 http://camel.apache.org/how-to-use-camel-as-a-http-proxy-between-a-client-and-server.html
  

 
  The Jetty consumer places the socket input stream with the http POST 
 body
  into the exchange and I can hook it up with a producer to forward the
  request. No problem here.
 
  The problem is the response. All http producers that I am aware of 
 (Jetty,
  http4, netty-http) read the response stream into a byte-array,wrap 
 it in an
  InputStream and place that in the exchange body. Thus a large http 
 response
  blows my proxy out of the water. None of the producers seem to offer an
  option to make them put the original socket input stream into the 
 exchange,
  just as the Jetty consumer does.
 
  http4: Everything happens in
  org.apache.camel.component.http4.HttpProducer::process() -
  populateResponse(..) - extractResponseBody(..) -
  doExtractResponseBodyAsStream(); here the original stream is copied 
 into an
  instance of CachedOutputStream, backed by a byte-array.
 
  Jetty: org.eclipse.jetty.client.AsyncHttpConnection::handle() -
  org.eclipse.jetty.http.HttpParser::parseNext() will fill a 
 byte-array in
  org.eclipse.jetty.client.ContentExchange which is a CachedExchange 
 which is
  a HttpExchange.
 
  netty-http: Builds a pipeline that assembles the HttpResponse 
 content as a
  composite ChannelBuffer. The wrapped channel buffers make up the 
 complete
  response stream.
 
  Is there a way to configure any of the clients to place the socket 
 input
  stream into the exchange body?
 
  This thread describes the same problem and proposes a patch, which I 
 think
  has not made it into the Camel code base as of yet:
  
 http://camel.465427.n5.nabble.com/Chunking-issue-with-http-producer-td5735075.html
  

 
  The question is how to close the socket stream of the client. If I 
 should
  have to replicate the suggested patch, would a Synchronization 
 call-back
  registered with the exchange via 
 Exchange::addOnCompletion(Synchronization)
  be the correct place to do it? I have tried with a FileInputStream 
 and that
  seems to work. I.e. the call-back is triggered after the stream 
 contents
  have been written out to the socket.
 
 
  Thanks!
  Ralf
 
 
 
  --
  View this message in context: 
 http://camel.465427.n5.nabble.com/Stream-only-reverse-proxy-with-minimal-memory-footprint-tp5754424.html
  

  Sent from the Camel - Users mailing list archive at Nabble.com.
 



 
 If you reply to this email, your message will be added to the 
 discussion below:
 http://camel.465427.n5.nabble.com/Stream-only-reverse-proxy-with-minimal-memory-footprint-tp5754424p5754438.html
  

 To unsubscribe from Stream-only reverse proxy with minimal memory 
 footprint, click here 
 http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=5754424code=cmFsZkBzdGVwcGFjaGVyLm5hbWV8NTc1NDQyNHwtMjc3MjkzMDM=.
 NAML 
 http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
  






--
View this message in context: 
http://camel.465427.n5.nabble.com/Stream-only-reverse-proxy-with-minimal-memory-footprint-tp5754424p5754440.html
Sent from the Camel - Users mailing list archive at Nabble.com.