[jira] [Created] (CAMEL-20280) JCachePolicy does not init bypassExpression
Jens Kleine-Herzbruch created CAMEL-20280: - Summary: JCachePolicy does not init bypassExpression Key: CAMEL-20280 URL: https://issues.apache.org/jira/browse/CAMEL-20280 Project: Camel Issue Type: Bug Components: camel-jcache Affects Versions: 4.3.0 Reporter: Jens Kleine-Herzbruch JCachePolicy does not init bypassExpression -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-16922) StringHelper.removeLeadingAndEndingQuotes() may cause IndexOutOfBoundsException
Jens Kleine-Herzbruch created CAMEL-16922:
-
Summary: StringHelper.removeLeadingAndEndingQuotes() may cause
IndexOutOfBoundsException
Key: CAMEL-16922
URL: https://issues.apache.org/jira/browse/CAMEL-16922
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 3.11.1
Reporter: Jens Kleine-Herzbruch
The method doesn't check whether the string passed actually contains enough
characters, so calling it with the string {{'}}, for example, causes an
IndexOutOfBoundsException.
This happens, for example, when you pass arguments like this as parameters to a
Bean expression.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-16566) Nested enrich with shareUnitOfWork=true result in ConcurrentModificationException
[
https://issues.apache.org/jira/browse/CAMEL-16566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Kleine-Herzbruch updated CAMEL-16566:
--
Component/s: (was: came-core)
camel-core
> Nested enrich with shareUnitOfWork=true result in
> ConcurrentModificationException
> -
>
> Key: CAMEL-16566
> URL: https://issues.apache.org/jira/browse/CAMEL-16566
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.7.3
>Reporter: Jens Kleine-Herzbruch
>Priority: Major
>
> If you have routes that have nested enrichers that use shareUnitOfWork=true,
> you'll get a ConcurrentModificationException when the subroutes are joined
> back.
>
> {code:java}
> from("direct:routeA").
> enrichWith("direct:routeB", true, true).body((a, b) -> a);
> from("direct:routeB").
> enrichWith("direct:routeC", true, true).body((a, b) -> a);
> from("direct:routeC").setBody(constant("xxx")); {code}
>
> {code:java}
> org.apache.camel.CamelExchangeException: Error occurred during aggregation.
> Exchange[0A01B3DD98090F3-0001]. Caused by:
> [java.util.ConcurrentModificationException - null]
> at org.apache.camel.processor.Enricher$1.done(Enricher.java:247)
> ~[camel-core-processor-3.7.3.jar:3.7.3]
> at org.apache.camel.AsyncCallback.run(AsyncCallback.java:44)
> ~[camel-api-3.7.3.jar:3.7.3]
> ...
> Caused by: java.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:1042) ~[?:?]
> at java.util.ArrayList$Itr.remove(ArrayList.java:1010) ~[?:?]
> at
> org.apache.camel.impl.engine.DefaultUnitOfWork.handoverSynchronization(DefaultUnitOfWork.java:202)
> ~[camel-base-engine-3.7.3.jar:3.7.3]
> at
> org.apache.camel.impl.engine.DefaultUnitOfWork.handoverSynchronization(DefaultUnitOfWork.java:179)
> ~[camel-base-engine-3.7.3.jar:3.7.3]
> at
> org.apache.camel.support.DefaultExchange.handoverCompletions(DefaultExchange.java:612)
> ~[camel-support-3.7.3.jar:3.7.3]
> at org.apache.camel.processor.Enricher$1.done(Enricher.java:242)
> ~[camel-core-processor-3.7.3.jar:3.7.3]
> ... {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-16566) Nested enrich with shareUnitOfWork=true result in ConcurrentModificationException
Jens Kleine-Herzbruch created CAMEL-16566:
-
Summary: Nested enrich with shareUnitOfWork=true result in
ConcurrentModificationException
Key: CAMEL-16566
URL: https://issues.apache.org/jira/browse/CAMEL-16566
Project: Camel
Issue Type: Bug
Components: came-core
Affects Versions: 3.7.3
Reporter: Jens Kleine-Herzbruch
If you have routes that have nested enrichers that use shareUnitOfWork=true,
you'll get a ConcurrentModificationException when the subroutes are joined back.
{code:java}
from("direct:routeA").
enrichWith("direct:routeB", true, true).body((a, b) -> a);
from("direct:routeB").
enrichWith("direct:routeC", true, true).body((a, b) -> a);
from("direct:routeC").setBody(constant("xxx")); {code}
{code:java}
org.apache.camel.CamelExchangeException: Error occurred during aggregation.
Exchange[0A01B3DD98090F3-0001]. Caused by:
[java.util.ConcurrentModificationException - null]
at org.apache.camel.processor.Enricher$1.done(Enricher.java:247)
~[camel-core-processor-3.7.3.jar:3.7.3]
at org.apache.camel.AsyncCallback.run(AsyncCallback.java:44)
~[camel-api-3.7.3.jar:3.7.3]
...
Caused by: java.util.ConcurrentModificationException
at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:1042) ~[?:?]
at java.util.ArrayList$Itr.remove(ArrayList.java:1010) ~[?:?]
at
org.apache.camel.impl.engine.DefaultUnitOfWork.handoverSynchronization(DefaultUnitOfWork.java:202)
~[camel-base-engine-3.7.3.jar:3.7.3]
at
org.apache.camel.impl.engine.DefaultUnitOfWork.handoverSynchronization(DefaultUnitOfWork.java:179)
~[camel-base-engine-3.7.3.jar:3.7.3]
at
org.apache.camel.support.DefaultExchange.handoverCompletions(DefaultExchange.java:612)
~[camel-support-3.7.3.jar:3.7.3]
at org.apache.camel.processor.Enricher$1.done(Enricher.java:242)
~[camel-core-processor-3.7.3.jar:3.7.3]
... {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-16110) camel-cxfrs - CxfRsProducer leaks Header when Exchange.HTTP_QUERY is set
[
https://issues.apache.org/jira/browse/CAMEL-16110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Kleine-Herzbruch updated CAMEL-16110:
--
Description:
If you send a message to a CxfRsProducer that has the header
Exchange.HTTP_QUERY set, the HTTP message sent will contain the header
{code:java}
org.apache.cxf.message.Message.QUERY_STRING=q=1{code}
for example.
This header should not be present in the message since it is internal to the
endpoint.
was:
If you send a message to a CxfRsProducer that has the header
Exchange.HTTP_METHOD set, the HTTP message sent will contain the header
{code:java}
org.apache.cxf.message.Message.QUERY_STRING=q=1{code}
for example.
This header should not be present in the message since it is internal to the
endpoint.
> camel-cxfrs - CxfRsProducer leaks Header when Exchange.HTTP_QUERY is set
>
>
> Key: CAMEL-16110
> URL: https://issues.apache.org/jira/browse/CAMEL-16110
> Project: Camel
> Issue Type: Bug
> Components: camel-cxfrs
>Affects Versions: 3.7.1
>Reporter: Jens Kleine-Herzbruch
>Assignee: Claus Ibsen
>Priority: Minor
>
> If you send a message to a CxfRsProducer that has the header
> Exchange.HTTP_QUERY set, the HTTP message sent will contain the header
> {code:java}
> org.apache.cxf.message.Message.QUERY_STRING=q=1{code}
> for example.
> This header should not be present in the message since it is internal to the
> endpoint.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-16110) camel-cxfrs - CxfRsProducer leaks Header when Exchange.HTTP_QUERY is set
[
https://issues.apache.org/jira/browse/CAMEL-16110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Kleine-Herzbruch updated CAMEL-16110:
--
Description:
If you send a message to a CxfRsProducer that has the header
Exchange.HTTP_METHOD set, the HTTP message sent will contain the header
{code:java}
org.apache.cxf.message.Message.QUERY_STRING=q=1{code}
for example.
This header should not be present in the message since it is internal to the
endpoint.
was:
If you send a message to a CxfRsProducer that has the header
Exchange.HTTP_METHOD set, the HTTP message sent will contain the header
{code}org.apache.cxf.request.method=GET{code}
for example.
This header should not be present in the message since it is internal to the
endpoint.
> camel-cxfrs - CxfRsProducer leaks Header when Exchange.HTTP_QUERY is set
>
>
> Key: CAMEL-16110
> URL: https://issues.apache.org/jira/browse/CAMEL-16110
> Project: Camel
> Issue Type: Bug
> Components: camel-cxfrs
>Affects Versions: 3.7.1
>Reporter: Jens Kleine-Herzbruch
>Assignee: Claus Ibsen
>Priority: Minor
>
> If you send a message to a CxfRsProducer that has the header
> Exchange.HTTP_METHOD set, the HTTP message sent will contain the header
> {code:java}
> org.apache.cxf.message.Message.QUERY_STRING=q=1{code}
> for example.
> This header should not be present in the message since it is internal to the
> endpoint.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-16110) camel-cxfrs - CxfRsProducer leaks Header when Exchange.HTTP_QUERY is set
[
https://issues.apache.org/jira/browse/CAMEL-16110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Kleine-Herzbruch updated CAMEL-16110:
--
Fix Version/s: (was: 3.7.1)
(was: 3.8.0)
> camel-cxfrs - CxfRsProducer leaks Header when Exchange.HTTP_QUERY is set
>
>
> Key: CAMEL-16110
> URL: https://issues.apache.org/jira/browse/CAMEL-16110
> Project: Camel
> Issue Type: Bug
> Components: camel-cxfrs
>Affects Versions: 3.7.1
>Reporter: Jens Kleine-Herzbruch
>Assignee: Claus Ibsen
>Priority: Minor
>
> If you send a message to a CxfRsProducer that has the header
> Exchange.HTTP_METHOD set, the HTTP message sent will contain the header
> {code}org.apache.cxf.request.method=GET{code}
> for example.
> This header should not be present in the message since it is internal to the
> endpoint.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-16110) camel-cxfrs - CxfRsProducer leaks Header when Exchange.HTTP_QUERY is set
[
https://issues.apache.org/jira/browse/CAMEL-16110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Kleine-Herzbruch updated CAMEL-16110:
--
Affects Version/s: (was: 3.4.0)
3.7.1
> camel-cxfrs - CxfRsProducer leaks Header when Exchange.HTTP_QUERY is set
>
>
> Key: CAMEL-16110
> URL: https://issues.apache.org/jira/browse/CAMEL-16110
> Project: Camel
> Issue Type: Bug
> Components: camel-cxfrs
>Affects Versions: 3.7.1
>Reporter: Jens Kleine-Herzbruch
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.7.1, 3.8.0
>
>
> If you send a message to a CxfRsProducer that has the header
> Exchange.HTTP_METHOD set, the HTTP message sent will contain the header
> {code}org.apache.cxf.request.method=GET{code}
> for example.
> This header should not be present in the message since it is internal to the
> endpoint.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-16110) camel-cxfrs - CxfRsProducer leaks Header when Exchange.HTTP_QUERY is set
Jens Kleine-Herzbruch created CAMEL-16110:
-
Summary: camel-cxfrs - CxfRsProducer leaks Header when
Exchange.HTTP_QUERY is set
Key: CAMEL-16110
URL: https://issues.apache.org/jira/browse/CAMEL-16110
Project: Camel
Issue Type: Bug
Components: camel-cxfrs
Affects Versions: 3.4.0
Reporter: Jens Kleine-Herzbruch
Assignee: Claus Ibsen
Fix For: 3.7.1, 3.8.0
If you send a message to a CxfRsProducer that has the header
Exchange.HTTP_METHOD set, the HTTP message sent will contain the header
{code}org.apache.cxf.request.method=GET{code}
for example.
This header should not be present in the message since it is internal to the
endpoint.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-15809) PredicateBuilder doesn't init predicates properly
Jens Kleine-Herzbruch created CAMEL-15809: - Summary: PredicateBuilder doesn't init predicates properly Key: CAMEL-15809 URL: https://issues.apache.org/jira/browse/CAMEL-15809 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 3.6.0 Reporter: Jens Kleine-Herzbruch The compound predicates created by PredicateBuilder should initialize their contained predicates/expressions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-15808) camel-mock: MockEndpoint doesn't init predicates
Jens Kleine-Herzbruch created CAMEL-15808:
-
Summary: camel-mock: MockEndpoint doesn't init predicates
Key: CAMEL-15808
URL: https://issues.apache.org/jira/browse/CAMEL-15808
Project: Camel
Issue Type: Bug
Components: camel-test
Affects Versions: 3.6.0
Reporter: Jens Kleine-Herzbruch
For Predicates added via
{code:java}
mock.expectedMessagesMatches(Perdicates... predicates) {code}
you can end up with NPE because those predicates never get initialized:
{code:java}
2020-11-04 15:11:14,244 [main] ERROR
org.apache.camel.component.mock.MockEndpoint - Caught exception on
mock://myMock due to: null
java.lang.NullPointerException: null
at
org.apache.camel.support.builder.ExpressionBuilder$55.evaluate(ExpressionBuilder.java:1587)
~[camel-support-3.6.0.jar:3.6.0]
at
org.apache.camel.support.ExpressionAdapter.evaluate(ExpressionAdapter.java:35)
~[camel-support-3.6.0.jar:3.6.0]
at
org.apache.camel.support.builder.BinaryPredicateSupport.matchesReturningFailureMessage(BinaryPredicateSupport.java:67)
~[camel-support-3.6.0.jar:3.6.0]
at
org.apache.camel.support.builder.BinaryPredicateSupport.matches(BinaryPredicateSupport.java:56)
~[camel-support-3.6.0.jar:3.6.0]
at
org.apache.camel.support.builder.PredicateBuilder$2.matches(PredicateBuilder.java:69)
~[camel-support-3.6.0.jar:3.6.0]
at
org.apache.camel.support.PredicateAssertHelper.doAssertMatches(PredicateAssertHelper.java:50)
~[camel-support-3.6.0.jar:3.6.0]
at
org.apache.camel.support.PredicateAssertHelper.assertMatches(PredicateAssertHelper.java:45)
~[camel-support-3.6.0.jar:3.6.0]
at
org.apache.camel.component.mock.AssertionClause.applyAssertionOn(AssertionClause.java:114)
~[camel-mock-3.6.0.jar:3.6.0]
at
org.apache.camel.component.mock.MockEndpoint$9.assertOnIndex(MockEndpoint.java:813)
~[camel-mock-3.6.0.jar:3.6.0]
at
org.apache.camel.component.mock.MockEndpoint.onExchange(MockEndpoint.java:1566)
~[camel-mock-3.6.0.jar:3.6.0]
at
org.apache.camel.component.mock.MockEndpoint$1.process(MockEndpoint.java:303)
~[camel-mock-3.6.0.jar:3.6.0] {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-15794) CxfRsEndpoint recreates SSL context for each message
[
https://issues.apache.org/jira/browse/CAMEL-15794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Kleine-Herzbruch updated CAMEL-15794:
--
Description:
CxfRsEndpoint contains this code in `_invoke*Client_`:
{code} WebClient client = cfb.createWebClient();
((CxfRsEndpoint)
getEndpoint()).getChainedCxfRsEndpointConfigurer().configureClient(client);{code}
This means, a new client is created on every request (ok, because possibly not
thread-safe) and then configured. The configuration step includes an
`_AbstractSslEndpointConfigurer_` which also recreates the _SSLSocketFactory_
on every call, and *that* includes re-opening and re-reading configured key and
trust stores.
Doing this on every request obviously degrades performance significantly.
was:
CxfRsEndpoint contains this code in `_invoke*Client_`:
{{ WebClient client = cfb.createWebClient();}}
{{ ((CxfRsEndpoint)
getEndpoint()).getChainedCxfRsEndpointConfigurer().configureClient(client);}}
This means, a new client is created on every request (ok, because possibly not
thread-safe) and then configured. The configuration step includes an
`_AbstractSslEndpointConfigurer_` which also recreates the _SSLSocketFactory_
on every call, and *that* includes re-opening and re-reading configured key and
trust stores.
Doing this on every request obviously degrades performance significantly.
> CxfRsEndpoint recreates SSL context for each message
>
>
> Key: CAMEL-15794
> URL: https://issues.apache.org/jira/browse/CAMEL-15794
> Project: Camel
> Issue Type: Bug
> Components: camel-cxfrs
>Affects Versions: 3.6.0
>Reporter: Jens Kleine-Herzbruch
>Priority: Major
> Labels: performance
>
> CxfRsEndpoint contains this code in `_invoke*Client_`:
> {code} WebClient client = cfb.createWebClient();
> ((CxfRsEndpoint)
> getEndpoint()).getChainedCxfRsEndpointConfigurer().configureClient(client);{code}
> This means, a new client is created on every request (ok, because possibly
> not thread-safe) and then configured. The configuration step includes an
> `_AbstractSslEndpointConfigurer_` which also recreates the _SSLSocketFactory_
> on every call, and *that* includes re-opening and re-reading configured key
> and trust stores.
> Doing this on every request obviously degrades performance significantly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-15794) CxfRsEndpoint recreates SSL context for each message
Jens Kleine-Herzbruch created CAMEL-15794:
-
Summary: CxfRsEndpoint recreates SSL context for each message
Key: CAMEL-15794
URL: https://issues.apache.org/jira/browse/CAMEL-15794
Project: Camel
Issue Type: Bug
Components: camel-cxfrs
Affects Versions: 3.6.0
Reporter: Jens Kleine-Herzbruch
CxfRsEndpoint contains this code in `_invoke*Client_`:
{{ WebClient client = cfb.createWebClient();}}
{{ ((CxfRsEndpoint)
getEndpoint()).getChainedCxfRsEndpointConfigurer().configureClient(client);}}
This means, a new client is created on every request (ok, because possibly not
thread-safe) and then configured. The configuration step includes an
`_AbstractSslEndpointConfigurer_` which also recreates the _SSLSocketFactory_
on every call, and *that* includes re-opening and re-reading configured key and
trust stores.
Doing this on every request obviously degrades performance significantly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-15290) camel-cxf - CxfRsProducer leaks Header when Exchange.HTTP_METHOD is set
[
https://issues.apache.org/jira/browse/CAMEL-15290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Kleine-Herzbruch updated CAMEL-15290:
--
Component/s: (was: came-cxf)
camel-cxfrs
> camel-cxf - CxfRsProducer leaks Header when Exchange.HTTP_METHOD is set
> ---
>
> Key: CAMEL-15290
> URL: https://issues.apache.org/jira/browse/CAMEL-15290
> Project: Camel
> Issue Type: Bug
> Components: camel-cxfrs
>Affects Versions: 3.4.0
>Reporter: Jens Kleine-Herzbruch
>Priority: Minor
>
> If you send a message to a CxfRsProducer that has the header
> Exchange.HTTP_METHOD set, the HTTP message sent will contain the header
> {code}org.apache.cxf.request.method=GET{code}
> for example.
> This header should not be present in the message since it is internal to the
> endpoint.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-15290) camel-cxfrs - CxfRsProducer leaks Header when Exchange.HTTP_METHOD is set
[
https://issues.apache.org/jira/browse/CAMEL-15290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Kleine-Herzbruch updated CAMEL-15290:
--
Summary: camel-cxfrs - CxfRsProducer leaks Header when Exchange.HTTP_METHOD
is set (was: camel-cxf - CxfRsProducer leaks Header when Exchange.HTTP_METHOD
is set)
> camel-cxfrs - CxfRsProducer leaks Header when Exchange.HTTP_METHOD is set
> -
>
> Key: CAMEL-15290
> URL: https://issues.apache.org/jira/browse/CAMEL-15290
> Project: Camel
> Issue Type: Bug
> Components: camel-cxfrs
>Affects Versions: 3.4.0
>Reporter: Jens Kleine-Herzbruch
>Priority: Minor
>
> If you send a message to a CxfRsProducer that has the header
> Exchange.HTTP_METHOD set, the HTTP message sent will contain the header
> {code}org.apache.cxf.request.method=GET{code}
> for example.
> This header should not be present in the message since it is internal to the
> endpoint.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-15290) camel-cxf - CxfRsProducer leaks Header when Exchange.HTTP_METHOD is set
Jens Kleine-Herzbruch created CAMEL-15290:
-
Summary: camel-cxf - CxfRsProducer leaks Header when
Exchange.HTTP_METHOD is set
Key: CAMEL-15290
URL: https://issues.apache.org/jira/browse/CAMEL-15290
Project: Camel
Issue Type: Bug
Components: came-cxf
Affects Versions: 3.4.0
Reporter: Jens Kleine-Herzbruch
If you send a message to a CxfRsProducer that has the header
Exchange.HTTP_METHOD set, the HTTP message sent will contain the header
{code}org.apache.cxf.request.method=GET{code}
for example.
This header should not be present in the message since it is internal to the
endpoint.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14937) ExpressionBuilder.headerExpression("name", class) results in ClassNotFoundException
[
https://issues.apache.org/jira/browse/CAMEL-14937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Kleine-Herzbruch updated CAMEL-14937:
--
Attachment: camel-header-expression.diff
> ExpressionBuilder.headerExpression("name", class) results in
> ClassNotFoundException
> ---
>
> Key: CAMEL-14937
> URL: https://issues.apache.org/jira/browse/CAMEL-14937
> Project: Camel
> Issue Type: Bug
> Components: came-core
>Affects Versions: 3.2.0
>Reporter: Jens Kleine-Herzbruch
>Priority: Major
> Attachments: camel-header-expression.diff
>
>
> {{ public static Expression headerExpression(final String headerName,
> final Class type) {}}
> {{ return headerExpression(simpleExpression(headerName),
> constantExpression(type));}}
> {{ }}}
>
> and
>
> {{ public static Expression headerExpression(final Expression headerName,
> final Expression typeName)}}
> {{}}{{}}
> tries to resolve the type via
> {{String text = typeName.evaluate(exchange, String.class);}}
> which results in the String "class xxx.yyy.type". Trying to resolve that as a
> class obviously is bound to fail. I'm not sure whether the type converter
> should be changed here or the headerExpression code is wrong.
>
> This worked in 3.1.0, btw.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-14937) ExpressionBuilder.headerExpression("name", class) results in ClassNotFoundException
[
https://issues.apache.org/jira/browse/CAMEL-14937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089445#comment-17089445
]
Jens Kleine-Herzbruch commented on CAMEL-14937:
---
Here's a simple test case and a possible fix.
> ExpressionBuilder.headerExpression("name", class) results in
> ClassNotFoundException
> ---
>
> Key: CAMEL-14937
> URL: https://issues.apache.org/jira/browse/CAMEL-14937
> Project: Camel
> Issue Type: Bug
> Components: came-core
>Affects Versions: 3.2.0
>Reporter: Jens Kleine-Herzbruch
>Priority: Major
> Attachments: camel-header-expression.diff
>
>
> {{ public static Expression headerExpression(final String headerName,
> final Class type) {}}
> {{ return headerExpression(simpleExpression(headerName),
> constantExpression(type));}}
> {{ }}}
>
> and
>
> {{ public static Expression headerExpression(final Expression headerName,
> final Expression typeName)}}
> {{}}{{}}
> tries to resolve the type via
> {{String text = typeName.evaluate(exchange, String.class);}}
> which results in the String "class xxx.yyy.type". Trying to resolve that as a
> class obviously is bound to fail. I'm not sure whether the type converter
> should be changed here or the headerExpression code is wrong.
>
> This worked in 3.1.0, btw.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-14937) ExpressionBuilder.headerExpression("name", class) results in ClassNotFoundException
[
https://issues.apache.org/jira/browse/CAMEL-14937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089315#comment-17089315
]
Jens Kleine-Herzbruch commented on CAMEL-14937:
---
I don't have a rproducer at the ready but the main problem is that
typeName.evaluate(exchange, String.class) with typeName being e.g. a
constantExpression(String.class) results in the string "class java.lang.String".
When that gets fed into the class resolver, it fails.
So either the class resolver needs to handle that case (probably not the
correct solution), or the type converter needs to make sure to convert to
"java.lang.String", or the headerExpression code needs to use the passed in
class parameter directly instead of converting to class name and back to class.
> ExpressionBuilder.headerExpression("name", class) results in
> ClassNotFoundException
> ---
>
> Key: CAMEL-14937
> URL: https://issues.apache.org/jira/browse/CAMEL-14937
> Project: Camel
> Issue Type: Bug
> Components: came-core
>Affects Versions: 3.2.0
>Reporter: Jens Kleine-Herzbruch
>Priority: Major
>
> {{ public static Expression headerExpression(final String headerName,
> final Class type) {}}
> {{ return headerExpression(simpleExpression(headerName),
> constantExpression(type));}}
> {{ }}}
>
> and
>
> {{ public static Expression headerExpression(final Expression headerName,
> final Expression typeName)}}
> {{}}{{}}
> tries to resolve the type via
> {{String text = typeName.evaluate(exchange, String.class);}}
> which results in the String "class xxx.yyy.type". Trying to resolve that as a
> class obviously is bound to fail. I'm not sure whether the type converter
> should be changed here or the headerExpression code is wrong.
>
> This worked in 3.1.0, btw.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-14937) ExpressionBuilder.headerExpression("name", class) results in ClassNotFoundException
Jens Kleine-Herzbruch created CAMEL-14937:
-
Summary: ExpressionBuilder.headerExpression("name", class) results
in ClassNotFoundException
Key: CAMEL-14937
URL: https://issues.apache.org/jira/browse/CAMEL-14937
Project: Camel
Issue Type: Bug
Components: came-core
Affects Versions: 3.2.0
Reporter: Jens Kleine-Herzbruch
{{ public static Expression headerExpression(final String headerName, final
Class type) {}}
{{ return headerExpression(simpleExpression(headerName),
constantExpression(type));}}
{{ }}}
and
{{ public static Expression headerExpression(final Expression headerName, final
Expression typeName)}}
{{}}{{}}
tries to resolve the type via
{{String text = typeName.evaluate(exchange, String.class);}}
which results in the String "class xxx.yyy.type". Trying to resolve that as a
class obviously is bound to fail. I'm not sure whether the type converter
should be changed here or the headerExpression code is wrong.
This worked in 3.1.0, btw.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-14589) camel-c8f - Service beans can only be set via context
[ https://issues.apache.org/jira/browse/CAMEL-14589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039206#comment-17039206 ] Jens Kleine-Herzbruch commented on CAMEL-14589: --- I'm afraid I'm not allowed to do that. > camel-cxf - Service beans can only be set via context > - > > Key: CAMEL-14589 > URL: https://issues.apache.org/jira/browse/CAMEL-14589 > Project: Camel > Issue Type: Bug > Components: camel-cxfrs >Affects Versions: 3.0.0, 3.0.1 >Reporter: Jens Kleine-Herzbruch >Priority: Major > Attachments: cxf-service-beans.diff > > > Since version 3.x it is no longer possible to set service beans directly. > They can only be resolved from the context instead. This was possible in 2.x. > The attached patch readds this configuration path. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-14589) camel-cxf - Service beans can only be set via context
Jens Kleine-Herzbruch created CAMEL-14589: - Summary: camel-cxf - Service beans can only be set via context Key: CAMEL-14589 URL: https://issues.apache.org/jira/browse/CAMEL-14589 Project: Camel Issue Type: Bug Components: camel-cxfrs Affects Versions: 3.0.1, 3.0.0 Reporter: Jens Kleine-Herzbruch Attachments: cxf-service-beans.diff Since version 3.x it is no longer possible to set service beans directly. They can only be resolved from the context instead. This was possible in 2.x. The attached patch readds this configuration path. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-14467) Dynamically bypass the cache for lookups
Jens Kleine-Herzbruch created CAMEL-14467: - Summary: Dynamically bypass the cache for lookups Key: CAMEL-14467 URL: https://issues.apache.org/jira/browse/CAMEL-14467 Project: Camel Issue Type: New Feature Components: camel-jcache Affects Versions: 3.0.1 Reporter: Jens Kleine-Herzbruch Attachments: bypass.diff Currently, the JCachePolicy can only enabled or disable the cache completely at startup. It would be useful to be able to enable or disable caching per request, though. This change adds a new property "bypassExpression". If this expression is set and returns true, the cache is ignored for lookup, the underlying route is executed as normal, and the returned value is inserted in the cache for future lookups. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-14281) Support sync reads/read locking in JCachePolicyProcessor
[ https://issues.apache.org/jira/browse/CAMEL-14281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Kleine-Herzbruch updated CAMEL-14281: -- Description: Currently, if two requests for the same cache key come in simultaneously, both requests will execute the route decorated with the cache policy. If this route includes expensive calculations/integrations this may be undesirable. Instead, only the first request should kick off the real route, and the second should block on the cache read until the result of the first route has entered the cache. Spring, for example, supports this with the "sync" parameter on @Cacheable. was: Currently, if two requests for the same cache key come in simultaneously, both requests will execute the route decorated with the cache policy. If this route includes expensive calculations/integrations this may be undesirable. Instead, only the first request should kick of the real route, and the second should block on the cache read until the result of the first route has entered the cache. Spring, for example, supports this with the "sync" parameter on @Cacheable. > Support sync reads/read locking in JCachePolicyProcessor > > > Key: CAMEL-14281 > URL: https://issues.apache.org/jira/browse/CAMEL-14281 > Project: Camel > Issue Type: New Feature > Components: camel-jcache >Affects Versions: 3.0.0 >Reporter: Jens Kleine-Herzbruch >Priority: Major > Fix For: 3.x > > > Currently, if two requests for the same cache key come in simultaneously, > both requests will execute the route decorated with the cache policy. If this > route includes expensive calculations/integrations this may be undesirable. > Instead, only the first request should kick off the real route, and the > second should block on the cache read until the result of the first route has > entered the cache. > > Spring, for example, supports this with the "sync" parameter on @Cacheable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14281) Support sync reads/read locking in JCachePolicyProcessor
[ https://issues.apache.org/jira/browse/CAMEL-14281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16993355#comment-16993355 ] Jens Kleine-Herzbruch commented on CAMEL-14281: --- No promises. It's something we need, but it's not the highest priority. > Support sync reads/read locking in JCachePolicyProcessor > > > Key: CAMEL-14281 > URL: https://issues.apache.org/jira/browse/CAMEL-14281 > Project: Camel > Issue Type: New Feature > Components: camel-jcache >Affects Versions: 3.0.0 >Reporter: Jens Kleine-Herzbruch >Priority: Major > Fix For: 3.x > > > Currently, if two requests for the same cache key come in simultaneously, > both requests will execute the route decorated with the cache policy. If this > route includes expensive calculations/integrations this may be undesirable. > Instead, only the first request should kick of the real route, and the second > should block on the cache read until the result of the first route has > entered the cache. > > Spring, for example, supports this with the "sync" parameter on @Cacheable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-14281) Support sync reads/read locking in JCachePolicyProcessor
Jens Kleine-Herzbruch created CAMEL-14281: - Summary: Support sync reads/read locking in JCachePolicyProcessor Key: CAMEL-14281 URL: https://issues.apache.org/jira/browse/CAMEL-14281 Project: Camel Issue Type: New Feature Components: camel-jcache Affects Versions: 3.0.0 Reporter: Jens Kleine-Herzbruch Currently, if two requests for the same cache key come in simultaneously, both requests will execute the route decorated with the cache policy. If this route includes expensive calculations/integrations this may be undesirable. Instead, only the first request should kick of the real route, and the second should block on the cache read until the result of the first route has entered the cache. Spring, for example, supports this with the "sync" parameter on @Cacheable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-12957) camel-cxf - Swagger/OpenAPI feature should not involve the Camel route
[ https://issues.apache.org/jira/browse/CAMEL-12957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16880965#comment-16880965 ] Jens Kleine-Herzbruch commented on CAMEL-12957: --- [~ffang]: Seems to work fine now with CXF snapshot versions. Thank you! > camel-cxf - Swagger/OpenAPI feature should not involve the Camel route > -- > > Key: CAMEL-12957 > URL: https://issues.apache.org/jira/browse/CAMEL-12957 > Project: Camel > Issue Type: Improvement > Components: camel-cxfrs >Affects Versions: 2.22.2 >Reporter: Jens Kleine-Herzbruch >Assignee: Freeman Fang >Priority: Minor > Attachments: camel-openapi-test-swagger2feature.tar, > camel-openapi-test.zip > > > Currently, when adding Swagger2Feature or OpenApiFeature to a CXFRS endpoint, > the calls to the API descriptions go through the Camel route, ie. one has to > implement an additional Camel route in order to make those features work. > Using runAsFilter=false a call to > http://localhost:8080/services/myCamelService/openapi.json > results in a call of the Camel route with an operation "getOpenApi" > http://localhost:8080/services/myCamelServive/api-docs?url=openapi.json > results in call of the Camel route with an operation "getResource" > Using runAsFilter=true the situation improves marginally: > http://localhost:8080/services/myCamelService/openapi.json > still results in a call of the Camel route with an operation "getOpenApi" > http://localhost:8080/services/myCamelServive/api-docs?url=openapi.json > at least now shows the Swagger UI page frame but still fails to load the > actual service description since it again calls the Camel route with the > "getOpenApi" operation. > Supposedly that means the filter correctly intercepts the getResource call > but not the getOpenApi call. It would be great if this worked out of the box. > A custom implementation would still be possible by not running as a filter. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-12957) camel-cxf - Swagger/OpenAPI feature should not involve the Camel route
[ https://issues.apache.org/jira/browse/CAMEL-12957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Kleine-Herzbruch updated CAMEL-12957: -- Attachment: camel-openapi-test.zip > camel-cxf - Swagger/OpenAPI feature should not involve the Camel route > -- > > Key: CAMEL-12957 > URL: https://issues.apache.org/jira/browse/CAMEL-12957 > Project: Camel > Issue Type: Improvement > Components: camel-cxfrs >Affects Versions: 2.22.2 >Reporter: Jens Kleine-Herzbruch >Priority: Minor > Attachments: camel-openapi-test.zip > > > Currently, when adding Swagger2Feature or OpenApiFeature to a CXFRS endpoint, > the calls to the API descriptions go through the Camel route, ie. one has to > implement an additional Camel route in order to make those features work. > Using runAsFilter=false a call to > http://localhost:8080/services/myCamelService/openapi.json > results in a call of the Camel route with an operation "getOpenApi" > http://localhost:8080/services/myCamelServive/api-docs?url=openapi.json > results in call of the Camel route with an operation "getResource" > Using runAsFilter=true the situation improves marginally: > http://localhost:8080/services/myCamelService/openapi.json > still results in a call of the Camel route with an operation "getOpenApi" > http://localhost:8080/services/myCamelServive/api-docs?url=openapi.json > at least now shows the Swagger UI page frame but still fails to load the > actual service description since it again calls the Camel route with the > "getOpenApi" operation. > Supposedly that means the filter correctly intercepts the getResource call > but not the getOpenApi call. It would be great if this worked out of the box. > A custom implementation would still be possible by not running as a filter. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-12957) camel-cxf - Swagger/OpenAPI feature should not involve the Camel route
[ https://issues.apache.org/jira/browse/CAMEL-12957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16870884#comment-16870884 ] Jens Kleine-Herzbruch commented on CAMEL-12957: --- Hi Freeman, here's a small test project that shows the problem. Cheers, Jens > camel-cxf - Swagger/OpenAPI feature should not involve the Camel route > -- > > Key: CAMEL-12957 > URL: https://issues.apache.org/jira/browse/CAMEL-12957 > Project: Camel > Issue Type: Improvement > Components: camel-cxfrs >Affects Versions: 2.22.2 >Reporter: Jens Kleine-Herzbruch >Priority: Minor > Attachments: camel-openapi-test.zip > > > Currently, when adding Swagger2Feature or OpenApiFeature to a CXFRS endpoint, > the calls to the API descriptions go through the Camel route, ie. one has to > implement an additional Camel route in order to make those features work. > Using runAsFilter=false a call to > http://localhost:8080/services/myCamelService/openapi.json > results in a call of the Camel route with an operation "getOpenApi" > http://localhost:8080/services/myCamelServive/api-docs?url=openapi.json > results in call of the Camel route with an operation "getResource" > Using runAsFilter=true the situation improves marginally: > http://localhost:8080/services/myCamelService/openapi.json > still results in a call of the Camel route with an operation "getOpenApi" > http://localhost:8080/services/myCamelServive/api-docs?url=openapi.json > at least now shows the Swagger UI page frame but still fails to load the > actual service description since it again calls the Camel route with the > "getOpenApi" operation. > Supposedly that means the filter correctly intercepts the getResource call > but not the getOpenApi call. It would be great if this worked out of the box. > A custom implementation would still be possible by not running as a filter. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-13037) camel-cxfrs - SimpleBinding ignores annotations on interface
[ https://issues.apache.org/jira/browse/CAMEL-13037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16762527#comment-16762527 ] Jens Kleine-Herzbruch commented on CAMEL-13037: --- Is this supposed to be committed already? > camel-cxfrs - SimpleBinding ignores annotations on interface > > > Key: CAMEL-13037 > URL: https://issues.apache.org/jira/browse/CAMEL-13037 > Project: Camel > Issue Type: Bug > Components: camel-cxfrs >Affects Versions: 2.23.0 >Reporter: Jens Kleine-Herzbruch >Priority: Major > Fix For: 3.0.0, 2.23.2, 2.24.0, 2.22.4 > > Attachments: > 0001-use-the-same-procedure-CXF-uses-for-discovering-JAX-.patch > > > When using a service resource that implements an interface, and the interface > carries the JAX-RS annotations (a common setup, e.g. when auto-generating > code with Swagger) the SimpleBinding ignores those annotations and does not > set up the proper Camel message headers. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-13037) camel-cxfrs - SimpleBinding ignores annotations on interface
[ https://issues.apache.org/jira/browse/CAMEL-13037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Kleine-Herzbruch updated CAMEL-13037: -- Issue Type: Bug (was: Improvement) > camel-cxfrs - SimpleBinding ignores annotations on interface > > > Key: CAMEL-13037 > URL: https://issues.apache.org/jira/browse/CAMEL-13037 > Project: Camel > Issue Type: Bug > Components: camel-cxfrs >Affects Versions: 2.23.0 >Reporter: Jens Kleine-Herzbruch >Priority: Major > Attachments: > 0001-use-the-same-procedure-CXF-uses-for-discovering-JAX-.patch > > > When using a service resource that implements an interface, and the interface > carries the JAX-RS annotations (a common setup, e.g. when auto-generating > code with Swagger) the SimpleBinding ignores those annotations and does not > set up the proper Camel message headers. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-13037) camel-cxfrs - SimpleBinding ignores annotations on interface
Jens Kleine-Herzbruch created CAMEL-13037: - Summary: camel-cxfrs - SimpleBinding ignores annotations on interface Key: CAMEL-13037 URL: https://issues.apache.org/jira/browse/CAMEL-13037 Project: Camel Issue Type: Improvement Components: camel-cxfrs Affects Versions: 2.23.0 Reporter: Jens Kleine-Herzbruch Attachments: 0001-use-the-same-procedure-CXF-uses-for-discovering-JAX-.patch When using a service resource that implements an interface, and the interface carries the JAX-RS annotations (a common setup, e.g. when auto-generating code with Swagger) the SimpleBinding ignores those annotations and does not set up the proper Camel message headers. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-12979) Service beans with custom lifecycle on CxfRsEndpoint
[ https://issues.apache.org/jira/browse/CAMEL-12979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16710130#comment-16710130 ] Jens Kleine-Herzbruch commented on CAMEL-12979: --- I'd like to see this on 2.23 at least. > Service beans with custom lifecycle on CxfRsEndpoint > > > Key: CAMEL-12979 > URL: https://issues.apache.org/jira/browse/CAMEL-12979 > Project: Camel > Issue Type: Improvement > Components: camel-cxfrs >Affects Versions: 2.23.0 >Reporter: Jens Kleine-Herzbruch >Assignee: Önder Sezgin >Priority: Major > Fix For: 2.24.0 > > Attachments: serviceBean.diff > > > The CXF server factory supports setting "serviceBeans" instead of (or in > addition to) "resourceClasses" which will have their lifecycle managed by the > application instead of the JAX-RS implementation. This is useful, e.g. to get > injection support from your application container. > > Currently it is not possible to set such beans on the CxfRsEndpoint. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-12979) Service beans with custom lifecycle on CxfRsEndpoint
[ https://issues.apache.org/jira/browse/CAMEL-12979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Kleine-Herzbruch updated CAMEL-12979: -- Attachment: serviceBean.diff > Service beans with custom lifecycle on CxfRsEndpoint > > > Key: CAMEL-12979 > URL: https://issues.apache.org/jira/browse/CAMEL-12979 > Project: Camel > Issue Type: Improvement > Components: camel-cxfrs >Affects Versions: 2.23.0 >Reporter: Jens Kleine-Herzbruch >Priority: Major > Attachments: serviceBean.diff > > > The CXF server factory supports setting "serviceBeans" instead of (or in > addition to) "resourceClasses" which will have their lifecycle managed by the > application instead of the JAX-RS implementation. This is useful, e.g. to get > injection support from your application container. > > Currently it is not possible to set such beans on the CxfRsEndpoint. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-12979) Service beans with custom lifecycle on CxfRsEndpoint
Jens Kleine-Herzbruch created CAMEL-12979: - Summary: Service beans with custom lifecycle on CxfRsEndpoint Key: CAMEL-12979 URL: https://issues.apache.org/jira/browse/CAMEL-12979 Project: Camel Issue Type: Improvement Components: camel-cxfrs Affects Versions: 2.23.0 Reporter: Jens Kleine-Herzbruch The CXF server factory supports setting "serviceBeans" instead of (or in addition to) "resourceClasses" which will have their lifecycle managed by the application instead of the JAX-RS implementation. This is useful, e.g. to get injection support from your application container. Currently it is not possible to set such beans on the CxfRsEndpoint. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-12957) Swagger/OpenAPI feature should not involve the Camel route
Jens Kleine-Herzbruch created CAMEL-12957: - Summary: Swagger/OpenAPI feature should not involve the Camel route Key: CAMEL-12957 URL: https://issues.apache.org/jira/browse/CAMEL-12957 Project: Camel Issue Type: Improvement Components: camel-cxfrs Affects Versions: 2.22.2 Reporter: Jens Kleine-Herzbruch Currently, when adding Swagger2Feature or OpenApiFeature to a CXFRS endpoint, the calls to the API descriptions go through the Camel route, ie. one has to implement an additional Camel route in order to make those features work. Using runAsFilter=false a call to http://localhost:8080/services/myCamelService/openapi.json results in a call of the Camel route with an operation "getOpenApi" http://localhost:8080/services/myCamelServive/api-docs?url=openapi.json results in call of the Camel route with an operation "getResource" Using runAsFilter=true the situation improves marginally: http://localhost:8080/services/myCamelService/openapi.json still results in a call of the Camel route with an operation "getOpenApi" http://localhost:8080/services/myCamelServive/api-docs?url=openapi.json at least now shows the Swagger UI page frame but still fails to load the actual service description since it again calls the Camel route with the "getOpenApi" operation. Supposedly that means the filter correctly intercepts the getResource call but not the getOpenApi call. It would be great if this worked out of the box. A custom implementation would still be possible by not running as a filter. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-12309) SpEL expression should be able to reference beans in non-Spring application context
[ https://issues.apache.org/jira/browse/CAMEL-12309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16385760#comment-16385760 ] Jens Kleine-Herzbruch commented on CAMEL-12309: --- Here's a diff with a small test included. I also modified the resolver slightly so that a null reference causes an exception. It's not ideal but since the registry interface doesn't differentiate between null and not found it's the closest we can get to the Spring behaviour, I believe. > SpEL expression should be able to reference beans in non-Spring application > context > --- > > Key: CAMEL-12309 > URL: https://issues.apache.org/jira/browse/CAMEL-12309 > Project: Camel > Issue Type: Improvement > Components: camel-spring >Affects Versions: 2.20.2 >Reporter: Jens Kleine-Herzbruch >Priority: Major > Labels: SpEL > Attachments: spel-ref.diff > > > Currently, a SpEL expression like @myBean only gets resolved correctly when > using a Spring application context. Considering that the Ref language can do > this with any type of context, it shouldn't be tto hard to support this for > SpEL, too. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-12309) SpEL expression should be able to reference beans in non-Spring application context
[ https://issues.apache.org/jira/browse/CAMEL-12309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Kleine-Herzbruch updated CAMEL-12309: -- Attachment: spel-ref.diff > SpEL expression should be able to reference beans in non-Spring application > context > --- > > Key: CAMEL-12309 > URL: https://issues.apache.org/jira/browse/CAMEL-12309 > Project: Camel > Issue Type: Improvement > Components: camel-spring >Affects Versions: 2.20.2 >Reporter: Jens Kleine-Herzbruch >Priority: Major > Labels: SpEL > Attachments: spel-ref.diff > > > Currently, a SpEL expression like @myBean only gets resolved correctly when > using a Spring application context. Considering that the Ref language can do > this with any type of context, it shouldn't be tto hard to support this for > SpEL, too. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-12309) SpEL expression should be able to reference beans in non-Spring application context
[ https://issues.apache.org/jira/browse/CAMEL-12309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Kleine-Herzbruch updated CAMEL-12309: -- Attachment: (was: spel-ref.diff) > SpEL expression should be able to reference beans in non-Spring application > context > --- > > Key: CAMEL-12309 > URL: https://issues.apache.org/jira/browse/CAMEL-12309 > Project: Camel > Issue Type: Improvement > Components: camel-spring >Affects Versions: 2.20.2 >Reporter: Jens Kleine-Herzbruch >Priority: Major > Labels: SpEL > Attachments: spel-ref.diff > > > Currently, a SpEL expression like @myBean only gets resolved correctly when > using a Spring application context. Considering that the Ref language can do > this with any type of context, it shouldn't be tto hard to support this for > SpEL, too. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-12309) SpEL expression should be able to reference beans in non-Spring application context
Jens Kleine-Herzbruch created CAMEL-12309: - Summary: SpEL expression should be able to reference beans in non-Spring application context Key: CAMEL-12309 URL: https://issues.apache.org/jira/browse/CAMEL-12309 Project: Camel Issue Type: Improvement Components: camel-spring Affects Versions: 2.20.2 Reporter: Jens Kleine-Herzbruch Attachments: spel-ref.diff Currently, a SpEL expression like @myBean only gets resolved correctly when using a Spring application context. Considering that the Ref language can do this with any type of context, it shouldn't be tto hard to support this for SpEL, too. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-5356) CXF endpoint doesn't play nice with doTry/doCatch
[
https://issues.apache.org/jira/browse/CAMEL-5356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16095955#comment-16095955
]
Jens Kleine-Herzbruch commented on CAMEL-5356:
--
cxf-bundle no longer exists with CXF 3.x. You probably need
{code}
org.apache.cxf
cxf-rt-transports-http-jetty
${cxf.version}
{code}
> CXF endpoint doesn't play nice with doTry/doCatch
> -
>
> Key: CAMEL-5356
> URL: https://issues.apache.org/jira/browse/CAMEL-5356
> Project: Camel
> Issue Type: Bug
> Components: camel-cxf
>Affects Versions: 2.8.3
>Reporter: Jens Granseuer
>Assignee: Önder Sezgin
> Fix For: Future
>
> Attachments: camelTryCatch.zip
>
>
> When using a CXF client endpoint to call a web service via SOAP/HTTP there
> are two possible error scenarios:
> 1) The call fails immediately with an exception (e.g. because the service is
> down/the address is wrong)
> 2) The call "succeeds" but returns a SOAP fault. This could also signal an
> error condition to the application.
> Currently, using doTry/doCatch doesn't work properly in either scenario
> because, apprently, the CXF endpoint nulls the message when receiving an
> exception or fault.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
