Hi
FYI, I'm actually seeing this combination (jetty at the top of the route
as opposed to servlet delegating to jaxrs:server) also working in the
demo I'm working upon now...
I wonder if the problem you were seeing had something to do with the
test set up.
Cheers, Sergey
On 11/06/13 14:55, Todd Orr wrote:
Thanks for your attention to this! I am only using Jetty for unit
testing. I have a route using the servlet endpoint as well for server
deployments. I am now working with a locally deployed instance and it
works as expected. I suppose I will need to find an alternative testing
mechanism. Thanks!
On Tue, Jun 11, 2013 at 8:58 AM, Sergey Beryozkin <sberyoz...@gmail.com
<mailto:sberyoz...@gmail.com>> wrote:
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
<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
<sberyoz...@gmail.com <mailto:sberyoz...@gmail.com>>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
<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
<torr0...@gmail.com <mailto:torr0...@gmail.com>> wrote:
That works perfectly. Thanks!
On Mon, Jun 3, 2013 at 4:09 PM, Sergey Beryozkin
<sberyoz...@gmail.com <mailto:sberyoz...@gmail.com>
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>>
<http://cxf.**apache.org/__transports/camel
<http://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><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
