[jira] [Updated] (CAMEL-9271) Extending RouteDefinition
[ https://issues.apache.org/jira/browse/CAMEL-9271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hans Orbaan updated CAMEL-9271: --- Attachment: ProcessorDefinition-2.16.x.patch > Extending RouteDefinition > - > > Key: CAMEL-9271 > URL: https://issues.apache.org/jira/browse/CAMEL-9271 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.16.0 >Reporter: Hans Orbaan >Priority: Trivial > Attachments: ProcessorDefinition-2.16.x.patch > > > Extending RouteDefinition gives issues because of 1 line in the > ProcessorDefinition. RouteDefinition should be made final or the attached > patch is needed. changing: > boolean parentIsRoute = > this.getClass().isAssignableFrom(RouteDefinition.class.); > to > boolean parentIsRoute = > RouteDefinition.class.isAssignableFrom(this.getClass()); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9272) openweathermap.org requires an APPID id since 09/10/2015
Charles Moulliard created CAMEL-9272:
Summary: openweathermap.org requires an APPID id since 09/10/2015
Key: CAMEL-9272
URL: https://issues.apache.org/jira/browse/CAMEL-9272
Project: Camel
Issue Type: Bug
Components: weather
Reporter: Charles Moulliard
Code must be updated as openweathermap.org requires an APPID id since
09/10/2015 & by consequence, the component can't be used anymore as we will get
a HTTP 401 error.
{code}
Caused by: org.apache.camel.TypeConversionException: Error during type
conversion from type: java.net.URL to the required type: java.lang.String with
value http://api.openweathermap.org/data/2.5/weather?q=Paris,France due
java.io.IOException: Server returned HTTP response code: 401 for URL:
http://api.openweathermap.org/data/2.5/weather?q=Paris,France
at
org.apache.camel.impl.converter.BaseTypeConverterRegistry.createTypeConversionException(BaseTypeConverterRegistry.java:610)
at
org.apache.camel.impl.converter.BaseTypeConverterRegistry.mandatoryConvertTo(BaseTypeConverterRegistry.java:177)
at
org.apache.camel.impl.converter.BaseTypeConverterRegistry.mandatoryConvertTo(BaseTypeConverterRegistry.java:156)
at
org.apache.camel.component.weather.WeatherProducer.process(WeatherProducer.java:48)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7860) Add sendReply functionality in RabbitMQConsumer
[
https://issues.apache.org/jira/browse/CAMEL-7860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14980608#comment-14980608
]
Fergus Nelson commented on CAMEL-7860:
--
I have recently upgraded from 2.12 to 2.16 and i am facing some issues with the
way this feature is implemented.
The rabbit producer will wait for a replay and timeout even when i have not set
a replyto. This seems to be related to the Exchange having an exchange pattern
of InOut , even though i have never set an exchange pattern of inout anywhere.
The BeanExpression seems to set the exchange pattern to inout?
If no replyTo is set should it really create a random queue and then fail when
there is no replay? This definitely breaks the principle of least surprise.
> Add sendReply functionality in RabbitMQConsumer
> ---
>
> Key: CAMEL-7860
> URL: https://issues.apache.org/jira/browse/CAMEL-7860
> Project: Camel
> Issue Type: Improvement
> Components: camel-rabbitmq
>Affects Versions: 2.13.2, 2.14.0
>Reporter: Raymond Cuenen
>Assignee: Willem Jiang
>Priority: Minor
> Labels: improvement, rpc
> Fix For: 2.15.0
>
> Attachments: consumer.patch
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> To provide the RPC functionality with RabbitMQ as described
> [here|http://www.rabbitmq.com/tutorials/tutorial-six-java.html] the
> {{ExchangePattern}} should be changed to {{InOut}} when the {{replyTo}} is
> present in the AMQP properties for the {{RabbitMQConsumer}}.
> After processing the {{Exchange}} the reply message can than be retrieved and
> published to the reply queue.
> For JMS is a similar construction already implemented.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9272) openweathermap.org requires an APPID id since 09/10/2015
[
https://issues.apache.org/jira/browse/CAMEL-9272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charles Moulliard updated CAMEL-9272:
-
Fix Version/s: 2.15.5
2.16.1
2.17
> openweathermap.org requires an APPID id since 09/10/2015
>
>
> Key: CAMEL-9272
> URL: https://issues.apache.org/jira/browse/CAMEL-9272
> Project: Camel
> Issue Type: Bug
> Components: weather
>Reporter: Charles Moulliard
> Fix For: 2.16.1, 2.15.5, 2.17
>
>
> Code must be updated as openweathermap.org requires an APPID id since
> 09/10/2015 & by consequence, the component can't be used anymore as we will
> get a HTTP 401 error.
> {code}
> Caused by: org.apache.camel.TypeConversionException: Error during type
> conversion from type: java.net.URL to the required type: java.lang.String
> with value http://api.openweathermap.org/data/2.5/weather?q=Paris,France due
> java.io.IOException: Server returned HTTP response code: 401 for URL:
> http://api.openweathermap.org/data/2.5/weather?q=Paris,France
> at
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.createTypeConversionException(BaseTypeConverterRegistry.java:610)
> at
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.mandatoryConvertTo(BaseTypeConverterRegistry.java:177)
> at
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.mandatoryConvertTo(BaseTypeConverterRegistry.java:156)
> at
> org.apache.camel.component.weather.WeatherProducer.process(WeatherProducer.java:48)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-9273) Enhance camel-weather component to support all the options of Api 2.5
Charles Moulliard created CAMEL-9273:
Summary: Enhance camel-weather component to support all the
options of Api 2.5
Key: CAMEL-9273
URL: https://issues.apache.org/jira/browse/CAMEL-9273
Project: Camel
Issue Type: Bug
Components: camel-weather
Reporter: Charles Moulliard
Many others queries are supported by the weather Api.
We should update the component to support more options
{code}
WEATHER
Access current weather data for any location on Earth including over 200,000
cities! Current weather is frequently updated based on global models and data
from more than 40,000 weather stations. Data is available in JSON, XML, or HTML
format.
api.openweathermap.org/data/2.5/weather?q={city name}
api.openweathermap.org/data/2.5/weather?q={city name},{country code}
api.openweathermap.org/data/2.5/weather?id=2172797
api.openweathermap.org/data/2.5/weather?lat={lat}={lon}
api.openweathermap.org/data/2.5/weather?zip={zip code},{country code}
api.openweathermap.org/data/2.5/box/city?bbox=12,32,15,37,10=yes
api.openweathermap.org/data/2.5/find?lat=55.5=37.5=10
api.openweathermap.org/data/2.5/group?id=524901,703448,2643743=metric
FORECAST - 5d
5 day forecast is available at any location or city. It includes weather data
every 3 hours. Forecast is available in JSON, XML, or HTML format.
api.openweathermap.org/data/2.5/forecast?q={city name},{country code}
api.openweathermap.org/data/2.5/forecast?id={city ID}
api.openweathermap.org/data/2.5/forecast?lat={lat}={lon}
FORECAST - 16d
16 day forecasts is available at any location or city. Forecasts include daily
weather and available in JSON, XML, or HTML format.
api.openweathermap.org/data/2.5/forecast/daily?q={city name},{country
code}={cnt}
api.openweathermap.org/data/2.5/forecast/daily?id={city ID}={cnt}
api.openweathermap.org/data/2.5/forecast/daily?lat={lat}={lon}={cnt}
HISTORY
http://api.openweathermap.org/data/2.5/history/city?id={id}=hour={start}={end}
http://api.openweathermap.org/data/2.5/history/city?id={id}=hour={start}={cnt}
start start date (unix time, UTC time zone), e.g. start=1369728000
end end date (unix time, UTC time zone), e.g. end=1369789200
cnt amount of returned data (one per hour, can be used instead of 'end')
http://api.openweathermap.org/data/2.5/history/city?q={city ID},{country
code}=hour={start}={end}
http://api.openweathermap.org/data/2.5/history/city?q={city ID},{country
code}=hour={start}={cnt}
http://api.openweathermap.org/data/2.5/history/city?lat={lat}={lon}=hour={start}={end}
http://api.openweathermap.org/data/2.5/history/city?lat={lat}={lon}=hour={start}={cnt}
http://api.openweathermap.org/data/2.5/history/station?id={id}=tick
http://api.openweathermap.org/data/2.5/history/station?id={id}=hour
http://api.openweathermap.org/data/2.5/history/station?id={id}=day
STATION
http://api.openweathermap.org/data/2.5/station?id={id}
http://api.openweathermap.org/data/2.5/box/station?cluster={yes/no}={cnt}={bbox}
http://api.openweathermap.org/data/2.5/station/find?lat=55=37=30
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9273) Enhance camel-weather component to support all the options of Api 2.5
[
https://issues.apache.org/jira/browse/CAMEL-9273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14981127#comment-14981127
]
Charles Moulliard commented on CAMEL-9273:
--
Use HttpURLConnection class instead of calling the HTTP Server (Weather API)
when the URL(q) is converted into a String.
That will allow to specify the method to be used, to define a timeout, to
handle the response code
> Enhance camel-weather component to support all the options of Api 2.5
> -
>
> Key: CAMEL-9273
> URL: https://issues.apache.org/jira/browse/CAMEL-9273
> Project: Camel
> Issue Type: Bug
> Components: camel-weather
>Reporter: Charles Moulliard
>
> Many others queries are supported by the weather Api -
> http://openweathermap.org/api.
> We should update the component to support more options
> {code}
> WEATHER
> Access current weather data for any location on Earth including over 200,000
> cities! Current weather is frequently updated based on global models and data
> from more than 40,000 weather stations. Data is available in JSON, XML, or
> HTML format.
> api.openweathermap.org/data/2.5/weather?q={city name}
> api.openweathermap.org/data/2.5/weather?q={city name},{country code}
> api.openweathermap.org/data/2.5/weather?id=2172797
> api.openweathermap.org/data/2.5/weather?lat={lat}={lon}
> api.openweathermap.org/data/2.5/weather?zip={zip code},{country code}
> api.openweathermap.org/data/2.5/box/city?bbox=12,32,15,37,10=yes
> api.openweathermap.org/data/2.5/find?lat=55.5=37.5=10
> api.openweathermap.org/data/2.5/group?id=524901,703448,2643743=metric
> FORECAST - 5d
> 5 day forecast is available at any location or city. It includes weather data
> every 3 hours. Forecast is available in JSON, XML, or HTML format.
> api.openweathermap.org/data/2.5/forecast?q={city name},{country code}
> api.openweathermap.org/data/2.5/forecast?id={city ID}
> api.openweathermap.org/data/2.5/forecast?lat={lat}={lon}
> FORECAST - 16d
> 16 day forecasts is available at any location or city. Forecasts include
> daily weather and available in JSON, XML, or HTML format.
> api.openweathermap.org/data/2.5/forecast/daily?q={city name},{country
> code}={cnt}
> api.openweathermap.org/data/2.5/forecast/daily?id={city ID}={cnt}
> api.openweathermap.org/data/2.5/forecast/daily?lat={lat}={lon}={cnt}
> HISTORY
> http://api.openweathermap.org/data/2.5/history/city?id={id}=hour={start}={end}
> http://api.openweathermap.org/data/2.5/history/city?id={id}=hour={start}={cnt}
> start start date (unix time, UTC time zone), e.g. start=1369728000
> end end date (unix time, UTC time zone), e.g. end=1369789200
> cnt amount of returned data (one per hour, can be used instead of 'end')
> http://api.openweathermap.org/data/2.5/history/city?q={city ID},{country
> code}=hour={start}={end}
> http://api.openweathermap.org/data/2.5/history/city?q={city ID},{country
> code}=hour={start}={cnt}
> http://api.openweathermap.org/data/2.5/history/city?lat={lat}={lon}=hour={start}={end}
> http://api.openweathermap.org/data/2.5/history/city?lat={lat}={lon}=hour={start}={cnt}
> http://api.openweathermap.org/data/2.5/history/station?id={id}=tick
> http://api.openweathermap.org/data/2.5/history/station?id={id}=hour
> http://api.openweathermap.org/data/2.5/history/station?id={id}=day
> STATION
> http://api.openweathermap.org/data/2.5/station?id={id}
> http://api.openweathermap.org/data/2.5/box/station?cluster={yes/no}={cnt}={bbox}
> http://api.openweathermap.org/data/2.5/station/find?lat=55=37=30
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9273) Enhance camel-weather component to support all the options of Api 2.5
[
https://issues.apache.org/jira/browse/CAMEL-9273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charles Moulliard updated CAMEL-9273:
-
Description:
Many others queries are supported by the weather Api -
http://openweathermap.org/api.
We should update the component to support more options
{code}
WEATHER
Access current weather data for any location on Earth including over 200,000
cities! Current weather is frequently updated based on global models and data
from more than 40,000 weather stations. Data is available in JSON, XML, or HTML
format.
api.openweathermap.org/data/2.5/weather?q={city name}
api.openweathermap.org/data/2.5/weather?q={city name},{country code}
api.openweathermap.org/data/2.5/weather?id=2172797
api.openweathermap.org/data/2.5/weather?lat={lat}={lon}
api.openweathermap.org/data/2.5/weather?zip={zip code},{country code}
api.openweathermap.org/data/2.5/box/city?bbox=12,32,15,37,10=yes
api.openweathermap.org/data/2.5/find?lat=55.5=37.5=10
api.openweathermap.org/data/2.5/group?id=524901,703448,2643743=metric
FORECAST - 5d
5 day forecast is available at any location or city. It includes weather data
every 3 hours. Forecast is available in JSON, XML, or HTML format.
api.openweathermap.org/data/2.5/forecast?q={city name},{country code}
api.openweathermap.org/data/2.5/forecast?id={city ID}
api.openweathermap.org/data/2.5/forecast?lat={lat}={lon}
FORECAST - 16d
16 day forecasts is available at any location or city. Forecasts include daily
weather and available in JSON, XML, or HTML format.
api.openweathermap.org/data/2.5/forecast/daily?q={city name},{country
code}={cnt}
api.openweathermap.org/data/2.5/forecast/daily?id={city ID}={cnt}
api.openweathermap.org/data/2.5/forecast/daily?lat={lat}={lon}={cnt}
HISTORY
http://api.openweathermap.org/data/2.5/history/city?id={id}=hour={start}={end}
http://api.openweathermap.org/data/2.5/history/city?id={id}=hour={start}={cnt}
start start date (unix time, UTC time zone), e.g. start=1369728000
end end date (unix time, UTC time zone), e.g. end=1369789200
cnt amount of returned data (one per hour, can be used instead of 'end')
http://api.openweathermap.org/data/2.5/history/city?q={city ID},{country
code}=hour={start}={end}
http://api.openweathermap.org/data/2.5/history/city?q={city ID},{country
code}=hour={start}={cnt}
http://api.openweathermap.org/data/2.5/history/city?lat={lat}={lon}=hour={start}={end}
http://api.openweathermap.org/data/2.5/history/city?lat={lat}={lon}=hour={start}={cnt}
http://api.openweathermap.org/data/2.5/history/station?id={id}=tick
http://api.openweathermap.org/data/2.5/history/station?id={id}=hour
http://api.openweathermap.org/data/2.5/history/station?id={id}=day
STATION
http://api.openweathermap.org/data/2.5/station?id={id}
http://api.openweathermap.org/data/2.5/box/station?cluster={yes/no}={cnt}={bbox}
http://api.openweathermap.org/data/2.5/station/find?lat=55=37=30
{code}
was:
Many others queries are supported by the weather Api.
We should update the component to support more options
{code}
WEATHER
Access current weather data for any location on Earth including over 200,000
cities! Current weather is frequently updated based on global models and data
from more than 40,000 weather stations. Data is available in JSON, XML, or HTML
format.
api.openweathermap.org/data/2.5/weather?q={city name}
api.openweathermap.org/data/2.5/weather?q={city name},{country code}
api.openweathermap.org/data/2.5/weather?id=2172797
api.openweathermap.org/data/2.5/weather?lat={lat}={lon}
api.openweathermap.org/data/2.5/weather?zip={zip code},{country code}
api.openweathermap.org/data/2.5/box/city?bbox=12,32,15,37,10=yes
api.openweathermap.org/data/2.5/find?lat=55.5=37.5=10
api.openweathermap.org/data/2.5/group?id=524901,703448,2643743=metric
FORECAST - 5d
5 day forecast is available at any location or city. It includes weather data
every 3 hours. Forecast is available in JSON, XML, or HTML format.
api.openweathermap.org/data/2.5/forecast?q={city name},{country code}
api.openweathermap.org/data/2.5/forecast?id={city ID}
api.openweathermap.org/data/2.5/forecast?lat={lat}={lon}
FORECAST - 16d
16 day forecasts is available at any location or city. Forecasts include daily
weather and available in JSON, XML, or HTML format.
api.openweathermap.org/data/2.5/forecast/daily?q={city name},{country
code}={cnt}
api.openweathermap.org/data/2.5/forecast/daily?id={city ID}={cnt}
api.openweathermap.org/data/2.5/forecast/daily?lat={lat}={lon}={cnt}
HISTORY
http://api.openweathermap.org/data/2.5/history/city?id={id}=hour={start}={end}
http://api.openweathermap.org/data/2.5/history/city?id={id}=hour={start}={cnt}
start start date (unix time, UTC time zone), e.g. start=1369728000
end end date (unix time, UTC time zone), e.g. end=1369789200
cnt amount of returned data (one per hour, can be used instead of 'end')
[jira] [Created] (CAMEL-9274) StreamCache does not work correctly with MarshalProcessor and pretty much all DataFormats
Aaron Whiteside created CAMEL-9274: -- Summary: StreamCache does not work correctly with MarshalProcessor and pretty much all DataFormats Key: CAMEL-9274 URL: https://issues.apache.org/jira/browse/CAMEL-9274 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.16.0 Reporter: Aaron Whiteside Priority: Critical StreamCache does not work correctly with MarshalProcessor and pretty much all DataFormats # Documentation states that stream caching can be turned on, on a per route basis. The places were we actually try and utilize stream caching only checks if the global option is turned on (MarshalProcessor + PGPKeyAccessDataFormat, I can't find any other meaningful attempts to use stream caching anywhere else) not the per route setting. # Secondly, if we ignore the first problem, only one data formatter tries to use stream caching for unmarshaling: PGPKeyAccessDataFormat. If you try and unzip a large zip file it's contents will be decompressed into memory. The same goes for any other large data formatter conversion (unmarshaling, only). Attached is a patch that corrects the first problem and part of the second problem (ZipFileDataFormat, ZipDataFormat and PGPKeyAccessDataFormat). A separate issue should probably be opened to fix all the remaining DataFormat implementation to support Stream Caching. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9274) StreamCache does not work correctly with MarshalProcessor and pretty much all DataFormats
[ https://issues.apache.org/jira/browse/CAMEL-9274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Whiteside updated CAMEL-9274: --- Attachment: CAMEL_9274.patch > StreamCache does not work correctly with MarshalProcessor and pretty much all > DataFormats > - > > Key: CAMEL-9274 > URL: https://issues.apache.org/jira/browse/CAMEL-9274 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.16.0 >Reporter: Aaron Whiteside >Priority: Critical > Attachments: CAMEL_9274.patch > > > StreamCache does not work correctly with MarshalProcessor and pretty much all > DataFormats > # Documentation states that stream caching can be turned on, on a per route > basis. The places were we actually try and utilize stream caching only checks > if the global option is turned on (MarshalProcessor + PGPKeyAccessDataFormat, > I can't find any other meaningful attempts to use stream caching anywhere > else) not the per route setting. > # Secondly, if we ignore the first problem, only one data formatter tries to > use stream caching for unmarshaling: PGPKeyAccessDataFormat. If you try and > unzip a large zip file it's contents will be decompressed into memory. The > same goes for any other large data formatter conversion (unmarshaling, only). > Attached is a patch that corrects the first problem and part of the second > problem (ZipFileDataFormat, ZipDataFormat and PGPKeyAccessDataFormat). > A separate issue should probably be opened to fix all the remaining > DataFormat implementation to support Stream Caching. > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9272) openweathermap.org requires an APPID id since 09/10/2015
[
https://issues.apache.org/jira/browse/CAMEL-9272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14980784#comment-14980784
]
Charles Moulliard commented on CAMEL-9272:
--
Can somebody backport the modification to 2.15.x & 2.16.x branches please ?
> openweathermap.org requires an APPID id since 09/10/2015
>
>
> Key: CAMEL-9272
> URL: https://issues.apache.org/jira/browse/CAMEL-9272
> Project: Camel
> Issue Type: Bug
> Components: weather
>Reporter: Charles Moulliard
> Fix For: 2.16.1, 2.15.5, 2.17
>
>
> Code must be updated as openweathermap.org requires an APPID id since
> 09/10/2015 & by consequence, the component can't be used anymore as we will
> get a HTTP 401 error.
> {code}
> Caused by: org.apache.camel.TypeConversionException: Error during type
> conversion from type: java.net.URL to the required type: java.lang.String
> with value http://api.openweathermap.org/data/2.5/weather?q=Paris,France due
> java.io.IOException: Server returned HTTP response code: 401 for URL:
> http://api.openweathermap.org/data/2.5/weather?q=Paris,France
> at
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.createTypeConversionException(BaseTypeConverterRegistry.java:610)
> at
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.mandatoryConvertTo(BaseTypeConverterRegistry.java:177)
> at
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.mandatoryConvertTo(BaseTypeConverterRegistry.java:156)
> at
> org.apache.camel.component.weather.WeatherProducer.process(WeatherProducer.java:48)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-9262) stopOnSuccess in Multicast, RecipientList
[ https://issues.apache.org/jira/browse/CAMEL-9262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-9262. Resolution: Won't Fix Assignee: Claus Ibsen > stopOnSuccess in Multicast, RecipientList > - > > Key: CAMEL-9262 > URL: https://issues.apache.org/jira/browse/CAMEL-9262 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Jyrki Ruuskanen >Assignee: Claus Ibsen >Priority: Minor > > Let's say we have an endpoint where we should send a message and if sending > fails there are a number of fallback endpoints we should try stopping after > the first successful sending (=no exception thrown during sending). > This sounds like a case for doTry..doCatch, but then we can't use > defaultErrorHander and friends. > I think it would look quite right if we could say .stopOnSuccess() or > .shortCircuit() on multicast and have it stop after the first successful send. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9262) stopOnSuccess in Multicast, RecipientList
[ https://issues.apache.org/jira/browse/CAMEL-9262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14979954#comment-14979954 ] Claus Ibsen commented on CAMEL-9262: Yeah you are very welcome to help improve the docs > stopOnSuccess in Multicast, RecipientList > - > > Key: CAMEL-9262 > URL: https://issues.apache.org/jira/browse/CAMEL-9262 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Jyrki Ruuskanen >Priority: Minor > > Let's say we have an endpoint where we should send a message and if sending > fails there are a number of fallback endpoints we should try stopping after > the first successful sending (=no exception thrown during sending). > This sounds like a case for doTry..doCatch, but then we can't use > defaultErrorHander and friends. > I think it would look quite right if we could say .stopOnSuccess() or > .shortCircuit() on multicast and have it stop after the first successful send. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9268) camel-okhttp - Using the popular okhttp client
Claus Ibsen created CAMEL-9268: -- Summary: camel-okhttp - Using the popular okhttp client Key: CAMEL-9268 URL: https://issues.apache.org/jira/browse/CAMEL-9268 Project: Camel Issue Type: New Feature Reporter: Claus Ibsen Fix For: Future A camel-okhttp component that uses the okhttp client http://square.github.io/okhttp/ http://square.github.io/okhttp/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9267) camel-nats - A java client component for the nats broker
Claus Ibsen created CAMEL-9267: -- Summary: camel-nats - A java client component for the nats broker Key: CAMEL-9267 URL: https://issues.apache.org/jira/browse/CAMEL-9267 Project: Camel Issue Type: New Feature Reporter: Claus Ibsen Fix For: Future It would be good with a camel-nats component that uses the java client to be able to send / consume from nats The client is here: https://github.com/tyagihas/java_nats And more about nats http://nats.io/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-9266) MockEnpoind :: expectedBodiesReceived does not seem to work
[
https://issues.apache.org/jira/browse/CAMEL-9266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-9266.
Resolution: Invalid
Assignee: Claus Ibsen
Please use the mailing list / user forum to get help with this first.
> MockEnpoind :: expectedBodiesReceived does not seem to work
> ---
>
> Key: CAMEL-9266
> URL: https://issues.apache.org/jira/browse/CAMEL-9266
> Project: Camel
> Issue Type: Bug
> Components: camel-test
>Affects Versions: 2.14.3
> Environment: Unit testing with Junit 4.12 and Spring 3.2.11.RELEASE
>Reporter: Frederic Gendebien
>Assignee: Claus Ibsen
>Priority: Minor
> Labels: test
>
> GIVEN: a mock endpoint : mock
> WHEN: I do this
> mock.expectedMessageCount(1);
> mock.expectedBodiesReceived("expected output");
> mock.assertIsSatisfied();
> THEN: I get "expected but was "
> BUT: when I do this:
> mock.expectedMessageCount(1);
> mock.expectedMessagesMatches(body().isEqualTo("expected output"));
> mock.assertIsSatisfied();
> THEN: it works...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-9269) NotifyBuilder.fromRoute() does not work for some endpoint types
Gert Vanthienen created CAMEL-9269:
--
Summary: NotifyBuilder.fromRoute() does not work for some endpoint
types
Key: CAMEL-9269
URL: https://issues.apache.org/jira/browse/CAMEL-9269
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.16.0
Reporter: Gert Vanthienen
Assignee: Gert Vanthienen
Fix For: 2.17.0, 2.16.1
{{NotifyBuilder.fromRoute()}} does not work if the endpoint uri in the
{{from()}} clause for a route does not match the actual endpoint uri the
exchange was sent to. Because we also have the route id itself available in the
exchange, we can use that as a fallback when the match on from endpoint uri
doesn't work.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-9270) rest-dsl - CORS support doesn't work with Restlet 2.3
Anton Koscejev created CAMEL-9270: - Summary: rest-dsl - CORS support doesn't work with Restlet 2.3 Key: CAMEL-9270 URL: https://issues.apache.org/jira/browse/CAMEL-9270 Project: Camel Issue Type: Bug Components: camel-core, camel-restlet Affects Versions: 2.16.0 Reporter: Anton Koscejev camel-restlet has upgraded to Restlet 2.3 (nice!), but this broke rest-dsl CORS support, because Restlet 2.3 no longer supports setting CORS headers via attributes. There are now API methods for these headers and attributes are ignored with a warning. Example of the new API method: http://restlet.com/technical-resources/restlet-framework/javadocs/2.3/jse/api/org/restlet/Response.html#setAccessControlAllowOrigin%28java.lang.String%29 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CAMEL-9270) rest-dsl - CORS support doesn't work with Restlet 2.3
[
https://issues.apache.org/jira/browse/CAMEL-9270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14980064#comment-14980064
]
Anton Koscejev edited comment on CAMEL-9270 at 10/29/15 8:58 AM:
-
Warnings in log:
{code}
2015-10-29 09:44:16,762 WARN [Restlet-1916677384] o.r.C.LogFilter
[Slf4jLogger.java:283] Addition of the standard header
"Access-Control-Allow-Headers" is not allowed. Please use the equivalent
property in the Restlet API.
2015-10-29 09:44:16,762 WARN [Restlet-1916677384] o.r.C.LogFilter
[Slf4jLogger.java:283] Addition of the standard header
"Access-Control-Allow-Methods" is not allowed. Please use the equivalent
property in the Restlet API.
2015-10-29 09:44:16,762 WARN [Restlet-1916677384] o.r.C.LogFilter
[Slf4jLogger.java:283] Addition of the standard header
"Access-Control-Allow-Origin" is not allowed. Please use the equivalent
property in the Restlet API.
{code}
Workaround using custom RestletBinding:
{code}
import com.google.common.base.Splitter;
import org.restlet.data.Header;
import org.restlet.data.Method;
import org.restlet.util.Series;
import static com.google.common.collect.Sets.newHashSet;
import static org.restlet.engine.header.HeaderConstants.ATTRIBUTE_HEADERS;
...
public class CustomRestletBinding extends DefaultRestletBinding {
private static final Splitter headerValueSplitter =
Splitter.on(',').trimResults().omitEmptyStrings();
@Override
public void populateRestletResponseFromExchange(Exchange exchange,
Response response) throws Exception {
super.populateRestletResponseFromExchange(exchange, response);
convertHeadersSupportedByRestletAPI(response);
}
/**
* Some headers are now supported by Restlet API and Restlet ignores
them, if not set via API.
* This method sets them to Restlet Response via API and then removes
these headers.
*/
private void convertHeadersSupportedByRestletAPI(Response response) {
Iterator iterator = response.getHeaders().iterator();
while (iterator.hasNext()) {
Header header = iterator.next();
if
("Access-Control-Allow-Origin".equals(header.getName())) {
response.setAccessControlAllowOrigin(header.getValue());
} else if
("Access-Control-Allow-Methods".equals(header.getName())) {
response.setAccessControlAllowMethods(asMethods(header.getValue()));
} else if
("Access-Control-Allow-Headers".equals(header.getName())) {
response.setAccessControlAllowHeaders(asHeaders(header.getValue()));
} else {
continue; // do not remove all other headers
}
iterator.remove();
}
}
@NotNull
private Set asMethods(@NotNull String value) {
return
StreamSupport.stream(headerValueSplitter.split(value).spliterator(), false)
.map(Method::valueOf)
.collect(toSet());
}
@NotNull
private HashSet asHeaders(@NotNull String value) {
return newHashSet(headerValueSplitter.split(value));
}
}
{code}
was (Author: koscejev):
Warnings in log:
{code}
2015-10-29 09:44:16,762 WARN [Restlet-1916677384] o.r.C.LogFilter
[Slf4jLogger.java:283] Addition of the standard header
"Access-Control-Allow-Headers" is not allowed. Please use the equivalent
property in the Restlet API.
2015-10-29 09:44:16,762 WARN [Restlet-1916677384] o.r.C.LogFilter
[Slf4jLogger.java:283] Addition of the standard header
"Access-Control-Allow-Methods" is not allowed. Please use the equivalent
property in the Restlet API.
2015-10-29 09:44:16,762 WARN [Restlet-1916677384] o.r.C.LogFilter
[Slf4jLogger.java:283] Addition of the standard header
"Access-Control-Allow-Origin" is not allowed. Please use the equivalent
property in the Restlet API.
{code}
Workaround using custom RestletBinding:
{code}
import com.google.common.base.Splitter;
import org.restlet.data.Header;
import org.restlet.data.Method;
import org.restlet.util.Series;
import static com.google.common.collect.Sets.newHashSet;
import static org.restlet.engine.header.HeaderConstants.ATTRIBUTE_HEADERS;
...
public class CustomRestletBinding extends DefaultRestletBinding {
private static final Splitter headerValueSplitter =
Splitter.on(',').trimResults().omitEmptyStrings();
@Override
public void populateRestletResponseFromExchange(Exchange exchange,
Response response) throws Exception {
super.populateRestletResponseFromExchange(exchange, response);
convertHeadersSupportedByRestletAPI(response);
[jira] [Comment Edited] (CAMEL-9270) rest-dsl - CORS support doesn't work with Restlet 2.3
[
https://issues.apache.org/jira/browse/CAMEL-9270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14980064#comment-14980064
]
Anton Koscejev edited comment on CAMEL-9270 at 10/29/15 9:22 AM:
-
Warnings in log:
{code}
2015-10-29 09:44:16,762 WARN [Restlet-1916677384] o.r.C.LogFilter
[Slf4jLogger.java:283] Addition of the standard header
"Access-Control-Allow-Headers" is not allowed. Please use the equivalent
property in the Restlet API.
2015-10-29 09:44:16,762 WARN [Restlet-1916677384] o.r.C.LogFilter
[Slf4jLogger.java:283] Addition of the standard header
"Access-Control-Allow-Methods" is not allowed. Please use the equivalent
property in the Restlet API.
2015-10-29 09:44:16,762 WARN [Restlet-1916677384] o.r.C.LogFilter
[Slf4jLogger.java:283] Addition of the standard header
"Access-Control-Allow-Origin" is not allowed. Please use the equivalent
property in the Restlet API.
{code}
Workaround using custom RestletBinding:
{code}
import com.google.common.base.Splitter;
import org.restlet.data.Header;
import org.restlet.data.Method;
import org.restlet.util.Series;
import static com.google.common.collect.Sets.newHashSet;
import static org.restlet.engine.header.HeaderConstants.ATTRIBUTE_HEADERS;
...
public class CustomRestletBinding extends DefaultRestletBinding {
private static final Splitter headerValueSplitter =
Splitter.on(',').trimResults().omitEmptyStrings();
@Override
public void populateRestletResponseFromExchange(Exchange exchange,
Response response) throws Exception {
super.populateRestletResponseFromExchange(exchange, response);
convertHeadersSupportedByRestletAPI(response);
}
/**
* Some headers are now supported by Restlet API and Restlet ignores
them, if not set via API.
* This method sets them to Restlet Response via API and then removes
these headers.
*/
private void convertHeadersSupportedByRestletAPI(Response response) {
Iterator iterator = response.getHeaders().iterator();
while (iterator.hasNext()) {
Header header = iterator.next();
if
("Access-Control-Allow-Origin".equals(header.getName())) {
response.setAccessControlAllowOrigin(header.getValue());
} else if
("Access-Control-Allow-Methods".equals(header.getName())) {
response.setAccessControlAllowMethods(asMethods(header.getValue()));
} else if
("Access-Control-Allow-Headers".equals(header.getName())) {
response.setAccessControlAllowHeaders(asHeaders(header.getValue()));
} else {
continue; // do not remove all other headers
}
iterator.remove();
}
}
@NotNull
private Set asMethods(@NotNull String value) {
return
StreamSupport.stream(headerValueSplitter.split(value).spliterator(), false)
.map(Method::valueOf)
.collect(toSet());
}
@NotNull
private HashSet asHeaders(@NotNull String value) {
return newHashSet(headerValueSplitter.split(value));
}
}
{code}
was (Author: koscejev):
Warnings in log:
{code}
2015-10-29 09:44:16,762 WARN [Restlet-1916677384] o.r.C.LogFilter
[Slf4jLogger.java:283] Addition of the standard header
"Access-Control-Allow-Headers" is not allowed. Please use the equivalent
property in the Restlet API.
2015-10-29 09:44:16,762 WARN [Restlet-1916677384] o.r.C.LogFilter
[Slf4jLogger.java:283] Addition of the standard header
"Access-Control-Allow-Methods" is not allowed. Please use the equivalent
property in the Restlet API.
2015-10-29 09:44:16,762 WARN [Restlet-1916677384] o.r.C.LogFilter
[Slf4jLogger.java:283] Addition of the standard header
"Access-Control-Allow-Origin" is not allowed. Please use the equivalent
property in the Restlet API.
{code}
Although there's a workaround using custom RestletBinding, perhaps a better
solution would be to somehow make use of
org.restlet.engine.application.CorsFilter. Workaround:
{code}
import com.google.common.base.Splitter;
import org.restlet.data.Header;
import org.restlet.data.Method;
import org.restlet.util.Series;
import static com.google.common.collect.Sets.newHashSet;
import static org.restlet.engine.header.HeaderConstants.ATTRIBUTE_HEADERS;
...
public class CustomRestletBinding extends DefaultRestletBinding {
private static final Splitter headerValueSplitter =
Splitter.on(',').trimResults().omitEmptyStrings();
@Override
public void populateRestletResponseFromExchange(Exchange exchange,
Response response) throws Exception {
[jira] [Commented] (CAMEL-9270) rest-dsl - CORS support doesn't work with Restlet 2.3
[ https://issues.apache.org/jira/browse/CAMEL-9270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14980106#comment-14980106 ] Anton Koscejev commented on CAMEL-9270: --- Proper solution should probably involve org.restlet.service.CorsService or org.restlet.engine.application.CorsFilter. Some non-camel example: http://stackoverflow.com/questions/28988671/how-to-use-cors-in-restlet-2-3-1 > rest-dsl - CORS support doesn't work with Restlet 2.3 > - > > Key: CAMEL-9270 > URL: https://issues.apache.org/jira/browse/CAMEL-9270 > Project: Camel > Issue Type: Bug > Components: camel-core, camel-restlet >Affects Versions: 2.16.0 >Reporter: Anton Koscejev > > camel-restlet has upgraded to Restlet 2.3 (nice!), but this broke rest-dsl > CORS support, because Restlet 2.3 no longer supports setting CORS headers via > attributes. There are now API methods for these headers and attributes are > ignored with a warning. > Example of the new API method: > http://restlet.com/technical-resources/restlet-framework/javadocs/2.3/jse/api/org/restlet/Response.html#setAccessControlAllowOrigin%28java.lang.String%29 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9270) rest-dsl - CORS support doesn't work with Restlet 2.3
[
https://issues.apache.org/jira/browse/CAMEL-9270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14980064#comment-14980064
]
Anton Koscejev commented on CAMEL-9270:
---
Warnings in log:
{code}
2015-10-29 09:44:16,762 WARN [Restlet-1916677384] o.r.C.LogFilter
[Slf4jLogger.java:283] Addition of the standard header
"Access-Control-Allow-Headers" is not allowed. Please use the equivalent
property in the Restlet API.
2015-10-29 09:44:16,762 WARN [Restlet-1916677384] o.r.C.LogFilter
[Slf4jLogger.java:283] Addition of the standard header
"Access-Control-Allow-Methods" is not allowed. Please use the equivalent
property in the Restlet API.
2015-10-29 09:44:16,762 WARN [Restlet-1916677384] o.r.C.LogFilter
[Slf4jLogger.java:283] Addition of the standard header
"Access-Control-Allow-Origin" is not allowed. Please use the equivalent
property in the Restlet API.
{code}
Workaround using custom RestletBinding:
{code}
import com.google.common.base.Splitter;
import org.restlet.data.Header;
import org.restlet.data.Method;
import org.restlet.util.Series;
import static com.google.common.collect.Sets.newHashSet;
import static org.restlet.engine.header.HeaderConstants.ATTRIBUTE_HEADERS;
...
public class CustomRestletBinding extends DefaultRestletBinding {
private static final Splitter headerValueSplitter =
Splitter.on(',').trimResults().omitEmptyStrings();
@Override
public void populateRestletResponseFromExchange(Exchange exchange,
Response response) throws Exception {
super.populateRestletResponseFromExchange(exchange, response);
convertHeadersSupportedByRestletAPI(response);
}
/**
* Some headers are now supported by Restlet API and Restlet ignores
them, if not set via API.
* This method sets them to Restlet Response via API and then removes
these headers.
*/
private void convertHeadersSupportedByRestletAPI(Response response) {
Series headers = getHeaders(response);
Iterator iterator = headers.iterator();
while (iterator.hasNext()) {
Header header = iterator.next();
if
("Access-Control-Allow-Origin".equals(header.getName())) {
response.setAccessControlAllowOrigin(header.getValue());
} else if
("Access-Control-Allow-Methods".equals(header.getName())) {
response.setAccessControlAllowMethods(asMethods(header.getValue()));
} else if
("Access-Control-Allow-Headers".equals(header.getName())) {
response.setAccessControlAllowHeaders(asHeaders(header.getValue()));
} else {
continue; // do not remove all other headers
}
iterator.remove();
}
}
@NotNull
private Set asMethods(@NotNull String value) {
return
StreamSupport.stream(headerValueSplitter.split(value).spliterator(), false)
.map(Method::valueOf)
.collect(toSet());
}
@NotNull
private HashSet asHeaders(@NotNull String value) {
return newHashSet(headerValueSplitter.split(value));
}
@SuppressWarnings("unchecked")
protected Series getHeaders(org.restlet.Message restletMessage)
{
return (Series) restletMessage.getAttributes()
.computeIfAbsent(ATTRIBUTE_HEADERS, k -> new
Series<>(Header.class));
}
}
{code}
> rest-dsl - CORS support doesn't work with Restlet 2.3
> -
>
> Key: CAMEL-9270
> URL: https://issues.apache.org/jira/browse/CAMEL-9270
> Project: Camel
> Issue Type: Bug
> Components: camel-core, camel-restlet
>Affects Versions: 2.16.0
>Reporter: Anton Koscejev
>
> camel-restlet has upgraded to Restlet 2.3 (nice!), but this broke rest-dsl
> CORS support, because Restlet 2.3 no longer supports setting CORS headers via
> attributes. There are now API methods for these headers and attributes are
> ignored with a warning.
> Example of the new API method:
> http://restlet.com/technical-resources/restlet-framework/javadocs/2.3/jse/api/org/restlet/Response.html#setAccessControlAllowOrigin%28java.lang.String%29
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CAMEL-9270) rest-dsl - CORS support doesn't work with Restlet 2.3
[
https://issues.apache.org/jira/browse/CAMEL-9270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14980064#comment-14980064
]
Anton Koscejev edited comment on CAMEL-9270 at 10/29/15 9:09 AM:
-
Warnings in log:
{code}
2015-10-29 09:44:16,762 WARN [Restlet-1916677384] o.r.C.LogFilter
[Slf4jLogger.java:283] Addition of the standard header
"Access-Control-Allow-Headers" is not allowed. Please use the equivalent
property in the Restlet API.
2015-10-29 09:44:16,762 WARN [Restlet-1916677384] o.r.C.LogFilter
[Slf4jLogger.java:283] Addition of the standard header
"Access-Control-Allow-Methods" is not allowed. Please use the equivalent
property in the Restlet API.
2015-10-29 09:44:16,762 WARN [Restlet-1916677384] o.r.C.LogFilter
[Slf4jLogger.java:283] Addition of the standard header
"Access-Control-Allow-Origin" is not allowed. Please use the equivalent
property in the Restlet API.
{code}
Although there's a workaround using custom RestletBinding, perhaps a better
solution would be to somehow make use of
org.restlet.engine.application.CorsFilter. Workaround:
{code}
import com.google.common.base.Splitter;
import org.restlet.data.Header;
import org.restlet.data.Method;
import org.restlet.util.Series;
import static com.google.common.collect.Sets.newHashSet;
import static org.restlet.engine.header.HeaderConstants.ATTRIBUTE_HEADERS;
...
public class CustomRestletBinding extends DefaultRestletBinding {
private static final Splitter headerValueSplitter =
Splitter.on(',').trimResults().omitEmptyStrings();
@Override
public void populateRestletResponseFromExchange(Exchange exchange,
Response response) throws Exception {
super.populateRestletResponseFromExchange(exchange, response);
convertHeadersSupportedByRestletAPI(response);
}
/**
* Some headers are now supported by Restlet API and Restlet ignores
them, if not set via API.
* This method sets them to Restlet Response via API and then removes
these headers.
*/
private void convertHeadersSupportedByRestletAPI(Response response) {
Iterator iterator = response.getHeaders().iterator();
while (iterator.hasNext()) {
Header header = iterator.next();
if
("Access-Control-Allow-Origin".equals(header.getName())) {
response.setAccessControlAllowOrigin(header.getValue());
} else if
("Access-Control-Allow-Methods".equals(header.getName())) {
response.setAccessControlAllowMethods(asMethods(header.getValue()));
} else if
("Access-Control-Allow-Headers".equals(header.getName())) {
response.setAccessControlAllowHeaders(asHeaders(header.getValue()));
} else {
continue; // do not remove all other headers
}
iterator.remove();
}
}
@NotNull
private Set asMethods(@NotNull String value) {
return
StreamSupport.stream(headerValueSplitter.split(value).spliterator(), false)
.map(Method::valueOf)
.collect(toSet());
}
@NotNull
private HashSet asHeaders(@NotNull String value) {
return newHashSet(headerValueSplitter.split(value));
}
}
{code}
was (Author: koscejev):
Warnings in log:
{code}
2015-10-29 09:44:16,762 WARN [Restlet-1916677384] o.r.C.LogFilter
[Slf4jLogger.java:283] Addition of the standard header
"Access-Control-Allow-Headers" is not allowed. Please use the equivalent
property in the Restlet API.
2015-10-29 09:44:16,762 WARN [Restlet-1916677384] o.r.C.LogFilter
[Slf4jLogger.java:283] Addition of the standard header
"Access-Control-Allow-Methods" is not allowed. Please use the equivalent
property in the Restlet API.
2015-10-29 09:44:16,762 WARN [Restlet-1916677384] o.r.C.LogFilter
[Slf4jLogger.java:283] Addition of the standard header
"Access-Control-Allow-Origin" is not allowed. Please use the equivalent
property in the Restlet API.
{code}
Workaround using custom RestletBinding:
{code}
import com.google.common.base.Splitter;
import org.restlet.data.Header;
import org.restlet.data.Method;
import org.restlet.util.Series;
import static com.google.common.collect.Sets.newHashSet;
import static org.restlet.engine.header.HeaderConstants.ATTRIBUTE_HEADERS;
...
public class CustomRestletBinding extends DefaultRestletBinding {
private static final Splitter headerValueSplitter =
Splitter.on(',').trimResults().omitEmptyStrings();
@Override
public void populateRestletResponseFromExchange(Exchange exchange,
Response response) throws Exception {
