[jira] [Updated] (CAMEL-8541) Came main TestSupport class is incompatible with the CDI specification
[
https://issues.apache.org/jira/browse/CAMEL-8541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-8541:
---
Issue Type: Improvement (was: Bug)
Came main TestSupport class is incompatible with the CDI specification
--
Key: CAMEL-8541
URL: https://issues.apache.org/jira/browse/CAMEL-8541
Project: Camel
Issue Type: Improvement
Components: camel-test
Affects Versions: 2.12.5, 2.14.2
Reporter: Alex Savitsky
JUnit4 test support class (org.apache.camel.test.junit4.TestSupport) contains
the following declaration:
{noformat}
// CHECKSTYLE:OFF
@Rule
public TestName testName = new TestName();
// CHECKSTYLE:ON
{noformat}
In addition to being a terrible idea overall, this public field also breaks
CDI integration, as any tests attempted to be bootstrapped in CDI will throw
the following error (WELD trace is shown for an example):
{noformat}
org.jboss.weld.exceptions.DefinitionException: WELD-75: Normal scoped
managed bean implementation class has a public field:
[EnhancedAnnotatedFieldImpl] @Rule public com.netotc.ha.route.TestCDI.testName
at
org.jboss.weld.bean.ManagedBean.checkBeanImplementation(ManagedBean.java:227)
at
org.jboss.weld.bean.AbstractClassBean.internalInitialize(AbstractClassBean.java:74)
at
org.jboss.weld.bean.ManagedBean.internalInitialize(ManagedBean.java:105)
at org.jboss.weld.bean.RIBean.initialize(RIBean.java:66)
at
org.jboss.weld.bootstrap.ConcurrentBeanDeployer$5.doWork(ConcurrentBeanDeployer.java:121)
at
org.jboss.weld.bootstrap.ConcurrentBeanDeployer$5.doWork(ConcurrentBeanDeployer.java:118)
at
org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
at
org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{noformat}
Suggesting to create a getter for this field, making the field private, and
moving the @Rule annotation to the getter.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8541) Came main TestSupport class is incompatible with the CDI specification
[
https://issues.apache.org/jira/browse/CAMEL-8541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-8541:
---
Priority: Minor (was: Major)
Came main TestSupport class is incompatible with the CDI specification
--
Key: CAMEL-8541
URL: https://issues.apache.org/jira/browse/CAMEL-8541
Project: Camel
Issue Type: Improvement
Components: camel-test
Affects Versions: 2.12.5, 2.14.2
Reporter: Alex Savitsky
Priority: Minor
JUnit4 test support class (org.apache.camel.test.junit4.TestSupport) contains
the following declaration:
{noformat}
// CHECKSTYLE:OFF
@Rule
public TestName testName = new TestName();
// CHECKSTYLE:ON
{noformat}
In addition to being a terrible idea overall, this public field also breaks
CDI integration, as any tests attempted to be bootstrapped in CDI will throw
the following error (WELD trace is shown for an example):
{noformat}
org.jboss.weld.exceptions.DefinitionException: WELD-75: Normal scoped
managed bean implementation class has a public field:
[EnhancedAnnotatedFieldImpl] @Rule public com.netotc.ha.route.TestCDI.testName
at
org.jboss.weld.bean.ManagedBean.checkBeanImplementation(ManagedBean.java:227)
at
org.jboss.weld.bean.AbstractClassBean.internalInitialize(AbstractClassBean.java:74)
at
org.jboss.weld.bean.ManagedBean.internalInitialize(ManagedBean.java:105)
at org.jboss.weld.bean.RIBean.initialize(RIBean.java:66)
at
org.jboss.weld.bootstrap.ConcurrentBeanDeployer$5.doWork(ConcurrentBeanDeployer.java:121)
at
org.jboss.weld.bootstrap.ConcurrentBeanDeployer$5.doWork(ConcurrentBeanDeployer.java:118)
at
org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
at
org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{noformat}
Suggesting to create a getter for this field, making the field private, and
moving the @Rule annotation to the getter.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-8544) Camel - Dynamic router - unsupported cacheSize attribute
[ https://issues.apache.org/jira/browse/CAMEL-8544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CAMEL-8544. - Resolution: Fixed Applied the patch into camel master, camel-2.14.x and camel-2.15.x branches. Camel - Dynamic router - unsupported cacheSize attribute Key: CAMEL-8544 URL: https://issues.apache.org/jira/browse/CAMEL-8544 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.14.2, 2.15.0 Reporter: Willem Jiang Assignee: Willem Jiang Fix For: 2.14.3, 2.15.1, 2.16.0 Dynamic Router pattern does not contain attribute cacheSize but RecipientList and Routing slip already support it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8541) Camel main TestSupport class is incompatible with the CDI specification
[
https://issues.apache.org/jira/browse/CAMEL-8541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-8541.
Resolution: Fixed
Fix Version/s: 2.16.0
2.15.1
2.14.3
Assignee: Claus Ibsen
Thanks for reporting.
Camel main TestSupport class is incompatible with the CDI specification
---
Key: CAMEL-8541
URL: https://issues.apache.org/jira/browse/CAMEL-8541
Project: Camel
Issue Type: Improvement
Components: camel-test
Affects Versions: 2.12.5, 2.14.2
Reporter: Alex Savitsky
Assignee: Claus Ibsen
Priority: Minor
Fix For: 2.14.3, 2.15.1, 2.16.0
JUnit4 test support class (org.apache.camel.test.junit4.TestSupport) contains
the following declaration:
{noformat}
// CHECKSTYLE:OFF
@Rule
public TestName testName = new TestName();
// CHECKSTYLE:ON
{noformat}
In addition to being a terrible idea overall, this public field also breaks
CDI integration, as any tests attempted to be bootstrapped in CDI will throw
the following error (WELD trace is shown for an example):
{noformat}
org.jboss.weld.exceptions.DefinitionException: WELD-75: Normal scoped
managed bean implementation class has a public field:
[EnhancedAnnotatedFieldImpl] @Rule public com.netotc.ha.route.TestCDI.testName
at
org.jboss.weld.bean.ManagedBean.checkBeanImplementation(ManagedBean.java:227)
at
org.jboss.weld.bean.AbstractClassBean.internalInitialize(AbstractClassBean.java:74)
at
org.jboss.weld.bean.ManagedBean.internalInitialize(ManagedBean.java:105)
at org.jboss.weld.bean.RIBean.initialize(RIBean.java:66)
at
org.jboss.weld.bootstrap.ConcurrentBeanDeployer$5.doWork(ConcurrentBeanDeployer.java:121)
at
org.jboss.weld.bootstrap.ConcurrentBeanDeployer$5.doWork(ConcurrentBeanDeployer.java:118)
at
org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
at
org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{noformat}
Suggesting to create a getter for this field, making the field private, and
moving the @Rule annotation to the getter.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8544) Camel - Dynamic router - unsupported cacheSize attribute
[ https://issues.apache.org/jira/browse/CAMEL-8544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-8544: --- Component/s: eip Camel - Dynamic router - unsupported cacheSize attribute Key: CAMEL-8544 URL: https://issues.apache.org/jira/browse/CAMEL-8544 Project: Camel Issue Type: Improvement Components: camel-core, eip Affects Versions: 2.14.2, 2.15.0 Reporter: Willem Jiang Assignee: Willem Jiang Fix For: 2.14.3, 2.15.1, 2.16.0 Dynamic Router pattern does not contain attribute cacheSize but RecipientList and Routing slip already support it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8544) Camel - Dynamic router - unsupported cacheSize attribute
[ https://issues.apache.org/jira/browse/CAMEL-8544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-8544: --- Issue Type: Improvement (was: Bug) Camel - Dynamic router - unsupported cacheSize attribute Key: CAMEL-8544 URL: https://issues.apache.org/jira/browse/CAMEL-8544 Project: Camel Issue Type: Improvement Components: camel-core, eip Affects Versions: 2.14.2, 2.15.0 Reporter: Willem Jiang Assignee: Willem Jiang Fix For: 2.14.3, 2.15.1, 2.16.0 Dynamic Router pattern does not contain attribute cacheSize but RecipientList and Routing slip already support it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8541) Camel main TestSupport class is incompatible with the CDI specification
[
https://issues.apache.org/jira/browse/CAMEL-8541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-8541:
---
Summary: Camel main TestSupport class is incompatible with the CDI
specification (was: Came main TestSupport class is incompatible with the CDI
specification)
Camel main TestSupport class is incompatible with the CDI specification
---
Key: CAMEL-8541
URL: https://issues.apache.org/jira/browse/CAMEL-8541
Project: Camel
Issue Type: Improvement
Components: camel-test
Affects Versions: 2.12.5, 2.14.2
Reporter: Alex Savitsky
Priority: Minor
JUnit4 test support class (org.apache.camel.test.junit4.TestSupport) contains
the following declaration:
{noformat}
// CHECKSTYLE:OFF
@Rule
public TestName testName = new TestName();
// CHECKSTYLE:ON
{noformat}
In addition to being a terrible idea overall, this public field also breaks
CDI integration, as any tests attempted to be bootstrapped in CDI will throw
the following error (WELD trace is shown for an example):
{noformat}
org.jboss.weld.exceptions.DefinitionException: WELD-75: Normal scoped
managed bean implementation class has a public field:
[EnhancedAnnotatedFieldImpl] @Rule public com.netotc.ha.route.TestCDI.testName
at
org.jboss.weld.bean.ManagedBean.checkBeanImplementation(ManagedBean.java:227)
at
org.jboss.weld.bean.AbstractClassBean.internalInitialize(AbstractClassBean.java:74)
at
org.jboss.weld.bean.ManagedBean.internalInitialize(ManagedBean.java:105)
at org.jboss.weld.bean.RIBean.initialize(RIBean.java:66)
at
org.jboss.weld.bootstrap.ConcurrentBeanDeployer$5.doWork(ConcurrentBeanDeployer.java:121)
at
org.jboss.weld.bootstrap.ConcurrentBeanDeployer$5.doWork(ConcurrentBeanDeployer.java:118)
at
org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
at
org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{noformat}
Suggesting to create a getter for this field, making the field private, and
moving the @Rule annotation to the getter.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8537) CamelHazelcast component should create its own HZ instance only if it's not provided
[
https://issues.apache.org/jira/browse/CAMEL-8537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-8537:
---
Fix Version/s: 2.16.0
CamelHazelcast component should create its own HZ instance only if it's not
provided
Key: CAMEL-8537
URL: https://issues.apache.org/jira/browse/CAMEL-8537
Project: Camel
Issue Type: Improvement
Components: camel-hazelcast
Affects Versions: 2.15.0
Reporter: ayache khettar
Labels: patch
Fix For: 2.16.0
Hi
Currently Hazelcast component creates its own HZ instance regardless if a
reference to a HZ instance is provided or not. So in the case of a reference
of HZ instance is provided, the one created by the component does not get
shutdown - see below code snippet, doesn't get shutdown. So one end up with
multipole instances.
I believe the component should not create its own instance at the doStart()
method. It should first check if a reference to HZ instance is provided, if
yes then use it and if not create its own.
I have made the changes to reflect the correct behaviour described above. The
changes will make sure only one instance of HZ is created. Also, added the
ability to reference HZ instance by its name.
{panel:title=What
remains?|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
* Update the wiki to show how to reference HZ by its name
* Update the wiki to show the newly introduced parameter
(hazelcastInstanceName)
* Update the wiki to ideally show an example of how to publish HZ instance as
an OSGI service for reuse by multiple bundles.
{panel}
{panel:title=Changes
made|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
* No longer the component creates its own HZ instance in doStart() method.
* When the component is initialised, only one instance is either been created
or use the referenced on in the endpoint.
* Ability to reference HZ instance by its name. This will serve the use case
whereby the hazelcast cluster is running remotely or not part of the camel
context.
{panel}
{code:title=HazelcastComponent.java|borderStyle=solid}
@Override
public void doStart() throws Exception {
super.doStart();
if (hazelcastInstance == null) {
createOwnInstance = true;
hazelcastInstance = createOwnInstance();
}
}
{code}
I have created a pull request for this, details can be seen here:
https://github.com/apache/camel/pull/443
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8537) CamelHazelcast component should create its own HZ instance only if it's not provided
[
https://issues.apache.org/jira/browse/CAMEL-8537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14379393#comment-14379393
]
Claus Ibsen commented on CAMEL-8537:
There is unit test errors due NPE with this patch. Do you mind checking what is
the problem and update the PR.
CamelHazelcast component should create its own HZ instance only if it's not
provided
Key: CAMEL-8537
URL: https://issues.apache.org/jira/browse/CAMEL-8537
Project: Camel
Issue Type: Improvement
Components: camel-hazelcast
Affects Versions: 2.15.0
Reporter: ayache khettar
Labels: patch
Fix For: 2.16.0
Hi
Currently Hazelcast component creates its own HZ instance regardless if a
reference to a HZ instance is provided or not. So in the case of a reference
of HZ instance is provided, the one created by the component does not get
shutdown - see below code snippet, doesn't get shutdown. So one end up with
multipole instances.
I believe the component should not create its own instance at the doStart()
method. It should first check if a reference to HZ instance is provided, if
yes then use it and if not create its own.
I have made the changes to reflect the correct behaviour described above. The
changes will make sure only one instance of HZ is created. Also, added the
ability to reference HZ instance by its name.
{panel:title=What
remains?|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
* Update the wiki to show how to reference HZ by its name
* Update the wiki to show the newly introduced parameter
(hazelcastInstanceName)
* Update the wiki to ideally show an example of how to publish HZ instance as
an OSGI service for reuse by multiple bundles.
{panel}
{panel:title=Changes
made|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
* No longer the component creates its own HZ instance in doStart() method.
* When the component is initialised, only one instance is either been created
or use the referenced on in the endpoint.
* Ability to reference HZ instance by its name. This will serve the use case
whereby the hazelcast cluster is running remotely or not part of the camel
context.
{panel}
{code:title=HazelcastComponent.java|borderStyle=solid}
@Override
public void doStart() throws Exception {
super.doStart();
if (hazelcastInstance == null) {
createOwnInstance = true;
hazelcastInstance = createOwnInstance();
}
}
{code}
I have created a pull request for this, details can be seen here:
https://github.com/apache/camel/pull/443
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-2650) @Produce and @Consume injected on prototype beans needs a mechanism for automatic stopping when no longer in use
[ https://issues.apache.org/jira/browse/CAMEL-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-2650. Resolution: Won't Fix Assignee: Claus Ibsen @Produce and @Consume injected on prototype beans needs a mechanism for automatic stopping when no longer in use Key: CAMEL-2650 URL: https://issues.apache.org/jira/browse/CAMEL-2650 Project: Camel Issue Type: Improvement Components: camel-spring Affects Versions: 2.2.0 Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: Future This only applies for prototype scoped POJOs which uses @Produce or @Consume to inject a Camel Producer/Consumer. As the prototype scoped POJO is short lived and there could potentially be created many of those POJOs. Then @Produce / @Consume will inject new instances of Producer / Consumer as well. And since there is no standard way of knowing when the POJO is no longer in need, which is where we can to stop the Producer/Consumer. For singleton scoped this is not a problem as CamelContext will keep track on the created Producer/Consumer in its internal _servicesToClose_. Which is then stopped when CamelContext stops. For prototype we need a different strategy such as - proxy it to use pooled producers/consumers which CamelContext manage the lifecycle - use a shared ProducerTemplate / ConsumerTemplate instead which CamelContext manages the lifecycle - other - maybe some thread local tricks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-4704) Allow type converters to be specified as Spring beans
[ https://issues.apache.org/jira/browse/CAMEL-4704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-4704: -- Assignee: Claus Ibsen Allow type converters to be specified as Spring beans - Key: CAMEL-4704 URL: https://issues.apache.org/jira/browse/CAMEL-4704 Project: Camel Issue Type: New Feature Components: camel-core Affects Versions: 2.8.2 Reporter: Daniel Gredler Assignee: Claus Ibsen Priority: Minor Fix For: 2.16.0 There are many Camel configuration elements that are auto-discovered when they are configured as Spring beans (Tracer, InterceptStrategy, EventNotifier, PlatformTransactionManager, etc): http://camel.apache.org/advanced-configuration-of-camelcontext-using-spring.html However, instances of TypeConverter are not auto-discovered based on the Spring configuration (there is a different auto-discovery mechanism): http://camel.apache.org/type-converter.html A related JIRA ticket (requesting custom XML syntax) was marked won't fix: CAMEL-1685. I agree that the extra XML tag is not necessary. However, the omission of Spring bean auto-discovery seems to violate the principle of least surprise -- as a new Camel user, knowing that Camel auto-discovers Spring beans for other configuration elements, I was surprised to find that Camel didn't find my TypeConverter Spring bean. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-4704) Allow type converters to be specified as Spring beans
[ https://issues.apache.org/jira/browse/CAMEL-4704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-4704: --- Fix Version/s: (was: 3.0.0) 2.16.0 Allow type converters to be specified as Spring beans - Key: CAMEL-4704 URL: https://issues.apache.org/jira/browse/CAMEL-4704 Project: Camel Issue Type: New Feature Components: camel-core Affects Versions: 2.8.2 Reporter: Daniel Gredler Priority: Minor Fix For: 2.16.0 There are many Camel configuration elements that are auto-discovered when they are configured as Spring beans (Tracer, InterceptStrategy, EventNotifier, PlatformTransactionManager, etc): http://camel.apache.org/advanced-configuration-of-camelcontext-using-spring.html However, instances of TypeConverter are not auto-discovered based on the Spring configuration (there is a different auto-discovery mechanism): http://camel.apache.org/type-converter.html A related JIRA ticket (requesting custom XML syntax) was marked won't fix: CAMEL-1685. I agree that the extra XML tag is not necessary. However, the omission of Spring bean auto-discovery seems to violate the principle of least surprise -- as a new Camel user, knowing that Camel auto-discovers Spring beans for other configuration elements, I was surprised to find that Camel didn't find my TypeConverter Spring bean. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-5618) The tag contextScan should inject @Converter methods from @Converter components.
[
https://issues.apache.org/jira/browse/CAMEL-5618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-5618.
Resolution: Won't Fix
context scan is for scanning for routes. There is another ticket about type
covert from spring easier.
The tag contextScan should inject @Converter methods from @Converter
components.
--
Key: CAMEL-5618
URL: https://issues.apache.org/jira/browse/CAMEL-5618
Project: Camel
Issue Type: Improvement
Components: camel-core, camel-spring
Affects Versions: 2.10.1
Reporter: Bernardo Silva
Assignee: Willem Jiang
Fix For: Future
Attachments: CamelConverterInjector.java
The ability to detect converters using
META-INF/services/org/apache/camel/TypeConverter SPI is cool, but obligates
me to make my converters as static methods.
This brings me 2 major issues:
1) It is hard to mock the converters in the CamelTestSupport because he
auto-detect the real ones;
2) If I want to inject beans in my converter class and use it in my
converter method, I can't.
So, to solve my problem I did a very simple class. I will copy the code at
the end of this. With this class, I don't use Camel SPI anymore and Spring
injects the converters for me using TypeConverterSupport.
Then, my suggestion is: why the annotation contextScan doesn't have a
similar behavior? It would be very nice and simple.
Thanks,
Bernardo Silva
CLASS:
{code}
import java.lang.reflect.Method;
import java.util.Map;
import org.apache.camel.CamelContext;
import org.apache.camel.Converter;
import org.apache.camel.Exchange;
import org.apache.camel.TypeConversionException;
import org.apache.camel.support.TypeConverterSupport;
import org.springframework.beans.factory.InitializingBean;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.ApplicationContext;
import org.springframework.stereotype.Component;
@SuppressWarnings(unchecked)
@Component
public class CamelConverterInjector implements InitializingBean {
@Autowired
private CamelContext camelContext;
@Autowired
private ApplicationContext springContext;
private static abstract class TypeConverterWrapper extends
TypeConverterSupport {
protected final Method method;
protected final Object bean;
protected TypeConverterWrapper(Method method, Object bean) {
this.method = method;
this.bean = bean;
}
}
private static final class TypeConverterSimpleWrapper extends
TypeConverterWrapper {
protected TypeConverterSimpleWrapper(Method method, Object
bean) {
super(method, bean);
}
public T T convertTo(ClassT type, Exchange exchange, Object
value) throws TypeConversionException {
try {
return (T) method.invoke(bean, value);
} catch (Throwable t) {
throw new TypeConversionException(value, type,
t);
}
}
}
private static final class TypeConverterExchangeWrapper extends
TypeConverterWrapper {
protected TypeConverterExchangeWrapper(Method method, Object
bean) {
super(method, bean);
}
public T T convertTo(ClassT type, Exchange exchange, Object
value) throws TypeConversionException {
try {
return (T) method.invoke(bean, value, exchange);
} catch (Throwable t) {
throw new TypeConversionException(value, type,
t);
}
}
}
public void afterPropertiesSet() throws Exception {
final MapString, Object beans =
springContext.getBeansWithAnnotation(Converter.class);
for (String beanName : beans.keySet()) {
final Object bean = beans.get(beanName);
for (Method method : bean.getClass().getMethods()) {
if (method.getAnnotation(Converter.class) !=
null) {
final Class?[] parameterTypes =
method.getParameterTypes();
final TypeConverterWrapper converter;
if (parameterTypes.length == 1) {
converter = new
TypeConverterSimpleWrapper(method, bean);
} else {
converter = new
[jira] [Resolved] (CAMEL-6009) camel-ftp - Improved logic for traversing directories with stepwise enabled
[ https://issues.apache.org/jira/browse/CAMEL-6009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-6009. Resolution: Later Assignee: Claus Ibsen camel-ftp - Improved logic for traversing directories with stepwise enabled --- Key: CAMEL-6009 URL: https://issues.apache.org/jira/browse/CAMEL-6009 Project: Camel Issue Type: Improvement Components: camel-ftp Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: Future See CAMEL-5574 with some comments The logic how Camel does recursive directory scanning on FTP components could be improved. In some cases it does a fair bit of directory changes. And also the logic for going to parent dir, could be improved for SFTP to use cd .. instead. Thought its in the fist poll we can really improve as well. What we should do is to at first poll to CD into the starting directory, only once. And then the existing logic can traverse the dirs, and when its done, the current dir is at the starting dir. Then we dont need to remember the beginning dir, and then change back to that when the poll is complete. eg we just CD into the starting dir the 1st time, and dont do that for 2+ polls. For that we need to have a state to remember this. And also if we need to re-login etc, then that state must be cleared. So 2 optimizes 1) How we do changeToParentDirectory 2) CD to starting directory on 1st poll (need state to remember) PS: starting directory = then directory configured on the ftp endpoint. Sometimes it may not be configured if you should just start from the home directory. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-6015) camel maven run plugin - Auto detect if spring or blueprint
[ https://issues.apache.org/jira/browse/CAMEL-6015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-6015. Resolution: Duplicate Assignee: Claus Ibsen camel maven run plugin - Auto detect if spring or blueprint --- Key: CAMEL-6015 URL: https://issues.apache.org/jira/browse/CAMEL-6015 Project: Camel Issue Type: Improvement Components: tooling Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: Future It would be nice if the mvn camel:run plugin could auto detect if your run a spring or blueprint project. Today it defaults to spring because it was the first. For blueprint you need to configure it to be blueprint. But we can detect the xml if its blueprint or spring in the namespace of the xml. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-6034) ClassResolver - Allow to add known package names to avoid typing FQN for known classes
[
https://issues.apache.org/jira/browse/CAMEL-6034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-6034.
Resolution: Later
Assignee: Claus Ibsen
ClassResolver - Allow to add known package names to avoid typing FQN for
known classes
--
Key: CAMEL-6034
URL: https://issues.apache.org/jira/browse/CAMEL-6034
Project: Camel
Issue Type: New Feature
Components: camel-core
Reporter: Claus Ibsen
Assignee: Claus Ibsen
Fix For: Future
We should allow the {{ClassResolver}} API to add packages so end users can
add their own package names. So looking up classes etc can use these known
packages as prefixes. This avoids typing in long FQN.
We would need some API in XML DSL to make that easier to configure.
This can also benefit the simple language with the new type function etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8027) Add ByteArrayCodec implementation for udp to camel-netty4
[ https://issues.apache.org/jira/browse/CAMEL-8027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14379480#comment-14379480 ] Thomas Termin commented on CAMEL-8027: -- Worked on tests yesterday evening. Looks promising for this week. Add ByteArrayCodec implementation for udp to camel-netty4 - Key: CAMEL-8027 URL: https://issues.apache.org/jira/browse/CAMEL-8027 Project: Camel Issue Type: Improvement Components: camel-netty4 Affects Versions: 2.14.0 Reporter: Thomas Termin Add a byte array codec for udp to the codec package so that it can be used directly from camel. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-2130) add a Visitor API to the org.apache.camel.model package so you can visit a RouteDefinition, a set of RouteDefinitions or a subset of a route to determine things like lang
[
https://issues.apache.org/jira/browse/CAMEL-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-2130:
---
Fix Version/s: (was: Future)
2.16.0
add a Visitor API to the org.apache.camel.model package so you can visit a
RouteDefinition, a set of RouteDefinitions or a subset of a route to
determine things like languages endpoints used etc
Key: CAMEL-2130
URL: https://issues.apache.org/jira/browse/CAMEL-2130
Project: Camel
Issue Type: Improvement
Components: camel-core
Reporter: james strachan
Assignee: Claus Ibsen
Priority: Minor
Fix For: 2.16.0
we should add a ModelVisitor interface to the model classes so that you can
visit the model to see what endpoints, languages, dataformats are used - for
example for reporting, OSGi dependency tracking or UI reasons.
{code}
definition = ...; // a route definition, a node in the route or a set or
routes
SimpleVisitor visitor = new SimpleVisitor();
definition.visit(visitor);
System.out.println(The dataformats are: + visitor.getDataFormats());
System.out.println(The endpoints are: + visitor.getEndpoints());
System.out.println(The expressions are: + visitor.getExpressions());
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-2130) add a Visitor API to the org.apache.camel.model package so you can visit a RouteDefinition, a set of RouteDefinitions or a subset of a route to determine things like la
[
https://issues.apache.org/jira/browse/CAMEL-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14379477#comment-14379477
]
Claus Ibsen commented on CAMEL-2130:
Now that we can link from model - processor it makes more sense to have a
nicer visitor api abstraction for this. We do have the foundation in a helper
class in the model to visit the model.
add a Visitor API to the org.apache.camel.model package so you can visit a
RouteDefinition, a set of RouteDefinitions or a subset of a route to
determine things like languages endpoints used etc
Key: CAMEL-2130
URL: https://issues.apache.org/jira/browse/CAMEL-2130
Project: Camel
Issue Type: Improvement
Components: camel-core
Reporter: james strachan
Assignee: Claus Ibsen
Priority: Minor
Fix For: 2.16.0
we should add a ModelVisitor interface to the model classes so that you can
visit the model to see what endpoints, languages, dataformats are used - for
example for reporting, OSGi dependency tracking or UI reasons.
{code}
definition = ...; // a route definition, a node in the route or a set or
routes
SimpleVisitor visitor = new SimpleVisitor();
definition.visit(visitor);
System.out.println(The dataformats are: + visitor.getDataFormats());
System.out.println(The endpoints are: + visitor.getEndpoints());
System.out.println(The expressions are: + visitor.getExpressions());
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-2719) EventNotifier - Add new out of box EventNotifier for logging sent exchanges
[ https://issues.apache.org/jira/browse/CAMEL-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-2719: --- Fix Version/s: (was: Future) 2.16.0 EventNotifier - Add new out of box EventNotifier for logging sent exchanges --- Key: CAMEL-2719 URL: https://issues.apache.org/jira/browse/CAMEL-2719 Project: Camel Issue Type: New Feature Components: camel-core Affects Versions: 2.3.0 Reporter: Claus Ibsen Priority: Minor Fix For: 2.16.0 See this link http://cwiki.apache.org/confluence/display/CAMEL/EventNotifier+to+log+details+about+all+sent+Exchanges We could create such an notifier out of the box which allows you to - easily use it - define filters for endpoints to include / exclude - which logger to use - thresholds for time taken to skip fast ones, eg if you only want slow ones -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-3168) Add REST based example using restlet or cxfrs as component
[ https://issues.apache.org/jira/browse/CAMEL-3168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-3168. Resolution: Fixed Fix Version/s: (was: Future) 2.15.0 Assignee: Claus Ibsen There is a few rest-dsl examples Add REST based example using restlet or cxfrs as component -- Key: CAMEL-3168 URL: https://issues.apache.org/jira/browse/CAMEL-3168 Project: Camel Issue Type: New Feature Components: examples Reporter: Claus Ibsen Assignee: Claus Ibsen Priority: Minor Fix For: 2.15.0 We need a REST based example to show how to do that. It should accept XML/JSON as input. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-2130) add a Visitor API to the org.apache.camel.model package so you can visit a RouteDefinition, a set of RouteDefinitions or a subset of a route to determine things like lan
[
https://issues.apache.org/jira/browse/CAMEL-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-2130:
--
Assignee: Claus Ibsen
add a Visitor API to the org.apache.camel.model package so you can visit a
RouteDefinition, a set of RouteDefinitions or a subset of a route to
determine things like languages endpoints used etc
Key: CAMEL-2130
URL: https://issues.apache.org/jira/browse/CAMEL-2130
Project: Camel
Issue Type: Improvement
Components: camel-core
Reporter: james strachan
Assignee: Claus Ibsen
Priority: Minor
Fix For: Future
we should add a ModelVisitor interface to the model classes so that you can
visit the model to see what endpoints, languages, dataformats are used - for
example for reporting, OSGi dependency tracking or UI reasons.
{code}
definition = ...; // a route definition, a node in the route or a set or
routes
SimpleVisitor visitor = new SimpleVisitor();
definition.visit(visitor);
System.out.println(The dataformats are: + visitor.getDataFormats());
System.out.println(The endpoints are: + visitor.getEndpoints());
System.out.println(The expressions are: + visitor.getExpressions());
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CAMEL-5452) DoCatch doesn't notify ExchangeFailureHandledEvent
[
https://issues.apache.org/jira/browse/CAMEL-5452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-5452:
--
Assignee: Claus Ibsen
DoCatch doesn't notify ExchangeFailureHandledEvent
--
Key: CAMEL-5452
URL: https://issues.apache.org/jira/browse/CAMEL-5452
Project: Camel
Issue Type: Improvement
Components: camel-core
Affects Versions: 2.8.0, 2.9.0, 2.10.0
Reporter: Raúl Kripalani
Assignee: Claus Ibsen
Fix For: 2.16.0
The doCatch EIP doesn't honour the emission of an
{{ExchangeFailureHandledEvent}} when it recognises and handles an exception.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-5452) DoCatch doesn't notify ExchangeFailureHandledEvent
[
https://issues.apache.org/jira/browse/CAMEL-5452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-5452:
---
Fix Version/s: (was: Future)
2.16.0
DoCatch doesn't notify ExchangeFailureHandledEvent
--
Key: CAMEL-5452
URL: https://issues.apache.org/jira/browse/CAMEL-5452
Project: Camel
Issue Type: Improvement
Components: camel-core
Affects Versions: 2.8.0, 2.9.0, 2.10.0
Reporter: Raúl Kripalani
Assignee: Claus Ibsen
Fix For: 2.16.0
The doCatch EIP doesn't honour the emission of an
{{ExchangeFailureHandledEvent}} when it recognises and handles an exception.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-5583) Add ning-compress as data format
[ https://issues.apache.org/jira/browse/CAMEL-5583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-5583: --- Estimated Complexity: Novice (was: Unknown) Add ning-compress as data format Key: CAMEL-5583 URL: https://issues.apache.org/jira/browse/CAMEL-5583 Project: Camel Issue Type: New Feature Reporter: Claus Ibsen Priority: Minor Fix For: Future Ning-compress https://github.com/ning/compress Is a compression library. We should add a data format for it. Its already an OSGi bundle as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-5690) Using bean component with beans that implement Service from Camel should have the lifecycle callbacks invoked
[ https://issues.apache.org/jira/browse/CAMEL-5690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-5690: -- Assignee: Claus Ibsen Using bean component with beans that implement Service from Camel should have the lifecycle callbacks invoked - Key: CAMEL-5690 URL: https://issues.apache.org/jira/browse/CAMEL-5690 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Claus Ibsen Assignee: Claus Ibsen Priority: Minor Fix For: Future See nabble http://camel.465427.n5.nabble.com/lifecycle-of-components-tp5720371.html If an user has a bean that implements org.apache.camel.Service we should invoke the start|stop methods on its when the route is being started|stopped. as we do for Processor et all. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-6082) File2 Component Over-normalizing A Files Absolute Path
[ https://issues.apache.org/jira/browse/CAMEL-6082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-6082. Resolution: Won't Fix Assignee: Claus Ibsen File2 Component Over-normalizing A Files Absolute Path -- Key: CAMEL-6082 URL: https://issues.apache.org/jira/browse/CAMEL-6082 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.10.3 Environment: Linux Reporter: Jeremy Lucier Assignee: Claus Ibsen Priority: Minor Fix For: Future We have a route using File2 to listen for a file to be dropped in a folder. When the file lock attempts to occur, it throws an exception saying the file doesn't exist. Same goes for moving the file using preMove. The reason being is some files that we're receiving have windows paths in their file name, ex: C:\logs\log.txt. On our Linux box it is represented as: /pickup/C:\logs\log.txt (note the slashes) A standard Java File would handle that fine and properly identify the filename vs the path, however GenericFile seems to want to normalize that to: /pickup/c:/logs/log.txt. That normalization causes camel to throw errors since that location/file doesn't exist. Untested, but in the GenericFile class, it looks like this might be the culprit: // we must normalize path according to protocol if we build our own paths String path = normalizePathToProtocol(getEndpointPath() + File.separator + getRelativeFilePath()); message.setHeader(Exchange.FILE_PATH, path); Let me know if you need more information, thanks! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-5398) Optimize String.replaceAll() to cache Patterns where suitable
[ https://issues.apache.org/jira/browse/CAMEL-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-5398: -- Assignee: Claus Ibsen Optimize String.replaceAll() to cache Patterns where suitable - Key: CAMEL-5398 URL: https://issues.apache.org/jira/browse/CAMEL-5398 Project: Camel Issue Type: Improvement Reporter: Henryk Konsek Assignee: Claus Ibsen Priority: Minor Fix For: 2.16.0 Inspired by issue [1] regarding performance of JMS headers, I performed a little search in IDE and found out that there's pretty much not optimized String.replaceAll() calls. I think it will be good to search the code base for such calls again and replace them with references to the static pre-compiled java.util.regex.Patterns. Of course if such action makes sense (like in StringHelper#removeQuotes()). [1] https://issues.apache.org/jira/browse/CAMEL-5396 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-5398) Optimize String.replaceAll() to cache Patterns where suitable
[ https://issues.apache.org/jira/browse/CAMEL-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-5398: --- Fix Version/s: (was: Future) 2.16.0 Optimize String.replaceAll() to cache Patterns where suitable - Key: CAMEL-5398 URL: https://issues.apache.org/jira/browse/CAMEL-5398 Project: Camel Issue Type: Improvement Reporter: Henryk Konsek Assignee: Claus Ibsen Priority: Minor Fix For: 2.16.0 Inspired by issue [1] regarding performance of JMS headers, I performed a little search in IDE and found out that there's pretty much not optimized String.replaceAll() calls. I think it will be good to search the code base for such calls again and replace them with references to the static pre-compiled java.util.regex.Patterns. Of course if such action makes sense (like in StringHelper#removeQuotes()). [1] https://issues.apache.org/jira/browse/CAMEL-5396 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-6329) File consumer - Allow to change directory using JMX
[ https://issues.apache.org/jira/browse/CAMEL-6329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-6329. Resolution: Won't Fix Assignee: Claus Ibsen File consumer - Allow to change directory using JMX --- Key: CAMEL-6329 URL: https://issues.apache.org/jira/browse/CAMEL-6329 Project: Camel Issue Type: Improvement Components: camel-core, jmx Affects Versions: 2.11.0 Reporter: Claus Ibsen Assignee: Claus Ibsen Priority: Minor Fix For: Future People may want to change a Camel route to pickup files from another directory. We should allow to re-configure this at runtime more easily with a JMX operation on the FileConsumer. The trick is possible that we should only allow to change it if the consumer has been suspended/stopped, so we don't change it during running. Though an alternative it to remember the change, and then only apply it at next poll. Then we can possible change it without the needed for suspend/stop first. See nabble http://camel.465427.n5.nabble.com/How-to-dynamically-configure-directory-on-file-consumer-tp5731811.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8533) camel-ognl exposes servicemix ognl bundle
[ https://issues.apache.org/jira/browse/CAMEL-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14379635#comment-14379635 ] Thomas Diesler commented on CAMEL-8533: --- We must not confuse compile/build time with runtime dependencies. At build time camel-ognl has dependencies on plain ognl, which in any execution environment except OSGi also become runtime dependencies. So in flat classpath env but also in a modular env camel-ognl must see the types from ognl. In an OSGi environment there must be a bundle deployed that exports ognl types (i.e. the smx ognl bundle). The maven compile time dependency from camel-ognl to ognl does not mean (and should not cause) ognl to be deployed as a bundle. Whatever configures the OSGi runtime must deploy both the camel-ognl bundle and a bundle for ognl itself. This should however not leak into non-osgi environments. The SMX OGNL bundle is OSGi specific and should not leak into non-osgi environments only because camel-ognl declares a maven compile time dependency on it. camel-ognl exposes servicemix ognl bundle - Key: CAMEL-8533 URL: https://issues.apache.org/jira/browse/CAMEL-8533 Project: Camel Issue Type: Task Components: camel-ognl Reporter: Thomas Diesler Assignee: Claus Ibsen Priority: Minor Fix For: 2.15.1, 2.16.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-5398) Optimize String.replaceAll() to cache Patterns where suitable
[ https://issues.apache.org/jira/browse/CAMEL-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-5398. Resolution: Fixed Optimize String.replaceAll() to cache Patterns where suitable - Key: CAMEL-5398 URL: https://issues.apache.org/jira/browse/CAMEL-5398 Project: Camel Issue Type: Improvement Reporter: Henryk Konsek Assignee: Claus Ibsen Priority: Minor Fix For: 2.16.0 Inspired by issue [1] regarding performance of JMS headers, I performed a little search in IDE and found out that there's pretty much not optimized String.replaceAll() calls. I think it will be good to search the code base for such calls again and replace them with references to the static pre-compiled java.util.regex.Patterns. Of course if such action makes sense (like in StringHelper#removeQuotes()). [1] https://issues.apache.org/jira/browse/CAMEL-5396 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-6415) camel-twitter - Support for the User Stream Endpoint
[ https://issues.apache.org/jira/browse/CAMEL-6415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-6415: --- Summary: camel-twitter - Support for the User Stream Endpoint (was: Support for the User Stream Endpoint) camel-twitter - Support for the User Stream Endpoint Key: CAMEL-6415 URL: https://issues.apache.org/jira/browse/CAMEL-6415 Project: Camel Issue Type: New Feature Components: camel-twitter Affects Versions: 2.11.0 Reporter: Jason Separovic Tweets from protected accounts can only be received on the user and site stream endpoints. It would be good to see this functionality added to the camel-twitter component so that protected tweets can be received by camel. The Hosebird Client could be used: https://github.com/twitter/hbc If connecting to a userstream, use Twitter4jUserstreamClient. If making a sitestream connection, use Twitter4jSitestreamClient -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-6212) Add support to allow json libraries to use jaxb annotations for marshal and unmarshal
[ https://issues.apache.org/jira/browse/CAMEL-6212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-6212. Resolution: Fixed Assignee: Claus Ibsen This is possible today Add support to allow json libraries to use jaxb annotations for marshal and unmarshal - Key: CAMEL-6212 URL: https://issues.apache.org/jira/browse/CAMEL-6212 Project: Camel Issue Type: Improvement Components: camel-jackson, camel-xstream Affects Versions: 2.10.4 Reporter: Jason Chaffee Assignee: Claus Ibsen Fix For: Future It would be nice to be able to marshal/unmarshal into json, but using jaxb annotations. Both Jackson and Jettison support this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-6334) camel-quartz - Add JMX MBean for CronScheduledRoutePolicy so people can change it at runtime
[ https://issues.apache.org/jira/browse/CAMEL-6334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-6334. Resolution: Won't Fix Assignee: Claus Ibsen Quartz has JMX camel-quartz - Add JMX MBean for CronScheduledRoutePolicy so people can change it at runtime Key: CAMEL-6334 URL: https://issues.apache.org/jira/browse/CAMEL-6334 Project: Camel Issue Type: New Feature Components: camel-quartz, jmx Affects Versions: 2.11.0 Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: Future See http://stackoverflow.com/questions/16388798/camel-change-route-policy-at-runtime-via-jmx We should enlist the route policies as JMX MBeans so people can adjust it at runtime. Though there may be a bit tricker to adjust as we would need to tell quartz about the change so it can re-trigger accordingly. Also we should look into if quartz has any JMX stats it can expose so we can make this out of the box / easier to enable. It would be nice to see some quartz stats of its scheduler etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-5398) Optimize String.replaceAll() to cache Patterns where suitable
[ https://issues.apache.org/jira/browse/CAMEL-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14379556#comment-14379556 ] Claus Ibsen commented on CAMEL-5398: I am optimizing the parts in camel-core that is relevant. Optimize String.replaceAll() to cache Patterns where suitable - Key: CAMEL-5398 URL: https://issues.apache.org/jira/browse/CAMEL-5398 Project: Camel Issue Type: Improvement Reporter: Henryk Konsek Assignee: Claus Ibsen Priority: Minor Fix For: 2.16.0 Inspired by issue [1] regarding performance of JMS headers, I performed a little search in IDE and found out that there's pretty much not optimized String.replaceAll() calls. I think it will be good to search the code base for such calls again and replace them with references to the static pre-compiled java.util.regex.Patterns. Of course if such action makes sense (like in StringHelper#removeQuotes()). [1] https://issues.apache.org/jira/browse/CAMEL-5396 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-6215) CacheReplicationTest resolve FIX ME
[
https://issues.apache.org/jira/browse/CAMEL-6215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-6215:
---
Priority: Minor (was: Major)
CacheReplicationTest resolve FIX ME
---
Key: CAMEL-6215
URL: https://issues.apache.org/jira/browse/CAMEL-6215
Project: Camel
Issue Type: Test
Components: camel-cache
Affects Versions: 2.11.0
Reporter: Piotr Klimczak
Priority: Minor
Resolve FIX ME on:
@Ignore(Fix me)
public class CacheReplicationTest
Cause:
{code}
net.sf.ehcache.CacheException: Another unnamed CacheManager already exists in
the same VM. Please provide unique names for each CacheManager in the config
or do one of following:
1. Use one of the CacheManager.create() static factory methods to reuse same
CacheManager with same name or create one if necessary
2. Shutdown the earlier cacheManager before creating new one with same name.
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-6215) CacheReplicationTest resolve FIX ME
[
https://issues.apache.org/jira/browse/CAMEL-6215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-6215:
---
Estimated Complexity: Novice (was: Unknown)
CacheReplicationTest resolve FIX ME
---
Key: CAMEL-6215
URL: https://issues.apache.org/jira/browse/CAMEL-6215
Project: Camel
Issue Type: Test
Components: camel-cache
Affects Versions: 2.11.0
Reporter: Piotr Klimczak
Priority: Minor
Resolve FIX ME on:
@Ignore(Fix me)
public class CacheReplicationTest
Cause:
{code}
net.sf.ehcache.CacheException: Another unnamed CacheManager already exists in
the same VM. Please provide unique names for each CacheManager in the config
or do one of following:
1. Use one of the CacheManager.create() static factory methods to reuse same
CacheManager with same name or create one if necessary
2. Shutdown the earlier cacheManager before creating new one with same name.
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-6269) MainSupport in camel-core should make it easier to have callbacks when starting / stopping etc
[ https://issues.apache.org/jira/browse/CAMEL-6269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-6269: --- Fix Version/s: (was: Future) 2.16.0 MainSupport in camel-core should make it easier to have callbacks when starting / stopping etc -- Key: CAMEL-6269 URL: https://issues.apache.org/jira/browse/CAMEL-6269 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Claus Ibsen Assignee: Claus Ibsen Priority: Minor Fix For: 2.16.0 See nabble http://camel.465427.n5.nabble.com/Callback-after-startup-from-org-apache-camel-main-Main-afterStart-tp5730284.html We should have an interface / or some methods people can override for start | stop events. Or consider just using the event notifier api from Camel. Though it has many events. And people may just an easier way of getting a callback for Camel has started. Camel has stopped etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-5452) DoCatch doesn't notify ExchangeFailureHandledEvent
[
https://issues.apache.org/jira/browse/CAMEL-5452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-5452.
Resolution: Fixed
DoCatch doesn't notify ExchangeFailureHandledEvent
--
Key: CAMEL-5452
URL: https://issues.apache.org/jira/browse/CAMEL-5452
Project: Camel
Issue Type: Improvement
Components: camel-core
Affects Versions: 2.8.0, 2.9.0, 2.10.0
Reporter: Raúl Kripalani
Assignee: Claus Ibsen
Fix For: 2.16.0
The doCatch EIP doesn't honour the emission of an
{{ExchangeFailureHandledEvent}} when it recognises and handles an exception.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-6269) MainSupport in camel-core should make it easier to have callbacks when starting / stopping etc
[ https://issues.apache.org/jira/browse/CAMEL-6269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-6269. Resolution: Fixed MainSupport in camel-core should make it easier to have callbacks when starting / stopping etc -- Key: CAMEL-6269 URL: https://issues.apache.org/jira/browse/CAMEL-6269 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Claus Ibsen Assignee: Claus Ibsen Priority: Minor Fix For: 2.16.0 See nabble http://camel.465427.n5.nabble.com/Callback-after-startup-from-org-apache-camel-main-Main-afterStart-tp5730284.html We should have an interface / or some methods people can override for start | stop events. Or consider just using the event notifier api from Camel. Though it has many events. And people may just an easier way of getting a callback for Camel has started. Camel has stopped etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-5398) Optimize String.replaceAll() to cache Patterns where suitable
[ https://issues.apache.org/jira/browse/CAMEL-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-5398: --- Component/s: camel-core Optimize String.replaceAll() to cache Patterns where suitable - Key: CAMEL-5398 URL: https://issues.apache.org/jira/browse/CAMEL-5398 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Henryk Konsek Assignee: Claus Ibsen Priority: Minor Fix For: 2.15.1, 2.16.0 Inspired by issue [1] regarding performance of JMS headers, I performed a little search in IDE and found out that there's pretty much not optimized String.replaceAll() calls. I think it will be good to search the code base for such calls again and replace them with references to the static pre-compiled java.util.regex.Patterns. Of course if such action makes sense (like in StringHelper#removeQuotes()). [1] https://issues.apache.org/jira/browse/CAMEL-5396 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-5929) camel-quartz - Add temporal window activation to route policies
[ https://issues.apache.org/jira/browse/CAMEL-5929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14379669#comment-14379669 ] Claus Ibsen commented on CAMEL-5929: Yeah lets see what we can do on quartz2 with DailyTimeIntervalTrigger But also quartz has misfire instructions you can set to catch-up if you do a server restart. So maybe the cron one can already do this camel-quartz - Add temporal window activation to route policies --- Key: CAMEL-5929 URL: https://issues.apache.org/jira/browse/CAMEL-5929 Project: Camel Issue Type: New Feature Components: camel-core, camel-quartz Affects Versions: 2.10.3 Reporter: Philip Glebow Labels: features Fix For: Future I have several routes that run at different times during the business day. A CronScheduledRoutePolicy is used to control the polling schedule. For example, the system polls for a file via FTP between 14:00 and 15:00 each week day - the file is not guaranteed to be there prior to that time per our SLA with the vendor. The route policy is in place so that the system does not constantly badger the FTP server with useless requests. However, from time to time, we need to restart our server. What I've observed is that if the server is restarted at 14:30, the route must be manually enabled via JMX. We actually have 20-30 routes and this is a burden for our support team; they often miss a route or two. What I'd like to have is a policy that says run this route every n minutes from 14:00 - 15:00 each weekday - and have it activated even we restart the server at 14:30. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-5553) camel-cdi - support injection of Endpoint and @Produce @Consume annotations
[
https://issues.apache.org/jira/browse/CAMEL-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-5553:
---
Summary: camel-cdi - support injection of Endpoint and @Produce @Consume
annotations (was: support injection of Endpoint and @Produce @Consume
annotations)
camel-cdi - support injection of Endpoint and @Produce @Consume annotations
---
Key: CAMEL-5553
URL: https://issues.apache.org/jira/browse/CAMEL-5553
Project: Camel
Issue Type: Improvement
Components: camel-cdi
Reporter: james strachan
Fix For: Future
we don't yet support the various camel annotation injections in CDI yet; we
should support the same capabilities as we have in spring/guice
http://camel.apache.org/bean-integration.html
http://camel.apache.org/bean-injection.html
I guess a more CDI way to do endpoint injection might be to have an
annotation for endpointURI specification. Then you'd either use
{code}
public class MyBean {
// named reference injection
@Inject @Named(foo) Endpoint bar;
// URI based injection
@Inject @Uri(mock:whatnot) MockEndpoint foo;
...
}
{code}
Rather than using the DI-agnostic @EndpointInject annotation - though I guess
we could support it too (though having Inject twice looks a bit icky and not
as DRY)...
{code}
public class MyBean {
// using current annotation...
@Inject @EndpointInject(uri = mock:whatnot) MockEndpoint bar;
...
}
{code}
For handling @Consume it would be nice to avoid having to use @Inject too as
that seems a bit odd (since there's no injection going on).
For @Produce I guess we could support a straight @Inject of a
ProcessorTemplate; allowing use of @Uri annotation to specify the default URI
to send to
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-6245) Add the camel-scala-extraz documentation to ASF docs
[ https://issues.apache.org/jira/browse/CAMEL-6245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-6245. Resolution: Unresolved Add the camel-scala-extraz documentation to ASF docs Key: CAMEL-6245 URL: https://issues.apache.org/jira/browse/CAMEL-6245 Project: Camel Issue Type: Sub-task Components: documentation Affects Versions: 2.10.0 Reporter: Claus Ibsen Assignee: Willem Jiang Priority: Minor Fix For: Future The docs from https://github.com/osinka/camel-scala-extra We should have that contribured to ASF so we can add some of that to our scala docs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8470) Several small fixes for camel-linkedin
[
https://issues.apache.org/jira/browse/CAMEL-8470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14379945#comment-14379945
]
ASF GitHub Bot commented on CAMEL-8470:
---
Github user trohovsky closed the pull request at:
https://github.com/apache/camel/pull/433
Several small fixes for camel-linkedin
--
Key: CAMEL-8470
URL: https://issues.apache.org/jira/browse/CAMEL-8470
Project: Camel
Issue Type: Bug
Affects Versions: 2.14.2
Reporter: Tomas Rohovsky
Assignee: Willem Jiang
Fix For: 2.14.3, 2.15.1, 2.16.0
# companies/addShare should return the created Update
# Share#comment should be String instead of Comment
# Group#isOpenToNonMembers and Group#allowMemberInvites should be Boolean
instead of boolean
Otherwise invoking of people/addGroupMembership causes
{code}
Error invoking addGroupMembership: Unexpected
{group-membership/group/is-open-to-non-members} element, Unexpected
{group-membership/group/allow-member-invites}
{code}
because both attributes (that are not valid for this resource) are present.
# remove role from people/getSuggestedGroupPosts
It is only for group-memberships/\{id\}/posts resource.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8456) Remove addCompanyUpdateComment endpoint from camel-linkedin
[
https://issues.apache.org/jira/browse/CAMEL-8456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14379949#comment-14379949
]
ASF GitHub Bot commented on CAMEL-8456:
---
Github user trohovsky closed the pull request at:
https://github.com/apache/camel/pull/424
Remove addCompanyUpdateComment endpoint from camel-linkedin
---
Key: CAMEL-8456
URL: https://issues.apache.org/jira/browse/CAMEL-8456
Project: Camel
Issue Type: Bug
Affects Versions: 2.14.1
Reporter: Tomas Rohovsky
Assignee: Willem Jiang
Fix For: 2.14.3, 2.15.1, 2.16.0
Underlying resource
{code}
/companies/{company-id}/updates/key={update-key}/update-comments
{code}
does not exist. It was probably added by mistake instead of
{code}
https://api.linkedin.com/v1/people/~/network/updates/key={update-key}/update-comments
{code}
mentioned in the documentation
[https://developer-programs.linkedin.com/documents/commenting-and-liking-company-share].
The resource is already mapped to linkedin://people/addUpdateComment so
there is no need to add it to companies prefixed endpoints.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8537) CamelHazelcast component should create its own HZ instance only if it's not provided
[
https://issues.apache.org/jira/browse/CAMEL-8537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14379899#comment-14379899
]
Claus Ibsen commented on CAMEL-8537:
Thanks I am pushing the code changes. Do you want to help update the wiki?
To do that read here
http://camel.apache.org/how-do-i-edit-the-website.html
It requires signing an ICLA which the link explains about.
CamelHazelcast component should create its own HZ instance only if it's not
provided
Key: CAMEL-8537
URL: https://issues.apache.org/jira/browse/CAMEL-8537
Project: Camel
Issue Type: Improvement
Components: camel-hazelcast
Affects Versions: 2.15.0
Reporter: ayache khettar
Labels: patch
Fix For: 2.16.0
Hi
Currently Hazelcast component creates its own HZ instance regardless if a
reference to a HZ instance is provided or not. So in the case of a reference
of HZ instance is provided, the one created by the component does not get
shutdown - see below code snippet, doesn't get shutdown. So one end up with
multipole instances.
I believe the component should not create its own instance at the doStart()
method. It should first check if a reference to HZ instance is provided, if
yes then use it and if not create its own.
I have made the changes to reflect the correct behaviour described above. The
changes will make sure only one instance of HZ is created. Also, added the
ability to reference HZ instance by its name.
{panel:title=What
remains?|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
* Update the wiki to show how to reference HZ by its name
* Update the wiki to show the newly introduced parameter
(hazelcastInstanceName)
* Update the wiki to ideally show an example of how to publish HZ instance as
an OSGI service for reuse by multiple bundles.
{panel}
{panel:title=Changes
made|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
* No longer the component creates its own HZ instance in doStart() method.
* When the component is initialised, only one instance is either been created
or use the referenced on in the endpoint.
* Ability to reference HZ instance by its name. This will serve the use case
whereby the hazelcast cluster is running remotely or not part of the camel
context.
{panel}
{code:title=HazelcastComponent.java|borderStyle=solid}
@Override
public void doStart() throws Exception {
super.doStart();
if (hazelcastInstance == null) {
createOwnInstance = true;
hazelcastInstance = createOwnInstance();
}
}
{code}
I have created a pull request for this, details can be seen here:
https://github.com/apache/camel/pull/443
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8458) camel-linkedin - public_profile_url option should be String
[
https://issues.apache.org/jira/browse/CAMEL-8458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-8458:
---
Fix Version/s: 2.15.1
2.14.3
camel-linkedin - public_profile_url option should be String
---
Key: CAMEL-8458
URL: https://issues.apache.org/jira/browse/CAMEL-8458
Project: Camel
Issue Type: Bug
Affects Versions: 2.14.1
Reporter: Tomas Rohovsky
Fix For: 2.14.3, 2.15.1
public_profile_url should be String instead of URI. The value of
public_profile_url must be URL encoded what is not possible with URI.
Currently I am getting
{code}
Error invoking getPersonByUrl: Unknown field {pub} in resource {Person}
{code}
for https://www.linkedin.com/pub/jboss-fuse-qe/b4/14b/b
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8455) camel-linkedin - update_key option should be optional in getHistoricalStatusUpdateStatistics
[
https://issues.apache.org/jira/browse/CAMEL-8455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14379952#comment-14379952
]
ASF GitHub Bot commented on CAMEL-8455:
---
Github user trohovsky closed the pull request at:
https://github.com/apache/camel/pull/423
camel-linkedin - update_key option should be optional in
getHistoricalStatusUpdateStatistics
Key: CAMEL-8455
URL: https://issues.apache.org/jira/browse/CAMEL-8455
Project: Camel
Issue Type: Bug
Affects Versions: 2.14.1
Reporter: Tomas Rohovsky
Assignee: Willem Jiang
Fix For: 2.14.3, 2.15.1, 2.16.0
update_key option should be optional in getHistoricalStatusUpdateStatistics
endpoint. Currently it ends with an exception if the option is not specified:
{{org.apache.camel.RuntimeCamelException: Missing properties for
getHistoricalStatusUpdateStatistics, need one or more from \[end_timestamp,
update_key\]}} See the LinkedIn API docs:
https://developer-programs.linkedin.com/historical-company-statistics.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8457) Correct return types of some endpoints in camel-linkedin
[ https://issues.apache.org/jira/browse/CAMEL-8457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14379948#comment-14379948 ] ASF GitHub Bot commented on CAMEL-8457: --- Github user trohovsky closed the pull request at: https://github.com/apache/camel/pull/425 Correct return types of some endpoints in camel-linkedin Key: CAMEL-8457 URL: https://issues.apache.org/jira/browse/CAMEL-8457 Project: Camel Issue Type: Bug Affects Versions: 2.14.1 Reporter: Tomas Rohovsky Assignee: Willem Jiang Fix For: 2.14.3, 2.15.1, 2.16.0 These endpoints return wrong type: - companies/getCompanyUpdateComments - Comments/UpdateComments - companies/getUpdateComments - Comments/UpdateComments - people/getGroupMembershipSettings - GroupMemberships/GroupMembership so it results in java.lang.ClassCastException. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8465) Add groups/getPosts endpoint to camel-linkedin
[
https://issues.apache.org/jira/browse/CAMEL-8465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14379954#comment-14379954
]
ASF GitHub Bot commented on CAMEL-8465:
---
Github user trohovsky closed the pull request at:
https://github.com/apache/camel/pull/429
Add groups/getPosts endpoint to camel-linkedin
--
Key: CAMEL-8465
URL: https://issues.apache.org/jira/browse/CAMEL-8465
Project: Camel
Issue Type: New Feature
Affects Versions: 2.14.1
Reporter: Tomas Rohovsky
Assignee: Willem Jiang
Fix For: 2.14.3, 2.15.1, 2.16.0
Add groups/getPosts endpint that covers following resource:
{code}
https://api.linkedin.com/v1/groups/{group-id}/posts
{code}
Similar functionality as this resource provides people/getPosts mapped to
{code}
https://api.linkedin.com/v1/people/~/group-memberships/{group-id}/posts
{code}
, but it requires role to be set.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-8545) Allow camel-swagger component to run in an internal container
Karl Openet created CAMEL-8545:
--
Summary: Allow camel-swagger component to run in an internal
container
Key: CAMEL-8545
URL: https://issues.apache.org/jira/browse/CAMEL-8545
Project: Camel
Issue Type: Improvement
Components: camel-swagger
Affects Versions: 2.14.1
Environment: All
Reporter: Karl Openet
I use camel as a front end to provide a RESTful API in front of a mix of
various web services. Requests come in in either xml or json, and are converted
to xml, transformed and sent on to the back end services which only support an
RPC style.
I use rest dsl with configuration via spring xml, and it runs in a java process.
{noformat}
restConfiguration bindingMode=auto component=jetty host=localhost
port=18910/
{noformat}
I would love to use the camel-swagger component to provide a live API document
of the Rest API's configured, but it seems that it is not possible without
configuring a web.xml file.
Is this feasible? Is there an alternative to document the Rest API the camel
context provides?
Camel-context below.
{noformat}
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:camel=http://camel.apache.org/schema/spring;
xmlns:cxf=http://camel.apache.org/schema/cxf;
xmlns:context=http://www.springframework.org/schema/context;
xsi:schemaLocation=
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context.xsd
http://camel.apache.org/schema/spring
http://camel.apache.org/schema/spring/camel-spring.xsd
http://camel.apache.org/schema/cxf
http://camel.apache.org/schema/cxf/camel-cxf.xsd;
import resource=classpath:META-INF/spring/jolokia.xml/
bean id=metricsRoutePolicyFactory
class=org.apache.camel.component.metrics.routepolicy.MetricsRoutePolicyFactory/
camelContext xmlns=http://camel.apache.org/schema/spring;
properties
property key=CamelLogDebugBodyStreams value=true/
/properties
propertyPlaceholder
location=classpath:incident.properties,file:target/custom.properties
id=properties/
endpoint uri=jetty:http://localhost:28950/ig?bridgeEndpoint=true;
id=jsonEndpoint/
endpoint
uri=cxf:http://localhost:28960/ig?dataFormat=PAYLOADamp;wsdlURL=http://localhost:28960/ig?WSDLamp;loggingFeatureEnabled=true;
id=soapEndpoint/
dataFormats
xmljson id=xmljson forceTopLevelObject=true
removeNamespacePrefixes=true/
xmljson id=xmljsonWithOptions trimSpaces=true
skipNamespaces=true
removeNamespacePrefixes=true/
/dataFormats
restConfiguration bindingMode=auto component=jetty host=localhost
port=18910/
rest path=/SubscriberProfilesJson/ consumes=application/json
get uri=/{SubscriberId}
to uri=direct:GetProfileJson/
/get
post uri=/{SubscriberId}/Subscriptions consumes=application/json
to uri=direct:CreateSubscriptionJson/
/post
get uri=/{SubscriberId}/Subscriptions consumes=application/json
to uri=direct:GetSubscriptionsJson/
/get
/rest
rest path=/SubscriberProfilesXml/ consumes=application/xml
get uri=/{SubscriberId}
to uri=direct:GetProfile/
/get
get uri=/{SubscriberId}/Subscriptions consumes=application/xml
to uri=direct:GetSubscriptions/
/get
post uri=/{SubscriberId}/Subscriptions consumes=application/xml
to uri=direct:CreateSubscription/
/post
/rest
rest path=/SubscriberProfilesJsonConvert/ consumes=application/json
get uri=/{SubscriberId}/Subscriptions consumes=application/json
to uri=direct:GetSubscriptionsJsonConvert/
/get
/rest
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-8546) No LanguageResolver found for language=js
Bart Horré created CAMEL-8546:
-
Summary: No LanguageResolver found for language=js
Key: CAMEL-8546
URL: https://issues.apache.org/jira/browse/CAMEL-8546
Project: Camel
Issue Type: Bug
Reporter: Bart Horré
{noformat}Unable to start blueprint container for bundle test.xml due to
unresolved dependencies
[((language=js)(objectClass=org.apache.camel.spi.LanguageResolver))]
java.util.concurrent.TimeoutException
at
org.apache.aries.blueprint.container.BlueprintContainerImpl$1.run(BlueprintContainerImpl.java:293)[10:org.apache.aries.blueprint:0.3.2]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)[:1.7.0_17]
at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)[:1.7.0_17]
at java.util.concurrent.FutureTask.run(FutureTask.java:166)[:1.7.0_17]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)[:1.7.0_17]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)[:1.7.0_17]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)[:1.7.0_17]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)[:1.7.0_17]
at java.lang.Thread.run(Thread.java:722)[:1.7.0_17] {noformat}
This happens when we try to use script with blueprint because blueprint tries
to resolve the LanguageResolver with filter language=js. However camel.osgi
registered a default LanguageResolver under resolver=default which causes
blueprint to wait for ever.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-8547) Usage of camel-xmlbeans depends on TCCL
James Netherton created CAMEL-8547: -- Summary: Usage of camel-xmlbeans depends on TCCL Key: CAMEL-8547 URL: https://issues.apache.org/jira/browse/CAMEL-8547 Project: Camel Issue Type: Bug Affects Versions: 2.15.0 Reporter: James Netherton xmlbeans marshalling and unmarshalling does not respect the ApplicationContextClassLoader CrossRef: https://github.com/wildfly-extras/wildfly-camel/issues/457 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8546) No LanguageResolver found for language=js
[
https://issues.apache.org/jira/browse/CAMEL-8546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bart Horré updated CAMEL-8546:
--
Component/s: camel-script
Affects Version/s: 2.14.1
Fix Version/s: 2.16.0
created a pull request for master branch at
https://github.com/apache/camel/pull/444
No LanguageResolver found for language=js
-
Key: CAMEL-8546
URL: https://issues.apache.org/jira/browse/CAMEL-8546
Project: Camel
Issue Type: Bug
Components: camel-script
Affects Versions: 2.14.1
Reporter: Bart Horré
Fix For: 2.16.0
{noformat}Unable to start blueprint container for bundle test.xml due to
unresolved dependencies
[((language=js)(objectClass=org.apache.camel.spi.LanguageResolver))]
java.util.concurrent.TimeoutException
at
org.apache.aries.blueprint.container.BlueprintContainerImpl$1.run(BlueprintContainerImpl.java:293)[10:org.apache.aries.blueprint:0.3.2]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)[:1.7.0_17]
at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)[:1.7.0_17]
at java.util.concurrent.FutureTask.run(FutureTask.java:166)[:1.7.0_17]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)[:1.7.0_17]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)[:1.7.0_17]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)[:1.7.0_17]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)[:1.7.0_17]
at java.lang.Thread.run(Thread.java:722)[:1.7.0_17] {noformat}
This happens when we try to use script with blueprint because blueprint tries
to resolve the LanguageResolver with filter language=js. However camel.osgi
registered a default LanguageResolver under resolver=default which causes
blueprint to wait for ever.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8546) No LanguageResolver found for language=js
[
https://issues.apache.org/jira/browse/CAMEL-8546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14380142#comment-14380142
]
ASF GitHub Bot commented on CAMEL-8546:
---
GitHub user barthorre opened a pull request:
https://github.com/apache/camel/pull/444
CAMEL-8546: fix script language resolvers
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/barthorre/camel CAMEL-8546
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/camel/pull/444.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 #444
commit d48a2600c1972a55d092224f7bcc64ed0e555703
Author: bart b...@anova.be
Date: 2015-03-25T15:59:57Z
CAMEL-8546: fix script language resolvers
No LanguageResolver found for language=js
-
Key: CAMEL-8546
URL: https://issues.apache.org/jira/browse/CAMEL-8546
Project: Camel
Issue Type: Bug
Reporter: Bart Horré
{noformat}Unable to start blueprint container for bundle test.xml due to
unresolved dependencies
[((language=js)(objectClass=org.apache.camel.spi.LanguageResolver))]
java.util.concurrent.TimeoutException
at
org.apache.aries.blueprint.container.BlueprintContainerImpl$1.run(BlueprintContainerImpl.java:293)[10:org.apache.aries.blueprint:0.3.2]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)[:1.7.0_17]
at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)[:1.7.0_17]
at java.util.concurrent.FutureTask.run(FutureTask.java:166)[:1.7.0_17]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)[:1.7.0_17]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)[:1.7.0_17]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)[:1.7.0_17]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)[:1.7.0_17]
at java.lang.Thread.run(Thread.java:722)[:1.7.0_17] {noformat}
This happens when we try to use script with blueprint because blueprint tries
to resolve the LanguageResolver with filter language=js. However camel.osgi
registered a default LanguageResolver under resolver=default which causes
blueprint to wait for ever.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8546) No LanguageResolver found for language=js
[
https://issues.apache.org/jira/browse/CAMEL-8546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14380139#comment-14380139
]
Claus Ibsen commented on CAMEL-8546:
You need to install the camel-script-javascript feature to install the language
No LanguageResolver found for language=js
-
Key: CAMEL-8546
URL: https://issues.apache.org/jira/browse/CAMEL-8546
Project: Camel
Issue Type: Bug
Reporter: Bart Horré
{noformat}Unable to start blueprint container for bundle test.xml due to
unresolved dependencies
[((language=js)(objectClass=org.apache.camel.spi.LanguageResolver))]
java.util.concurrent.TimeoutException
at
org.apache.aries.blueprint.container.BlueprintContainerImpl$1.run(BlueprintContainerImpl.java:293)[10:org.apache.aries.blueprint:0.3.2]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)[:1.7.0_17]
at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)[:1.7.0_17]
at java.util.concurrent.FutureTask.run(FutureTask.java:166)[:1.7.0_17]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)[:1.7.0_17]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)[:1.7.0_17]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)[:1.7.0_17]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)[:1.7.0_17]
at java.lang.Thread.run(Thread.java:722)[:1.7.0_17] {noformat}
This happens when we try to use script with blueprint because blueprint tries
to resolve the LanguageResolver with filter language=js. However camel.osgi
registered a default LanguageResolver under resolver=default which causes
blueprint to wait for ever.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8464) Remove likeCompanyUpdate endpoint from camel-linkedin
[
https://issues.apache.org/jira/browse/CAMEL-8464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14379955#comment-14379955
]
ASF GitHub Bot commented on CAMEL-8464:
---
Github user trohovsky closed the pull request at:
https://github.com/apache/camel/pull/428
Remove likeCompanyUpdate endpoint from camel-linkedin
-
Key: CAMEL-8464
URL: https://issues.apache.org/jira/browse/CAMEL-8464
Project: Camel
Issue Type: Bug
Affects Versions: 2.14.1
Reporter: Tomas Rohovsky
Assignee: Willem Jiang
Fix For: 2.14.3, 2.15.1, 2.16.0
Similar as CAMEL-8456. The underlying resource
{code}
/companies/{company-id}/updates/key={update-key}/is-liked
{code}
doesn't exist. It was probably added by mistake instead of
{code}
https://api.linkedin.com/v1/people/~/network/updates/key={update-key}/is-liked
{code}
mentioned in the documentation
https://developer-programs.linkedin.com/documents/commenting-and-liking-company-share.
The resource is already mapped to linkedin://people/likeUpdate so there is
no need to add it to companies prefixed endpoints.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7638) Use response input stream directly in http producer
[ https://issues.apache.org/jira/browse/CAMEL-7638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14380217#comment-14380217 ] Ralf Steppacher commented on CAMEL-7638: Is this ticket somewhere on the roadmap? It would be extremely beneficial to my project if this could be implemented. Another thing I noticed in this context: The netty4-http component currently re-calculates the content length of a response if used in a proxy route. And it seems I have no control over the headers, that is I cannot switch to chunked transfer encoding if I massage the response stream contents in a streaming fashion. I came across at least one recent ticket that was about expected content length/transfer encoding headers in proxy setups. Use response input stream directly in http producer --- Key: CAMEL-7638 URL: https://issues.apache.org/jira/browse/CAMEL-7638 Project: Camel Issue Type: Improvement Reporter: Willem Jiang Assignee: Willem Jiang It could save us lots of the memory and time if the response is a big and chunked message. Here are some discussion in the mailing list about it. http://camel.465427.n5.nabble.com/Stream-only-reverse-proxy-with-minimal-memory-footprint-tp5754424.html http://camel.465427.n5.nabble.com/Chunking-issue-with-http-producer-td5735075.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8547) Usage of camel-xmlbeans depends on TCCL
[ https://issues.apache.org/jira/browse/CAMEL-8547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14380198#comment-14380198 ] ASF GitHub Bot commented on CAMEL-8547: --- GitHub user jamesnetherton opened a pull request: https://github.com/apache/camel/pull/445 [CAMEL-8547] Usage of camel-xmlbeans depends on TCCL You can merge this pull request into a Git repository by running: $ git pull https://github.com/jamesnetherton/camel CAMEL-8547 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/445.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 #445 commit dec46867f6d02fa26e14892776b68c33428ec708 Author: James Netherton jneth...@redhat.com Date: 2015-03-25T16:19:16Z [CAMEL-8547] Usage of camel-xmlbeans depends on TCCL Usage of camel-xmlbeans depends on TCCL --- Key: CAMEL-8547 URL: https://issues.apache.org/jira/browse/CAMEL-8547 Project: Camel Issue Type: Bug Affects Versions: 2.15.0 Reporter: James Netherton xmlbeans marshalling and unmarshalling does not respect the ApplicationContextClassLoader CrossRef: https://github.com/wildfly-extras/wildfly-camel/issues/457 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8546) No LanguageResolver found for language=js
[
https://issues.apache.org/jira/browse/CAMEL-8546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14380254#comment-14380254
]
Bart Horré commented on CAMEL-8546:
---
I installed the camel-script-javascript feature but could not find a
LanguageResolver registered with language=js in the services list.
No LanguageResolver found for language=js
-
Key: CAMEL-8546
URL: https://issues.apache.org/jira/browse/CAMEL-8546
Project: Camel
Issue Type: Bug
Components: camel-script
Affects Versions: 2.14.1
Reporter: Bart Horré
Fix For: 2.16.0
{noformat}Unable to start blueprint container for bundle test.xml due to
unresolved dependencies
[((language=js)(objectClass=org.apache.camel.spi.LanguageResolver))]
java.util.concurrent.TimeoutException
at
org.apache.aries.blueprint.container.BlueprintContainerImpl$1.run(BlueprintContainerImpl.java:293)[10:org.apache.aries.blueprint:0.3.2]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)[:1.7.0_17]
at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)[:1.7.0_17]
at java.util.concurrent.FutureTask.run(FutureTask.java:166)[:1.7.0_17]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)[:1.7.0_17]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)[:1.7.0_17]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)[:1.7.0_17]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)[:1.7.0_17]
at java.lang.Thread.run(Thread.java:722)[:1.7.0_17] {noformat}
This happens when we try to use script with blueprint because blueprint tries
to resolve the LanguageResolver with filter language=js. However camel.osgi
registered a default LanguageResolver under resolver=default which causes
blueprint to wait for ever.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-5884) camel-cxf - Allow to define which operationNames a given consumer services
[ https://issues.apache.org/jira/browse/CAMEL-5884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14381041#comment-14381041 ] Faisal Masood commented on CAMEL-5884: -- We actually have this problem in of the projects I was doing. In the end, I created a gateway route, which then on the basis of operation names further route to other routes. I made everything configurable so that names of other routes and transport also become customisable. One thing though, I had to write an intercetptor to fetch the soap operation name. This all thing can be done in the cxc component and i am happy to take this lira. camel-cxf - Allow to define which operationNames a given consumer services -- Key: CAMEL-5884 URL: https://issues.apache.org/jira/browse/CAMEL-5884 Project: Camel Issue Type: New Feature Components: camel-cxf Reporter: Claus Ibsen Fix For: Future Currently when using a cxf consumer in a route, then all the operations is serviced by this route. This may confuse some people. As well some may want one route per operation. We should look into how we can support this. Today people would need to use the recipient list and direct endpoints to suport this. But many people dont know about this. See this example: http://camel.apache.org/cxf-tomcat-example.html I guess this is not so easy, as you would then have mutliple routes with the same CXF webservice. But we would like to have this level of indirection. And then I guess if a operation name is not bound to any route, then a soap fault should be thrown. Or we should allow to let Camel fail on startup saying that operation XXX is not bound to any consumer/route. Or something like that. Or allow people to turn this on|off. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-8547) Usage of camel-xmlbeans depends on TCCL
[ https://issues.apache.org/jira/browse/CAMEL-8547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang reassigned CAMEL-8547: --- Assignee: Willem Jiang Usage of camel-xmlbeans depends on TCCL --- Key: CAMEL-8547 URL: https://issues.apache.org/jira/browse/CAMEL-8547 Project: Camel Issue Type: Bug Affects Versions: 2.15.0 Reporter: James Netherton Assignee: Willem Jiang xmlbeans marshalling and unmarshalling does not respect the ApplicationContextClassLoader CrossRef: https://github.com/wildfly-extras/wildfly-camel/issues/457 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-8546) No LanguageResolver found for language=js
[
https://issues.apache.org/jira/browse/CAMEL-8546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang reassigned CAMEL-8546:
---
Assignee: Willem Jiang
No LanguageResolver found for language=js
-
Key: CAMEL-8546
URL: https://issues.apache.org/jira/browse/CAMEL-8546
Project: Camel
Issue Type: Bug
Components: camel-script
Affects Versions: 2.14.1
Reporter: Bart Horré
Assignee: Willem Jiang
Fix For: 2.16.0
{noformat}Unable to start blueprint container for bundle test.xml due to
unresolved dependencies
[((language=js)(objectClass=org.apache.camel.spi.LanguageResolver))]
java.util.concurrent.TimeoutException
at
org.apache.aries.blueprint.container.BlueprintContainerImpl$1.run(BlueprintContainerImpl.java:293)[10:org.apache.aries.blueprint:0.3.2]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)[:1.7.0_17]
at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)[:1.7.0_17]
at java.util.concurrent.FutureTask.run(FutureTask.java:166)[:1.7.0_17]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)[:1.7.0_17]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)[:1.7.0_17]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)[:1.7.0_17]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)[:1.7.0_17]
at java.lang.Thread.run(Thread.java:722)[:1.7.0_17] {noformat}
This happens when we try to use script with blueprint because blueprint tries
to resolve the LanguageResolver with filter language=js. However camel.osgi
registered a default LanguageResolver under resolver=default which causes
blueprint to wait for ever.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
