Actually, I think I know what it is.
You have the route starting with
<from uri="jetty:http://0.0.0.0:8099/api/rest?matchOnUriPrefix=true";>
which looks like consumes the input stream completely and saves it on
the exchange. Hmm... Not sure if it is exactly right, but I guess that
is the way it is.
In our demo we have the route starting with:
<from uri="servlet:///HelloWorld?matchOnUriPrefix=true"/>
I think the latter option can be better, example, in OSGI this should
work better with HTTP Service, etc. It probably defaults to
localhost:8080 which can likely be configured further in the servlet
component.
You have though "0.0.0.0" which may be the reason why you want to start
with a Jetty frontend.
well, I'd consider checking if the same wildcard address can be done
with the servlet component, if not then replace HTTPServletRequest with
the wrapper as I suggested in the previous email. Can you try that ?
In meantime I can try preparing a patch
Sergey
On 11/06/13 13:40, Todd Orr wrote:
I have tried both streaming on and off. The behavior is the same. I think
this is because the inputstream on the request is not affected by this
setting.
On Mon, Jun 10, 2013 at 3:59 PM, Sergey Beryozkin <[email protected]>wrote:
Hi
On 10/06/13 20:05, Todd Orr wrote:
I spoke too soon. I have been trying to figure out why the CXF service's
JAXB unmarshalling has been throwing EOF in prolog errors. I created a
processor to get some idea as to what the messages are looking like before
getting sent off to CXF. My routes are configured as such:
<route>
<from uri="jetty:http://0.0.0.0:**8099/api/rest?**
matchOnUriPrefix=true<http://0.0.0.0:8099/api/rest?matchOnUriPrefix=true>
"
/>
<process ref="myBeanName" />
<to uri="direct:api" />
<to uri="ref:message-logger" />
</route>
streamCache is set to true. The processor has the following code:
HttpServletRequest request =
exchange.getIn(HttpMessage.**class).getRequest();
String something = IOUtils.toString(request.**getInputStream());
String requestBody =
IOUtils.toString(exchange.**getIn().getBody(InputStream.**class));
The request's inputStream, something, is "". The requestBody, however,
contains the entire XML structure that I am posting. I believe that the
problem is that Camel reads the incoming Http request's input stream and
copies the data to the Camel message body, but leaves the request's input
stream as read and therefore un-rereadable. Correct me if I'm wrong, but
it
is this request, I believe, that gets routed to the CXF service. Then CXF
has nothing to read and the unmarshalling fails.
Am I right? Is this a bug?
I'm not sure, we have a demo where this kind of routing works.
I wonder if enabling 'streamCache' can explain why the original
InputStream is empty, may be you should not enable that property ?
That said, I wonder if CXFRS (and CXF) component should check
exchange.getIn().getBody(**InputStream.class)
first ? And if it is set, then register HTTPServletRequestWrapper with
this stream returned instead ? I can do a patch if it makes sense...
Sergey
On Mon, Jun 3, 2013 at 4:13 PM, Todd Orr <[email protected]> wrote:
That works perfectly. Thanks!
On Mon, Jun 3, 2013 at 4:09 PM, Sergey Beryozkin <[email protected]
wrote:
Hi
On 03/06/13 20:53, Todd Orr wrote:
I'm relatively new to Camel. I did research what I am attempting to do,
but
did not find much help.
The goal is to take an existing standalone CXF rest service (with many
service beans) and split it into multiple independent CXF rest services
coordinated by Camel.
As an initial step, I am attempting to front the existing service with
Camel. So to be clear, at this stage, I only want to pass HTTP requests
from Camel down to the CXF service. To this end I have run into
multiple
issues. I am currently unable to route the HTTP message received by
Camel
to the CXF service.
My route:
<route>
<from
uri="servlet:///rest?****servletName=CamelAPI&****
matchOnUriPrefix=true"
/>
<to uri="ref:message-logger" />
<setBody><simple>****CamelHttpServletRequest</****
simple></setBody>
<to uri="ref:message-logger" />
<to uri="direct:api" />
</route>
I have configured CXF using camel's transport factory using:
<bean
class="org.apache.camel.****component.cxf.transport.**
CamelTransportFactory">
<property name="bus" ref="cxf" />
<property name="camelContext" ref="camelContext" />
<property name="checkException" value="true" />
<property name="transportIds">
<list>
<value>http://cxf.apache.org/****transports/camel<http://cxf.apache.org/**transports/camel>
<http://cxf.**apache.org/transports/camel<http://cxf.apache.org/transports/camel>
</value>
</list>
</property>
</bean>
This was required to get around some earlier issues I ran into. My CXF
service is configured like:
<jaxrs:server id="restService" address="direct:api">
<jaxrs:serviceBeans>
...
Startup is fine. On attempting to hit the servlet via RESTClient I can
see
the message I passed in logged correctly. However, the CXF service
cannot
receive the message. The error is:
No consumers available on endpoint: Endpoint[direct://api] to process:
Exchange ...
Any help is greatly appreciated.
This is an interesting idea, to try to use a 'direct' URI scheme as
jaxrs server endpoint. I don't think it works right now, and I'm not
sure
what has to be done yet, but definitely worth investigating...
In meantime, using Camel transport scheme will do, try something like
this:
<jaxrs:server id="hello_rest" address="camel://direct:**
HelloWorldRestServerEndpoint">
<!-- usual declarations here -->
</jaxrs:server>
<!-- Camel routes from addresses on the servlet to rest and jaxws
servers -->
<camelContext id="camelContext" xmlns="http://camel.apache.**
org/schema/spring
<http://camel.apache.org/**schema/spring<http://camel.apache.org/schema/spring>>"
trace="false">
<route>
<from uri="servlet:///HelloWorld?****
matchOnUriPrefix=true"/>
<to uri="direct:****HelloWorldRestServerEndpoint"/****>
</route>
</camelContext>
HTH, Sergey
T
