I have a camel cxf-rs endpoint that splits the requests into two main parts.
form("cxfrs:bean:rsServer")
.when(isForward()).to("cxfrs:http://example.com")
.otherwise().process(myCustomDispatcher) // i want to get rid of this custom dispatcher
The first part is straight forwarded to a different service.
For the second part i would like to dispatch/call classes/methods that have jaxrs annotation. Currently i have a custom processor myCustomerDispatcher that duplicates the logic from the annotations and dispatches manually to classes and methods. Especially #Path and #PathParams are duplicated.
I tried:
to("bean:MyJaxRsImplemantion") this will work for beans with a single method matching the parameters in the camel exchange, but does not consider jax-rs annotations.
Serveral combinations with to("cxfrs:bean:cxfEndpoint?resourceClasses=MyJaxRsImplemantion"). it either requires a forwarding address, or acts on a new endpoint creating camel exchanges. I couldn't find a way to call the actual implementation.
The ProduceTemplates all seem to handle singular paths or situations.
Question:
How can i write a camel route that actually calls jax-rs resource methods without forwarding to a new service?
This is actually a really tough question. For one, even when you google it you don't get any straight answers. After an eternity of web surfing, it feels like it's the law of the land for camel routes to call jx-rs resource methods by forwarding to a new service.
And yes, it's almost like to("bean:MyJxRsImplemantion") is DESIGNED to ignore jax-rs annotations. So I've decided that it's impossible. Sorry.
Related
I have a restful server using spring mvc. Many of the controllers (though not all) take a certain path parameter /fruits/{type}.
I need to centrally configure what types of fruit are acceptable. I.e., apple, banana, cherry are ok. For everything else I need to throw a 400 level http status code.
It is important that this be done quickly and elegantly. Some ways that this can be done are:
I write some kind of utility pojo and invoke it's method in every controller method that handles /fruit/{type}. Seems pretty cludgy.
A spring web request interceptor
Spring security?
AOP?
Something else?
What is the most professional, quick, elegant way to achieve this goal?
You might not get a 'best way' answer. Each 'best way' depends on your specific situation, needs, and desires. Here is 'a' way...
We do this via PropertyEditors during request Binding.
You could have one PropertyEditor per controller type and if you do not receive the correct type of 'thing' you're expecting then throw an exception from the PropertyEditor.
You can register your PropertyEditors per Controller or globally via a customized PropertyEditorRegistrar mapped to a RequestMappingHandlerAdapter.
I would then use the Spring SimpleMappingExceptionResolver to map your different exceptions to the view and error code you want to return.
BTW, I would consider using 404 vs 400, but that is just me.
We are facing problems with XSS attacks to our application. We are preventing this by using normal filters for GET requests.
We are using RESTEasy REST webservice calls to our application. Our filter not filtering the data inside form GET/POST/DELETE/PUT requests.
The basic requirment is we need to check the XSS attacks on all the fields,headers and cookies as well.
How do we get the posted values before invoking the method. Just like filters what we did for normal requests.
I am using resteasy2.0 version for our app.
Is there anyway to update the request wrapper before going to invoke rest method.
Please give us some suggestions on this. Thanks in advance.
Thanks,
Govind.
Resteasy 2.0 allows you to use Interceptors on JAX-RS invocations and route them through listener-like objects.
You can declare an interceptor to check your request body and/or header before a JAX-RS resource method is invoked.
You can give a look to the docs here : Resteasy Interceptors Documentation
An example on how use it : Resteasy Interceptors Example
If I have understood it properly you want a filter like in Servlet so that you can handle each request before it hit the REST function. It will also keep your implementation common for all REST alls. Correct me if I am wrong.
One simple solution coming in my mind though I never worked with resteasy2.0.
You can write a common function and call that function from your REST methods first line. Check for scripting elements in that function and if found throw error or do something else.
I'm trying to do a PoC in order to implement the pipes and filters eip pattern with Apache Camel.
From Camel documentation, I'm assuming that each filter must be implemented as an Endpoint ("With Camel you can split your processing across multiple independent Endpoint instances which can then be chained together.")
So, if I understood correctly, the Authenticate filter (from the example) must implement the Endpoint interface.
The "problem" is that I don't want to "re-invent the wheel". So instead of implementing the interface from the scratch, I'm almost sure that I can use an already implemented one. And the one is the BeanEndpoint.
Is that right?
I found a few examples of pipes and filters patterns (like this one) but none of then show how to implement the beans.
Can someone provide a bean implementation example?
TIA,
Bob
First of all, although I get where you're coming from when you say "camel implements filters as endpoints", I wouldn't strictly classify them as endpoints. More like message transformer/translators in my opinion.
So, in case you need to implement a custom filter as per your requirement, use the processor interface.
Basically, write a class(say, CustomProcessor) that implements Camel's Processor and write your custom filter strategy. Then, call it in your route as to("CustomProcessor").
The Processor page will surely clear all your concerns, so please have a look.
Also I assume you're aware of the camel message-filter pattern.
Thank you.
The Camel EIPs is listed here, and they all have examples and whatnot
http://camel.apache.org/eip
So for the pipes and filters you can find it on that link and see some examples
http://camel.apache.org/pipes-and-filters.html
And it seems you are new to Camel. Then I suggest to read this intro article to get your heads around Camel: http://java.dzone.com/articles/open-source-integration-apache
I'm trying to wrap my head around Apache Camel, and after spending some time this morning reading both the online Camel docs as well as the Javadocs, I have some questions that I can't seem to find answers for.
Is it true that all endpoints are either consumers or producers (or both)? Is it true that all processors are endpoints? Are there
any endpoints that are not processors?
What's the difference between a Message header and an Exchange? An exchange is considered to be a "message container", but how is that different from the metadata that a header would contain?
Is it typical to implement your own Message/Exchange? If so, what would be an example of doing so, and "straying" from the typical DefaultMessage and DefaultExchange?
Thanks in advance.
First things first: A good suggestion is to read the book Camel in Action, it explains most of the basic concepts. There is a free first chapter available online which explains the kind of questions you ask http://manning.com/ibsen/
An endpoint references a component and some component specific options, such as addresses etc. The endpoint can then (depending on the component) function as either consumer (ex. "servlet:path/to/web/service") or producer (ex. "http://localhost/path/to/web/service") or both of them (ex. "jms:queue:orderQueue").
There are headers in Camel messages as well. An exchange outlives an entire route, and exchange properties will also stay for the entire route. Message headers in Camel are a bit different concept. They are often closely mapped to the component used - i.e. a HTTP endpoint might set/change headers (for instance COOKIES etc.) while HTTP headers has no influence on exchange properties as these are for use within the camel route and camel logic only. The exchange also wrapps other non message specific things, such as exceptions.
It is quite uncommon to develop new message implementations. There could be a point in extending DefaultMessage when you have implemented your own component/protocol and need to keep instances of helper objects around in the message or whatnot. It's typically not done even when developing components. I have never heard of any custom implementation of an Exchange, and you should typically not do so without good reasons.
#DirtyMikeAndTheBoys you wrote:
Is it true that all processors are endpoints? Are there any endpoints
that are not processors?
This is not true. 'Processors' in Camel terminology are callbacks which are part of some pattern (like Aggregator, Message Channel or RoutingSlip). Processors receive the messages when they are flowing within a route and do something on messages. Messages are wrapped within Exchanges.
An Endpoint is where a route will receive messages (consumer endpoint) and where it will send the processed messages (To endpoint). So when you see the 'from' clause in a route, Camel engine is using a 'Consumer' instance associated with the endpoint instance defined in 'from' clause. It really depends on the endpoint implementation whether a new consumer instance is created/reused every where that given endpoint appears in a 'from' clause in your camel context.
Similarly when the same endpoint is mentioned in a 'To' clause, a Producer instance will be used (either created/reused) and will remain associated with the endpoint instance.
I've been poring over the Apache Camel docs trying to get a concrete understanding of two of its most basic concepts (endpoints and routes), and although these terms are used everywhere throughout the docs, I can find no reference that actually defines what they are and what they are used for. And although their names are fairly obvious-sounding, and I think I understand what they are, I've now been assigned to a task that has landed me neck-deep in Apache Camel Land, and its absolutely vital that I understand what these mechanisms are.
My guess is that an "endpoint" is just a bean - one that can be configured in a config file like any other - that maps a name to a URI/port combo (this taken from the W3C docs). In the context of Apache Camel, my guess is that endpoints are used to connect components together, so that "routes" (connections/maps) can be formed between them. So when Component A living at Endpoint 1 wants to communicate with Component B living at Endpoint 2, so long as there is a mapping from 1 to 2, Camel will be able to transmit messages between these two.
Please stop me and correct me if I am wrong here!
So now, I've seen examples where it looks like routes can be configured in Java:
from("endpointA").routeId("someMessage").to("endpointB");
And I've seen examples where it looks like routes can be configured in XML:
<route id="">
<from .../>
<to .../>
</route>
Are these two methods for configuring routes, or are they different concepts altogether?
Finally, what is the format of the messages that can be routed between endpoints? If it has to be XML, for example, what is the XSD/schema of these routed messages? If it has to be a Java object, what bounds/restrictions apply to the objects that Camel can send?
It seems like you are getting a decent grasp of the concept.
I think it helps to think about endpoints in more abstract terms. The camel documentation is not much help here. Endpoints can be thought of as interfaces to a component. Each component can have 1 or more endpoints configured. It helps me to think about endpoints within the context of a route. A simple route can go from Endpoint A (This could be a JMS Queue, tcp socket, file or any camel component) and go to Endpoint B (which can be any camel component). You can of course have processors in the route too that transform the data.
The two examples of route creation you give are just that, two ways to create a route. They are the examples of the same concept. The first being Java DSL and the second using XML.
The format of the messages is typically XML, and the XML can be any valid XML and does not need to be tied to an XSD. The message can also be any Java object. As long as it is staying in the JVM (ie, not going over a socket) it doesn't need to be serializeable.
Route is an ordered combination of processing steps
Endpoint represents the beginning or end of a route (for the most part), that other routes might connect to as their beginning/end or might back onto an external system (e.g. JMS, email, etc.)