[jira] [Updated] (CAMEL-7622) No outputs found matching id when upgrading from 2.13 to 2.14
[
https://issues.apache.org/jira/browse/CAMEL-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-7622:
---
Fix Version/s: 2.14.0
No outputs found matching id when upgrading from 2.13 to 2.14
-
Key: CAMEL-7622
URL: https://issues.apache.org/jira/browse/CAMEL-7622
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.14.0
Reporter: Matt Raible
Assignee: Claus Ibsen
Fix For: 2.14.0
Attachments: outputnotfound.zip
I have the following route defined with the Java DSL:
from(direct:localMemberLookup).routeId(localMemberLookup)
.process(new MemberLookupToSqlParametersProcessor()).id(sqlParams)
.recipientList(simple(sql:{{sql.memberLookup}})).delimiter(false)
.to(log:output)
.process(new MemberLookupProcessor())
// do more processing
.to(log:output);
I'm testing it with a test that looks as follows:
@EndpointInject(uri = mock:lookupHeaders)
MockEndpoint lookupHeaders;
@EndpointInject(uri = mock:searchResult)
MockEndpoint searchResult;
@EndpointInject(uri = mock:lookupResult)
MockEndpoint lookupResult;
@Autowired
CamelContext camelContext;
@Before
public void before() throws Exception {
ModelCamelContext context = (ModelCamelContext) camelContext;
context.setTracing(true);
RouteDefinition searchRoute =
context.getRouteDefinition(memberSearchRequest);
searchRoute.to(searchResult);
RouteDefinition lookupRoute =
context.getRouteDefinition(localMemberLookup);
lookupRoute.adviceWith(context, new AdviceWithRouteBuilder() {
@Override
public void configure() throws Exception {
weaveById(sqlParams).after().to(lookupHeaders);
}
});
lookupRoute.to(lookupResult);
context.start();
}
With Camel 2.13.1, this works fine. However, with 2.14-SNAPSHOT, I get the
following error:
java.lang.IllegalArgumentException: There are no outputs which matches:
sqlParams in the route
Mailing list thread:
http://camel.465427.n5.nabble.com/weaveById-works-with-2-13-1-not-with-2-14-SNAPSHOT-td5753809.html
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CAMEL-7622) advice-with - No outputs found matching id when upgrading from 2.13 to 2.14
[
https://issues.apache.org/jira/browse/CAMEL-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-7622:
---
Summary: advice-with - No outputs found matching id when upgrading from
2.13 to 2.14 (was: No outputs found matching id when upgrading from 2.13 to
2.14)
advice-with - No outputs found matching id when upgrading from 2.13 to 2.14
---
Key: CAMEL-7622
URL: https://issues.apache.org/jira/browse/CAMEL-7622
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.14.0
Reporter: Matt Raible
Assignee: Claus Ibsen
Fix For: 2.14.0
Attachments: outputnotfound.zip
I have the following route defined with the Java DSL:
from(direct:localMemberLookup).routeId(localMemberLookup)
.process(new MemberLookupToSqlParametersProcessor()).id(sqlParams)
.recipientList(simple(sql:{{sql.memberLookup}})).delimiter(false)
.to(log:output)
.process(new MemberLookupProcessor())
// do more processing
.to(log:output);
I'm testing it with a test that looks as follows:
@EndpointInject(uri = mock:lookupHeaders)
MockEndpoint lookupHeaders;
@EndpointInject(uri = mock:searchResult)
MockEndpoint searchResult;
@EndpointInject(uri = mock:lookupResult)
MockEndpoint lookupResult;
@Autowired
CamelContext camelContext;
@Before
public void before() throws Exception {
ModelCamelContext context = (ModelCamelContext) camelContext;
context.setTracing(true);
RouteDefinition searchRoute =
context.getRouteDefinition(memberSearchRequest);
searchRoute.to(searchResult);
RouteDefinition lookupRoute =
context.getRouteDefinition(localMemberLookup);
lookupRoute.adviceWith(context, new AdviceWithRouteBuilder() {
@Override
public void configure() throws Exception {
weaveById(sqlParams).after().to(lookupHeaders);
}
});
lookupRoute.to(lookupResult);
context.start();
}
With Camel 2.13.1, this works fine. However, with 2.14-SNAPSHOT, I get the
following error:
java.lang.IllegalArgumentException: There are no outputs which matches:
sqlParams in the route
Mailing list thread:
http://camel.465427.n5.nabble.com/weaveById-works-with-2-13-1-not-with-2-14-SNAPSHOT-td5753809.html
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (CAMEL-7622) No outputs found matching id when upgrading from 2.13 to 2.14
[
https://issues.apache.org/jira/browse/CAMEL-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-7622:
--
Assignee: Claus Ibsen
No outputs found matching id when upgrading from 2.13 to 2.14
-
Key: CAMEL-7622
URL: https://issues.apache.org/jira/browse/CAMEL-7622
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.14.0
Reporter: Matt Raible
Assignee: Claus Ibsen
Fix For: 2.14.0
Attachments: outputnotfound.zip
I have the following route defined with the Java DSL:
from(direct:localMemberLookup).routeId(localMemberLookup)
.process(new MemberLookupToSqlParametersProcessor()).id(sqlParams)
.recipientList(simple(sql:{{sql.memberLookup}})).delimiter(false)
.to(log:output)
.process(new MemberLookupProcessor())
// do more processing
.to(log:output);
I'm testing it with a test that looks as follows:
@EndpointInject(uri = mock:lookupHeaders)
MockEndpoint lookupHeaders;
@EndpointInject(uri = mock:searchResult)
MockEndpoint searchResult;
@EndpointInject(uri = mock:lookupResult)
MockEndpoint lookupResult;
@Autowired
CamelContext camelContext;
@Before
public void before() throws Exception {
ModelCamelContext context = (ModelCamelContext) camelContext;
context.setTracing(true);
RouteDefinition searchRoute =
context.getRouteDefinition(memberSearchRequest);
searchRoute.to(searchResult);
RouteDefinition lookupRoute =
context.getRouteDefinition(localMemberLookup);
lookupRoute.adviceWith(context, new AdviceWithRouteBuilder() {
@Override
public void configure() throws Exception {
weaveById(sqlParams).after().to(lookupHeaders);
}
});
lookupRoute.to(lookupResult);
context.start();
}
With Camel 2.13.1, this works fine. However, with 2.14-SNAPSHOT, I get the
following error:
java.lang.IllegalArgumentException: There are no outputs which matches:
sqlParams in the route
Mailing list thread:
http://camel.465427.n5.nabble.com/weaveById-works-with-2-13-1-not-with-2-14-SNAPSHOT-td5753809.html
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (CAMEL-7456) Camel PropertiesComponent ignores custom parser in Blueprint
[
https://issues.apache.org/jira/browse/CAMEL-7456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek resolved CAMEL-7456.
-
Resolution: Fixed
Documentation updated
Camel PropertiesComponent ignores custom parser in Blueprint
Key: CAMEL-7456
URL: https://issues.apache.org/jira/browse/CAMEL-7456
Project: Camel
Issue Type: Bug
Components: osgi
Affects Versions: 2.12.3
Reporter: Joe Luo
Assignee: Grzegorz Grzybek
Priority: Minor
Fix For: 2.12.5, 2.13.3, 2.14.0
I have implemented a custom PropertiesParser which allows me to use system
property placeholders in propertyPrefix and propertySuffix.
In my use case the propertyPrefix is defined as $\{container.stage}., where
container.stage is a jvm option defined at container creation. The value is
one of dev, test and prod.
This works fine in Java DSL world (SCR bundle), but custom parser is ignored
in Blueprint. Here is sample of my blueprint xml:
{code}
cm:property-placeholder id=integration
persistent-id=org.apache.camel.sample.temp placeholder-prefix=[[
placeholder-suffix=]]
cm:default-properties
cm:property name=example value=this value is the default/
cm:property name=dev.example value=this value is used in
development environment/
cm:property name=test.example value=this value is used in test
environment/
cm:property name=prod.example value=this value is used in
production environment/
/cm:default-properties
/cm:property-placeholder
bean id=parser class=org.apache.camel.sample.MyCustomPropertiesParser/
!-- Load properties for current container stage --
bean id=properties
class=org.apache.camel.component.properties.PropertiesComponent
property name=propertiesParser ref=parser/
property name=propertyPrefix value=${container.stage}./
property name=fallbackToUnaugmentedProperty value=true/
property name=location
value=blueprint:integration,classpath:properties/temp.properties//bean
camelContext id=temp xmlns=http://camel.apache.org/schema/blueprint;
route id=exampleRoute
from uri=timer:foo?period=5000/
transform
simple{{example}}/simple
/transform
to uri=log:something/
/route
/camelContext
{code}
The reason it did not work was because by default, it uses blueprint property
resolver (useBlueprintPropertyResolver=true) to bridge PropertiesComponent
to blueprint in order to support looking up property placeholders from the
Blueprint Property Placeholder Service. Then it always creates a
BlueprintPropertiesParser object and set it to PropertiesComponent.
The customer Property Parser I created was only set into the
BlueprintPropertiesParser object as a delegate Property Parser. Therefore, it
was always the method parseUri() from the BlueprintPropertiesParser object
got invoked. The same method from your custom parser was ignored.
For more detail, please take a look at
org.apache.camel.blueprint.CamelContextFactoryBean.initPropertyPlaceholder()
function.
The only workaround is to add the attribute
useBlueprintPropertyResolver=false to camelContext element to disable
default blueprint property resolver. However, I will have to change
PropertiesComponent's location property to remove blueprint
blueprint:integration from the comma separated value list:
{code}
property name=location value=classpath:properties/temp.properties/
{code}
Because once I set it to false, I will no longer be able to lookup from
blueprint property service.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CAMEL-7622) advice-with - No outputs found matching id when upgrading from 2.13 to 2.14
[
https://issues.apache.org/jira/browse/CAMEL-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14069924#comment-14069924
]
Claus Ibsen commented on CAMEL-7622:
Thanks for the sample code. I have reproduced the issue and have a fix in the
works.
advice-with - No outputs found matching id when upgrading from 2.13 to 2.14
---
Key: CAMEL-7622
URL: https://issues.apache.org/jira/browse/CAMEL-7622
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.14.0
Reporter: Matt Raible
Assignee: Claus Ibsen
Fix For: 2.14.0
Attachments: outputnotfound.zip
I have the following route defined with the Java DSL:
from(direct:localMemberLookup).routeId(localMemberLookup)
.process(new MemberLookupToSqlParametersProcessor()).id(sqlParams)
.recipientList(simple(sql:{{sql.memberLookup}})).delimiter(false)
.to(log:output)
.process(new MemberLookupProcessor())
// do more processing
.to(log:output);
I'm testing it with a test that looks as follows:
@EndpointInject(uri = mock:lookupHeaders)
MockEndpoint lookupHeaders;
@EndpointInject(uri = mock:searchResult)
MockEndpoint searchResult;
@EndpointInject(uri = mock:lookupResult)
MockEndpoint lookupResult;
@Autowired
CamelContext camelContext;
@Before
public void before() throws Exception {
ModelCamelContext context = (ModelCamelContext) camelContext;
context.setTracing(true);
RouteDefinition searchRoute =
context.getRouteDefinition(memberSearchRequest);
searchRoute.to(searchResult);
RouteDefinition lookupRoute =
context.getRouteDefinition(localMemberLookup);
lookupRoute.adviceWith(context, new AdviceWithRouteBuilder() {
@Override
public void configure() throws Exception {
weaveById(sqlParams).after().to(lookupHeaders);
}
});
lookupRoute.to(lookupResult);
context.start();
}
With Camel 2.13.1, this works fine. However, with 2.14-SNAPSHOT, I get the
following error:
java.lang.IllegalArgumentException: There are no outputs which matches:
sqlParams in the route
Mailing list thread:
http://camel.465427.n5.nabble.com/weaveById-works-with-2-13-1-not-with-2-14-SNAPSHOT-td5753809.html
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CAMEL-5604) camel-jackson - Make it easier to support List as output out of the box
[ https://issues.apache.org/jira/browse/CAMEL-5604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070020#comment-14070020 ] Claus Ibsen commented on CAMEL-5604: Thanks but IMHO we should try to add an option on the existing data format, so that option is exposed in the DSL for both java / xml. And reuse the existing code. Then that code can based on the option do the list stuff or not. camel-jackson - Make it easier to support List as output out of the box --- Key: CAMEL-5604 URL: https://issues.apache.org/jira/browse/CAMEL-5604 Project: Camel Issue Type: Improvement Components: camel-jackson Affects Versions: 2.10.0 Reporter: Claus Ibsen Assignee: Willem Jiang Priority: Minor Fix For: Future Attachments: JacksonCollectionDataFormat.java See nabble http://camel.465427.n5.nabble.com/JSON-Jackson-return-list-rather-than-POJO-tp5717341.html We should look into making it easier to output a List as output with jackson json. On the nabble link there is an example and pseduo code how to do that. We should find a way to make that easy in Camel. Either as some new option, or somehow auto detect its a List etc. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7616) using camle exec
[ https://issues.apache.org/jira/browse/CAMEL-7616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070022#comment-14070022 ] Claus Ibsen commented on CAMEL-7616: You can set the command arguments as a header, or use the RAW() syntax in the endpoint uri The header is ExecBinding.EXEC_COMMAND_ARGS http://camel.apache.org/exec And the raw is documented here http://camel.apache.org/how-do-i-configure-endpoints.html using camle exec - Key: CAMEL-7616 URL: https://issues.apache.org/jira/browse/CAMEL-7616 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.10.4 Reporter: Satyanarayana M Apologize. I do not see camle-exec in the components list, so selected camle-core. Have to run an lftp command which also has ls /+mode=text command(with out quotes) to be executed. However, camel exec uses +(plus) singe to represent space. How to escape this so that i can tell camel exec that + is also part of the commend ? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CAMEL-7616) using camle exec
[ https://issues.apache.org/jira/browse/CAMEL-7616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7616: --- Fix Version/s: (was: 2.10.4) using camle exec - Key: CAMEL-7616 URL: https://issues.apache.org/jira/browse/CAMEL-7616 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.10.4 Reporter: Satyanarayana M Apologize. I do not see camle-exec in the components list, so selected camle-core. Have to run an lftp command which also has ls /+mode=text command(with out quotes) to be executed. However, camel exec uses +(plus) singe to represent space. How to escape this so that i can tell camel exec that + is also part of the commend ? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CAMEL-7616) using camle exec
[ https://issues.apache.org/jira/browse/CAMEL-7616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-7616. Resolution: Not a Problem using camle exec - Key: CAMEL-7616 URL: https://issues.apache.org/jira/browse/CAMEL-7616 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.10.4 Reporter: Satyanarayana M Fix For: 2.10.4 Apologize. I do not see camle-exec in the components list, so selected camle-core. Have to run an lftp command which also has ls /+mode=text command(with out quotes) to be executed. However, camel exec uses +(plus) singe to represent space. How to escape this so that i can tell camel exec that + is also part of the commend ? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7612) Setting maxIdleTime in endpoint
[
https://issues.apache.org/jira/browse/CAMEL-7612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070029#comment-14070029
]
Claus Ibsen commented on CAMEL-7612:
Camel sets that option on Jetty.
{code}
if (endpoint.getMaxIdleTime() != null) {
context.setInitParameter(maxIdleTime,
endpoint.getMaxIdleTime().toString());
}
{code}
And jetty documents that option in their javadoc at:
org.eclipse.jetty.server.AbstractConnector#setMaxIdleTime
{code}
/* */
/**
* Set the maximum Idle time for a connection, which roughly translates to
the {@link Socket#setSoTimeout(int)} call, although with NIO implementations
* other mechanisms may be used to implement the timeout. The max idle time
is applied:
* ul
* liWhen waiting for a new request to be received on a connection/li
* liWhen reading the headers and content of a request/li
* liWhen writing the headers and content of a response/li
* /ul
* Jetty interprets this value as the maximum time between some progress
being made on the connection. So if a single byte is read or written, then the
* timeout (if implemented by jetty) is reset. However, in many instances,
the reading/writing is delegated to the JVM, and the semantic is more strictly
* enforced as the maximum time a single read/write operation can take.
Note, that as Jetty supports writes of memory mapped file buffers, then a write
may
* take many 10s of seconds for large content written to a slow device.
* p
* Previously, Jetty supported separate idle timeouts and IO operation
timeouts, however the expense of changing the value of soTimeout was
significant, so
* these timeouts were merged. With the advent of NIO, it may be possible
to again differentiate these values (if there is demand).
*
* @param maxIdleTime
*The maxIdleTime to set.
*/
public void setMaxIdleTime(int maxIdleTime)
{
_maxIdleTime = maxIdleTime;
}
{code}
Setting maxIdleTime in endpoint
---
Key: CAMEL-7612
URL: https://issues.apache.org/jira/browse/CAMEL-7612
Project: Camel
Issue Type: Bug
Components: camel-websocket
Affects Versions: 2.12.3
Environment: Linux CentOS 6.5, OpenJDK 1.7.0.55.x86_64, WebBrowser:
Chromium 31.0.1650.63, ServiceMix 5.0.0
Reporter: Daniel Tremblay
Priority: Minor
I created a camel-websocket endpoint with this uri:
websocket:/alerts?maxIdleTime=3.
The websocket is successfully created on the browser and messages can flow
back and forth. The maxIdleTime should be 30 seconds. However it times out
at 300 seconds (5 minutes).
My initial goal was to set the timeout to 15 minutes, instead of the default
5 minutes, but changing this setting does not seem to change the default.
I've modified the camel-websocket component to set the maxIdleTime on the
controller, but this doesn't work either. I'm not sure if the error is in
Jetty or Camel.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CAMEL-7612) Setting maxIdleTime in endpoint
[ https://issues.apache.org/jira/browse/CAMEL-7612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070034#comment-14070034 ] Claus Ibsen commented on CAMEL-7612: There is an unit tests that checks that Camel sets that option correctly org.apache.camel.component.websocket.WebscoketEndpointConfigurationTest Setting maxIdleTime in endpoint --- Key: CAMEL-7612 URL: https://issues.apache.org/jira/browse/CAMEL-7612 Project: Camel Issue Type: Bug Components: camel-websocket Affects Versions: 2.12.3 Environment: Linux CentOS 6.5, OpenJDK 1.7.0.55.x86_64, WebBrowser: Chromium 31.0.1650.63, ServiceMix 5.0.0 Reporter: Daniel Tremblay Priority: Minor I created a camel-websocket endpoint with this uri: websocket:/alerts?maxIdleTime=3. The websocket is successfully created on the browser and messages can flow back and forth. The maxIdleTime should be 30 seconds. However it times out at 300 seconds (5 minutes). My initial goal was to set the timeout to 15 minutes, instead of the default 5 minutes, but changing this setting does not seem to change the default. I've modified the camel-websocket component to set the maxIdleTime on the controller, but this doesn't work either. I'm not sure if the error is in Jetty or Camel. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CAMEL-7612) Setting maxIdleTime in endpoint
[ https://issues.apache.org/jira/browse/CAMEL-7612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-7612. Resolution: Not a Problem Not a Camel issue as the option gets set by Camel. Setting maxIdleTime in endpoint --- Key: CAMEL-7612 URL: https://issues.apache.org/jira/browse/CAMEL-7612 Project: Camel Issue Type: Bug Components: camel-websocket Affects Versions: 2.12.3 Environment: Linux CentOS 6.5, OpenJDK 1.7.0.55.x86_64, WebBrowser: Chromium 31.0.1650.63, ServiceMix 5.0.0 Reporter: Daniel Tremblay Priority: Minor I created a camel-websocket endpoint with this uri: websocket:/alerts?maxIdleTime=3. The websocket is successfully created on the browser and messages can flow back and forth. The maxIdleTime should be 30 seconds. However it times out at 300 seconds (5 minutes). My initial goal was to set the timeout to 15 minutes, instead of the default 5 minutes, but changing this setting does not seem to change the default. I've modified the camel-websocket component to set the maxIdleTime on the controller, but this doesn't work either. I'm not sure if the error is in Jetty or Camel. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CAMEL-7623) Camel is blocked while trying to shutdown a JMS consumer
Martin Lichtin created CAMEL-7623:
-
Summary: Camel is blocked while trying to shutdown a JMS consumer
Key: CAMEL-7623
URL: https://issues.apache.org/jira/browse/CAMEL-7623
Project: Camel
Issue Type: Bug
Components: camel-jms
Affects Versions: 2.12.3
Environment: Karaf 2.3.4, Camel 2.12.3, spring-jms 3.2.5.RELEASE
Reporter: Martin Lichtin
Camel is blocked while trying to shutdown a JMS consumer.
{noformat}
FelixStartLevel daemon prio=10 tid=0x2aaab03d2000 nid=0x6803 in
Object.wait() [0x405cd000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0x00079b473700 (a java.lang.Object)
at java.lang.Object.wait(Object.java:503)
at
org.springframework.jms.listener.DefaultMessageListenerContainer.doShutdown(DefaultMessageListenerContainer.java:545)
- locked 0x00079b473700 (a java.lang.Object)
at
org.springframework.jms.listener.AbstractJmsListeningContainer.shutdown(AbstractJmsListeningContainer.java:233)
at
org.springframework.jms.listener.AbstractJmsListeningContainer.destroy(AbstractJmsListeningContainer.java:173)
at
org.apache.camel.component.jms.DefaultJmsMessageListenerContainer.destroy(DefaultJmsMessageListenerContainer.java:100)
at
org.apache.camel.component.jms.JmsConsumer.stopAndDestroyListenerContainer(JmsConsumer.java:179)
at
org.apache.camel.component.jms.JmsConsumer.doStop(JmsConsumer.java:217)
at org.apache.camel.support.ServiceSupport.stop(ServiceSupport.java:102)
at
org.apache.camel.util.ServiceHelper.stopService(ServiceHelper.java:141)
at
org.apache.camel.impl.DefaultShutdownStrategy.shutdownNow(DefaultShutdownStrategy.java:336)
at
org.apache.camel.impl.DefaultShutdownStrategy.shutdownRoutesNow(DefaultShutdownStrategy.java:310)
at
org.apache.camel.impl.DefaultShutdownStrategy.doShutdown(DefaultShutdownStrategy.java:204)
at
org.apache.camel.impl.DefaultShutdownStrategy.shutdownForced(DefaultShutdownStrategy.java:131)
at
org.apache.camel.impl.DefaultCamelContext.doStop(DefaultCamelContext.java:1753)
- locked 0x00079b1cb208 (a
org.apache.camel.blueprint.BlueprintCamelContext)
at org.apache.camel.support.ServiceSupport.stop(ServiceSupport.java:102)
at
org.apache.camel.blueprint.BlueprintCamelContext.destroy(BlueprintCamelContext.java:119)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:297)
at
org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:958)
at
org.apache.aries.blueprint.container.BeanRecipe.destroy(BeanRecipe.java:863)
at
org.apache.aries.blueprint.container.BlueprintRepository.destroy(BlueprintRepository.java:320)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.destroyComponents(BlueprintContainerImpl.java:722)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.tidyupComponents(BlueprintContainerImpl.java:916)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.destroy(BlueprintContainerImpl.java:866)
at
org.apache.aries.blueprint.container.BlueprintExtender$3.run(BlueprintExtender.java:301)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
org.apache.aries.blueprint.container.BlueprintExtender.destroyContainer(BlueprintExtender.java:322)
at
org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:218)
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)
at
org.apache.felix.framework.util.SecureAction.invokeBundleEventHook(SecureAction.java:1103)
at
org.apache.felix.framework.util.EventDispatcher.createWhitelistFromHooks(EventDispatcher.java:695)
at
[jira] [Resolved] (CAMEL-7623) Camel is blocked while trying to shutdown a JMS consumer
[
https://issues.apache.org/jira/browse/CAMEL-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-7623.
Resolution: Not a Problem
Assignee: Claus Ibsen
Then use the async shutdown, if you do not want to wait for the JMS to shutdown
http://camel.apache.org/jms
Camel is blocked while trying to shutdown a JMS consumer
Key: CAMEL-7623
URL: https://issues.apache.org/jira/browse/CAMEL-7623
Project: Camel
Issue Type: Bug
Components: camel-jms
Affects Versions: 2.12.3
Environment: Karaf 2.3.4, Camel 2.12.3, spring-jms 3.2.5.RELEASE
Reporter: Martin Lichtin
Assignee: Claus Ibsen
Camel is blocked while trying to shutdown a JMS consumer.
{noformat}
FelixStartLevel daemon prio=10 tid=0x2aaab03d2000 nid=0x6803 in
Object.wait() [0x405cd000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0x00079b473700 (a java.lang.Object)
at java.lang.Object.wait(Object.java:503)
at
org.springframework.jms.listener.DefaultMessageListenerContainer.doShutdown(DefaultMessageListenerContainer.java:545)
- locked 0x00079b473700 (a java.lang.Object)
at
org.springframework.jms.listener.AbstractJmsListeningContainer.shutdown(AbstractJmsListeningContainer.java:233)
at
org.springframework.jms.listener.AbstractJmsListeningContainer.destroy(AbstractJmsListeningContainer.java:173)
at
org.apache.camel.component.jms.DefaultJmsMessageListenerContainer.destroy(DefaultJmsMessageListenerContainer.java:100)
at
org.apache.camel.component.jms.JmsConsumer.stopAndDestroyListenerContainer(JmsConsumer.java:179)
at
org.apache.camel.component.jms.JmsConsumer.doStop(JmsConsumer.java:217)
at
org.apache.camel.support.ServiceSupport.stop(ServiceSupport.java:102)
at
org.apache.camel.util.ServiceHelper.stopService(ServiceHelper.java:141)
at
org.apache.camel.impl.DefaultShutdownStrategy.shutdownNow(DefaultShutdownStrategy.java:336)
at
org.apache.camel.impl.DefaultShutdownStrategy.shutdownRoutesNow(DefaultShutdownStrategy.java:310)
at
org.apache.camel.impl.DefaultShutdownStrategy.doShutdown(DefaultShutdownStrategy.java:204)
at
org.apache.camel.impl.DefaultShutdownStrategy.shutdownForced(DefaultShutdownStrategy.java:131)
at
org.apache.camel.impl.DefaultCamelContext.doStop(DefaultCamelContext.java:1753)
- locked 0x00079b1cb208 (a
org.apache.camel.blueprint.BlueprintCamelContext)
at
org.apache.camel.support.ServiceSupport.stop(ServiceSupport.java:102)
at
org.apache.camel.blueprint.BlueprintCamelContext.destroy(BlueprintCamelContext.java:119)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:297)
at
org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:958)
at
org.apache.aries.blueprint.container.BeanRecipe.destroy(BeanRecipe.java:863)
at
org.apache.aries.blueprint.container.BlueprintRepository.destroy(BlueprintRepository.java:320)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.destroyComponents(BlueprintContainerImpl.java:722)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.tidyupComponents(BlueprintContainerImpl.java:916)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.destroy(BlueprintContainerImpl.java:866)
at
org.apache.aries.blueprint.container.BlueprintExtender$3.run(BlueprintExtender.java:301)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
org.apache.aries.blueprint.container.BlueprintExtender.destroyContainer(BlueprintExtender.java:322)
at
org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:218)
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)
at
[jira] [Commented] (CAMEL-7623) Camel is blocked while trying to shutdown a JMS consumer
[
https://issues.apache.org/jira/browse/CAMEL-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070047#comment-14070047
]
Claus Ibsen commented on CAMEL-7623:
And if you are using any kind of connection pooling then make sure to stop
those too as documented here
http://camel.apache.org/activemq
Camel is blocked while trying to shutdown a JMS consumer
Key: CAMEL-7623
URL: https://issues.apache.org/jira/browse/CAMEL-7623
Project: Camel
Issue Type: Bug
Components: camel-jms
Affects Versions: 2.12.3
Environment: Karaf 2.3.4, Camel 2.12.3, spring-jms 3.2.5.RELEASE
Reporter: Martin Lichtin
Assignee: Claus Ibsen
Camel is blocked while trying to shutdown a JMS consumer.
{noformat}
FelixStartLevel daemon prio=10 tid=0x2aaab03d2000 nid=0x6803 in
Object.wait() [0x405cd000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0x00079b473700 (a java.lang.Object)
at java.lang.Object.wait(Object.java:503)
at
org.springframework.jms.listener.DefaultMessageListenerContainer.doShutdown(DefaultMessageListenerContainer.java:545)
- locked 0x00079b473700 (a java.lang.Object)
at
org.springframework.jms.listener.AbstractJmsListeningContainer.shutdown(AbstractJmsListeningContainer.java:233)
at
org.springframework.jms.listener.AbstractJmsListeningContainer.destroy(AbstractJmsListeningContainer.java:173)
at
org.apache.camel.component.jms.DefaultJmsMessageListenerContainer.destroy(DefaultJmsMessageListenerContainer.java:100)
at
org.apache.camel.component.jms.JmsConsumer.stopAndDestroyListenerContainer(JmsConsumer.java:179)
at
org.apache.camel.component.jms.JmsConsumer.doStop(JmsConsumer.java:217)
at
org.apache.camel.support.ServiceSupport.stop(ServiceSupport.java:102)
at
org.apache.camel.util.ServiceHelper.stopService(ServiceHelper.java:141)
at
org.apache.camel.impl.DefaultShutdownStrategy.shutdownNow(DefaultShutdownStrategy.java:336)
at
org.apache.camel.impl.DefaultShutdownStrategy.shutdownRoutesNow(DefaultShutdownStrategy.java:310)
at
org.apache.camel.impl.DefaultShutdownStrategy.doShutdown(DefaultShutdownStrategy.java:204)
at
org.apache.camel.impl.DefaultShutdownStrategy.shutdownForced(DefaultShutdownStrategy.java:131)
at
org.apache.camel.impl.DefaultCamelContext.doStop(DefaultCamelContext.java:1753)
- locked 0x00079b1cb208 (a
org.apache.camel.blueprint.BlueprintCamelContext)
at
org.apache.camel.support.ServiceSupport.stop(ServiceSupport.java:102)
at
org.apache.camel.blueprint.BlueprintCamelContext.destroy(BlueprintCamelContext.java:119)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:297)
at
org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:958)
at
org.apache.aries.blueprint.container.BeanRecipe.destroy(BeanRecipe.java:863)
at
org.apache.aries.blueprint.container.BlueprintRepository.destroy(BlueprintRepository.java:320)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.destroyComponents(BlueprintContainerImpl.java:722)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.tidyupComponents(BlueprintContainerImpl.java:916)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.destroy(BlueprintContainerImpl.java:866)
at
org.apache.aries.blueprint.container.BlueprintExtender$3.run(BlueprintExtender.java:301)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
org.apache.aries.blueprint.container.BlueprintExtender.destroyContainer(BlueprintExtender.java:322)
at
org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:218)
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)
at
[jira] [Reopened] (CAMEL-7623) Camel is blocked while trying to shutdown a JMS consumer
[
https://issues.apache.org/jira/browse/CAMEL-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Lichtin reopened CAMEL-7623:
---
Sorry this wasn't clear, but the thread is in this state since an hour. Async
shutdown wouldn't help, afaics.
Camel is blocked while trying to shutdown a JMS consumer
Key: CAMEL-7623
URL: https://issues.apache.org/jira/browse/CAMEL-7623
Project: Camel
Issue Type: Bug
Components: camel-jms
Affects Versions: 2.12.3
Environment: Karaf 2.3.4, Camel 2.12.3, spring-jms 3.2.5.RELEASE
Reporter: Martin Lichtin
Assignee: Claus Ibsen
Camel is blocked while trying to shutdown a JMS consumer.
{noformat}
FelixStartLevel daemon prio=10 tid=0x2aaab03d2000 nid=0x6803 in
Object.wait() [0x405cd000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0x00079b473700 (a java.lang.Object)
at java.lang.Object.wait(Object.java:503)
at
org.springframework.jms.listener.DefaultMessageListenerContainer.doShutdown(DefaultMessageListenerContainer.java:545)
- locked 0x00079b473700 (a java.lang.Object)
at
org.springframework.jms.listener.AbstractJmsListeningContainer.shutdown(AbstractJmsListeningContainer.java:233)
at
org.springframework.jms.listener.AbstractJmsListeningContainer.destroy(AbstractJmsListeningContainer.java:173)
at
org.apache.camel.component.jms.DefaultJmsMessageListenerContainer.destroy(DefaultJmsMessageListenerContainer.java:100)
at
org.apache.camel.component.jms.JmsConsumer.stopAndDestroyListenerContainer(JmsConsumer.java:179)
at
org.apache.camel.component.jms.JmsConsumer.doStop(JmsConsumer.java:217)
at
org.apache.camel.support.ServiceSupport.stop(ServiceSupport.java:102)
at
org.apache.camel.util.ServiceHelper.stopService(ServiceHelper.java:141)
at
org.apache.camel.impl.DefaultShutdownStrategy.shutdownNow(DefaultShutdownStrategy.java:336)
at
org.apache.camel.impl.DefaultShutdownStrategy.shutdownRoutesNow(DefaultShutdownStrategy.java:310)
at
org.apache.camel.impl.DefaultShutdownStrategy.doShutdown(DefaultShutdownStrategy.java:204)
at
org.apache.camel.impl.DefaultShutdownStrategy.shutdownForced(DefaultShutdownStrategy.java:131)
at
org.apache.camel.impl.DefaultCamelContext.doStop(DefaultCamelContext.java:1753)
- locked 0x00079b1cb208 (a
org.apache.camel.blueprint.BlueprintCamelContext)
at
org.apache.camel.support.ServiceSupport.stop(ServiceSupport.java:102)
at
org.apache.camel.blueprint.BlueprintCamelContext.destroy(BlueprintCamelContext.java:119)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:297)
at
org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:958)
at
org.apache.aries.blueprint.container.BeanRecipe.destroy(BeanRecipe.java:863)
at
org.apache.aries.blueprint.container.BlueprintRepository.destroy(BlueprintRepository.java:320)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.destroyComponents(BlueprintContainerImpl.java:722)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.tidyupComponents(BlueprintContainerImpl.java:916)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.destroy(BlueprintContainerImpl.java:866)
at
org.apache.aries.blueprint.container.BlueprintExtender$3.run(BlueprintExtender.java:301)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
org.apache.aries.blueprint.container.BlueprintExtender.destroyContainer(BlueprintExtender.java:322)
at
org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:218)
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)
at
[jira] [Commented] (CAMEL-7623) Camel is blocked while trying to shutdown a JMS consumer
[
https://issues.apache.org/jira/browse/CAMEL-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070049#comment-14070049
]
Claus Ibsen commented on CAMEL-7623:
And use the mailing list / user forum first to get help
Camel is blocked while trying to shutdown a JMS consumer
Key: CAMEL-7623
URL: https://issues.apache.org/jira/browse/CAMEL-7623
Project: Camel
Issue Type: Bug
Components: camel-jms
Affects Versions: 2.12.3
Environment: Karaf 2.3.4, Camel 2.12.3, spring-jms 3.2.5.RELEASE
Reporter: Martin Lichtin
Assignee: Claus Ibsen
Camel is blocked while trying to shutdown a JMS consumer.
{noformat}
FelixStartLevel daemon prio=10 tid=0x2aaab03d2000 nid=0x6803 in
Object.wait() [0x405cd000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0x00079b473700 (a java.lang.Object)
at java.lang.Object.wait(Object.java:503)
at
org.springframework.jms.listener.DefaultMessageListenerContainer.doShutdown(DefaultMessageListenerContainer.java:545)
- locked 0x00079b473700 (a java.lang.Object)
at
org.springframework.jms.listener.AbstractJmsListeningContainer.shutdown(AbstractJmsListeningContainer.java:233)
at
org.springframework.jms.listener.AbstractJmsListeningContainer.destroy(AbstractJmsListeningContainer.java:173)
at
org.apache.camel.component.jms.DefaultJmsMessageListenerContainer.destroy(DefaultJmsMessageListenerContainer.java:100)
at
org.apache.camel.component.jms.JmsConsumer.stopAndDestroyListenerContainer(JmsConsumer.java:179)
at
org.apache.camel.component.jms.JmsConsumer.doStop(JmsConsumer.java:217)
at
org.apache.camel.support.ServiceSupport.stop(ServiceSupport.java:102)
at
org.apache.camel.util.ServiceHelper.stopService(ServiceHelper.java:141)
at
org.apache.camel.impl.DefaultShutdownStrategy.shutdownNow(DefaultShutdownStrategy.java:336)
at
org.apache.camel.impl.DefaultShutdownStrategy.shutdownRoutesNow(DefaultShutdownStrategy.java:310)
at
org.apache.camel.impl.DefaultShutdownStrategy.doShutdown(DefaultShutdownStrategy.java:204)
at
org.apache.camel.impl.DefaultShutdownStrategy.shutdownForced(DefaultShutdownStrategy.java:131)
at
org.apache.camel.impl.DefaultCamelContext.doStop(DefaultCamelContext.java:1753)
- locked 0x00079b1cb208 (a
org.apache.camel.blueprint.BlueprintCamelContext)
at
org.apache.camel.support.ServiceSupport.stop(ServiceSupport.java:102)
at
org.apache.camel.blueprint.BlueprintCamelContext.destroy(BlueprintCamelContext.java:119)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:297)
at
org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:958)
at
org.apache.aries.blueprint.container.BeanRecipe.destroy(BeanRecipe.java:863)
at
org.apache.aries.blueprint.container.BlueprintRepository.destroy(BlueprintRepository.java:320)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.destroyComponents(BlueprintContainerImpl.java:722)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.tidyupComponents(BlueprintContainerImpl.java:916)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.destroy(BlueprintContainerImpl.java:866)
at
org.apache.aries.blueprint.container.BlueprintExtender$3.run(BlueprintExtender.java:301)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
org.apache.aries.blueprint.container.BlueprintExtender.destroyContainer(BlueprintExtender.java:322)
at
org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:218)
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)
at
[jira] [Commented] (CAMEL-7623) Camel is blocked while trying to shutdown a JMS consumer
[
https://issues.apache.org/jira/browse/CAMEL-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070048#comment-14070048
]
Claus Ibsen commented on CAMEL-7623:
Still its not a Camel problem if something is holding that up and you do not
shutdown those resources correctly.
Camel is blocked while trying to shutdown a JMS consumer
Key: CAMEL-7623
URL: https://issues.apache.org/jira/browse/CAMEL-7623
Project: Camel
Issue Type: Bug
Components: camel-jms
Affects Versions: 2.12.3
Environment: Karaf 2.3.4, Camel 2.12.3, spring-jms 3.2.5.RELEASE
Reporter: Martin Lichtin
Assignee: Claus Ibsen
Camel is blocked while trying to shutdown a JMS consumer.
{noformat}
FelixStartLevel daemon prio=10 tid=0x2aaab03d2000 nid=0x6803 in
Object.wait() [0x405cd000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0x00079b473700 (a java.lang.Object)
at java.lang.Object.wait(Object.java:503)
at
org.springframework.jms.listener.DefaultMessageListenerContainer.doShutdown(DefaultMessageListenerContainer.java:545)
- locked 0x00079b473700 (a java.lang.Object)
at
org.springframework.jms.listener.AbstractJmsListeningContainer.shutdown(AbstractJmsListeningContainer.java:233)
at
org.springframework.jms.listener.AbstractJmsListeningContainer.destroy(AbstractJmsListeningContainer.java:173)
at
org.apache.camel.component.jms.DefaultJmsMessageListenerContainer.destroy(DefaultJmsMessageListenerContainer.java:100)
at
org.apache.camel.component.jms.JmsConsumer.stopAndDestroyListenerContainer(JmsConsumer.java:179)
at
org.apache.camel.component.jms.JmsConsumer.doStop(JmsConsumer.java:217)
at
org.apache.camel.support.ServiceSupport.stop(ServiceSupport.java:102)
at
org.apache.camel.util.ServiceHelper.stopService(ServiceHelper.java:141)
at
org.apache.camel.impl.DefaultShutdownStrategy.shutdownNow(DefaultShutdownStrategy.java:336)
at
org.apache.camel.impl.DefaultShutdownStrategy.shutdownRoutesNow(DefaultShutdownStrategy.java:310)
at
org.apache.camel.impl.DefaultShutdownStrategy.doShutdown(DefaultShutdownStrategy.java:204)
at
org.apache.camel.impl.DefaultShutdownStrategy.shutdownForced(DefaultShutdownStrategy.java:131)
at
org.apache.camel.impl.DefaultCamelContext.doStop(DefaultCamelContext.java:1753)
- locked 0x00079b1cb208 (a
org.apache.camel.blueprint.BlueprintCamelContext)
at
org.apache.camel.support.ServiceSupport.stop(ServiceSupport.java:102)
at
org.apache.camel.blueprint.BlueprintCamelContext.destroy(BlueprintCamelContext.java:119)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:297)
at
org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:958)
at
org.apache.aries.blueprint.container.BeanRecipe.destroy(BeanRecipe.java:863)
at
org.apache.aries.blueprint.container.BlueprintRepository.destroy(BlueprintRepository.java:320)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.destroyComponents(BlueprintContainerImpl.java:722)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.tidyupComponents(BlueprintContainerImpl.java:916)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.destroy(BlueprintContainerImpl.java:866)
at
org.apache.aries.blueprint.container.BlueprintExtender$3.run(BlueprintExtender.java:301)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
org.apache.aries.blueprint.container.BlueprintExtender.destroyContainer(BlueprintExtender.java:322)
at
org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:218)
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)
at
[jira] [Resolved] (CAMEL-7622) advice-with - No outputs found matching id when upgrading from 2.13 to 2.14
[
https://issues.apache.org/jira/browse/CAMEL-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-7622.
Resolution: Fixed
Thanks for the sample code. It passes now on my laptop
advice-with - No outputs found matching id when upgrading from 2.13 to 2.14
---
Key: CAMEL-7622
URL: https://issues.apache.org/jira/browse/CAMEL-7622
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.14.0
Reporter: Matt Raible
Assignee: Claus Ibsen
Fix For: 2.14.0
Attachments: outputnotfound.zip
I have the following route defined with the Java DSL:
from(direct:localMemberLookup).routeId(localMemberLookup)
.process(new MemberLookupToSqlParametersProcessor()).id(sqlParams)
.recipientList(simple(sql:{{sql.memberLookup}})).delimiter(false)
.to(log:output)
.process(new MemberLookupProcessor())
// do more processing
.to(log:output);
I'm testing it with a test that looks as follows:
@EndpointInject(uri = mock:lookupHeaders)
MockEndpoint lookupHeaders;
@EndpointInject(uri = mock:searchResult)
MockEndpoint searchResult;
@EndpointInject(uri = mock:lookupResult)
MockEndpoint lookupResult;
@Autowired
CamelContext camelContext;
@Before
public void before() throws Exception {
ModelCamelContext context = (ModelCamelContext) camelContext;
context.setTracing(true);
RouteDefinition searchRoute =
context.getRouteDefinition(memberSearchRequest);
searchRoute.to(searchResult);
RouteDefinition lookupRoute =
context.getRouteDefinition(localMemberLookup);
lookupRoute.adviceWith(context, new AdviceWithRouteBuilder() {
@Override
public void configure() throws Exception {
weaveById(sqlParams).after().to(lookupHeaders);
}
});
lookupRoute.to(lookupResult);
context.start();
}
With Camel 2.13.1, this works fine. However, with 2.14-SNAPSHOT, I get the
following error:
java.lang.IllegalArgumentException: There are no outputs which matches:
sqlParams in the route
Mailing list thread:
http://camel.465427.n5.nabble.com/weaveById-works-with-2-13-1-not-with-2-14-SNAPSHOT-td5753809.html
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (CAMEL-7623) Camel is blocked while trying to shutdown a JMS consumer
[
https://issues.apache.org/jira/browse/CAMEL-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-7623.
Resolution: Not a Problem
Camel is blocked while trying to shutdown a JMS consumer
Key: CAMEL-7623
URL: https://issues.apache.org/jira/browse/CAMEL-7623
Project: Camel
Issue Type: Bug
Components: camel-jms
Affects Versions: 2.12.3
Environment: Karaf 2.3.4, Camel 2.12.3, spring-jms 3.2.5.RELEASE
Reporter: Martin Lichtin
Assignee: Claus Ibsen
Camel is blocked while trying to shutdown a JMS consumer.
{noformat}
FelixStartLevel daemon prio=10 tid=0x2aaab03d2000 nid=0x6803 in
Object.wait() [0x405cd000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0x00079b473700 (a java.lang.Object)
at java.lang.Object.wait(Object.java:503)
at
org.springframework.jms.listener.DefaultMessageListenerContainer.doShutdown(DefaultMessageListenerContainer.java:545)
- locked 0x00079b473700 (a java.lang.Object)
at
org.springframework.jms.listener.AbstractJmsListeningContainer.shutdown(AbstractJmsListeningContainer.java:233)
at
org.springframework.jms.listener.AbstractJmsListeningContainer.destroy(AbstractJmsListeningContainer.java:173)
at
org.apache.camel.component.jms.DefaultJmsMessageListenerContainer.destroy(DefaultJmsMessageListenerContainer.java:100)
at
org.apache.camel.component.jms.JmsConsumer.stopAndDestroyListenerContainer(JmsConsumer.java:179)
at
org.apache.camel.component.jms.JmsConsumer.doStop(JmsConsumer.java:217)
at
org.apache.camel.support.ServiceSupport.stop(ServiceSupport.java:102)
at
org.apache.camel.util.ServiceHelper.stopService(ServiceHelper.java:141)
at
org.apache.camel.impl.DefaultShutdownStrategy.shutdownNow(DefaultShutdownStrategy.java:336)
at
org.apache.camel.impl.DefaultShutdownStrategy.shutdownRoutesNow(DefaultShutdownStrategy.java:310)
at
org.apache.camel.impl.DefaultShutdownStrategy.doShutdown(DefaultShutdownStrategy.java:204)
at
org.apache.camel.impl.DefaultShutdownStrategy.shutdownForced(DefaultShutdownStrategy.java:131)
at
org.apache.camel.impl.DefaultCamelContext.doStop(DefaultCamelContext.java:1753)
- locked 0x00079b1cb208 (a
org.apache.camel.blueprint.BlueprintCamelContext)
at
org.apache.camel.support.ServiceSupport.stop(ServiceSupport.java:102)
at
org.apache.camel.blueprint.BlueprintCamelContext.destroy(BlueprintCamelContext.java:119)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:297)
at
org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:958)
at
org.apache.aries.blueprint.container.BeanRecipe.destroy(BeanRecipe.java:863)
at
org.apache.aries.blueprint.container.BlueprintRepository.destroy(BlueprintRepository.java:320)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.destroyComponents(BlueprintContainerImpl.java:722)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.tidyupComponents(BlueprintContainerImpl.java:916)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.destroy(BlueprintContainerImpl.java:866)
at
org.apache.aries.blueprint.container.BlueprintExtender$3.run(BlueprintExtender.java:301)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
org.apache.aries.blueprint.container.BlueprintExtender.destroyContainer(BlueprintExtender.java:322)
at
org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:218)
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)
at
[jira] [Assigned] (CAMEL-7618) Enhancement for xmlsecurity Component: Detached XML Signatures
[ https://issues.apache.org/jira/browse/CAMEL-7618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-7618: -- Assignee: Claus Ibsen Enhancement for xmlsecurity Component: Detached XML Signatures -- Key: CAMEL-7618 URL: https://issues.apache.org/jira/browse/CAMEL-7618 Project: Camel Issue Type: New Feature Components: camel-crypto Reporter: Franz Forsthofer Assignee: Claus Ibsen Fix For: 2.14.0 Attachments: 0001-detached-xml-signatures.patch The current xmlsecurity component supports enveloping and enveloped XML signatures. The attached patch enhances this component so that also detached XML signatures (see specification http://www.w3.org/TR/xmldsig-core/#def-SignatureDetached) can be used. The patch supports the case where the signature is a sibling of the signed element and the signed element is referred by a ID attribute value. Also several signatures within the same XML document (even nested signatures) are supported. For this new functionality, the signer configuration has got two new parameters: # xpathsToIdAttributes xpathes to attributes which are of type ID which define the elements to be signed (for each element to be signed a separate signature is created as a sibling of the element) # schemaResourceUri defines a classpath to the XML schema, the XML schema is needed during the parsing to specify the ID attributes and the verifier configuration has got one new parameter: # schemaResourceUri defines a classpath to the XML schema, the XML schema is needed during the parsing to find the ID attributes Because we allow several signatures within one XML document, the signatures can be nested. In order to produce the correct nested signatures, the signatures are created in a certain order; elements with deeper hierarchy level are signed first. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7618) Enhancement for xmlsecurity Component: Detached XML Signatures
[ https://issues.apache.org/jira/browse/CAMEL-7618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070060#comment-14070060 ] Claus Ibsen commented on CAMEL-7618: Thanks again Franz, the patch has been applied to the 2.14 codebase. You are welcome to update the documentation. Enhancement for xmlsecurity Component: Detached XML Signatures -- Key: CAMEL-7618 URL: https://issues.apache.org/jira/browse/CAMEL-7618 Project: Camel Issue Type: New Feature Components: camel-xmlsecurity Reporter: Franz Forsthofer Assignee: Claus Ibsen Fix For: 2.14.0 Attachments: 0001-detached-xml-signatures.patch The current xmlsecurity component supports enveloping and enveloped XML signatures. The attached patch enhances this component so that also detached XML signatures (see specification http://www.w3.org/TR/xmldsig-core/#def-SignatureDetached) can be used. The patch supports the case where the signature is a sibling of the signed element and the signed element is referred by a ID attribute value. Also several signatures within the same XML document (even nested signatures) are supported. For this new functionality, the signer configuration has got two new parameters: # xpathsToIdAttributes xpathes to attributes which are of type ID which define the elements to be signed (for each element to be signed a separate signature is created as a sibling of the element) # schemaResourceUri defines a classpath to the XML schema, the XML schema is needed during the parsing to specify the ID attributes and the verifier configuration has got one new parameter: # schemaResourceUri defines a classpath to the XML schema, the XML schema is needed during the parsing to find the ID attributes Because we allow several signatures within one XML document, the signatures can be nested. In order to produce the correct nested signatures, the signatures are created in a certain order; elements with deeper hierarchy level are signed first. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CAMEL-7618) Enhancement for xmlsecurity Component: Detached XML Signatures
[ https://issues.apache.org/jira/browse/CAMEL-7618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7618: --- Component/s: (was: camel-crypto) camel-xmlsecurity Enhancement for xmlsecurity Component: Detached XML Signatures -- Key: CAMEL-7618 URL: https://issues.apache.org/jira/browse/CAMEL-7618 Project: Camel Issue Type: New Feature Components: camel-xmlsecurity Reporter: Franz Forsthofer Assignee: Claus Ibsen Fix For: 2.14.0 Attachments: 0001-detached-xml-signatures.patch The current xmlsecurity component supports enveloping and enveloped XML signatures. The attached patch enhances this component so that also detached XML signatures (see specification http://www.w3.org/TR/xmldsig-core/#def-SignatureDetached) can be used. The patch supports the case where the signature is a sibling of the signed element and the signed element is referred by a ID attribute value. Also several signatures within the same XML document (even nested signatures) are supported. For this new functionality, the signer configuration has got two new parameters: # xpathsToIdAttributes xpathes to attributes which are of type ID which define the elements to be signed (for each element to be signed a separate signature is created as a sibling of the element) # schemaResourceUri defines a classpath to the XML schema, the XML schema is needed during the parsing to specify the ID attributes and the verifier configuration has got one new parameter: # schemaResourceUri defines a classpath to the XML schema, the XML schema is needed during the parsing to find the ID attributes Because we allow several signatures within one XML document, the signatures can be nested. In order to produce the correct nested signatures, the signatures are created in a certain order; elements with deeper hierarchy level are signed first. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CAMEL-7624) camel-jackson - Add option to set inclusion to skip null fields from pojos
Claus Ibsen created CAMEL-7624: -- Summary: camel-jackson - Add option to set inclusion to skip null fields from pojos Key: CAMEL-7624 URL: https://issues.apache.org/jira/browse/CAMEL-7624 Project: Camel Issue Type: Improvement Components: camel-jackson Reporter: Claus Ibsen Assignee: Claus Ibsen Priority: Minor Fix For: 2.14.0 It takes a bit to configure jackson to skip null fields from pojos. You can annote your pojos but then they have jackson annotations on their classpath. But we need an option on json dataformat in camel, so you can configure that option. Some details at http://stackoverflow.com/questions/11449211/how-to-prevent-null-values-inside-a-map-and-null-fields-inside-a-bean-from-getti -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CAMEL-7624) camel-jackson - Add option to set inclusion to skip null fields from pojos
[ https://issues.apache.org/jira/browse/CAMEL-7624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-7624. Resolution: Fixed Fix Version/s: 2.13.3 camel-jackson - Add option to set inclusion to skip null fields from pojos -- Key: CAMEL-7624 URL: https://issues.apache.org/jira/browse/CAMEL-7624 Project: Camel Issue Type: Improvement Components: camel-jackson Reporter: Claus Ibsen Assignee: Claus Ibsen Priority: Minor Fix For: 2.13.3, 2.14.0 It takes a bit to configure jackson to skip null fields from pojos. You can annote your pojos but then they have jackson annotations on their classpath. But we need an option on json dataformat in camel, so you can configure that option. Some details at http://stackoverflow.com/questions/11449211/how-to-prevent-null-values-inside-a-map-and-null-fields-inside-a-bean-from-getti -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7624) camel-jackson - Add option to set inclusion to skip null fields from pojos
[ https://issues.apache.org/jira/browse/CAMEL-7624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070096#comment-14070096 ] Claus Ibsen commented on CAMEL-7624: There is an include option that can be configured now to NOT_NULL camel-jackson - Add option to set inclusion to skip null fields from pojos -- Key: CAMEL-7624 URL: https://issues.apache.org/jira/browse/CAMEL-7624 Project: Camel Issue Type: Improvement Components: camel-jackson Reporter: Claus Ibsen Assignee: Claus Ibsen Priority: Minor Fix For: 2.13.3, 2.14.0 It takes a bit to configure jackson to skip null fields from pojos. You can annote your pojos but then they have jackson annotations on their classpath. But we need an option on json dataformat in camel, so you can configure that option. Some details at http://stackoverflow.com/questions/11449211/how-to-prevent-null-values-inside-a-map-and-null-fields-inside-a-bean-from-getti -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7606) Expose the component options for Camel Zookeeper
[ https://issues.apache.org/jira/browse/CAMEL-7606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070321#comment-14070321 ] ASF GitHub Bot commented on CAMEL-7606: --- GitHub user kevinearls opened a pull request: https://github.com/apache/camel/pull/225 Fix for CAMEL-7606 Expose the component options for Camel Zookeeper You can merge this pull request into a Git repository by running: $ git pull https://github.com/kevinearls/camel CAMEL-7606 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/225.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #225 commit 041e8e9e8d22941a548c0d7481af1285a93e0eb7 Author: Kevin Earls ke...@kevinearls.com Date: 2014-07-22T14:30:06Z Fix for CAMEL-7606 Expose the component options for Camel Zookeeper Expose the component options for Camel Zookeeper Key: CAMEL-7606 URL: https://issues.apache.org/jira/browse/CAMEL-7606 Project: Camel Issue Type: Improvement Components: camel-zookeeper Reporter: Kevin Earls Priority: Minor Expose the component options for the Camel Zookeeper component as has already been done for camel-core components and selected others such as jms / ftp / twitter etc. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CAMEL-7625) Expose the component options for Camel Dropbox
Kevin Earls created CAMEL-7625: -- Summary: Expose the component options for Camel Dropbox Key: CAMEL-7625 URL: https://issues.apache.org/jira/browse/CAMEL-7625 Project: Camel Issue Type: Improvement Reporter: Kevin Earls Priority: Minor Expose the component options for the Camel Dropbox component, as has already been done for camel-core components and selected others such as jms / ftp / twitter etc. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CAMEL-7626) camel-restlet - Should set content-type header
Claus Ibsen created CAMEL-7626: -- Summary: camel-restlet - Should set content-type header Key: CAMEL-7626 URL: https://issues.apache.org/jira/browse/CAMEL-7626 Project: Camel Issue Type: Improvement Components: camel-restlet Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.14.0 So we know the content-type if it was provided in the HTTP request -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CAMEL-7626) camel-restlet - Should set content-type header
[ https://issues.apache.org/jira/browse/CAMEL-7626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-7626. Resolution: Fixed camel-restlet - Should set content-type header -- Key: CAMEL-7626 URL: https://issues.apache.org/jira/browse/CAMEL-7626 Project: Camel Issue Type: Improvement Components: camel-restlet Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.14.0 So we know the content-type if it was provided in the HTTP request -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CAMEL-7627) Quartz/Quartz2 in cluster mode doesn't apply changed trigger settings
Nikolay Turpitko created CAMEL-7627: --- Summary: Quartz/Quartz2 in cluster mode doesn't apply changed trigger settings Key: CAMEL-7627 URL: https://issues.apache.org/jira/browse/CAMEL-7627 Project: Camel Issue Type: Bug Components: camel-quartz, camel-quartz2 Affects Versions: 2.13.2, 2.14.0 Reporter: Nikolay Turpitko When quartz/quartz2 component used in cluster mode with JDBCJobStore it stores trigger settings (cron expression or simple trigger repeat interval and repeat count) provided in component's URI in DB. When application next time, it uses stored values from DB and ignores possibly changed ones from URI. It is inconvenient in production environment to alter values in database every time we deploy new version of application with changed schedule. Especially, when we have bunch of clustered timers in several application modules, using same DB. Desirable behavior is to check trigger settings in DB and reschedule quartz job when they changed. I created a patch with unit test to illustrate this issue. Test prepares DB, than creates application context twice with different cron expressions in configuration xml. Both times it retrieves back the cron expression, accessing it via trigger (so, using value stored in DB). After that it asserts that two cron expressions are not equal. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CAMEL-7627) Quartz/Quartz2 in cluster mode doesn't apply changed trigger settings
[ https://issues.apache.org/jira/browse/CAMEL-7627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Turpitko updated CAMEL-7627: Attachment: 0001-fix-reshedule-quartz.patch Here is a patch for quartz2 component. I assume, that similar issue exists in quartz component as well. At least, source code looks similar. But, honestly, I have not tested it yet. Quartz/Quartz2 in cluster mode doesn't apply changed trigger settings - Key: CAMEL-7627 URL: https://issues.apache.org/jira/browse/CAMEL-7627 Project: Camel Issue Type: Bug Components: camel-quartz, camel-quartz2 Affects Versions: 2.13.2, 2.14.0 Reporter: Nikolay Turpitko Attachments: 0001-fix-reshedule-quartz.patch When quartz/quartz2 component used in cluster mode with JDBCJobStore it stores trigger settings (cron expression or simple trigger repeat interval and repeat count) provided in component's URI in DB. When application next time, it uses stored values from DB and ignores possibly changed ones from URI. It is inconvenient in production environment to alter values in database every time we deploy new version of application with changed schedule. Especially, when we have bunch of clustered timers in several application modules, using same DB. Desirable behavior is to check trigger settings in DB and reschedule quartz job when they changed. I created a patch with unit test to illustrate this issue. Test prepares DB, than creates application context twice with different cron expressions in configuration xml. Both times it retrieves back the cron expression, accessing it via trigger (so, using value stored in DB). After that it asserts that two cron expressions are not equal. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7619) Rest DSL - Add support for json/xml bindings
[
https://issues.apache.org/jira/browse/CAMEL-7619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070505#comment-14070505
]
Claus Ibsen commented on CAMEL-7619:
Got the first prototype that can map json/xml to a pojo using the rest dsl
defined as
{code}
// use the rest DSL to define the rest services
rest(/users/)
.post(new).as(UserPojo.class)
.to(mock:input);
{code}
Notice the as in the route. May come up with a better name.
The current code checks the content-type and message body to see if its json or
xml and maps accordingly using jackson. Though we may allow users to configure
this behavior so they can control if it should always be json only or xml only
etc.
Rest DSL - Add support for json/xml bindings
Key: CAMEL-7619
URL: https://issues.apache.org/jira/browse/CAMEL-7619
Project: Camel
Issue Type: Sub-task
Components: camel-core
Affects Versions: 2.14.0
Reporter: Claus Ibsen
Assignee: Claus Ibsen
Fix For: 2.14.0
see parent ticket
So we can plugin json bindings such as jackson etc.
And for xml, we can plugin jaxb etc.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CAMEL-7627) Quartz/Quartz2 in cluster mode doesn't apply changed trigger settings
[ https://issues.apache.org/jira/browse/CAMEL-7627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Turpitko updated CAMEL-7627: Description: When quartz/quartz2 component used in cluster mode with JDBCJobStore it gets trigger settings (cron expression or simple trigger repeat interval and repeat count) provided in component's URI and stores them into DB. When application runs next time, it uses stored values from DB and ignores (possibly changed) ones from URI. It is inconvenient in production environment to alter values in database every time we deploy a new version of the application with changed schedule. Especially, when we have bunch of clustered timers in several application modules, using same DB. Desirable behavior is to check trigger settings in DB and reschedule quartz job when they changed. I created a patch with unit test to illustrate this issue. The test prepares DB, than creates application context twice with different cron expressions in configuration xml. Both times it retrieves back the cron expression, accessing it via trigger (so, using value stored in DB). After that it asserts that two cron expressions are not equal. was: When quartz/quartz2 component used in cluster mode with JDBCJobStore it stores trigger settings (cron expression or simple trigger repeat interval and repeat count) provided in component's URI in DB. When application next time, it uses stored values from DB and ignores possibly changed ones from URI. It is inconvenient in production environment to alter values in database every time we deploy new version of application with changed schedule. Especially, when we have bunch of clustered timers in several application modules, using same DB. Desirable behavior is to check trigger settings in DB and reschedule quartz job when they changed. I created a patch with unit test to illustrate this issue. Test prepares DB, than creates application context twice with different cron expressions in configuration xml. Both times it retrieves back the cron expression, accessing it via trigger (so, using value stored in DB). After that it asserts that two cron expressions are not equal. Quartz/Quartz2 in cluster mode doesn't apply changed trigger settings - Key: CAMEL-7627 URL: https://issues.apache.org/jira/browse/CAMEL-7627 Project: Camel Issue Type: Bug Components: camel-quartz, camel-quartz2 Affects Versions: 2.13.2, 2.14.0 Reporter: Nikolay Turpitko Attachments: 0001-fix-reshedule-quartz.patch When quartz/quartz2 component used in cluster mode with JDBCJobStore it gets trigger settings (cron expression or simple trigger repeat interval and repeat count) provided in component's URI and stores them into DB. When application runs next time, it uses stored values from DB and ignores (possibly changed) ones from URI. It is inconvenient in production environment to alter values in database every time we deploy a new version of the application with changed schedule. Especially, when we have bunch of clustered timers in several application modules, using same DB. Desirable behavior is to check trigger settings in DB and reschedule quartz job when they changed. I created a patch with unit test to illustrate this issue. The test prepares DB, than creates application context twice with different cron expressions in configuration xml. Both times it retrieves back the cron expression, accessing it via trigger (so, using value stored in DB). After that it asserts that two cron expressions are not equal. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CAMEL-7628) Incorrect test of quartz2 component
Nikolay Turpitko created CAMEL-7628: --- Summary: Incorrect test of quartz2 component Key: CAMEL-7628 URL: https://issues.apache.org/jira/browse/CAMEL-7628 Project: Camel Issue Type: Bug Components: camel-quartz2 Affects Versions: 2.14.0 Reporter: Nikolay Turpitko There is, probably, incorrect test of quartz2 component: org.apache.camel.component.quartz2.SpringQuartzPersistentStoreTest. And, there are, seemingly, similar issues in some other tests with persistent store. Mentioned test used spring context xml from org/apache/camel/component/quartz2/SpringQuartzPersistentStoreTest.xml. There are several issues I suspect in it: 1. File describes jdbc:embedded-database but used ref to it in dataSource property of scheduler. Other tests create intermediate bean of the type BasicDataSource (for example, in org/apache/camel/component/quartz2/SpringQuartzConsumerClusteredAppOne.xml). 2. Even is first point is correct, scheduler further passed to bean with id quartz, but in endpoint's uri in route used bean with id quartz2. I'm afraid, this test ignores database at all. 3. Moreover, in this and some other tests, there is no property org.quartz.jobStore.class in the list of quartz properties, and here: http://www.ibm.com/developerworks/library/j-quartz/ I found that default setting is RAMJobStore. Which means, that DB is ignored once again. I'm not absolutely sure about whether these are issues in particular context or not, but when I tried to create similar test on my own, based on SpringQuartzPersistentStoreTest, behavior was as if DB was ignored. Only when I fixed my test's context as in SpringQuartzConsumerClusteredAppOne (and added prop key=org.quartz.jobStore.classorg.quartz.impl.jdbcjobstore.JobStoreTX/prop) it worked as expected. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CAMEL-7629) camel-jackson - Add support for header to define the unmarshalType dynamic
Claus Ibsen created CAMEL-7629: -- Summary: camel-jackson - Add support for header to define the unmarshalType dynamic Key: CAMEL-7629 URL: https://issues.apache.org/jira/browse/CAMEL-7629 Project: Camel Issue Type: Improvement Components: camel-jackson Reporter: Claus Ibsen Assignee: Claus Ibsen Priority: Minor Fix For: 2.14.0 Today you can define a fixed unmarshalType on the data format. But that becomes fixed. There may be cases where you want to provide that as a header to be more dynamic. For example the JMSType is a JMS spec header to tell the java class type. So we could support that. And also a CamelJsonType header so people can set that also. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CAMEL-7629) camel-jackson - Add support for header to define the unmarshalType dynamic
[ https://issues.apache.org/jira/browse/CAMEL-7629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-7629. Resolution: Fixed There is a header now that can tell jackson which class to unmarshal as. Also added support for JMSType but you need to turn that on if you want to use that too. camel-jackson - Add support for header to define the unmarshalType dynamic -- Key: CAMEL-7629 URL: https://issues.apache.org/jira/browse/CAMEL-7629 Project: Camel Issue Type: Improvement Components: camel-jackson Reporter: Claus Ibsen Assignee: Claus Ibsen Priority: Minor Fix For: 2.14.0 Today you can define a fixed unmarshalType on the data format. But that becomes fixed. There may be cases where you want to provide that as a header to be more dynamic. For example the JMSType is a JMS spec header to tell the java class type. So we could support that. And also a CamelJsonType header so people can set that also. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CAMEL-7619) Rest DSL - Add support for json/xml bindings
[
https://issues.apache.org/jira/browse/CAMEL-7619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070505#comment-14070505
]
Claus Ibsen edited comment on CAMEL-7619 at 7/22/14 7:05 PM:
-
Got the first prototype that can map json/xml to a pojo using the rest dsl
defined as
{code}
// use the rest DSL to define the rest services
rest(/users/)
.post(new).type(UserPojo.class)
.to(mock:input);
{code}
Notice the type in the route. May come up with a better name.
The current code checks the content-type and message body to see if its json or
xml and maps accordingly using jackson. Though we may allow users to configure
this behavior so they can control if it should always be json only or xml only
etc.
was (Author: davsclaus):
Got the first prototype that can map json/xml to a pojo using the rest dsl
defined as
{code}
// use the rest DSL to define the rest services
rest(/users/)
.post(new).as(UserPojo.class)
.to(mock:input);
{code}
Notice the as in the route. May come up with a better name.
The current code checks the content-type and message body to see if its json or
xml and maps accordingly using jackson. Though we may allow users to configure
this behavior so they can control if it should always be json only or xml only
etc.
Rest DSL - Add support for json/xml bindings
Key: CAMEL-7619
URL: https://issues.apache.org/jira/browse/CAMEL-7619
Project: Camel
Issue Type: Sub-task
Components: camel-core
Affects Versions: 2.14.0
Reporter: Claus Ibsen
Assignee: Claus Ibsen
Fix For: 2.14.0
see parent ticket
So we can plugin json bindings such as jackson etc.
And for xml, we can plugin jaxb etc.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CAMEL-7613) camel-linkedin-api - Cannot be built with java 8
[
https://issues.apache.org/jira/browse/CAMEL-7613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070995#comment-14070995
]
Dhiraj Bokde commented on CAMEL-7613:
-
Hmm, looks like Java8 Javadoc tool has introduced significant changes to the
generated HTML. Anchor names, formats for links, etc. have been changed, which
break the Javadoc HTML parser in camel-api-component-maven-plugin.
I'll see what I can do to make it work with both pre and post Java8 Javadoc
HTML.
camel-linkedin-api - Cannot be built with java 8
Key: CAMEL-7613
URL: https://issues.apache.org/jira/browse/CAMEL-7613
Project: Camel
Issue Type: Task
Affects Versions: 2.14.0
Reporter: Claus Ibsen
Assignee: Dhiraj Bokde
Fix For: 2.14.0
This is due that insane javadoc default that fails the compiler if there is
javadoc errors.
There is a compiler flag you can use to turn this off.
Got this error
{code}
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 12:42.648s
[INFO] Finished at: Sat Jul 19 08:51:17 CEST 2014
[INFO] Final Memory: 256M/622M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:jar (add-javadoc) on
project camel-linkedin-api: MavenReportException: Error while creating
archive:
[ERROR] Exit code: 1 -
/Users/davsclaus/workspace/camel/components/camel-linkedin/camel-linkedin-api/src/main/java/org/apache/camel/component/linkedin/api/OAuthSecureStorage.java:33:
warning: no description for @param
[ERROR] * @param newToken
[ERROR] ^
[ERROR]
/Users/davsclaus/workspace/camel/components/camel-linkedin/camel-linkedin-api/target/generated-sources/cxf/org/apache/camel/component/linkedin/api/model/Action.java:17:
error: bad use of ''
[ERROR] * lt;complexType
[ERROR] ^
[ERROR]
/Users/davsclaus/workspace/camel/components/camel-linkedin/camel-linkedin-api/target/generated-sources/cxf/org/apache/camel/component/linkedin/api/model/Action.java:18:
error: bad use of ''
[ERROR] * lt;complexContent
[ERROR] ^
[ERROR]
/Users/davsclaus/workspace/camel/components/camel-linkedin/camel-linkedin-api/target/generated-sources/cxf/org/apache/camel/component/linkedin/api/model/Action.java:19:
error: bad use of ''
[ERROR] * lt;restriction
base={http://www.w3.org/2001/XMLSchema}anyType;
[ERROR] ^
[ERROR]
/Users/davsclaus/workspace/camel/components/camel-linkedin/camel-linkedin-api/target/generated-sources/cxf/org/apache/camel/component/linkedin/api/model/Action.java:20:
error: bad use of ''
[ERROR] * lt;sequence
[ERROR] ^
[ERROR]
/Users/davsclaus/workspace/camel/components/camel-linkedin/camel-linkedin-api/target/generated-sources/cxf/org/apache/camel/component/linkedin/api/model/Action.java:21:
error: bad use of ''
[ERROR] * lt;element ref={}code/
[ERROR] ^
[ERROR]
/Users/davsclaus/workspace/camel/components/camel-linkedin/camel-linkedin-api/target/generated-sources/cxf/org/apache/camel/component/linkedin/api/model/Action.java:22:
error: bad use of ''
[ERROR] * lt;/sequence
[ERROR] ^
[ERROR]
/Users/davsclaus/workspace/camel/components/camel-linkedin/camel-linkedin-api/target/generated-sources/cxf/org/apache/camel/component/linkedin/api/model/Action.java:23:
error: bad use of ''
[ERROR] * lt;/restriction
[ERROR] ^
[ERROR]
/Users/davsclaus/workspace/camel/components/camel-linkedin/camel-linkedin-api/target/generated-sources/cxf/org/apache/camel/component/linkedin/api/model/Action.java:24:
error: bad use of ''
[ERROR] * lt;/complexContent
[ERROR] ^
[ERROR]
/Users/davsclaus/workspace/camel/components/camel-linkedin/camel-linkedin-api/target/generated-sources/cxf/org/apache/camel/component/linkedin/api/model/Action.java:25:
error: bad use of ''
[ERROR] * lt;/complexType
[ERROR] ^
[ERROR]
/Users/davsclaus/workspace/camel/components/camel-linkedin/camel-linkedin-api/target/generated-sources/cxf/org/apache/camel/component/linkedin/api/model/Activity.java:22:
error: bad use of ''
[ERROR] * lt;complexType
[ERROR] ^
[ERROR]
/Users/davsclaus/workspace/camel/components/camel-linkedin/camel-linkedin-api/target/generated-sources/cxf/org/apache/camel/component/linkedin/api/model/Activity.java:23:
error: bad use of ''
[ERROR] * lt;complexContent
[ERROR] ^
[ERROR]
/Users/davsclaus/workspace/camel/components/camel-linkedin/camel-linkedin-api/target/generated-sources/cxf/org/apache/camel/component/linkedin/api/model/Activity.java:24:
error: bad use of ''
[ERROR] * lt;restriction
base={http://www.w3.org/2001/XMLSchema}anyType;
