I have a setup with Swagger and the Rest DSL. Swagger uses the
OutType(MyType.class) to annotate the API with the return type. However,
there are times when I wish to return something else to the caller, e.g. an
error message with a HTTP response code.
Take the following Route as an example:
I am going to answer this one myself. As it is you cannot use content from
the Exchange message to manipulate the Gson marshalling. At least not using
the built in GsonDataFormat. You need to roll your own dataformat and use
that. I guess that is fair enough :)
--
View this message in context:
I am struggling to wrap my head around how to create a Gson ExclusionStrategy
that depends on a value in the Message object from the Exchange (this is
stored in a Header).
I am registering restConfiguration().setJsonDataFormat(json-gson) in my
route definition (so Google Gson is being used for
I will, and have: https://issues.apache.org/jira/browse/CAMEL-7936
Thanks.
--
View this message in context:
http://camel.465427.n5.nabble.com/Query-paramteres-in-the-REST-DSL-Camel-2-14-tp5757650p5757831.html
Sent from the Camel - Users mailing list archive at Nabble.com.
I I expose this class:
@ApiModel(value = MyDTO , description = My data transporter)
public class MyDTO {
@ApiModelProperty(value = This is a private field)
private String myPrivateField;
}
Swagger will not document the class as JSON. I am unsure if this is
happening in camel-core, or if
NB, this is happening in camel-swagger 2.14.0
--
View this message in context:
http://camel.465427.n5.nabble.com/Private-variables-not-being-inspected-camel-swagger-tp5757833p5757834.html
Sent from the Camel - Users mailing list archive at Nabble.com.
I haven't tried going through CXF. We are trying to be consistent in the
route definitions, and the REST DSL is extremely clean and nice in that
regards (however still lacking a few features - such as interceptors and
query paramteres).
--
View this message in context:
It will not be possible to intercept a pure RESTdsl route until it has been
implemented in the camel-core. However I was able to work around it by
piping it into a normal route like this:
rest(/holdings).description(Holdings service)
I am unable to figure out how to expose Query params to a Rest resource
exposed with the new Rest DSL in Camel 2.14
How would I go about to enable something like 'username' and 'password' via
query params?
rest(/user).description(User services)
.get(/login).description(Login user.
Thank you for your answer.
If this is how the Rest DSL enables it, how is it then possible to tell E.G.
the new Swagger component that we are supporting the two parameters?
--
View this message in context:
I am struggelig to get interceptFrom() working for the rest-DSL.
My project only has one Rest DSL route.
If I add interceptFrom().stop() in the beginning of a my RouteDefinition
file, no stop of that route occurs. In addition, if I add the
interceptFrom().stop() after my rest dsl route is
Here is a snippet of the code:
@Component
@DependsOn(camelConfig)
public class IncomingRestCalls extends RouteBuilder {
interceptFrom().id(Logging interceptor).bean(NISAccessLog.class);
restConfiguration()more code here..;
rest(NISConfig.API_VERSION_1 +
I've been able to work a bit more on this topic. Here is what is happening.
The exchange headers used in the Camel part propagates into HTTP headers. I
wasen't aware of this.
Websphere is very strict about the content of the headers and a data object
that I was using carried an illegal sequence
Yes, I removed the header, and that works fine.
However carrying all exchange headers over to HTTP headers makes it very
difficult to carry over route payload if the CXF endpoint was not the last
endpoint. However, I am getting the feeling it is not going to be easily
possible to respond back to
Thank you for your reply.
For the WSDL: Yes, return type is correct.
xs:complexType name=fetchVesselRegisterV1Response
xs:sequence
xs:element minOccurs=0 name=return type=xs:string/
/xs:sequence
/xs:complexType
I have tried both staying away from putting anything into the
No change when wrapping the string inside an object.
I have two other contract first webservices. Those does not display the
above behaviour. So I am going to pick up the WSDL file and rewrite the
spring wiring.
--
View this message in context:
I have created a CXF webservice and exposed it with camel. The webservice is
code first (JSR-181) annotated Java class, springed up in my application
context.
The class looks like this:
@WebService(name=DataExport, serviceName=DataExport,
targetNamespace=com.somecompany.dataexport.v1)
public
NB: Camel version: 2.6.0 (latest possible on Websphere 6.1).
--
View this message in context:
http://camel.465427.n5.nabble.com/Websphere-6-1-0-45-Unable-to-return-data-from-a-camel-cxf-component-POJO-mode-tp5726083p5726084.html
Sent from the Camel - Users mailing list archive at Nabble.com.
I am unsure which approach I should take in order to express the following
route as a Java DSL.
This is part of a password reset function with an email being sent out.
1. Consume a client rest call from the web via a rest URL
2. Do the reset stuff in the database
2a. Return OK to the Rest
Is it possible to discover if aJMS message processing threw an exception when
you aggregate after a split (that splits to JMS)?
I have tried using an aggregator that runs on completionSize (that I set
prior to splitting). All messages sent to the JMSqueue show up, but no
indication of exceptions
I have a compound problem that i am unsure if has arisen due to lack of
architectural understanding.
I have a route that consumes a POJO call from a contract first Webservice.
This message is a XML that is split up into pieces and consumed individually
(as JMS messages). In the process of
I think I have found the answer.
For 1:
Tell Camel that the message that replies back to the originator is the
ConvertImportFileWSToImportJob by adding the .inOnly() flag later in the
route. Now the exchange.out.body will be sent back to the caller of the
Webservice.
22 matches
Mail list logo
