Re: Urgent - Endpoint wsdl XSD's are stored in heap memory
> On Jan 31, 2017, at 1:58 AM, sari.reach wrote: > > My wsdls contain xsd's which are of 1MB size, All these xsd's are loaded in > memory when context is loaded for the first time. I don't want these xsd's > to be loaded in memory. Please let me know how to stop this You can’t. CXF uses the XSD’s at runtime to match up parts with schemas and do various checking and namespace mappings. You can potentially create a service/client without the wsdlLocation and have it just use the annotations, but even then we create a schema based on the objects. That created schema may be smaller, but it also wouldn’t be as complete. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Kafka Producer Performance
For one of my clients, I ended up not using the splitter in Camel and instead
us a custom processor that would create an Iterator. This will work
with updates to camel-kafka that are included in 2.17.3. For my tests, using
the camel splitter like you have would get about 5K-10K msg/sec. With this, I
get about 200K. However, within camel, it stays as a single message so
anything in the camel route that needs to look at each line wouldn’t really
work.
from(“file://…….")
.process(new Processor() {
public void process(Exchange exchange) throws Exception {
InputStream ins = exchange.getIn().getBody(InputStream.class);
exchange.getIn().setBody(new SplitterIterator(ins));
}
})
.to("kafka:brokerAddr?topic=messages"
+
"&serializerClass=org.apache.kafka.common.serialization.ByteArraySerializer"
+
"&keySerializerClass=org.apache.kafka.common.serialization.ByteArraySerializer"
);
class SplitterIterator implements Iterator {
final InputStream stream;
byte[] next;
SplitterIterator(InputStream i) {
stream = i;
next = readNext();
}
private byte[] readNext() {
ByteArrayOutputStream bout = new ByteArrayOutputStream();
try {
int v = stream.read();
while (v != -1 && v != '\n') {
bout.write(v);
v = stream.read();
}
if (bout.size() == 0) {
return null;
}
return bout.toByteArray();
} catch (IOException e) {
throw new RuntimeException(e);
}
}
public boolean hasNext() {
return next != null;
}
public byte[] next() {
byte[] tmp = next;
next = readNext();
return tmp;
}
@Override
public void remove() {
}
};
> On Aug 1, 2016, at 4:38 AM, Sergey Zhemzhitsky wrote:
>
> Hi Camel Gurus,
>
> I've faced with some performance issues of camel-kafka component during
> migrating it from 2.17.0 then to 2.17.1 and then to 2.17.2.
>
> The camel route is pretty simple and looks like this
>
> from("file:/var/lib/app/input")
>.split().simple("\n").streaming()
>.to("direct:kafka");
> from("direct:kafka")
>.to("kafka:brokerAddr?topic=messages");
>
> The first issue with camel 2.17.0 was the possibility of losing messages
> <https://github.com/apache/camel/blob/camel-2.17.0/components/camel-kafka/src/main/java/org/apache/camel/component/kafka/KafkaProducer.java#L101>.
> Kafka's native producer is buffering the messages
> <https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/clients/producer/KafkaProducer.java#L468>
> and if kafka broker is unavailable then the messages can be lost when the
> route is restarted. Although the messages can be lost, the performance was
> pretty good (~10K rps) due to kafka's producer buffering.
>
> The second issue with camel 2.17.1 was that the performance of kafka
> producer degraded tremendously (up to 100 times) because of blocking on
> every message
> <https://github.com/apache/camel/blob/camel-2.17.1/components/camel-kafka/src/main/java/org/apache/camel/component/kafka/KafkaProducer.java#L100>
> (although in that case no message losing occurs).
>
> The third issue with camel 2.17.2 (although camel started using async
> callbacks
> <https://github.com/apache/camel/blob/camel-2.17.2/components/camel-kafka/src/main/java/org/apache/camel/component/kafka/KafkaProducer.java#L180>)
> was that the performance was still pretty poor because kafka's native
> producer was not able to buffer more than a single message (because of
> synchronous direct endpoint).
>
> The two solutions for the mentioned issues I was able to figure out:
>
> - using seda endpoint instead of direct one (then kafka's native producer
> is able to buffer the messages, but there is still a possibility to lose
> messages (because of nature of seda))
>
> - using aggregator with direct endpoint (then the route becomes more
> complicated than it is expected to be, aggregator adds additional not
> necessary delays and why at all we need additional aggregator for batching
> if the kafka's native producer already does buffering/batching?)
>
> So the question is - is there any possibility to allow kafka's native
> producer buffer more than a single message not using aggregator eip and not
> lose the messages as it can happen with intermediate seda endpoint?
>
> Kind Regards,
> Sergey
--
Daniel Kulp
dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog
<http://dankulp.com/blog>
Talend Community Coder - http://coders.talend.com <http://coders.talend.com/>
Re: Camel 2.16 vs Jetty9 vs camel-websocket
I looked at this briefly when I updated a bunch of things to be able to use Jetty9. In CXF, we were able to use a bit of reflection to allow the CXF web socket transport to support both Jetty 8 and Jetty 9. However, camel-websocket uses a LOT LOT more of the web socket API’s than CXF does and it didn’t look possible to support both Jetty 8 and 9 from the same component. That then brings up the question of whether we split it into a “common”, “jetty8”, and “jetty9” set like we have for HTTP or just completely drop the Jetty 8 support. If we drop Jetty 8, that would then also mandate Karaf 4 when using camel-websocket in OSGi. Dan > On Nov 10, 2015, at 12:20 PM, Claus Ibsen wrote: > > Yeah I think there is a ticket about upgrading camel-websocket to > jetty 9. We love help so anyone who has the time is welcome to help > with this. It should IMHO be jetty9 by default as 8 is EOL. > > On Tue, Nov 10, 2015 at 6:11 PM, Aki Yoshida wrote: >> jetty8 and jetty9 have a different websocket handler interface, so you >> can't just replace the jetty version unless the component includes two >> specific implementations that can be used depending on the available >> version. >> >> if you want to choose your own serverlet container (e.g., jetty9, >> tomcat8, etc), you can use camel-atmosphere-websocket. >> >> >> 2015-11-10 17:49 GMT+01:00 fabrizio.spataro : >>> Hello, >>> >>> i would use camel 2.16 + jetty9 + camel-websocket but this component depends >>> from jetty8. >>> >>> How can i do? >>> >>> i am trying force to use jetty9 from maven without success. >>> >>> >>> >>> -- >>> View this message in context: >>> http://camel.465427.n5.nabble.com/Camel-2-16-vs-Jetty9-vs-camel-websocket-tp5773575.html >>> Sent from the Camel - Users mailing list archive at Nabble.com. > > > > -- > Claus Ibsen > - > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Apache Camel CXF Transport - Adding interceptors to JaxWs Client
Ah.. I see the problem. You are within an element (the client element) that has the default namespace reset to xmlns="http://cxf.apache.org/jaxws”. Thus the “ref” element is in that namespace, not the spring namespace.Either use a prefix for the cxf elements or put an xmlns decl on the ref element or similar to get that back into the spring namespace. Dan > On Aug 13, 2015, at 2:55 AM, Resmis wrote: > > Hi Dan, > > Thanks for the response. > > also not working. It is giving following exception: > > org.springframework.beans.factory.parsing.BeanDefinitionParsingException: > Configuration problem: Cannot locate BeanDefinitionParser for element [bean] > > I was referring to http://camel.apache.org/cxf.html, in which the following > sample is given for adding interceptors: > > > > > > Thanks, > Resmi > > > > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Apache-Camel-CXF-Transport-Adding-interceptors-to-JaxWs-Client-tp5770596p5770640.html > Sent from the Camel - Users mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Apache Camel CXF Transport - Adding interceptors to JaxWs Client
Isn’t it “ and not “ ? Dan > On Aug 12, 2015, at 2:16 AM, Resmis wrote: > > Hi, > > We are invoking a soap service through RabbitMQ using Camel transport JaxWS > client as given below (Ref: > http://camel.apache.org/better-jms-transport-for-cxf-webservice-using-apache-camel.html > , and used camel-cxf-transport version 2.15.2). > > Service invoked successfully, but could not add interceptors to the JaxWS > client proxy. Tried the following: > > >http://cxf.apache.org/jaxws"; > xmlns:testsvc="http://mytest.com/services/test/v2"; > serviceName="testsvc:Test_v2_0_service" > endpointName="testsvc:HttpTestPort" > address="camel://direct:TestService" > serviceClass="test.v2.TestSVCV20" >> > > > > > > > http://cxf.apache.org/core"/> > > > > > class="org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor"> > > > > >value="PasswordTestTxt" /> >value="test.PwdCallbackclass" /> > > > > > > > When interceptor tag with bean ref is added it is showing the following > error: > > > > org.springframework.beans.factory.parsing.BeanDefinitionParsingException: > Configuration problem: Cannot locate BeanDefinitionParser for element [ref] > > Can anyone please help with a sample on how to correctly add the > interceptors in camel transport cxf client? > > Thanks, > Resmi > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Apache-Camel-CXF-Transport-Adding-interceptors-to-JaxWs-Client-tp5770596.html > Sent from the Camel - Users mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Camel CXF cannot be loaded to Karaf 4.0.0
The problem is that CXF the 3.0.x features file (which is pulled in via Camel 2.15.2) doesn’t support Karaf 4. CXF only supports Karaf 4 starting with CXF 3.1. Thus, when the Karaf resolver is trying to resolve the camel-cxf feature file, it has a problem with the jetty 8 feature as CXF 3.0.x needs Jetty 8, not the Jetty 9 that Karaf 4 provides. You can “work around” this by doing: feature:install camel-core camel-spring install -s mvn:org.apache.camel/camel-cxf-transport/2.15.2 install -s mvn:org.apache.camel/camel-cxf/2.15.2 which should work fine. If you look at the features file for camel-cxf, it’s really the same as the above but wouldn’t attempt to look at the 3.0.x versions of CXF. That said, this MAY be a bug in Karaf’s resolver. The Camel feature file specifies a version range of [2.7,4.0) for CXF and CXF 3.1.1 would already be installed and resolved so I have no idea why it’s even looking at the 3.0.5 features. Dan > On Aug 10, 2015, at 3:52 PM, bocamel wrote: > > Just a heads up. Tried the latest Karaf 4.0.0. Cannot load camel-cxf > feature (Camel 2.15.2/CXF 3.1.1). Below is the error - looks like someone > needs to bump up Jetty dependency. > > > karaf@root()> feature:repo-add cxf 3.1.1 > Adding feature url mvn:org.apache.cxf.karaf/apache-cxf/3.1.1/xml/features > karaf@root()> feature:install cxf cxf-rt-security > karaf@root()> feature:repo-add camel 2.15.2 > Adding feature url > mvn:org.apache.camel.karaf/apache-camel/2.15.2/xml/features > karaf@root()> feature:install camel-core camel-spring camel-cxf > Error executing command: Unable to resolve root: missing requirement [root] > osgi > .identity; osgi.identity=jetty; type=karaf.feature; version="[7.0.0,9.0.0)" > karaf@root()> > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Camel-CXF-cannot-be-loaded-to-Karaf-4-0-0-tp5770537.html > Sent from the Camel - Users mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Problem with camel-cxf when Jolokia is installed
g to get to the bottom of this for a couple weeks >>> now, and I'm stuck >>>>>>> >>>>>>> I'll try to keep things as short as possible, but basically, I have >>> a soap webservice created with the camel cxf component, running in karaf >>> 3.0.3, java 8 update 25, camel 2.15.2, cxf 3.0.4 (simple sample project >>> linked at the end) >>>>>>> >>>>>>> And if the jolokia-osgi bundle is installed, every call to my >>> webservice results in a rather nasty stack trace in the log file: >>>>>>> >>>>>>> 2015-07-18 14:37:03,379 | WARN | qtp23458725-67 | Response >>> | 71 - org.eclipse.jetty.aggregate.jetty-all-server - >>> 8.1.15.v20140411 | Committed before 401 null >>>>>>> 2015-07-18 14:37:03,379 | WARN | qtp23458725-67 | >>> AbstractHttpConnection | 71 - >>> org.eclipse.jetty.aggregate.jetty-all-server - 8.1.15.v20140411 | /cxf/test/ >>>>>>> java.lang.IllegalStateException: Committed >>>>>>>at >>> org.eclipse.jetty.server.Response.resetBuffer(Response.java:1154)[71:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411] >>>>>>>at >>> org.eclipse.jetty.server.Response.sendError(Response.java:317)[71:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411] >>>>>>>at >>> org.eclipse.jetty.server.Response.sendError(Response.java:419)[71:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411] >>>>>>>at >>> javax.servlet.http.HttpServletResponseWrapper.sendError(HttpServletResponseWrapper.java:137)[65:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0.0] >>>>>>>at >>> org.jolokia.osgi.security.BasicAuthenticationHttpContext.handleSecurity(BasicAuthenticationHttpContext.java:49)[144:org.jolokia.osgi:1.3.1] >>>>>>>at >>> org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:68)[80:org.ops4j.pax.web.pax-web-jetty:3.1.4] >>>>>>>at >>> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)[71:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411] >>>>>>> ... >>>>>>> >>>>>>> I abbreviated the trace, the full stack can be found in the jira >>> link further down, but you can see in the stack it's trying to call the >>> org.jolokia.osgi.security.BasicAuthenticationHttpContext, which is bizzare >>>>>>> >>>>>>> Ok, so first thing to mention, the webservice call works fine, and >>> works fine every time, the error in the logs occurs after the client >>> receives a successful response >>>>>>> >>>>>>> At first I thought this was an issue with pax-web, so I opened a >>> ticket over there: >>>>>>> >>>>>>> https://ops4j1.jira.com/browse/PAXWEB-863 >>>>>>> >>>>>>> Achim very nicely spent some time looking into this, and has not >>> been able to find any issues with the pax-web code. >>>>>>> >>>>>>> So out of curiosity, I setup a straight CXF soap webservice in the >>> same environment, and it works great, no errors even when jolokia is >>> installed. >>>>>>> >>>>>>> This has lead me over to camel, or how camel is using CXF >>>>>>> >>>>>>> I've spent a few hours with the debugger but I'm really not getting >>> anywhere, everything looks to me like jetty is processing the call through >>> camel/cxf as it should, and then a second process is made to through the >>> context jolokia registers when its installed, and this results in the error >>> (because the jolokia context looks for the Authorization header, doesn't >>> see it, throws an exception back to the client, but the connection to the >>> client is already closed because it was handled and closed in the >>> successful camel call) >>>>>>> >>>>>>> But this second call stack is mostly jetty and some pax-web >>> classes. So it doesn't look like camel code is directly causing this. >>>>>>> >>>>>>> Some of my thoughts are how the webservice is registered with cxf >>> and in turn with pax/jetty in the osgi environment, or maybe there is some >>> kind of missing "handled" notification to jetty to keep it from sending he >>> request to more contexts? I dunno if that second thing is real or not, >>> just thinking outloud. >>>>>>> >>>>>>> I made a sample project to make this easier to test: >>> https://github.com/erwelch/paxweb-863 >>>>>>> >>>>>>> I'm afraid I'm at a loss for how to further debug this, I'm not >>> convinced this is a camel issue, but since it's the case I can only >>> re-create this using camel, I'm hoping someone can help! >>>>>>> >>>>>>> Thanks, >>>>>>> Ed >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Claus Ibsen >>>>>> - >>>>>> http://davsclaus.com @davsclaus >>>>>> Camel in Action 2nd edition: http://www.manning.com/ibsen2 >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Claus Ibsen >>>> - >>>> http://davsclaus.com @davsclaus >>>> Camel in Action 2nd edition: http://www.manning.com/ibsen2 >>> >>> >>> >> >> >> -- >> >> Apache Member >> Apache Karaf <http://karaf.apache.org/> Committer & PMC >> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & >> Project Lead >> blog <http://notizblog.nierbeck.de/> >> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> >> >> Software Architect / Project Manager / Scrum Master > > -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Camel website is not showing the code blocks
Hmm… looks like they updated confluence and the new version has changed a bunch of the class names for various elements.That’s causing issues with the scripts for the code formatters, but there are also CSS issues due to the changed class names. Looking at it now. Dan > On Jun 29, 2015, at 1:48 AM, xlogger wrote: > > I tried with a few different browsers on my PC (Firefox, Chrome, and IE..) > but found that the code blocks in all the Camel web pages are not displaying > properly... it looks like they are all collapsed... It was Okay last week > when I browse around > > E.g. > http://camel.apache.org/content-based-router.html > <http://camel.465427.n5.nabble.com/file/n5768644/Apache_Camel_Content_Based_Router_-_Mozilla_Firefox_2015-06-29_13-44-32.png> > > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Camel-website-is-not-showing-the-code-blocks-tp5768644.html > Sent from the Camel - Users mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Adding jaas authentication to a cxf endpoint in karaf
I’ll let Sergey handle most of this, but….. > On Nov 3, 2014, at 6:12 AM, Hilderich wrote: > > > Last week I have commenced with an update to Karaf 3.0.2 but so far I am not > able to start my bundle because cxf bus in blueprint cannot initialized > (this part in bluprint.xml: ). Probably this > has something to do with wrong versions and missing imports. I am very > discouraged. > I’m a bit curious by this one. Do you have a test case for this? I’d really like to know what would cause this. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: WSS4JInInterceptor: The signature or decryption was invalid
On Mar 27, 2014, at 6:12 PM, chaij wrote: > Dan - I am using soapUI as a client to test this service. When the request > comes in, it says signature value invalid. > > This only occurs if I have a binary content attachment in the SOAP body. > > Do you know it would be a CXF related issue or soapUI issue? If there is a xop:include in there, then it’s definitely because CXF doesn’t support properly signing things when MTOM is turned on. If it’s inlined as base64, it SHOULD be working fine and SOAP UI should be able to validate the signature. Dan > It is hard to tell for me. > > Thanks! > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/WSS4JInInterceptor-The-signature-or-decryption-was-invalid-tp5749409p5749453.html > Sent from the Camel - Users mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: WSS4JInInterceptor: The signature or decryption was invalid
reProcessor.java:231)[159:org.apache.ws.security.wss4j:1.6.12] > at > org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:396)[159:org.apache.ws.security.wss4j:1.6.12] > at > org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:279)[162:org.apache.cxf.cxf-rt-ws-security:2.7.7] > ... 23 more > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/WSS4JInInterceptor-The-signature-or-decryption-was-invalid-tp5749409.html > Sent from the Camel - Users mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: HOW TO convert SOAPMessage to POJO
You would need to capture the SOAP message (wireshark or use the logging
interceptors) and double check that the SOAP message matches what you have
configured for the WSS4JInInterceptor.
Another suggestion is to subclass the WSS4JInInterceptor and override the
method:
protected boolean checkReceiverResultsAnyOrder(
List wsResult, List actions
)
to print out information about the actions in the wsResult list there to see
what was actually processed compared to the actions that were configured.
Here’s the full code for the method as it is now:
protected boolean checkReceiverResultsAnyOrder(
List wsResult, List actions
) {
List recordedActions = new ArrayList(actions.size());
for (Integer action : actions) {
recordedActions.add(action);
}
for (WSSecurityEngineResult result : wsResult) {
final Integer actInt = (Integer)
result.get(WSSecurityEngineResult.TAG_ACTION);
int act = actInt.intValue();
if (act == WSConstants.SC || act == WSConstants.BST) {
continue;
}
if (!recordedActions.remove(actInt)) {
return false;
}
}
if (!recordedActions.isEmpty()) {
return false;
}
return true;
}
Dan
On Mar 26, 2014, at 4:29 PM, chaij wrote:
> Dan - Your response has been very helpful and concrete enough for me to
> follow through. Really appreciate. I am relatively new to Camel.. has a lot
> to learn.
>
> I am facing the following issues when use CXF Endpoint POJO mode with WSS4J
> interceptors for security related processing.
>
> Please see this post for more details.
> http://camel.465427.n5.nabble.com/Camel-CXF-Proxy-with-WS-Security-td5749223i20.html
>
> org.apache.cxf.binding.soap.SoapFault: An error was discovered processing
> the header
>at
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.createSoapFault(WSS4JInInterceptor.java:788)[162:org.apache.cxf.cxf-rt-ws-security:2.7.7]
>at
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:336)[162:org.apache.cxf.cxf-rt-ws-security:2.7.7]
>at
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:95)[162:org.apache.cxf.cxf-rt-ws-security:2.7.7]
>at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)[122:org.apache.cxf.cxf-api:2.7.7]
>at
> org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:817)[122:org.apache.cxf.cxf-api:2.7.7]
>at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1606)[130:org.apache.cxf.cxf-rt-transports-http:2.7.7]
>at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream$1.run(HTTPConduit.java:1128)[130:org.apache.cxf.cxf-rt-transports-http:2.7.7]
>at
> org.apache.cxf.workqueue.AutomaticWorkQueueImpl$3.run(AutomaticWorkQueueImpl.java:428)[122:org.apache.cxf.cxf-api:2.7.7]
>at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_29]
>at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_29]
>at
> org.apache.cxf.workqueue.AutomaticWorkQueueImpl$AWQThreadFactory$1.run(AutomaticWorkQueueImpl.java:353)[122:org.apache.cxf.cxf-api:2.7.7]
>at java.lang.Thread.run(Thread.java:662)[:1.6.0_29]
> Caused by: org.apache.ws.security.WSSecurityException: An error was
> discovered processing the header
>at
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.checkActions(WSS4JInInterceptor.java:363)[162:org.apache.cxf.cxf-rt-ws-security:2.7.7]
>at
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:319)[162:org.apache.cxf.cxf-rt-ws-security:2.7.7]
>... 10 more
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/HOW-TO-convert-SOAPMessage-to-POJO-tp5749392p5749400.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: HOW TO convert SOAPMessage to POJO
On Mar 26, 2014, at 8:00 AM, chaij wrote:
> I use CXF endpoint in CXF_MESSAGE format. The incoming message body is type
> of SOAPMessage.
>
> This request is wsdl first approach and I have access to all the wsdl2java
> generated classes. I wonder if there is an easy way to convert this message
> to POJO?
> Camel must be doing it since that is behavior when CXF endpoint data format
> is POJO.
If you need the POJO’s, just use the CXF POJO mode. CXF will then unmarshall
the incoming data directly into the JAXB objects and avoid all the intermediary
types which can consume extra memory and processing time and such.
If you NEED to use CXF_MESSAGE (and there shouldn’t be any reason to use
CXF_MESSAGE), then you would need to do something like an XPath to select the
first element in the soap:Body element and then a convert using the JAXB data
binding thing. Something like:
DataFormat jaxb = new JaxbDataFormat("com.acme.model");
from (“cxf:….”)
.filter().xpath(“//soap:Body/*”, new Namespaces(“soap”,
“http://schemas.xmlsoap.org/wsdl/soap/”))
.unmarshall(jaxb)
.to(…….)
Like I said though, don’t do that unless there really is a big reason for it,
which usually there is not. Just let CXF do it’s job.
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Camel CXF Proxy with WS-Security
This error is occurring from the action checking. Double check your actions on your Wss4jInInterceptor configuration. In particular, should the UsernameToken be there? I don’t think a service would send BACK a username token. Dan On Mar 24, 2014, at 10:39 PM, chaij wrote: > Dan - This is the exception I got if I use the default format which should be > POJO. > > org.apache.cxf.binding.soap.SoapFault: An error was discovered processing > the header > at > org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.createSoapFault(WSS4JInInterceptor.java:788)[162:org.apache.cxf.cxf-rt-ws-security:2.7.7] > at > org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:336)[162:org.apache.cxf.cxf-rt-ws-security:2.7.7] > at > org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:95)[162:org.apache.cxf.cxf-rt-ws-security:2.7.7] > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)[122:org.apache.cxf.cxf-api:2.7.7] > at > org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:817)[122:org.apache.cxf.cxf-api:2.7.7] > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1606)[130:org.apache.cxf.cxf-rt-transports-http:2.7.7] > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream$1.run(HTTPConduit.java:1128)[130:org.apache.cxf.cxf-rt-transports-http:2.7.7] > at > org.apache.cxf.workqueue.AutomaticWorkQueueImpl$3.run(AutomaticWorkQueueImpl.java:428)[122:org.apache.cxf.cxf-api:2.7.7] > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_29] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_29] > at > org.apache.cxf.workqueue.AutomaticWorkQueueImpl$AWQThreadFactory$1.run(AutomaticWorkQueueImpl.java:353)[122:org.apache.cxf.cxf-api:2.7.7] > at java.lang.Thread.run(Thread.java:662)[:1.6.0_29] > Caused by: org.apache.ws.security.WSSecurityException: An error was > discovered processing the header > at > org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.checkActions(WSS4JInInterceptor.java:363)[162:org.apache.cxf.cxf-rt-ws-security:2.7.7] > at > org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:319)[162:org.apache.cxf.cxf-rt-ws-security:2.7.7] > ... 10 more > > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Camel-CXF-Proxy-with-WS-Security-tp5749223p5749308.html > Sent from the Camel - Users mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Camel CXF Proxy with WS-Security
On Mar 24, 2014, at 9:52 PM, chaij wrote: > So I should do exchange.getOut().setBody(soapMessage) and leave the > exchange.getIn().getHeaders() behind since it has a lot of other information > which should not be relevant? > > I saw you added convertBody to String for SOAPMessage. It would be really > nice if there is one to do the reverse. Take the string and rightfully > construct the SOAPMessage. You could try setting the body with a "new StreamSource(new StringReader(string))”. That would force it to be XML. Dan > > Appreciate your feedback. > > Thanks! > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Camel-CXF-Proxy-with-WS-Security-tp5749223p5749304.html > Sent from the Camel - Users mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Camel CXF Proxy with WS-Security
On Mar 24, 2014, at 11:00 AM, chaij wrote: > Also, everything works fine with POJO data format which I was using before. I > was able to send request and get response from soapUI mockup service. > > Now, since I need to add security, I have to switch to CXF_MESSAGE format. > Things doesn't work anymore. Why do you have to switch to CXF_MESSAGE mode for security? I don’t understand why you think you need CXF_MESSAGE mode for the security stuff. It should work with POJO as well. Dan > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Camel-CXF-Proxy-with-WS-Security-tp5749223p5749283.html > Sent from the Camel - Users mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Camel CXF Proxy with WS-Security
Is it JUST the namespace that needs to be changed? One option would be to have CXF do that while reading or writing messages by use CXF’s transform feature: https://cwiki.apache.org/confluence/display/CXF20DOC/TransformationFeature It’s primary purpose was to handle Namespace mapping and minor XML changes while reading in messages or writing messages. That could help simplify things a bit for you. Dan On Mar 24, 2014, at 10:39 AM, chaij wrote: > I don't really know what needs to done with the Camel message headers. I > couldn't find documentation on how to use CXF_MESSAGE. I think that's the > issue. > > When I feed the soap envelope in string format to CXF endpoint, the SOAP > body is empty when coming out the endpoint. > > To recap what I need: > > proxy client ->CXF Endpoint->processor to modify namespace and values > etc->CXF Endpoint with Security->Real Service > > I am stuck on the processor. How to process the incoming message and then > feed it to the next CXF Endpoint in CXF_MESSAGE format since security is > needed. > > Can some expert help out here? > > Thanks, > Jin > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Camel-CXF-Proxy-with-WS-Security-tp5749223p5749280.html > Sent from the Camel - Users mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Cross war comms using direct-vm and cxf
You should be able to use the Local transport, but as you said, it’s not exactly easy. It would likely also require you to have the CXF jars in the shared/lib area of your app server so that the actual java classes are shared and can be cast to one another. You’d probably need to create a very small jar (also in shared/lib) with a Spring factory thing that would return a LocalTransportFactory singleton (instead of a new instance per bus). Each of your wars would then grab their LocalTranportFactory via that factory.May also be able to do it via a BusLIstener or similar that would register a singleton factory for each bus that is created. Dan On Feb 9, 2014, at 5:21 PM, Mandy Warren wrote: > Hi, > > I've just started looking at Camel and I was wondering whether there was a > way to call from a CXF rest service deployed in war A to a CXF rest service > deployed in war B without the overhead of an HTTP call if both wars are > deployed in the same JVM? > > Some background to my requirement.. > - we have a large number of cxf services deployed in weblogic and a single > service may call 2 or 3 other services to complete its work. We'd ideally > like the calls to be made on a single thread when the calls are within the > same JVM as it makes debugging much easier. > > Local transport in CXF looks ideal except it doesn't work across wars (at > least I haven't managed to make it work). > > direct-vm looks interesting but I don't want the 2 services to be dependent > on each others service interface classes - instead I'd just like to pass a > JSON request between the 2 services and then have something execute the > appropriate rest service (and it's interceptors ideally). > > Is there any way to achieve this? > > Many thanks > Mandy -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Exposing a Remote Web Service written in Axis2
omponent.cxf.CxfConsumer.(CxfConsumer.java:62) > at > org.apache.camel.component.cxf.CxfEndpoint.createConsumer(CxfEndpoint.java:203) > at > org.apache.camel.impl.EventDrivenConsumerRoute.addServices(EventDrivenConsumerRoute.java:65) > at > org.apache.camel.impl.DefaultRoute.onStartingServices(DefaultRoute.java:80) > at org.apache.camel.impl.RouteService.warmUp(RouteService.java:133) > at > org.apache.camel.impl.DefaultCamelContext.doWarmUpRoutes(DefaultCamelContext.java:2011) > at > org.apache.camel.impl.DefaultCamelContext.safelyStartRouteServices(DefaultCamelContext.java:1939) > at > org.apache.camel.impl.DefaultCamelContext.doStartOrResumeRoutes(DefaultCamelContext.java:1727) > at > org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:1608) > at > org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:1475) > at > org.apache.camel.spring.SpringCamelContext.doStart(SpringCamelContext.java:179) > at org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61) > at > org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:1443) > at > org.apache.camel.spring.SpringCamelContext.maybeStart(SpringCamelContext.java:228) > at > org.apache.camel.spring.SpringCamelContext.onApplicationEvent(SpringCamelContext.java:118) > ... 10 more > > > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Exposing-a-Remote-Web-Service-written-in-Axis2-tp5743186.html > Sent from the Camel - Users mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: How to expose a remote Web Service
On Nov 12, 2013, at 12:00 PM, madusanka wrote: > Hi, > > So is there any way I can expose an Axis2 Web Service in Apache Camel ? Depends on what you are trying to do really. If you have an existing web service someplace (doesn’t matter what it’s using to implement it) and you want to create some sort of route to it or some sort of proxy in front of it, you can easily do that with Camel using a variety of possible components including the CXF component, soap component, etc… If you actually want to run the Axis2 service in Camel and have Camel route to it directly, that wouldn’t be possible right now. However, that’s not a “normal” case I think. Most of the time, you already have an Axis2 service running and you just need to proxy over it or route information to it in which case the capabilities of Camel already should be fine. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Spring ASM issue with Camel + CXF
I’d suggest a “mvn dependency:tree” and see what’s there. It sounds like a mis-match of versions of spring jars. Possibly a 3.2.x version of spring-asm being picked up but a 3.1.x version of core or similar. Dan On Oct 23, 2013, at 1:59 PM, Charles Moulliard wrote: > Hi, > > Using Spring 3.1.3.RELEASE + Camel 2.12.1 + CXF 2.7.7, I get this exception > > java.lang.IncompatibleClassChangeError: class > org.springframework.core.LocalVariableTableParameterNameDiscoverer$ParameterNameDiscoveringVisitor > has interface org.springframework.asm.ClassVisitor as super class > > when I run Camel in Tomcat (but I can also reproduce this error when > running locally my camel project so they are not related). > > https://gist.github.com/7123359 > > I have added this exclusion to camel-cxf but that does not help a lot > > >org.apache.camel >camel-cxf > > >org.springframework >spring-asm > > > > > but that does not help a lot. Any idea is welcome ? > > Regards, > > -- > Charles Moulliard > Apache Committer / Architect @RedHat > Twitter : @cmoulliard | Blog : http://cmoulliard.github.io -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: SyntaxHighlighter cannot find brush for: xml
Sighh… *NOW* fixed. Dan On Jun 26, 2013, at 11:29 AM, Daniel Kulp wrote: > No fixed. > > Thanks! > Dan > > > > On Jun 26, 2013, at 9:47 AM, ikoblik wrote: > >> Hello, >> >> Just wanted to report a minor issue on this page: >> http://camel.apache.org/using-camelproxy.html >> >> When loading SyntaxHighlighter complains that it cannot find brush for XML >> and because of it XML example is not displayed. >> >> Ivan. >> >> >> >> -- >> View this message in context: >> http://camel.465427.n5.nabble.com/SyntaxHighlighter-cannot-find-brush-for-xml-tp5734811.html >> Sent from the Camel - Users mailing list archive at Nabble.com. > > -- > Daniel Kulp > dk...@apache.org - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: SyntaxHighlighter cannot find brush for: xml
No fixed. Thanks! Dan On Jun 26, 2013, at 9:47 AM, ikoblik wrote: > Hello, > > Just wanted to report a minor issue on this page: > http://camel.apache.org/using-camelproxy.html > > When loading SyntaxHighlighter complains that it cannot find brush for XML > and because of it XML example is not displayed. > > Ivan. > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/SyntaxHighlighter-cannot-find-brush-for-xml-tp5734811.html > Sent from the Camel - Users mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: SyntaxHighlighter cannot find brush for: xml
On Jun 26, 2013, at 9:47 AM, ikoblik wrote:
> Hello,
>
> Just wanted to report a minor issue on this page:
> http://camel.apache.org/using-camelproxy.html
>
> When loading SyntaxHighlighter complains that it cannot find brush for XML
> and because of it XML example is not displayed.
Thanks. I'll fix it.
That page is using the {snippet} macro for that which the exporter isn't taking
into account when trying to build the list of brushes to include. The
exporter right now is just looking at the {code} macros. I'll get that
updated.
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: cxf producer needs a break?
What version of the JDK are you using?Can you back up a few versions?
There is a bug introduced in 1.6 update 38 that can cause some of the
keep-alive handling in the JDK to mis-behave. This might be a symptom of this.
Dan
On Apr 9, 2013, at 6:58 PM, Smith-John wrote:
> Hi,
>
> I have a strange (at least for me) issue with my route respectively the cxf
> component in it.
>
> The route looks like
> from("cxf:XXX?wsdlURL=YYY&...")to(...)...to("cxf:${header[ReplyTo]}?wsdlURL=YYY&...");
>
> I get a one way SOAP message, do some work with it and send a response back
> to the callback address specified.
>
> In principle this works perfect.
> But sending requests with a short interval, I would say less than 5 seconds
> between the requests, the messaging fails.
> Sending requests every > 5 seconds: no problem.
> Sending requests with time between them < 5 seconds: all except the first
> one fail.
>
> I'm using camel 2.10.4 and for sending the requests SoapUI.
>
> Unfortunately the console shows no errors. The only difference between a
> working and a not working try is the last DEBUG notification that is
> [default-workqueue-1] DEBUG o.a.c.c.cxf.CxfClientCallback -
> default-workqueue-1 calling handleResponse
> for a working one and
> [default-workqueue-2] DEBUG o.a.c.c.cxf.CxfClientCallback -
> default-workqueue-2 calling handleException
> for a failing one.
>
> Is this a bug or normal behaviour? Is there something to prevent this?
>
> Best regards.
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/cxf-producer-needs-a-break-tp5730612.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: CXF Example OSGi
On Apr 9, 2013, at 3:16 PM, Christian Müller wrote: > dev:dynamic-import will resolve this > issue. It's the missing import of > > Apache CXF Runtime Core (116): META-INF.cxf; version=2.6.6 > > which cause this issue. > I will resolve this for Camel 2.10.5 and 2.11.1 and add a note to the know > issues. Thanks for reporting! This shouldn't be an issue for 2.11 as that import was removed from the spring.xml. Dan > > Best, > Christian > > > On Tue, Apr 9, 2013 at 1:04 AM, Krzysztof Sobkowiak < > krzys.sobkow...@gmail.com> wrote: > >> ** >> >> Hi >> >> >> >> I'm trying to deploy camel-example-cxf-osgi/2.10.4 on Karaf 2.3.1 or SMX >> 4.5.1 using following commands (as described in >> http://camel.apache.org/cxf-example-osgi.html) >> >> >> >> in Karaf i have to add Camel features first >> >> features:chooseurl camel 2.10.4 >> >> >> >> and next (Karaf or SMX) >> >> >> >> >> >> features:install war >> >> features:install cxf >> >> features:install camel-spring >> >> features:install camel-jaxb >> >> features:install camel-cxf >> >> osgi:install -s mvn:org.apache.camel/camel-example-cxf-osgi/2.10.4 >> >> After installing the sample bundle the spring context fails to start >> >> [ 176] [Active ] [] [Failed ] [ 80] camel-example-cxf-osgi >> (2.10.4) >> >> In the log file I can see following error (full stacktrace attached) >> >> >> >> Caused by: java.io.FileNotFoundException: OSGi >> resource[classpath:META-INF/cxf/cxf.xml|bnd.id=176|bnd.sym=org.apache.camel.camel-example-cxf-osgi] >> cannot be resolved to URL because it does not exist >> >> >> I could successfully install the camel-example-cxf-osgi/2.9.0 >> >> I thing my problem is caused by >> https://issues.apache.org/jira/browse/CAMEL-5441 which removes the >> META-INF.cxf from the imports of the example bundle >> (https://github.com/apache/camel/commit/73c3d4fd2a306557be8f79b502697fe3cd475695#examples/camel-example-cxf-osgi/pom.xml) >> >> Was this removal correct? I don't understand why this files should by loaded >> by Spring DM and why it is not necessary to import them. >> >> Could you write me the correct steps for successful installation of the >> sample? >> >> >> Best regards >> >> Krzysztof >> >> >> >> -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Issue using camel-cxf and wss4j
On Jan 10, 2013, at 4:37 AM, Charles Moulliard wrote: > I don't find info about this dataFormat (CXF_MESSAGE) in CXF. Does it exist > ? Yes it exists, but I'm really not exactly happy about how it works. I'd like to kind of "redo" it, but it would require a lot of internal CXF changes which I haven't had time to figure all out either. Basically: MESSAGE/RAW mode sucks from a CXF standpoint as pretty much all the CXF processing is bypassed. (that's the problem you saw) What's super confusing about it is that is also REMOVES things that the user may be relying on (like the SAAJ interceptors) that then can result in very strange error messages. (again what you saw) Really, I'm unsure why you wouldn't just use a pure HTTP component for most of this OTHER than for the WSDL generation, but even that is kind of doable if you have a static WSDL pre-generated. In any case, my gut feeling is that a pure http component would perform slightly better.For the most part, the advantage of this over the other two modes is performance though. Keeps the raw byte streaming, very little processing. PAYLOAD does allow all of the proper CXF processing. Using StAX, it can also do a lot of "xml streaming", but XML streaming is much slower than byte streaming due to the parsing and such. HOWEVER, PAYLOAD just gives the contents of the Body. If you need to route the soap headers and attachments and such along as well, you need to do more work. I was hoping that CXF_MESSAGE could be somewhere in the middle where you could have CXF process everything correctly, but still be able to route on the full message. HOWEVER, with the way CXF works internally, we have to build up a full SAAJ model in this case. Thus, ALL of the streaming does not work in CXF_MESSAGE mode. This is what I was hoping to somehow change, but would require a ton of work in CXF. :-(I'd like to be able to optimize this isn't something closer to how the PAYLOAD mode works with the XML streaming, but definitely requires a lot of work in CXF first. That said, when using WS-Security, we have to build the full SAAJ model anyway so the broken streaming wouldn't be an issue. Dan > On Thu, Jan 10, 2013 at 8:43 AM, Willem jiang wrote: > >> CXF_MESSAGE > > > > > -- > Charles Moulliard > Apache Committer / Sr. Enterprise Architect (RedHat) > Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: CXF proxy for ws security
On Nov 21, 2012, at 5:51 AM, Jesper Nygårds wrote: > Great thanks, Daniel! > > That solved the problem. I have a hard time finding any documentation about > CXF_MESSAGE mode. What is the difference between this and the PAYLOAD mode? MESSAGE (or RAW) pretty much is equivalent to passing a raw InputStream through the system. Most of CXF's handling is bypassed. For the most part, this would be very close to just using the Jetty or other http component, although there are somethings that the CXF component can do in this scenario (like generate the WSDL). CXF_MESSAGE mode is similar to the JAX-WS Message mode for Provider/Dispatch clients where the entire message is available in the route. All of the CXF processing is available as this is handled internally just like the Provider/Dispatches. Downside is that the entire message is parsed and is likely in memory (SAAJ). PAYLOAD mode is somewhat similar to the PAYLOAD mode for Provider/Dispatches. The only information available in the route is the contents of the soap:Body. However, CXF's processing is more optimized for this use case which, in some scenarios, allows streaming to continue for this. However, it's a StAX based streaming, not input/output stream based streaming like in MESSAGE/RAW mode. Also, in PAYLOAD mode, I believe that since it's just the body pushed through the route, things like headers are, by default, stripped off. In CXF_MESSAGE mode, you may need to write some code to remove headers. (conversely, in PAYLOAD mode, you may need code to copy headers if needed) There are upsides and downsides for each of the three modes. Dan > > Jesper > > > > On Tue, Nov 20, 2012 at 9:31 PM, Daniel Kulp wrote: > >> >> With MESSAGE mode, camel-cxf pretty much keeps everything as a stream and >> bypasses much of the CXF interceptor chain and conversions and such. In >> some cases, that's very good. Performance and stuff works well. However, >> it also means a lot of CXF's processing capabilities are not used/usable. >> >> If you flip to PAYLOAD mode or the new CXF_MESSAGE mode, it will likely >> work find for you. Those will behave more like normal CXF clients/servers >> that would allow all the ws-security stuff to work. >> >> Dan >> >> >> >> On Nov 20, 2012, at 10:01 AM, Jesper Nygårds >> wrote: >> >>> I have a scenario where I want to add wss signing to an outgoing web >>> service call. I am trying to accomplish this by using a cxf consumer and >> a >>> cxf producer wired together by camel as a simple proxy. >>> >>> The idea is this: a system sends an un-signed SOAP request to our CXF web >>> service requiring no security. The call is then routed to a CXF client, >>> which signs th eoutgoing message using wss. This way, the original caller >>> does not concern itself with any security related issues. >>> >>> I have included our spring configuration below. The problem is that the >>> call gets routed as it should through the two CXF beans, but the outgoing >>> call leaves the CXF client without being signed. There is no trace of any >>> wss headers in the outgoing call. >>> >>> Turning on debugging, I can see that the WSS4JOutInterceptor is invoked, >>> and it writes to the debug messages that it has created a >>> xmldsig:SignedInfo element, but this is never added to the outgoing >>> message. Can anyone here throw some light on this problem? >>> >>> Here's the configuration: >>> >>> >>> >>> http://www.springframework.org/schema/beans"; xmlns:xsi=" >>> http://www.w3.org/2001/XMLSchema-instance"; xmlns:camel=" >>> http://camel.apache.org/schema/spring"; >>> xmlns:cxf="http://camel.apache.org/schema/cxf"; xmlns:context=" >>> http://www.springframework.org/schema/context"; >>> xsi:schemaLocation="http://www.springframework.org/schema/beans >>> http://www.springframework.org/schema/beans/spring-beans.xsd >>> http://www.springframework.org/schema/context >>> http://www.springframework.org/schema/context/spring-context.xsd >>> http://camel.apache.org/schema/spring >>> http://camel.apache.org/schema/spring/camel-spring.xsd >>> http://camel.apache.org/schema/cxf >>> http://camel.apache.org/schema/cxf/camel-cxf.xsd";> >>> >>> >>> >>> >> wsdlURL="etc/SendOccupationalPensionService.wsdl" >>> address="/sendOccupationalPen
Re: CXF and Camel Compatibility - noSuchMethod getBindingOperationInfo()
.java:179) > at > org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:108) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:621) > at > org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:225) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169) > at > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98) > at > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) > at > org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:999) > at > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:565) > at > org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:309) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > Caused by: *java.lang.NoSuchMethodError: > org.apache.cxf.message.Exchange.getBindingOperationInfo()Lorg/apache/cxf/service/model/BindingOperationInfo;* > at > org.apache.camel.component.cxf.CxfConsumer$1.perpareCamelExchange(CxfConsumer.java:140) > at > org.apache.camel.component.cxf.CxfConsumer$1.syncInvoke(CxfConsumer.java:117) > at > org.apache.camel.component.cxf.CxfConsumer$1.invoke(CxfConsumer.java:71) > at > org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at > org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37) > at > org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:106) > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/CXF-and-Camel-Compatibility-noSuchMethod-getBindingOperationInfo-tp5722954.html > Sent from the Camel - Users mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: CXF proxy for ws security
With MESSAGE mode, camel-cxf pretty much keeps everything as a stream and
bypasses much of the CXF interceptor chain and conversions and such. In some
cases, that's very good. Performance and stuff works well. However, it also
means a lot of CXF's processing capabilities are not used/usable.
If you flip to PAYLOAD mode or the new CXF_MESSAGE mode, it will likely work
find for you. Those will behave more like normal CXF clients/servers that
would allow all the ws-security stuff to work.
Dan
On Nov 20, 2012, at 10:01 AM, Jesper Nygårds wrote:
> I have a scenario where I want to add wss signing to an outgoing web
> service call. I am trying to accomplish this by using a cxf consumer and a
> cxf producer wired together by camel as a simple proxy.
>
> The idea is this: a system sends an un-signed SOAP request to our CXF web
> service requiring no security. The call is then routed to a CXF client,
> which signs th eoutgoing message using wss. This way, the original caller
> does not concern itself with any security related issues.
>
> I have included our spring configuration below. The problem is that the
> call gets routed as it should through the two CXF beans, but the outgoing
> call leaves the CXF client without being signed. There is no trace of any
> wss headers in the outgoing call.
>
> Turning on debugging, I can see that the WSS4JOutInterceptor is invoked,
> and it writes to the debug messages that it has created a
> xmldsig:SignedInfo element, but this is never added to the outgoing
> message. Can anyone here throw some light on this problem?
>
> Here's the configuration:
>
>
>
> http://www.springframework.org/schema/beans"; xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance"; xmlns:camel="
> http://camel.apache.org/schema/spring";
>xmlns:cxf="http://camel.apache.org/schema/cxf"; xmlns:context="
> http://www.springframework.org/schema/context";
>xsi:schemaLocation="http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd
> http://www.springframework.org/schema/context
> http://www.springframework.org/schema/context/spring-context.xsd
> http://camel.apache.org/schema/spring
> http://camel.apache.org/schema/spring/camel-spring.xsd
> http://camel.apache.org/schema/cxf
> http://camel.apache.org/schema/cxf/camel-cxf.xsd";>
>
>
>
> wsdlURL="etc/SendOccupationalPensionService.wsdl"
> address="/sendOccupationalPension"
>serviceName="s:SendOccupationalPensionService" xmlns:s="
> http://ssek.ic.afa.se/";>
>
>
>
>
>
>http://localhost:8088/mockSendOccupationalPensionResponseToFKSOAPBinding";>
>
>
>
>
> class="org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor">
>
>
>
>
> value="DirectReference" />
>
> value="classpath:etc/ssek.serviceKeystore.properties" />
>
> class="se.afa.ic.ssek.ServiceKeystorePasswordCallback">
>
>myservicekey
>
>
>skpass
>
>
>
> value="{Element}{
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp;{Element}{http://schemas.xmlsoap.org/soap/envelope/}Body";
> />
>
>
>
>
>
>
>http://camel.apache.org/schema/spring";>
>
>
>
>
>
>
>
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Dependency to jaxb-impl
On Nov 2, 2012, at 9:23 AM, PJ Walstroem wrote: > hello, > I see that camel-core, camel-jms and camel-spring transitively depends on > jaxb-impl. What would be the reason for that? There are a bunch of things we do that require a fully working and stable version of JAXB which is not something you really get if you completely depend on the version in the JDK. The version in the JDK will depend completely on what version of the JDK you grab (1.7.0_01 vs 1.7.0_07 for example) with each having different bugs and such. In addition, some of the new features that have been developed recently require the jaxb-impl, not the in-jdk version. In particular, we added the ability to control the namespace prefixes and locations that are output when using the JAXB component. That requires the jaxb-impl as all the package names are different for the in-jdk versions. If you don't use the camel jaxb component/databindings and you can live with the bugs and issues from the in-jdk version, you can likely use the exclusion. However, you may be better off with adding a more recent and stable JAX-WS implementation as a dependency (CXF 2.7.0 for example or even the latest RI: http://repo1.maven.org/maven2/com/sun/xml//ws/jaxws-rt/2.2.7/) which should be set to work correctly with the jaxb-impl dependency. Dan > This causes some problems when using jax-ws. > > java.lang.ClassCastException: com.sun.xml.bind.v2.runtime.JAXBContextImpl > cannot be cast to com.sun.xml.internal.bind.api.JAXBRIContext at > com.sun.xml.internal.ws.fault.SOAPFaultBuilder > > I had to do > > com.sun.xml.bind > jaxb-impl > > > to prevent the ClassCastException > > using Camel 2.10.2 and Java 1.7.0_07 > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Dependency-to-jaxb-impl-tp5722030.html > Sent from the Camel - Users mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Issue with Camel + CXF + Blueprint
rker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_35] >at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_35] >at java.lang.Thread.run(Thread.java:680)[:1.6.0_35] > Caused by: org.apache.cxf.service.factory.ServiceConstructionException >at > org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:176) >at > org.apache.camel.component.cxf.CxfConsumer.(CxfConsumer.java:226) >at > org.apache.camel.component.cxf.CxfEndpoint.createConsumer(CxfEndpoint.java:202) >at > org.apache.camel.impl.EventDrivenConsumerRoute.addServices(EventDrivenConsumerRoute.java:65) >at > org.apache.camel.impl.DefaultRoute.onStartingServices(DefaultRoute.java:80) >at org.apache.camel.impl.RouteService.warmUp(RouteService.java:133) >at > org.apache.camel.impl.DefaultCamelContext.doWarmUpRoutes(DefaultCamelContext.java:1971) >at > org.apache.camel.impl.DefaultCamelContext.safelyStartRouteServices(DefaultCamelContext.java:1899) >at > org.apache.camel.impl.DefaultCamelContext.doStartOrResumeRoutes(DefaultCamelContext.java:1692) >at > org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:1580) >at > org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:1437) >at org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:60) >at > org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:1405) >at > org.apache.camel.blueprint.BlueprintCamelContext.maybeStart(BlueprintCamelContext.java:86) >at > org.apache.camel.blueprint.BlueprintCamelContext.init(BlueprintCamelContext.java:78) >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native > Method)[:1.6.0_35] >at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)[:1.6.0_35] >at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)[:1.6.0_35] >at java.lang.reflect.Method.invoke(Method.java:597)[:1.6.0_35] >at > org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:225)[10:org.apache.aries.blueprint:0.3.2] >at > org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:838)[10:org.apache.aries.blueprint:0.3.2] >at > org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:638)[10:org.apache.aries.blueprint:0.3.2] >... 15 more > Caused by: org.apache.cxf.BusException: NO_BINDING_FACTORY_EXC >at > org.apache.cxf.bus.managers.BindingFactoryManagerImpl.getBindingFactory(BindingFactoryManagerImpl.java:123) >at > org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:115) >at > org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:159) >... 36 more > > > Best, > Christian > > -- -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: business case for migration
Related to #2 in Christian's list are bugs and issues in some of the third party dependencies. If you need fixes in things like CXF or ActiveMQ or similar, you may need to move to the latest Camel releases to be able to use those fixes. As a concrete example, if you are using camel-cxf with Camel 2.5.0, you are vulnerable to several security vulnerabilities: http://cxf.apache.org/security-advisories.html However, to get fixes for some of the vulnerabilities, you would need to move up to the latest Camel releases that will work with the latest CXF releases. In general, if you can keep your business close to "up to date", if a security vulnerability is discovered, it's a LOT quicker and easier to upgrade to the fixed versions.Jumping up several versions in a timely manner to address a security issue can be challenge. Updating just a patch can be significantly quicker and cheaper. Dan On Sep 24, 2012, at 4:30 PM, Christian Müller wrote: > 1) You have to pay to get support for older version or you have to do it by > your own. Both cases has costs... > > 2) If you check our issue tracker [1] you will see we fixed 720 issues > which are considered as bug starting with Camel 2.5.0 to 2.10.1 (the latest > version). > 2293 issues in total, by the way... > It's likely you will hit a few of them if you use a very old version. To > find the issue and fix it (by your own) or find a workaround also has > costs... > > 3) If you violate your SLA because of an issues, you may have to pay > penalty. More important, you will lose confidence... At the end, it's > money... > > Hope this will help... > > [1] https://issues.apache.org/jira/browse/CAMEL > > Best, > Christian > > On Mon, Sep 24, 2012 at 8:16 PM, anoordover wrote: > >> As a java-developer I think it is very important to migrate when new >> versions >> are released. >> Currently we are running camel 2.4.2. >> I think that we should migrate to 2.9 or 2.10, but I find it hard to define >> a business-case for this. >> So "sell" that migration is neccesary. >> How should I support it that this is really needed. >> Any ideas? >> >> >> >> -- >> View this message in context: >> http://camel.465427.n5.nabble.com/business-case-for-migration-tp5719868.html >> Sent from the Camel - Users mailing list archive at Nabble.com. >> > > > > -- -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Issue using camel + cxf in an unit test
It's a semi-Jetty issue. If you use Keep-Alive connections (the default), Jetty has issues shutting down the port for some reason. It holds the port in some sort of strange semi-open state that accepts connections but doesn't properly process things. Never really had time to investigate any potential workarounds or fixes. Couple of solutions: 1) Turn off the keep-alives in the connections 2) Put a "Thread.sleep(6)" between the tests. (might just be 1) to wait for the keep-alive to timeout. Yea, not recommended, but thought I'd mention it. :-) 3) Set the System property: "org.apache.cxf.transports.http_jetty.DontClosePort." + port (port is the port number you are using) to true. which tells CXF to just keep the port open and not make any attempt to close it. Thus, when the second server starts up, it just registers on the already running instance. This is what we do for all the Camel and CXF unit/system tests. Dan On Aug 29, 2012, at 12:25 PM, Charles Moulliard wrote: > Hi, > > I have a unit test issue with camel (2.7.1) and cxf. One camel test class > (extending CamelSpringTestSupport) contain 2 unit tests where we call a web > service exposed by a camel route using a CamelProducerTemplate. Tests > executed individually pass well but If I would like to execute both tests, > I get an exception that the jetty server of CXF cannot respond on the > socket. I have tried to add @DirtiesContext for each individual unit test > (to force Spring to create a new CamelContext) but that does not help. It > seems that when the second test is executed by Junit/Spring, it tries to > call the Jetty server created during execution of the first test. > > Any idea is welcome ? > > Regards, > -- > Charles Moulliard > Apache Committer / Sr. Pr. Consultant at FuseSource.com > Twitter : @cmoulliard > Blog : http://cmoulliard.blogspot.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: camel-cxf and HTTP BASIC authentication
Are you using a pax-web based endpoint (address like "/foo") or a full CXF controlled Jetty port? (http://0.0.0.0:8080/foo) For the former, you'd have to look into how you can configure the pax-web stuff. I'm not really sure. For the latter, you would need to configure stuff into the jetty instance. You can use one of the CXF system tests as an example: http://svn.apache.org/repos/asf/cxf/trunk/systests/transports/src/test/java/org/apache/cxf/systest/http_jetty/ See the jettyBasicAuthServer.xml and jetty-realm.properties files as examples. That said, not sure how will that would work in OSGi. Dan On Tuesday, July 17, 2012 11:30:29 PM Christian Müller wrote: > Thanks Yogesh for taking time for my question. > > The information in [1] only helps for the client site (unit testing), but > I have to provide this service (the server part). > The information in [2] and [3] are useful how to implement such kind of > CXF interceptor, but I still hope there is an existing solution in CXF or > Jetty which doesn't force me to implement this. May be only a simple > PasswordCallback or so... > > [1] > http://cxf.apache.org/docs/client-http-transport-including-ssl-support.htm > l [2] > http://chrisdail.com/2008/03/31/apache-cxf-with-http-basic-authentication/ > [3] > http://chrisdail.com/2008/08/13/http-basic-authentication-with-apache-cxf- > revisited/ > > Best, > Christian > > On Tue, Jul 17, 2012 at 9:45 PM, ychawla wrote: > > Hi Christian, > > What about adding an HTTP Conduit to your CXF bean? > > > > http://cxf.apache.org/docs/client-http-transport-including-ssl-support.h > > tml > > > > Is your requirement for inbound or outbound HTTP basic auth? Depending > > on your container, you might be able to do this at the Apache HTTPD or > > Tomcat layer as well. > > > > Thanks, > > Yogesh > > > > -- > > View this message in context: > > http://camel.465427.n5.nabble.com/camel-cxf-and-HTTP-BASIC-authenticatio > > n-tp5716163p5716169.html Sent from the Camel - Users mailing list > > archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Improving the Documentation (Articles, Presentations, etc.)
I agree.CXF had a user help out with the same kind of problem on the CXF site. Result looks much better: http://cxf.apache.org/resources-and-articles.html Dan On Thursday, May 17, 2012 12:27:48 PM megachucky wrote: > Apache Camel is growing every month... > > IMO, one single page for articles, presentations, bloggers, etc. is not > enough (http://camel.apache.org/articles.html). Besides, the site is > outdated a lot (e.g. there are so many good slides about Camel available > in the meantime). > > I would suggest to either rename the site (it is not just articles) or > separate it into more than one site (e.g. articles, presentations, and > other resources). > > Besides, the content should obtain a better structure. For example, all > articles are "just" listed. There is no structure (e.g. introduction, > advanced, non-english, specific problem area such as cloud, ...). > > As Claus already gave me rights to edit the Camel documentation, I would > improve this a little bit, when I find some time... > > What are your thoughts ??? > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Improving-the-Documentation-Articles-Pr > esentations-etc-tp5711559.html Sent from the Camel - Users mailing list > archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Help with a Karaf/Camel/Cxf/ActiveMQ setup that results in an NPE
Hmm... Not really sure what the actual cause is. Can you wireshark the interaction and see what did get written? From the stack trace, it looks like a request came in, it was processed, a response was started to be written out. During writing the response, some exception occurred from Jetty (no idea why... maybe client closed the stream or something). At that point, the fault chain was started. However, since at least part of the response was written out already, you get that exception. Basically, when streaming responses, it's nearly impossible to recover from exceptions. That's the stack trace you are seeing. I'm NOT sure what jetty is doing to cause the NPE in Jetty. No idea on that. :-( Dan On Wednesday, May 09, 2012 03:45:39 PM ED Barwani wrote: > Hello, > > I have a camel route that looks like: > > > > > /> > > > > > /> > > This route works desirably when I run it using the camel maven plugin > "mvn camel:run". However, when I run it in the karaf container I get a > NullPointerException > > 2012-05-09 11:26:40,108 | WARN | tp1202105401-632 | > Soap11FaultOutInterceptor| - - | Error writing to > XMLStreamWriter. > javax.xml.stream.XMLStreamException: Trying to output second root, > at > com.ctc.wstx.sw.BaseStreamWriter.throwOutputError(BaseStreamWriter.java:1 > 524)[122:woodstox-core-asl:4.1.2] at > com.ctc.wstx.sw.BaseStreamWriter.throwOutputError(BaseStreamWriter.java:1 > 531)[122:woodstox-core-asl:4.1.2] at > com.ctc.wstx.sw.BaseStreamWriter.reportNwfStructure(BaseStreamWriter.java > :1559)[122:woodstox-core-asl:4.1.2] at > com.ctc.wstx.sw.BaseNsStreamWriter.checkStartElement(BaseNsStreamWriter.j > ava:469)[122:woodstox-core-asl:4.1.2] at > com.ctc.wstx.sw.SimpleNsStreamWriter.writeStartOrEmpty(SimpleNsStreamWrit > er.java:252)[122:woodstox-core-asl:4.1.2] at > com.ctc.wstx.sw.BaseNsStreamWriter.writeStartElement(BaseNsStreamWriter.j > ava:317)[122:woodstox-core-asl:4.1.2] at > org.apache.cxf.binding.soap.interceptor.Soap11FaultOutInterceptor$Soap11F > aultOutInterceptorInternal.handleMessage(Soap11FaultOutInterceptor.java:75 > )[135:org.apache.cxf.cxf-rt-bindings-soap:2.6.0] ... > > The entire exception can be found in the attached log snippet. > > I am posting because am not entirely certain what is the issue here. > Is it my karaf instance, or is it an issue with CXF? A little nudge in > the right direction will help. Thanks! > > *Environment* > Java: Oracle/Sun version "1.6.0_32" > Karaf: 2.2.7 > ActiveMQ: 5.5.1 > CXF: 2.6.0 > Camel: 2.9.2 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Message loss with transacted CXF consumer
Can you try setting the property: org.apache.cxf.interceptor.USE_ORIGINAL_THREAD, "true" on the CXF endpoint and seeing if that helps? That should keep the request on the original thread and should allow the stack for that to unwind on an exception. Dan On Wednesday, May 02, 2012 04:36:35 PM Stefan Burkard wrote: > Hi > > The facts: > - InOnly route > - CXF bean consumes with "transacted" from JMS queue > => therefore I expect the message to succeed or to go to JMS-DLQ > > Result: CXF consumer commits JMS message in any case - no matter if > exceptions occur in route. If an error occurs during route processing > the message is lost. > > Conclusion: "transacted" is currently useless if CXF is used with InOnly > Suggestions: Mark the route as InOut => did not help > > Attached is a small maven project that illustrates the problem with > unittests. > > One solution would of course be to handle ALL route errors with a > Camel error handler, but this is more of a workaround. I am wondering > if there is a real solution for this problem. > > Thanks > Stefan -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: karaf 2.2.5, cxf 2.6.0 and camel 2.9.0 install problem
May be ordering Try: 1) Karaf 2.2.7 with the jre.properties.cxf 2) Install the ActiveMQ 5.5.1 feature.xml 3) Install the CXF 2.6.0 feature.xml 4) Install the Camel 2.9.2 feature.xml Then install the various features themselves, likely in roughly the same order. ActiveMQ first, CXF next, then Camel. Dan On Monday, April 30, 2012 05:54:39 PM Fitzcaraldo wrote: > I'm now trying to add ActiveMQ 5.5.1 to the above container (karaf 2.2.7, > cxf 2.6.0, camel 2.9.2) > > features:addUrl mvn:org.apache.activemq/activemq-karaf/5.5.1/xml/features > > then > > features:install activemq-spring > > This fails with the message: > > Error executing command: Could not start bundle > mvn:org.apache.activemq/activemq-spring/5.5.1 in feature(s) > activemq-spring-5.5.1: Unresolved constraint in bundle > org.apache.activemq.activemq-spring [199]: Unable to resolve 199.0: > missing requirement [199.0] package; > (&(package=org.apache.activemq)(version>=5.5.0)(!(version>=6.0.0))) > > As well as the dependency in AMQ V5.5.0 shown this step also pulls in cxf > 2.5.2 again! > > Is there another dependency I'm not aware of? > > Can someone recommend a combination of the 4 products that work together. > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/karaf-2-2-5-cxf-2-6-0-and-camel-2-9-0-i > nstall-problem-tp5675060p5677249.html Sent from the Camel - Users mailing > list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: karaf 2.2.5, cxf 2.6.0 and camel 2.9.0 install problem
On Sunday, April 29, 2012 11:50:05 PM Fitzcaraldo wrote: > Good call. > > With karaf v2.2.7, cxf v2.6.0 and camel v2.9.2 - it installs cleanly. > This time the war didn't pull in an earlier version of cxf. If using CXF 2.6.0, you really need Camel 2.9.1 or newer (2.9.2 obviously preferred).2.9.0 was release way too long before 2.6.0 was really "ready" and thus was not tested with 2.6.0. 2.9.2 is definitely known to work well with CXF 2.6.0. Dan > > Thanks > > -- > View this message in context: > http://camel.465427.n5.nabble.com/karaf-2-2-5-cxf-2-6-0-and-camel-2-9-0-i > nstall-problem-tp5675060p5675234.html Sent from the Camel - Users mailing > list archive at Nabble.com. -- Daniel Kulp d...@kulp.com http://dankulp.com/blog
Re: Jetty server...Performance testing ...
In this case, you CAN configure the CXF Jetty instance we use based on the config stuff documented at: http://cxf.apache.org/docs/jetty-configuration.html (assuming Spring) However, I'm not sure you need to. With the more recent versions of Jetty, the "default" is a maximum of 256 threads in the pool.A couple of those are used for their selectors, but you still end up with potentially a lot of threads available. Dan On Tuesday, April 03, 2012 04:11:05 PM Omar Atia wrote: > Is this what you want ? > >address="http://0.0.0.0:7782/services/JBoss4CBS"; > id="JBossCBSWS" > serviceClass="com.huawei.oss.business.intf.webservice.cbs.Boss4CBSInterfa > ceEndpoint" wsdlURL="JBoss4CBS/Boss4CBSInterfaceService.wsdl"> > > > > > > > > > > > > > > > > -Original Message- > From: Raul Kripalani [mailto:r...@fusesource.com] > Sent: Tuesday, April 03, 2012 7:02 PM > To: users@camel.apache.org > Subject: Re: Jetty server...Performance testing ... > > Hi Omar, > > I believe the performance you get will depend on the CXF transport you are > using. Can you post your CXF JBossCBSWS bean definition? > > Are you using a Jetty runtime to expose your HTTP endpoints? If so, you > may be able to tune your threading parameters according to this page: > http://cxf.apache.org/docs/jetty-configuration.html. Jetty behaves > asynchronously thanks to the Continuations API. > > Additionally, you can consider splitting your route into segments with > different concurrency levels by using SEDA endpoints with the > concurrentConsumers option. > > Regards, > > *Raúl Kripalani* > *Principal Consultant | FuseSource Corp. > r...@fusesource.com | fusesource.com <http://www.fusesource.com/> > skype: raul.fuse | twitter: @raulvk <http://twitter.com/raulvk>, > @fusenews<http://twitter.com/fusenews> * > > On 3 April 2012 16:34, Omar Atia wrote: > > Sorry I will deploy CXF WS on ServiceMix using Apache camel : > > > > Like this route : > > > > > > > > > > > > > > > > > > > > > > > > > > > > Bean has to JDBC connect to DB and execute a DB package . > > > > Thanks, > > Omar Atia > > > > > > > > From: Omar Atia > > Sent: Tuesday, April 03, 2012 6:20 PM > > To: 'users@camel.apache.org' > > Subject: Jetty server...Performance testing ... > > > > Dears, > > > > I have Jetty server with WS deployed on ServiceMix , that WS connect > > using JDBC to DB and call DB package , well Can we have performance > > for 15 request to be processed per second I know it depends on DB > > response . > > > > How we can increase no of threads for Jetty server? Can we have such > > number of request per second? I believe performance testing should > > Judge. > > > > Well appreciate your feedback, > > > > Thanks, > > Omar Atia -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Camel features depending on Camel Component
On Friday, March 02, 2012 12:56:40 PM Reuben Garrett wrote: > RabbitMQ appears to be licensed under MPL 1.1 [1], but there is a new MPL > 2.0 [2] that is purportedly more Apache-friendly [3]. Are MPL 2.0 projects > compatible for incorporation in APL projects? I don't fully understand all > the intricacies entailed, but perhaps new possibilities will arise [4]. MPL is a category-b license and is OK in binary form. See: http://www.apache.org/legal/resolved.html#category-b Dan > > [1] : http://www.rabbitmq.com/mpl.html > [2] : http://www.mozilla.org/MPL/2.0/ > [3] : > http://www.zdnet.com/blog/open-source/mozilla-license-becoming-apache-compat > ible/6039 [4] : > https://groups.google.com/d/topic/rabbitmq-discuss/O1VTqoquetU/discussion > > ~ RNPG > > On Thu, Mar 1, 2012 at 12:16, Ashwin Karpe wrote: > > Hi, > > > > I believe, I had seen a submission a few months ago of a Camel RabbitMQ > > component and had referred it to be hosted in camel-extras or at git-hub. > > > > Can you please look for it in this forum and in camel-extras/github... The > > component was quite compelling and could not be brought into the Apache > > Camel offering due to license restrictions in RabbitMQ. > > > > Cheers, > > > > Ashwin... > > > > - > > - > > Ashwin Karpe > > Apache Camel Committer & Sr Principal Consultant > > FUSESource (a Progress Software Corporation subsidiary) > > http://fusesource.com > > > > Blog: http://opensourceknowledge.blogspot.com > > - > > -- > > View this message in context: > > http://camel.465427.n5.nabble.com/Camel-features-depending-on-Camel-Compon > > ent-tp5528357p5528713.html Sent from the Camel - Users mailing list > > archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Setting timeout for http-conf:client doesn't seem to work
On Friday, February 24, 2012 1:45:23 PM JoeR wrote: > In my case I was attempting something very simple: > > http://camel.apache.org/schema/spring";> > uri="http://localhost:8080/ws-example/ws-example"/> > > > > > > > > Should this work ? You are basically using the http component and not CXF by using an http URI for the "to".Thus, you would need to check the docs for that component on how to configure any timeout: http://camel.apache.org/http.html Likely just add: ?httpClient.soTimeout=5000 to the end of the URI there. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Setting timeout for http-conf:client doesn't seem to work
What does the uri in the line: look like? Is that a cxf URI or an http URI?I'd like to see the "to" setup for the route. Dan On Thursday, February 23, 2012 12:00:34 PM hellosir wrote: > Hi, I'm trying to edit the default timeout for my web service to wait for a > response. > > When I try it using this config file, nothing seems to happen. I set the > timeout to be 1000 ms, and I have a generic web service I am calling where I > do a Thread.sleep for 4000 ms and a timeout error never occurs. > > Can someone enlighten me as to what I am doing wrong? > > I had to edit out some of the names of my config file, but everything is > listed below. > > Thanks in advance, > > (Config file below) > > > > > http://www.springframework.org/schema/beans"; >xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >xmlns:camel="http://camel.apache.org/schema/spring"; >xmlns:cxf="http://camel.apache.org/schema/cxf"; >xmlns:context="http://www.springframework.org/schema/context"; > xmlns:http-conf="http://cxf.apache.org/transports/http/configuration"; >xsi:schemaLocation=" >http://www.springframework.org/schema/beans > http://www.springframework.org/schema/beans/spring-beans.xsd >http://www.springframework.org/schema/context > http://www.springframework.org/schema/context/spring-context.xsd >http://camel.apache.org/schema/spring > http://camel.apache.org/schema/spring/camel-spring.xsd >http://camel.apache.org/schema/cxf > http://camel.apache.org/schema/cxf/camel-cxf.xsd > http://cxf.apache.org/transports/http/configuration > http://cxf.apache.org/schemas/configuration/http-conf.xsd";> > > > > > > > > http://localhost:11100/.*";> > > > > > > address="http://localhost:8080/ws"; >endpointName="s:servicePort" >serviceName="s:Service" >wsdlURL="etc/some.wsdl" >xmlns:s="http://ws/some.wsdl";> > > > > > http://camel.apache.org/schema/spring";> > > > > > > > > > > > > > > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Setting-timeout-for-http-conf-client-does > n-t-seem-to-work-tp5509173p5509173.html Sent from the Camel - Users mailing > list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Problem with multiple CXF services using the same https port
On Thursday, February 09, 2012 5:47:09 AM snatera wrote: > Hello Dan! > > Thanks for taking your time to reply to me. > > In this link Fuse Source explains the way that I implemented: > http://fusesource.com/docs/esb/4.3/cxf_security/HTTPCompatible.html#i488847 Nice of them to promote the use of generally bad ideas... :-( > I was trying to use > before, but I had this Exception: > > -- Exception in thread "SpringOsgiExtenderThread-29" > org.springframework.beans.factory.CannotLoadBeanClassException: Cannot find > class [org.apache.cxf.bus.spring.SpringBus] for bean with name 'cxf' defined > in OSGi > resource[classpath:META-INF/cxf/cxf.xml|bnd.id=219|bnd.sym=cnti-sw-dev-https > ]; nested exception is java.lang.ClassNotFoundException: > org.apache.cxf.bus.spring.SpringBus not found from bundle [my-bundle] -- You likely need to either add some imports (org.apache.cxf.bus.spring) or add a "Require-Bundle: org.apache.cxf.bundle" header to the manifest. Definitely one of the more annoying things about spring-dm. > And.. if I do this I get this Exception: > > -- org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: > Line 24 in XML document from URL > [bundle://219.29:0/META-INF/spring/beans.xml] is invalid; nested exception > is org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching > wildcard is strict, but no declaration can be found for element 'cxf:bus'. This is easier You need to update the schemaLocation attribute on the root beans to add "http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd"; to the list of namespaces to map to a schema for validation purposes. Dan > -- > > What can I do to solve this? > Thanks a lot, > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Problem-with-multiple-CXF-services-using- > the-same-https-port-tp3379301p5469462.html Sent from the Camel - Users > mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Problem with multiple CXF services using the same https port
On Wednesday, February 08, 2012 11:10:35 AM snatera wrote:
> I could solve the last post, where I mention the Exception about 'cxf'
> bean.
>
> In your beans.xml or camel-config.xml you have to put this source:
>
>
Please do not do that. That's a surefire way to make sure you'll have
configuration issues, strange errors, and issues upgrading to newer versions
of CXF.
Just import:
or do a:
And let CXF setup the bus. CXFBusImpl is not spring aware and is also not
even CXF extension aware. Thus, it's quite likely that nothing using that bus
will even work.
Dan
>
> Then, go to pom.xml and put this dependendy and this import:
>
> Dependency:
>
>
> org.apache.camel
> camel-cxf
> ${camel.version}
>
>
> Import:
>
>
> ...,
> org.apache.cxf.bus
>
>
>
> This way I could solve it.
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Problem-with-multiple-CXF-services-using-
> the-same-https-port-tp3379301p5467423.html Sent from the Camel - Users
> mailing list archive at Nabble.com.
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: how to improve concurrent performance use cxf in Camel?
On Monday, January 09, 2012 6:55:17 AM xiangqiuzhao wrote: > like the concurrent pool size? or others options? Can I get a more complete description of what you are doing? Depending on what is going on, you may need to adjust Jetty or JMS thread pools or maybe the CXF async clients pools or possibly some Camel pool.Without a rather complete description of where the current bottlenecks are, it's kind of hard to make suggestions. For things like the Jetty stuff, that also can depend on if you are using the Jetty transport in CXF or the jetty stuff in Camel or even external. Dan > -- > View this message in context: > http://camel.465427.n5.nabble.com/how-to-improve-concurrent-performance-use > -cxf-in-Camel-tp5131454p5131454.html Sent from the Camel - Users mailing > list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Setting CXF TLSClientParameters programmatically
On Wednesday, January 04, 2012 8:39:54 PM Alexandre Gattiker wrote:
> As of Camel 2.9.0 I can write:
>
> Map cxfProperties = new HashMap();
> cxfProperties.put(AuthorizationPolicy.class.getName(), policy);
> cxfEndpoint.setProperties(cxfProperties);
>
> Is there a similar way to set the TLSClientParameters? I would like to
> set them e.g. from the usual system properties
> javax.net.ssl.keyStoreType, etc. which are not honored by the default
> HTTP Conduit (why?).
Argh bug in CXF. Just looked at the code. We are grabbing the
system property for javax.net.ssl.keyStore and javax.net.ssl.keyStorePassword,
but not for keyStoreType. :-(
Will fix.
Dan
>
> In CXF I can write the following, but I couldn't find a Camel equivalent:
> JaxWsClientFactoryBean factory = new JaxWsClientFactoryBean();
> ...
> proxy = factory.create();
> HTTPConduit conduit = (HTTPConduit) proxy.getConduit();
> TLSClientParameters tcp = new TLSClientParameters();
> tcp.setUseHttpsURLConnectionDefaultHostnameVerifier(true);
> tcp.setUseHttpsURLConnectionDefaultSslSocketFactory(true);
> conduit.setTlsClientParameters(tcp);
>
>
> I found a workaround as follows, but it is quite complicated. Also,
> the CXF conduit wildcard (name="*.http-conduit") doesn't work.
>
> context = new SpringCamelContext(new
> ClassPathXmlApplicationContext("/camel-ssl.xml"));
> context.addRoutes(...)
>
> camel-ssl.xml:
>
> http://www.springframework.org/schema/beans";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:http="http://cxf.apache.org/transports/http/configuration";
> xmlns:sec="http://cxf.apache.org/configuration/security";
> xmlns:jaxws="http://java.sun.com/xml/ns/jaxws";
> xsi:schemaLocation="
>http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
> http://cxf.apache.org/transports/http/configuration
> http://cxf.apache.org/schemas/configuration/http-conf.xsd
>http://cxf.apache.org/configuration/security
> http://cxf.apache.org/schemas/configuration/security.xsd
> ">
>
> class="org.springframework.beans.factory.config.PropertyPlaceholderConfigur
> er">
>
> key="javax.net.ssl.trustStoreType">JKS
> key="javax.net.ssl.keyStoreType">JKS
> key="javax.net.ssl.keyStorePassword">changeit
>
>
>
> SYSTEM_PROPERTIES_MODE_OVERRIDE
>
>
>
>
>
> keyPassword="${javax.net.ssl.keyStorePassword}">
> type="${javax.net.ssl.keyStoreType}"
> password="${javax.net.ssl.keyStorePassword}"
> file="${javax.net.ssl.keyStore}" />
>
>
> type="${javax.net.ssl.trustStoreType}"
> file="${javax.net.ssl.trustStore}" />
>
>
>
>
>
> Thanks in advance for your advice.
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Past release info
On Wednesday, December 21, 2011 12:03:06 PM Narita Bagchi wrote: > Is there a link to find out the dates of past releases of Camel ? I did not > find the dates in the download archive. > http://camel.apache.org/download-archives.html Or probably I missed it. JIRA somewhat records this: https://issues.apache.org/jira/browse/CAMEL#selectedTab=com.atlassian.jira.plugin.system.project:versions-panel&subset=-1 Dan > > Thanks. > Regards, > Narita > > > ***The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review,retransmission,dissemination or other use of, or > taking of any action in reliance upon, this information by persons or > entities other than the intended recipient is prohibited. If you received > this in error, please contact the sender and delete the material from any > computer.*** -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Defining a CXF bus in Blueprint for use with cxfbean endpoint
On Wednesday, November 23, 2011 12:03:08 PM Brian Topping wrote: > Some more details about what I am doing. I've distilled the configuration > down to what's below. It's Camel 2.9-SNAPSHOT running on Karaf 2.2.4, with > CXF 2.4.3. > > About five lines from the end, there are two endpoints that I've been trying > to work with. The first one with cxfbean works fine, but it's not clear > how to define a bus in Blueprint to use with it. The cxf component allows > the definition of a bus in Blueprint, but only as a part (and associated > with) the cxfEndpoint element. > > Should there be a bus element at the top level of the > http://camel.apache.org/schema/blueprint/cxf schema? No. At that point, you start actually using parts of CXF's blueprint support: http://cxf.apache.org/schemas/blueprint/core.xsd Use: http://cxf.apache.org/blueprint/core"; name="cxf"> .. Dan > > Thanks kindly for any input! > > http://www.osgi.org/xmlns/blueprint/v1.0.0"; >xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > > xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.0.0"; > xmlns:camelcxf="http://camel.apache.org/schema/blueprint/cxf"; > xmlns:camel="http://camel.apache.org/schema/blueprint"; >xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0 > http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd "> > > > > > > > > > > > serviceClass="org.apache.camel.itest.osgi.cxf.jaxrs.testbean.CustomerServic > e"> > > http://camel.apache.org/schema/blueprint";> > > > > uri="jetty:http://0.0.0.0:9000/customerservice?matchOnUriPrefix=true"/> uri="jms:queue:test"/> > > > > > > > > > > class="org.apache.camel.itest.osgi.cxf.jaxrs.testbean.CustomerService"/> > > > On Nov 22, 2011, at 4:44 PM, Brian Topping wrote: > > Hi all, > > > > I'd like to secure a cxfbean resource using Spring Security and SS > > authorization annotations. To do so, it appears that it will require > > adding an interceptor to the CXF endpoint as an element of a bus. > > > > So far, I have been trying to do everything in blueprint. But it > > doesn't appear that there's a good way to define a bus in blueprint. > > Bus appears to be new in 2.9, is this an implementation detail that > > hasn't made it in yet or am I missing some subtlety on how to put this > > together? > > > > It may also be that I need to use the "cxf:bean:" endpoint (which does > > have the ability to configure a bus), but I haven't been able to > > discern that JAX-RS is supported by the cxf endpoint yet. > > > > Any thoughts appreciated! > > > > Brian -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Writing own Camel Components
On Wednesday, November 09, 2011 12:49:09 PM Ashwin Karpe wrote: > Hi, > > Unless I am mistaken, RabbitMQ is released under the Mozilla Public License > 1.1. This license version is not compatible with Apache License v2.0. There > was talk of having a compatible Mozilla Public License v 2.0. If Rabbit MQ > is available under Mozilla License 2.0 my sense is that it should be fine. > > I believe that the MPL 1.1 license will lead to complications in terms of > contributing the code to the Apache Camel project. Umm MPL 1.1 is a Category B license. Thus, it CAN be incorporated as a binary into Apache releases. This is the same category as things like JAXB, Eclipse, etc -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Unit test failure on trunk in camel-saxon
On Monday, November 21, 2011 6:35:47 PM Christian Müller wrote: > As mentioned in [1]: > "You have to be a subscriber of the Camel mailinglist to be able to post on > the user forum... If you are not a subscriber your post will not be > forwarded and thus most people will not see your post." > > [1] http://camel.apache.org/discussion-forums.html Which is actually kind of wrong. In MOST cases, if someone not subscribed to the list sends a mail, it goes into the moderation queue. At some point later, one of the moderators (we currently have 4 I think) may see it and moderate it through at which point it will appear on the list. If your post isn't be accepted to dev@ via that mechanism, that would be a bit strange.Next time it happens, if you could get on IRC or something so I can get the message ID and such, I can likely work with the infrastructure folks to try and figure out why. Dan > > Best, > Christian > > On Mon, Nov 21, 2011 at 3:15 PM, bvahdat wrote: > > Hi, > > > > As my posts don't get accepted @ dev here a link to my 2 cents: > > > > > > http://camel.465427.n5.nabble.com/Unit-test-failure-on-trunk-in-camel-sa > > xon-tp5009713p5010536.html > > > > Question: if I would subscribe to dev-subscr...@camel.apache.org as > > provided > > by [1] would it then be accepted? > > > > [1] http://camel.apache.org/mailing-lists.html > > Babak > > > > -- > > View this message in context: > > http://camel.465427.n5.nabble.com/Unit-test-failure-on-trunk-in-camel-sa > > xon-tp5010610p5010610.html Sent from the Camel - Users mailing list > > archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Questions on Camel camel-example-cxf-osgi sample
On Thursday, November 03, 2011 2:03:15 PM Glen Mazza wrote: > Hi all, two questions: > > 1.) Line #51 of the camel-example-cxf-osgi sample's README[1] hosts a > CXF web service at the following URL: > > http://localhost:8181/cxf/camel-example-cxf-osgi/webservices/incident?wsdl > > However, the default string for OOTB Karaf would have "services" instead > of CXF: > > http://localhost:8181/services/camel-example-cxf-osgi/webservices/incident > <http://localhost:8181/cxf/camel-example-cxf-osgi/webservices/incident>?wsdl > > I have a patch to update the README and can have the URL changed to > "services" but was wondering where "cxf" came from--is that the default > string if it is hosted on ServiceMix (only Karaf uses "services" by > default?), or does ServiceMix use "services" too by default? Then we > can switch the README to have them use "services" instead so no special > container configuration would be needed. /cxf is the default for CXF and is likely the right URL. It sounds like you have a kind of mixed up OSGi container thing. Likely you are trying to use something like CXF 2.4.3 with Felix (which has some issues that will be fixed in 2.4.4, use Equinox) or possibly using some karaf configs from Talend products. Definitely retry with a more vanilla install of Karaf.You can follow instructions from my blog: http://www.dankulp.com/blog/?p=352 to get Camel/CXF setup and try that. I just gave that a try with that example and it seemed to show up fine at : http://localhost:8181/cxf/camel-example-cxf-osgi/webservices/incident?wsdl Dan > 2.) I cannot get this sample to work using either "cxf" or "services" > above in the URL string. Karaf log error message is: "Can't find the the > request for > http://localhost:8181/services/camel-example-cxf-osgi/webservices/incident's > Observer " which may mean CXF configuration isn't being properly detected. > > Line #32 of the Spring camel-context.xml configuration here: > *http://tinyurl.com/3bumwtx* seems suspect: > * > *address="/camel-example-cxf-osgi/webservices/incident" > > Shouldn't it be the entire address, like so: > > address="http://localhost:8181/services/camel-example-cxf-osgi/webservices/i > ncident > <http://localhost:8181/cxf/camel-example-cxf-osgi/webservices/incident>?wsd > l" > > (although that didn't seem to work for me either, same error!) The > address value of the camel-context.xml for *test* cases has the full URL > as above. > > Thanks, > Glen > > [1] > http://svn.apache.org/viewvc/camel/trunk/examples/camel-example-cxf-osgi/REA > DME.txt?annotate=1147432 -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
Re: Problem running camel-example-cxf-osgi
You likely need to install the various featuers in a different order.I would try doing: features:install war features:install cxf features:install camel-spring features:install camel-jaxb features:install camel-cxf The cxf feature should pull in the full JAXB-API jars and such and POSSIBLY avoid some of the "Refreshing bundles" things. Going in that order you can also use CXF 2.5.x instead of 2.4.3. Dan On Monday, October 31, 2011 2:10:58 PM Glen Mazza wrote: > Thanks--that worked--sort of. Making your recommended changes now > reports the following error when I do "features:install camel-cxf": > > karaf@root> features:addUrl > mvn:org.apache.camel.karaf/apache-camel/2.8.2/xml/fe > atures > karaf@root> features:install war > karaf@root> features:install camel-spring > karaf@root> features:install camel-jaxb > karaf@root> features:install camel-cxf > Refreshing bundles org.springframework.context (84), > org.springframework.context.support (85), org.apache.camel.camel-core > (97), org.apache.servicemix.bundles.jaxb-impl (95) > ERROR: Bundle org.springframework.osgi.extender [89] Error stopping > bundle. (java.lang.NoClassDefFoundError: > org/osgi/framework/ServiceRegistration) > java.lang.NoClassDefFoundError: org/osgi/framework/ServiceRegistration > at > org.springframework.osgi.util.OsgiServiceUtils.unregisterService(OsgiService > Utils.java:41) at > org.springframework.osgi.extender.internal.support.NamespaceManager.unregist > erResolverService(NamespaceManager.java:195) at > org.springframework.osgi.extender.internal.support.NamespaceManager.destroy( > NamespaceManager.java:223) at > org.springframework.osgi.extender.internal.activator.ContextLoaderListener.s > hutdown(ContextLoaderListener.java:547) at > org.springframework.osgi.extender.internal.activator.ContextLoaderListener.s > top(ContextLoaderListener.java:431) at > org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java > :651) at org.apache.felix.framework.Felix.stopBundle(Felix.java:2216) at > org.apache.felix.framework.Felix$RefreshHelper.stop(Felix.java:4489) at > org.apache.felix.framework.Felix.refreshPackages(Felix.java:3581) at > org.apache.felix.framework.PackageAdminImpl.run(PackageAdminImpl.java:363) > at java.lang.Thread.run(Thread.java:619) > Caused by: java.lang.ClassNotFoundException: > org.osgi.framework.ServiceRegistration not found by > org.springframework.osgi.core [88] > at > org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(Module > Impl.java:787) at > org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:71) at > org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl > .java:1768) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) > ... 11 more > > Any more ideas? > > Glen > > On 10/30/2011 09:53 PM, Daniel Kulp wrote: > > The README.txt needs updating. You need to edit the jre.properties and > > comment out a bunch of the javax.* things that are provided by the > > bundles. That would include javax.xml.bind*, javax.jws*, > > javax.xml.soap*, javax.xml.ws*, I think javax.mail, javax.activation. > > > > Dan > > > > On Sunday, October 30, 2011 7:10:21 PM Glen Mazza wrote: > >> Hello, I'm trying to run the Camel 2.8.2 sample > >> "camel-example-cxf-osgi" > >> on Apache Karaf 2.2.4. Following these instructions: > >> https://svn.apache.org/repos/asf/camel/trunk/examples/camel-example-cx > >> f-osgi /README.txt, I'm able to run the first four of these five > >> commands with no problem: > >> > >> features:addUrl > >> mvn:org.apache.camel.karaf/apache-camel/2.8.2/xml/features > >> features:install war > >> features:install camel-spring > >> features:install camel-jaxb > >> features:install camel-cxf > >> > >> The last command above, however, reports this error: > >> > >> karaf@root> features:install camel-cxf > >> Error executing command: Could not start bundle > >> mvn:org.apache.camel/camel-cxf-transport/2.8.2 in feature(s) > >> camel-cxf-2.8.2: Unable to resolve module org.apache.cxf.bundle > >> [137.0] > >> because it is exposed to package 'javax.xml.bind.attachment' from > >> org.apache.felix.framework [0] and > >> org.apache.servicemix.specs.jaxb-api-2.2 [53.0] via two dependency > >> chains.>> > >> Chain 1: > >> org.apache.cxf.bundle [137.0] > >> > >> import: (package=javax.xml.bind.attachment) > >> > >> export: pac
Re: Validation supporting schemas with includes?
On Sunday, October 30, 2011 11:21:41 PM Christian Müller wrote: > I wanted to add the missing unit test for handling multiple schema file, > but it doesn't work. :-( > I made a test where a root schema file imports a nested schema file. Bot > schema file was valid. But I got an exception by starting the route. I > think to support multiple schemas, we have to use > schemaFactory.newSchema(Source[] sources); > instead of > schemaFactory.newSchema(Source source); > but I'm not sure. We have to figure it out... > > Feel free to open a JIRA to track this issue as improvement. This is one of those things that's really hard to get working. And it also tends to "break". Includes are a bit different than imports and just doing Source[] doesn't really work either as it still calls the Resolver if the [] doesn't have them in "perfect" order (the leafs first). If you want a starting point for some code, look into the CXF EndpointReferenceUtils class. There is a SchemaLSResourceResolver class right at the top that makes some attempts at this.It's gone through many iterations trying to get something to work and it seems to work OK now. Dan > > Best, > Christian > > On Sat, Oct 29, 2011 at 10:04 AM, Claus Ibsen wrote: > > On Fri, Oct 28, 2011 at 1:13 PM, Lars wrote: > > > I'm using Camel 2.8.2 and I try to use the Validator with a schema > > > which includes other schemas? > > > Is this functionality supported? > > > If yes, how do I specify the schemas? > > > > Have you tried to include the other schemas from a schema file? > > I assume you can use some sort of xsd:include or xsd:import or whatever > > you do. > > > > > Lars Stuevold > > > > > > -- > > > > > View this message in context: > > http://camel.465427.n5.nabble.com/Validation-supporting-schemas-with-inc > > ludes-tp4945655p4945655.html> > > > Sent from the Camel - Users mailing list archive at Nabble.com. > > > > -- > > Claus Ibsen > > - > > FuseSource > > Email: cib...@fusesource.com > > Web: http://fusesource.com > > Twitter: davsclaus, fusenews > > Blog: http://davsclaus.blogspot.com/ > > Author of Camel in Action: http://www.manning.com/ibsen/ -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
Re: Problem running camel-example-cxf-osgi
The README.txt needs updating. You need to edit the jre.properties and comment out a bunch of the javax.* things that are provided by the bundles. That would include javax.xml.bind*, javax.jws*, javax.xml.soap*, javax.xml.ws*, I think javax.mail, javax.activation. Dan On Sunday, October 30, 2011 7:10:21 PM Glen Mazza wrote: > Hello, I'm trying to run the Camel 2.8.2 sample "camel-example-cxf-osgi" > on Apache Karaf 2.2.4. Following these instructions: > https://svn.apache.org/repos/asf/camel/trunk/examples/camel-example-cxf-osgi > /README.txt, I'm able to run the first four of these five commands with no > problem: > > features:addUrl mvn:org.apache.camel.karaf/apache-camel/2.8.2/xml/features > features:install war > features:install camel-spring > features:install camel-jaxb > features:install camel-cxf > > The last command above, however, reports this error: > > karaf@root> features:install camel-cxf > Error executing command: Could not start bundle > mvn:org.apache.camel/camel-cxf-transport/2.8.2 in feature(s) > camel-cxf-2.8.2: Unable to resolve module org.apache.cxf.bundle [137.0] > because it is exposed to package 'javax.xml.bind.attachment' from > org.apache.felix.framework [0] and > org.apache.servicemix.specs.jaxb-api-2.2 [53.0] via two dependency chains. > > Chain 1: >org.apache.cxf.bundle [137.0] > import: (package=javax.xml.bind.attachment) > > export: package=javax.xml.bind.attachment >org.apache.felix.framework [0] > > Chain 2: >org.apache.cxf.bundle [137.0] > import: (package=com.sun.tools.xjc.reader.xmlschema.parser) > > export: package=com.sun.tools.xjc.reader.xmlschema.parser; > uses:=javax.xml.bind >org.apache.servicemix.bundles.jaxb-xjc [58.0] > import: (&(package=javax.xml.bind)(version>=2.2.0)(!(version>=3.0.0))) > > export: package=javax.xml.bind; uses:=javax.xml.bind.attachment > export: package=javax.xml.bind.attachment >org.apache.servicemix.specs.jaxb-api-2.2 [53.0] > > Any idea what the solution would be? > > Thanks, > Glen -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
Re: tracing large messages
On Thursday, October 20, 2011 3:07:20 PM Claus Ibsen wrote: > On Thu, Oct 20, 2011 at 2:59 PM, Mond Raymond wrote: > > I had a user today that had camel blow up because he was sending a > > message body of 96Mb and had the tracer on. By default the tracer > > outputs bodies so he ran out of memory ;-) > > > > Quite an easy fix to configure a formatter and turn off the printing of > > message bodies... but it made me think, shouldn't there be a limit (10k, > > 100k or whatever) which is the default beyond which bodies will not be > > printed, unless configured explicitly ... this would prevent users > > shooting off their feet. > > But yeah maybe the maxChars default should be 1 or something. Just an FYI: CXF uses 100K for the limit by default. > People can then use -1 or 0 for no limit. > Fell free to create a JIRA. And also work on a patch :) I would say -1 for no limit and 0 for no body. (just log headers) That seems a little more intuitive to me, but that's my opinion. Dan > > > Thoughts? > > > > Cheers > > > > Ray > > > > -- > > View this message in context: > > http://camel.465427.n5.nabble.com/tracing-large-messages-tp4921360p4921 > > 360.html Sent from the Camel - Users mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
Re: Missing "detail" element in SOAP fault
I guess the questions would be: 1) What version of Camel? 2) What does the route look like? Is it using camel-cxf or similar? Dan On Tuesday, October 18, 2011 5:41:41 AM sengel wrote: > Hello, > > we have a system consisting of (web and other) clients and our backend (SOAP > web services). Now when we throw a Fault/Exception in a backend operation, > the SOAP fault looks like this: > > http://schemas.xmlsoap.org/soap/envelope/";> > > > > env:Server > An entity with the same ID already > exists > > xmlns:ns2="http://www.example.com/example/";> >Entity was not created. An entity with the same ID > already exists > > > > > > > The client side uses the subelement "duplicateEntityFault" of "detail" to > generate the Exception class which we expect and catch > (DuplicateEntityFault_Exception). > > So now we added Camel to the setup which routes requests to the backend. We > expected that if a Fault/Exception is thrown on the backend, Camel would > just pass it back to the client. But, no. Instead the client gets this: > > http://schemas.xmlsoap.org/soap/envelope/";> > > > soap:Server > HTTP operation failed invoking > http://www.example.com/example/example-service with statusCode: > 500 > > > > > So the problem is that there is no "detail" element in the fault message > from which the client can generate the Exception. Camel logs this: > Exhausted after delivery attempt: 1 caught: > org.apache.camel.component.http.HttpOperationFailedException: HTTP operation > failed invoking http://www.example.com/example/example-service with > statusCode: 500 > > Could you please tell us what is missing or what we do wrong? > Thanks in advance, > > Sebastian > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Missing-detail-element-in-SOAP-fault-tp49 > 13512p4913512.html Sent from the Camel - Users mailing list archive at > Nabble.com. -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
Re: 'mvn eclipse:clean eclipse:eclipse' not being happy with ${jetty-version}
On Monday, October 03, 2011 6:09:55 AM bvahdat wrote: > Hi, > > One more try in the hope that I get some echo if I'm wrong or if I'm the > only one having this "jetty-version" issue by "Camel build POM". > > I would really appreciate all kinds of advices. Can you try now? I just moved the plugin config for the jetty plugin to the parent pom (where the version is defined). That should eliminate that. Dan > > Regards, Babak > > -- > View this message in context: > http://camel.465427.n5.nabble.com/mvn-eclipse-clean-eclipse-eclipse-not-bei > ng-happy-with-jetty-version-tp4806907p4864775.html Sent from the Camel - > Users mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
Re: SOAP Headers and spring-ws
On Wednesday, September 21, 2011 9:18:05 PM Damian Harvey wrote:
> We have a small issue with the way that the SpringWebserviceConsumer
> retrieves SOAP Headers.
>
> SOAP Headers must be namespace qualified
> (http://www.w3schools.com/soap/soap_header.asp), and when the Consumer
> extracts the SOAP headers to populate the Exchange Headers it uses the
> QName.toString() method. This results in a headers key like :
>
> {http://mynamespace.url}MyHeaderKey
>
> Aside from being a *nasty* key this breaks the consistency of headers in a
> Route.
>
> I'd like to propose that the extractSoapHeadersFromWebServiceMessage method
> in the SpringWebserviceConsumer is modified to use the getLocalPart()
> method instead, as I can't think of a use case where you want the key
> prefixed with the namespace.
The only thing I can really think of is if the soap message has multiple
headers with the same local name but different namespaces.Likely a very
rare occurrence though.
Dan
>
> If this sounds ok I'll submit a patch.
>
> Thanks,
>
> Damian.
>
>
>
>
> This communication (and any attachments) is directed in confidence to the
> addressee(s) listed above, and may not otherwise be distributed, copied or
> used. The contents of this communication may also be subject to privilege,
> and all rights to that privilege are expressly claimed and not waived. If
> you have received this communication in error, please notify us by reply
> e-mail or by telephone and delete this communication (and any attachments)
> without making a copy.
>
> Before opening or using attachments, you should check them for viruses and
> defects. We do not accept liability in connection with computer virus, data
> corruption, delay, interruption, unauthorised access or unauthorised
> amendment.
--
Daniel Kulp
dk...@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: log4j.properties in camel
Another option would be to move the "restricted" log4j.properties file into something like src/test/log4j and then add a system property to surefire configuration to pick it up from there. When running with maven, it would be used. When running in your IDE, it wouldn't be picked up and the default log4j stuff. Another option MIGHT be to change to using slf4j-jdk14 instead of log4j in combination with the above. By default, the jul stuff doesn't really pick up a config file so in the IDE, you get INFO level and stuff printed. By passing in the properties file via maven surefire config, maven can use a more restricted one. This is somewhat what CXF does. (although CXF uses jul natively, but does use slf4j-jdk14 for the stuff that needs it) I definitely agree that when running in the IDE, I would like to see the logs on the console. Dan On Monday, August 22, 2011 9:03:41 AM bvahdat wrote: > Hi, > > while running the camel's own test cases one can't see the logs directly in > his IDE as always the 'org.apache.log4j.FileAppender' is used/active in > log4j.properties under camel-xyz/src/test/resources/log4j.properties. So you > always have to switch from your IDE to the redirected outputs in > target/camel-xyz-test.log to see the logs. To me this was annoying but don't > know what others think about it. Other than that while changing/working on > the camel code & running the unit-tests the Camel Riders would prefer to > see the logs directly in their IDE, I assume! > > On the other hand, I think the reason for that was not to flood the maven > console while doing 'mvn test', 'mvn install', etc. right? > > IMHO I think one can change them to out instead of file, that's > > log4j.rootLogger='LOG_LEVEL', out > > But instruct sunfire-plugin in [1] (a pluginManagment entry in there) to > redirect the output to files through the option [2]. > > Would it make sense to you? At least that's the way I do it by my client's > projects. > > [1] https://svn.apache.org/repos/asf/camel/trunk/parent/pom.xml > [2] > http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html#redirec > tTestOutputToFile > > Regards, Babak > > -- > View this message in context: > http://camel.465427.n5.nabble.com/log4j-properties-in-camel-tp4723887p47238 > 87.html Sent from the Camel - Users mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
Re: cxf rest service disappears with camel 2.8.0
On Thursday, August 11, 2011 10:19:04 PM Willem Jiang wrote: > Hi Mirko, > > After I add a simple test I found that jaxrs:server will use the > BusFactory.getDeafultThreadBus() when the bus is not set, it will make > the jaxrs server using a bus which is not wired with CXF Servlet. > And it can explain that the jaxrs server doesn't show up in service list. > > In Camel 2.7.x, camel-cxf is using the old CXF bus updating API which > may work around that kind of issue. > > I will work a patch of CXF about it shortly , but it just missed the > release train of CXF 2.4.2. I withdrew the vote for 2.4.2 and rebuilt with the fix for this. Thus, it didn't miss the release train for 2.4.2. :-) Dan > > On 8/11/11 8:38 PM, Mirko Caserta wrote: > > Hi Willem, > > adding a depends-on="camelContext" didn't work. > > > > However, > > > > > > >depends-on="resellerAccountingEndp > >oint" > >address="/restService"> > > > > where resellerAccountingEndpoint is the soap > > endpoint did work and I can see the rest endpoint being correctly > > initialized. > > > > Hope this helps. > > > > Mirko > > > > On Thu, Aug 11, 2011 at 1:21 PM, Willem Jiang wrote: > >> Hi Mirko, > >> > >> I checked the camel route that you sent to me, I didn't find any > >> jaxws:endpoint. > >> > >> jaxrs:server and cxf:cxfEndpoit are using the same code to find a bus > >> to > >> wire. Can you try to add depends-on attribute on the jaxrs:server to > >> let it depends-on camel context ? > >> > >> In this way I guess the jaxrs:server can be loaded after the cxf bus > >> is > >> created rightly. > >> > >> On 8/11/11 5:42 PM, Mirko Caserta wrote: > >>> Hi Willem, > >>> thanks for investigating this. > >>> > >>> The attached file is the version which works. To make it not work, > >>> the > >>> only difference is that I'll have to remove this line: > >>> > >>> > >>> > >>> Also, please note that the rest endpoint is not wired into the camel > >>> context but is directly connected to a bean implementation. Maybe > >>> this > >>> is what makes a difference. > >>> > >>> Again, thanks. > >>> > >>> Mirko > >> > >> -- > >> Willem > >> -- > >> FuseSource > >> Web: http://www.fusesource.com > >> Blog:http://willemjiang.blogspot.com (English) > >> > >> http://jnn.javaeye.com (Chinese) > >> > >> Twitter: willemjiang > >> Weibo: willemjiang -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
Re: RSS Feed for official Apache Camel News
That's kind of cool. I wonder if that could be added to the asf planet: http://blogs.apache.org/ Dan On Saturday, July 02, 2011 11:24:17 AM Christian Schneider wrote: > After testing this for a while on my reader I now added a RSS Feed for > the Apache Camel News to the Camel site. > So feel free to subscribe to always stay up to date about all the great > things that happen in the Apache Camel project. > > See (not yet synchronized): > http://camel.apache.org/ > > And the feed: > https://cwiki.apache.org/confluence/createrssfeed.action?types=blogpost&spac > es=CAMEL&title=Apache+Camel+News&sort=modified&maxResults=10&timeSpan=60&sho > wContent=true&confirm=Create+RSS+Feed > > > Christian -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
Re: why i building camel2.7.2 use maven install error?
On Thursday, June 30, 2011 11:29:00 AM Jon Anstey wrote:
> FYI I can build Camel trunk fine with IBM JDK 1.6.0 on Linux. So least that
> platform works :)
>
> janstey@duffman:/x1/asf/camel/trunk$ mvn --version
> Apache Maven 3.0.2 (r1056850; 2011-01-08 21:28:10-0330)
> Java version: 1.6.0, vendor: IBM Corporation
> Java home: /opt/ibm-java-i386-60/jre
> Default locale: en_CA, platform encoding: UTF-8
> OS name: "linux", version: "2.6.32-27-generic", arch: "x86", family: "unix"
Even from a clean? For me, a "mvn clean install" would fail with strange
errors and such:
Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)
Maven home: /opt/tools/maven
Java version: 1.6.0, vendor: IBM Corporation
Java home: /opt/ibm-jdk-bin-1.6.0.8_p1/jre
Default locale: en_US, platform encoding: ANSI_X3.4-1968
OS name: "linux", version: "2.6.39", arch: "amd64", family: "unix"
Dan
>
> On Wed, Jun 29, 2011 at 11:49 AM, Claus Ibsen wrote:
> > Its likely not only IBM JDKs.
> > HP-UX has been know to have compiling issues as well.
> >
> > Well we can always blame sun for creating the crappy confusing generics.
> > I guess the compiler engineers dont even get generics right as well.
> >
> > The work around I have seen was to add a type cast to the super type
> > ProcessorDefinition def = (ProcessorDefinition) processorType
> >
> > And then do that instacenof check afterwards. So something like
> >
> >
> > ProcessorDefinition def = (ProcessorDefinition) processorType;
> >
> > if (def instanceof LoadBalanceDefinition) {
> >
> > On Wed, Jun 29, 2011 at 4:05 PM, bvahdat
> >
> > wrote:
> > > Hi Claus,
> > >
> > > I suspect xiangqiuzhao uses the IBM-JDK6 which has this issue,
> >
> > @xiangqiuzhao
> >
> > > is this really the case?
> > > I used to experience exactly the same problem while using IBM-JDK,
> >
> > however
> >
> > > since moving to SUN-JDK the problem is resolved for me.
> > >
> > > On my box if I set JAVA_HOME to IBM's JDK, then 'mvn clean compile'
> > > on
> > > 'camel-core' comes up with (same as for xiangqiuzhao):
> > >
> > > [ERROR] Failed to execute goal
> > > org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile
> > > (default
> > > compile) on project camel-core: Compilation failure
> > > [ERROR]
> >
> > \Data\eclipse-workspace\camel-trunk\camel-core\src\main\java\org\apache\
> > camel\model\LoadBalanceDefinition.java:[134,16]
> >
> > > inconvertible types
> >
> > > [ERROR] found :
> > org.apache.camel.model.ProcessorDefinition<capture#945
> >
> > > of ?>
> > > [ERROR] required: org.apache.camel.model.LoadBalanceDefinition
> > >
> > > Where 'mvn -version' says:
> > > Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
> > > Maven home: P:\My Documents\dev\env\apache-maven-3.0.3\bin\..
> > > Java version: 1.6.0, vendor: IBM Corporation
> > > Java home: C:\Program Files\IBM\SDP75\jdk\jre
> > > Default locale: de_CH, platform encoding: Cp1252
> > > OS name: "windows xp", version: "5.1 build 2600 service pack 3",
> > > arch:
> > > "x86", family: "windows"
> > >
> > > If one would change the line 134 on LoadBalanceDefinition from:
> > > if (processorType instanceof LoadBalanceDefinition) {
> > >
> > > To:
> > > if (LoadBalanceDefinition.class.isInstance(processorType)) {
> > >
> > > Then the compilation would pass on this class. I didn't find
> > > anything
> >
> > about
> >
> > > this issue on
> > > http://camel.apache.org/does-camel-work-on-ibms-jdk.html
> > >
> > > Regards, Babak
> > > PS: actually there're more compilation issues while using IBM-JDK
> > >
> > > --
> >
> > > View this message in context:
> > http://camel.465427.n5.nabble.com/why-i-building-camel2-7-2-use-maven-in
> > stall-error-tp4532013p4535242.html
> >
> > > Sent from the Camel - Users mailing list archive at Nabble.com.
> >
> > --
> > Claus Ibsen
> > -
> > FuseSource
> > Email: cib...@fusesource.com
> > Web: http://fusesource.com
> > Twitter: davsclaus, fusenews
> > Blog: http://davsclaus.blogspot.com/
> > Author of Camel in Action: http://www.manning.com/ibsen/
--
Daniel Kulp
dk...@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: why i building camel2.7.2 use maven install error?
Yep. There are still a bunch of build related issues with the IBM JDK. The
last couple weeks, I managed to get all the UNIT TESTS passing on the IBM JDK
which was important to validate that Camel works with the IBM JDK, but there
are still a bunch of build related issues.The way camel uses antrun to run
the jxc stuff also doesn't work on the IBM JDK. I didn't get a chance to
look at that yet.
For now, I've had to use the Sun JDK to build, and then use the IBM JDK to run
the tests and such.
Patches are welcome to fix issues. :-)
Dan
On Wednesday, June 29, 2011 7:05:57 AM bvahdat wrote:
> Hi Claus,
>
> I suspect xiangqiuzhao uses the IBM-JDK6 which has this issue, @xiangqiuzhao
> is this really the case?
> I used to experience exactly the same problem while using IBM-JDK, however
> since moving to SUN-JDK the problem is resolved for me.
>
> On my box if I set JAVA_HOME to IBM's JDK, then 'mvn clean compile' on
> 'camel-core' comes up with (same as for xiangqiuzhao):
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default
> compile) on project camel-core: Compilation failure
> [ERROR]
> \Data\eclipse-workspace\camel-trunk\camel-core\src\main\java\org\apache\came
> l\model\LoadBalanceDefinition.java:[134,16] inconvertible types
> [ERROR] found : org.apache.camel.model.ProcessorDefinition<capture#945
> of ?>
> [ERROR] required: org.apache.camel.model.LoadBalanceDefinition
>
> Where 'mvn -version' says:
> Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
> Maven home: P:\My Documents\dev\env\apache-maven-3.0.3\bin\..
> Java version: 1.6.0, vendor: IBM Corporation
> Java home: C:\Program Files\IBM\SDP75\jdk\jre
> Default locale: de_CH, platform encoding: Cp1252
> OS name: "windows xp", version: "5.1 build 2600 service pack 3", arch:
> "x86", family: "windows"
>
> If one would change the line 134 on LoadBalanceDefinition from:
> if (processorType instanceof LoadBalanceDefinition) {
>
> To:
> if (LoadBalanceDefinition.class.isInstance(processorType)) {
>
> Then the compilation would pass on this class. I didn't find anything about
> this issue on http://camel.apache.org/does-camel-work-on-ibms-jdk.html
>
> Regards, Babak
> PS: actually there're more compilation issues while using IBM-JDK
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/why-i-building-camel2-7-2-use-maven-insta
> ll-error-tp4532013p4535242.html Sent from the Camel - Users mailing list
> archive at Nabble.com.
--
Daniel Kulp
dk...@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: Easy One way soap services
Quite honestly, I'm not sure why the CXF stuff in Camel has to be so
complex. To me, it should be based more on the technology in CXF that
supports the JAX-WS Dispatch/Provider stuff (or implemented via the JAX-WS
Dispatch/Provider stuff). In this case, if it was a "PAYLOAD" mode
Provider, it ends up as essentially the same thing. You get the payload as
a "Source" (in some cases, a StaxSource so streaming can be maintained) and
all the "soap" stuff is not there. If camel needs the whole message, the
Provider is put in MESSAGE mode.
The benefit of the Provider/Dispatch stuff is that you DO get all the
complext WS-* processing and things like schema validation and other
important things that CXF provides, but you don't have to do all the code
generation and things like that.
Dan
Christian Schneider wrote:
>
> Hi all,
>
> I am thinking about how to make one way services easier. Currently I
> generate code for the service using cxf codegen and use the camel-cxf
> module to create a client or endpoint that can be routed over jms using
> the camel-jms component. Using CXF for this task is a little overkill as
> very few features of CXF are used and quite a lot of configuration has
> to be done. I wonder if this can be done easier.
>
> I have experimented with a possible solution for the server part. It
> looks like this:
> from("jms:myqueue").process(new
> SoapProcessor("com.example.customerservice")).to("bean:serviceHandler");
>
> The idea is that a soap message for the service comes in over jms. The
> soap processor parses the soap xml, strips the Envelope and Body and
> unmarshals the content using JAXB. The processor needs the package name
> of the generated stub code for the service. The advantage over using
> camel-cxf is that there is much less configuration and you do not need
> cxf at runtime (which means much less jars). Additionally the
> serviceHandler bean only needs to have a method with the expected classs
> type as input parameter it does not need to implement a service
> interface. I have added the code of SoapProcessor to the mail as it is
> quite small.
>
> So what do you think? Does it make sense to have such small scale SOAP
> functionality in camel?
> I am thinking about turning my Processor into a DataFormat and provide
> marshalling and unmarshalling. Does this make sense or is a processor
> better?
>
> Greetings
>
> Christian
>
> --
>
> Christian Schneider
> ---
> http://www.liquid-reality.de
>
>
>
>
> import java.io.InputStream;
> import java.util.Iterator;
>
> import javax.xml.bind.JAXBContext;
> import javax.xml.bind.JAXBElement;
> import javax.xml.bind.JAXBException;
> import javax.xml.bind.Unmarshaller;
> import javax.xml.namespace.NamespaceContext;
> import javax.xml.xpath.XPath;
> import javax.xml.xpath.XPathConstants;
> import javax.xml.xpath.XPathExpression;
> import javax.xml.xpath.XPathExpressionException;
> import javax.xml.xpath.XPathFactory;
>
> import org.apache.camel.Exchange;
> import org.apache.camel.Processor;
> import org.w3c.dom.Element;
> import org.xml.sax.InputSource;
>
> public class SoapProcessor implements Processor {
>
> private XPathExpression xpathExpression;
> private Unmarshaller unmarshaller;
>
> public SoapProcessor(String jaxbPackage) {
> super();
> XPath xpath = XPathFactory.newInstance().newXPath();
> xpath.setNamespaceContext(new SoapNameSpaceContext());
> try {
> xpathExpression =
> xpath.compile("/soap:Envelope/soap:Body/*");
> JAXBContext jContext =
> JAXBContext.newInstance(jaxbPackage);
> unmarshaller = jContext.createUnmarshaller();
> } catch (XPathExpressionException e) {
> throw new RuntimeException(e.getMessage(), e);
> } catch (JAXBException e) {
> throw new RuntimeException(e.getMessage(), e);
> }
>
> }
>
> private final class SoapNameSpaceContext implements NamespaceContext {
> private static final String SOAP_NAMESPACE =
> "http://schemas.xmlsoap.org/soap/envelope/";;
>
> public Iterator getPrefixes(String namespaceURI) {
> return null;
> }
>
> public String getPrefix(String namespaceURI) {
> return null;
> }
>
> public String getNamespaceURI(String prefix) {
> return SOAP_NAMESPACE;
> }
> }
>
> public void process(Exchange exchange) throws Exception {
> InputStream request =
> exchange.getIn().getBody(InputStream.class);
> InputSource is = new InputSource(request);
> Element payload = (Element) xpathExpression.evaluate(is,
> XPathConstants.NODE);
> JAXBElement el = (JAXBElement)
> unmars
