[jira] [Commented] (CAMEL-4707) Features descriptor should define the namespace

2014-03-08 Thread Christoph Emmersberger (JIRA)

[ 
https://issues.apache.org/jira/browse/CAMEL-4707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13924786#comment-13924786
 ] 

Christoph Emmersberger commented on CAMEL-4707:
---

I've updated the original thread, since the integration test issue still 
persists:

http://camel.465427.n5.nabble.com/camel-itest-karaf-Failure-due-some-XSD-validation-issue-td5024780.html#a5748485

 Features descriptor should define the namespace
 ---

 Key: CAMEL-4707
 URL: https://issues.apache.org/jira/browse/CAMEL-4707
 Project: Camel
  Issue Type: Improvement
  Components: karaf
Affects Versions: 2.8.3, 2.9.0
Reporter: Jean-Baptiste Onofré
Assignee: Jean-Baptiste Onofré
 Fix For: 3.0.0


 In future Karaf 3.0, the features XML validation will be required. It means 
 that the features XML descriptor should define the right namespace.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Commented] (CAMEL-7269) joinTransaction called for RESOURCE_LOCAL datasource

2014-03-08 Thread Claus Ibsen (JIRA)

[ 
https://issues.apache.org/jira/browse/CAMEL-7269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13925132#comment-13925132
 ] 

Claus Ibsen commented on CAMEL-7269:


Yeah maybe we should have an option on the component you can turn on|off to 
control if join should be called or not?

 joinTransaction called for RESOURCE_LOCAL datasource
 

 Key: CAMEL-7269
 URL: https://issues.apache.org/jira/browse/CAMEL-7269
 Project: Camel
  Issue Type: Bug
  Components: camel-jpa
Affects Versions: 2.12.0, 2.12.1, 2.12.2, 2.12.3
 Environment: tomcat+eclipselink+camel 2.12.2
Reporter: Hristo Sabev
 Fix For: 2.12.4, 2.13.0


 At line 82, JpaConsumer calls entityManager.joinTransaction(). This call 
 cannot really work in environmnent without JTA. This is a change since 2.11.x 
 and earlier versions where non JTA environments were supported



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (CAMEL-6707) Asynchronous Mode In camel-servlet, Servlet 3.0 AsyncContext

2014-03-08 Thread Claus Ibsen (JIRA)

 [ 
https://issues.apache.org/jira/browse/CAMEL-6707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-6707:
---

Priority: Major  (was: Minor)

 Asynchronous Mode In camel-servlet, Servlet 3.0 AsyncContext
 

 Key: CAMEL-6707
 URL: https://issues.apache.org/jira/browse/CAMEL-6707
 Project: Camel
  Issue Type: Improvement
  Components: camel-http, camel-servlet
Affects Versions: 2.13.0
Reporter: Jörg Schubert
 Fix For: Future


 My Goal is routing larger amounts of HTTP-Traffic 
 CamelServlet is blocking the HTTP-thread while message is being processed.
 I'm currently preparing a patch which uses AsyncContext and starts processor 
 in async mode. Hope that will improve throughput.
 The async feature is switchable by parameter. 
 I will attach a patch as soon as it works. 
 There is one point: To avoid conflicts geronimo-servlet_2.5_spec must be 
 replaced by geronimo-servlet_3.0_spec in parent pom.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (CAMEL-7269) joinTransaction called for RESOURCE_LOCAL datasource

2014-03-08 Thread Claus Ibsen (JIRA)

 [ 
https://issues.apache.org/jira/browse/CAMEL-7269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-7269:
---

Fix Version/s: 2.13.0
   2.12.4

 joinTransaction called for RESOURCE_LOCAL datasource
 

 Key: CAMEL-7269
 URL: https://issues.apache.org/jira/browse/CAMEL-7269
 Project: Camel
  Issue Type: Bug
  Components: camel-jpa
Affects Versions: 2.12.0, 2.12.1, 2.12.2, 2.12.3
 Environment: tomcat+eclipselink+camel 2.12.2
Reporter: Hristo Sabev
 Fix For: 2.12.4, 2.13.0


 At line 82, JpaConsumer calls entityManager.joinTransaction(). This call 
 cannot really work in environmnent without JTA. This is a change since 2.11.x 
 and earlier versions where non JTA environments were supported



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Resolved] (CAMEL-7270) New ListAggregationStrategy

2014-03-08 Thread Claus Ibsen (JIRA)

 [ 
https://issues.apache.org/jira/browse/CAMEL-7270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen resolved CAMEL-7270.


Resolution: Implemented

We have this functionality implemented already as Raul says.

Help with the docs is appreciated

 New ListAggregationStrategy
 ---

 Key: CAMEL-7270
 URL: https://issues.apache.org/jira/browse/CAMEL-7270
 Project: Camel
  Issue Type: Improvement
  Components: camel-core
Reporter: Jan Matèrne
Priority: Minor





--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (CAMEL-7266) TraceEventMessage should not return String in methods getProperties() and getHeaders()

2014-03-08 Thread Claus Ibsen (JIRA)

 [ 
https://issues.apache.org/jira/browse/CAMEL-7266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-7266:
---

Priority: Minor  (was: Major)

 TraceEventMessage should not return String in methods getProperties() and 
 getHeaders()
 --

 Key: CAMEL-7266
 URL: https://issues.apache.org/jira/browse/CAMEL-7266
 Project: Camel
  Issue Type: Wish
  Components: camel-core
Affects Versions: 2.12.3
Reporter: Marcus Krantz
Priority: Minor
 Fix For: 3.0.0


 I would like to save trace event messages into a MongoDB. Since there is no 
 need for a schema, I would like to persist properties and headers as pure 
 json.
 In the DefaultTraceEventMessage the properties map as well as the headers map 
 are converted to Strings (using toString()) due to the fact that the 
 TraceEventMessage interface defines the methods getProperties() and 
 getHeaders() to return a String. It would be much better if the headers and 
 properties could be left as is (MapString, Object) which would allow me to 
 persist the maps directly to my NoSQL-database.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Assigned] (CAMEL-7276) camel-quartz - use of management name to provide default scheduler name breaks context isolation

2014-03-08 Thread Claus Ibsen (JIRA)

 [ 
https://issues.apache.org/jira/browse/CAMEL-7276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen reassigned CAMEL-7276:
--

Assignee: Claus Ibsen

 camel-quartz - use of management name to provide default scheduler name 
 breaks context isolation
 

 Key: CAMEL-7276
 URL: https://issues.apache.org/jira/browse/CAMEL-7276
 Project: Camel
  Issue Type: Bug
  Components: camel-quartz
Affects Versions: 2.12.3
Reporter: Bob Browning
Assignee: Claus Ibsen

 When using the camel-quartz component in an unmanged context with multiple 
 camel contexts, for example in a JUnit test case, causes the scheduler to be 
 created with the instance name DefaultQuartzScheduler which is then shared 
 across all camel context's within the same jvm.
 This is in contradiction of the previous behaviour that uses 
 `getCamelContext.getName()` which isolates the scheduler by denoting that the 
 default instance is specific to the camel context.
 {code}
 package org.apache.camel.component.quartz;
 import org.apache.camel.CamelContext;
 import org.apache.camel.impl.DefaultCamelContext;
 import org.apache.camel.management.JmxSystemPropertyKeys;
 import org.junit.Test;
 import org.quartz.Scheduler;
 import org.quartz.SchedulerException;
 import static org.junit.Assert.assertNotEquals;
 import static org.junit.Assert.assertNotSame;
 /**
  * Test regression of camel-context isolation of default scheduler instance 
 introduced in CAMEL-7034.
  */
 public class QuartzComponentCamelContextSchedulerIsolationTest {
   @Test
   public void testSchedulerIsolation_unmanaged() throws Exception {
 disableJMX();
 testSchedulerIsolation();
   }
   @Test
   public void testSchedulerIsolation_managed() throws Exception {
 enableJMX();
 testSchedulerIsolation();
   }
   private void testSchedulerIsolation() throws Exception {
 CamelContext context = createCamelContext();
 context.start();
 CamelContext anotherContext = createCamelContext();
 assertNotEquals(anotherContext.getName(), context.getName());
 assertNotEquals(anotherContext, context);
 assertNotSame(getDefaultScheduler(context), 
 getDefaultScheduler(anotherContext));
   }
   /**
* Create a new camel context instance.
*/
   private DefaultCamelContext createCamelContext() {
 return new DefaultCamelContext();
   }
   /**
* Get the quartz component for the provided camel context.
*/
   private QuartzComponent getQuartzComponent(CamelContext context) {
 return context.getComponent(quartz, QuartzComponent.class);
   }
   /**
* Get the default scheduler for the provided camel context.
*/
   private Scheduler getDefaultScheduler(CamelContext context) throws 
 SchedulerException {
 return getQuartzComponent(context).getFactory().getScheduler();
   }
   /**
* Disables the JMX agent.
*/
   private void disableJMX() {
 System.setProperty(JmxSystemPropertyKeys.DISABLED, true);
   }
   /**
* Enables the JMX agent.
*/
   private void enableJMX() {
 System.setProperty(JmxSystemPropertyKeys.DISABLED, false);
   }
 }
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (CAMEL-7276) camel-quartz - use of management name to provide default scheduler name breaks context isolation

2014-03-08 Thread Claus Ibsen (JIRA)

 [ 
https://issues.apache.org/jira/browse/CAMEL-7276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-7276:
---

Fix Version/s: 2.13.0
   2.12.4

 camel-quartz - use of management name to provide default scheduler name 
 breaks context isolation
 

 Key: CAMEL-7276
 URL: https://issues.apache.org/jira/browse/CAMEL-7276
 Project: Camel
  Issue Type: Bug
  Components: camel-quartz
Affects Versions: 2.12.3
Reporter: Bob Browning
Assignee: Claus Ibsen
Priority: Minor
 Fix For: 2.12.4, 2.13.0


 When using the camel-quartz component in an unmanged context with multiple 
 camel contexts, for example in a JUnit test case, causes the scheduler to be 
 created with the instance name DefaultQuartzScheduler which is then shared 
 across all camel context's within the same jvm.
 This is in contradiction of the previous behaviour that uses 
 `getCamelContext.getName()` which isolates the scheduler by denoting that the 
 default instance is specific to the camel context.
 {code}
 package org.apache.camel.component.quartz;
 import org.apache.camel.CamelContext;
 import org.apache.camel.impl.DefaultCamelContext;
 import org.apache.camel.management.JmxSystemPropertyKeys;
 import org.junit.Test;
 import org.quartz.Scheduler;
 import org.quartz.SchedulerException;
 import static org.junit.Assert.assertNotEquals;
 import static org.junit.Assert.assertNotSame;
 /**
  * Test regression of camel-context isolation of default scheduler instance 
 introduced in CAMEL-7034.
  */
 public class QuartzComponentCamelContextSchedulerIsolationTest {
   @Test
   public void testSchedulerIsolation_unmanaged() throws Exception {
 disableJMX();
 testSchedulerIsolation();
   }
   @Test
   public void testSchedulerIsolation_managed() throws Exception {
 enableJMX();
 testSchedulerIsolation();
   }
   private void testSchedulerIsolation() throws Exception {
 CamelContext context = createCamelContext();
 context.start();
 CamelContext anotherContext = createCamelContext();
 assertNotEquals(anotherContext.getName(), context.getName());
 assertNotEquals(anotherContext, context);
 assertNotSame(getDefaultScheduler(context), 
 getDefaultScheduler(anotherContext));
   }
   /**
* Create a new camel context instance.
*/
   private DefaultCamelContext createCamelContext() {
 return new DefaultCamelContext();
   }
   /**
* Get the quartz component for the provided camel context.
*/
   private QuartzComponent getQuartzComponent(CamelContext context) {
 return context.getComponent(quartz, QuartzComponent.class);
   }
   /**
* Get the default scheduler for the provided camel context.
*/
   private Scheduler getDefaultScheduler(CamelContext context) throws 
 SchedulerException {
 return getQuartzComponent(context).getFactory().getScheduler();
   }
   /**
* Disables the JMX agent.
*/
   private void disableJMX() {
 System.setProperty(JmxSystemPropertyKeys.DISABLED, true);
   }
   /**
* Enables the JMX agent.
*/
   private void enableJMX() {
 System.setProperty(JmxSystemPropertyKeys.DISABLED, false);
   }
 }
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (CAMEL-7276) camel-quartz - use of management name to provide default scheduler name breaks context isolation

2014-03-08 Thread Claus Ibsen (JIRA)

 [ 
https://issues.apache.org/jira/browse/CAMEL-7276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-7276:
---

Priority: Minor  (was: Major)

 camel-quartz - use of management name to provide default scheduler name 
 breaks context isolation
 

 Key: CAMEL-7276
 URL: https://issues.apache.org/jira/browse/CAMEL-7276
 Project: Camel
  Issue Type: Bug
  Components: camel-quartz
Affects Versions: 2.12.3
Reporter: Bob Browning
Assignee: Claus Ibsen
Priority: Minor
 Fix For: 2.12.4, 2.13.0


 When using the camel-quartz component in an unmanged context with multiple 
 camel contexts, for example in a JUnit test case, causes the scheduler to be 
 created with the instance name DefaultQuartzScheduler which is then shared 
 across all camel context's within the same jvm.
 This is in contradiction of the previous behaviour that uses 
 `getCamelContext.getName()` which isolates the scheduler by denoting that the 
 default instance is specific to the camel context.
 {code}
 package org.apache.camel.component.quartz;
 import org.apache.camel.CamelContext;
 import org.apache.camel.impl.DefaultCamelContext;
 import org.apache.camel.management.JmxSystemPropertyKeys;
 import org.junit.Test;
 import org.quartz.Scheduler;
 import org.quartz.SchedulerException;
 import static org.junit.Assert.assertNotEquals;
 import static org.junit.Assert.assertNotSame;
 /**
  * Test regression of camel-context isolation of default scheduler instance 
 introduced in CAMEL-7034.
  */
 public class QuartzComponentCamelContextSchedulerIsolationTest {
   @Test
   public void testSchedulerIsolation_unmanaged() throws Exception {
 disableJMX();
 testSchedulerIsolation();
   }
   @Test
   public void testSchedulerIsolation_managed() throws Exception {
 enableJMX();
 testSchedulerIsolation();
   }
   private void testSchedulerIsolation() throws Exception {
 CamelContext context = createCamelContext();
 context.start();
 CamelContext anotherContext = createCamelContext();
 assertNotEquals(anotherContext.getName(), context.getName());
 assertNotEquals(anotherContext, context);
 assertNotSame(getDefaultScheduler(context), 
 getDefaultScheduler(anotherContext));
   }
   /**
* Create a new camel context instance.
*/
   private DefaultCamelContext createCamelContext() {
 return new DefaultCamelContext();
   }
   /**
* Get the quartz component for the provided camel context.
*/
   private QuartzComponent getQuartzComponent(CamelContext context) {
 return context.getComponent(quartz, QuartzComponent.class);
   }
   /**
* Get the default scheduler for the provided camel context.
*/
   private Scheduler getDefaultScheduler(CamelContext context) throws 
 SchedulerException {
 return getQuartzComponent(context).getFactory().getScheduler();
   }
   /**
* Disables the JMX agent.
*/
   private void disableJMX() {
 System.setProperty(JmxSystemPropertyKeys.DISABLED, true);
   }
   /**
* Enables the JMX agent.
*/
   private void enableJMX() {
 System.setProperty(JmxSystemPropertyKeys.DISABLED, false);
   }
 }
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Resolved] (CAMEL-7276) camel-quartz - use of management name to provide default scheduler name breaks context isolation

2014-03-08 Thread Claus Ibsen (JIRA)

 [ 
https://issues.apache.org/jira/browse/CAMEL-7276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen resolved CAMEL-7276.


Resolution: Fixed

 camel-quartz - use of management name to provide default scheduler name 
 breaks context isolation
 

 Key: CAMEL-7276
 URL: https://issues.apache.org/jira/browse/CAMEL-7276
 Project: Camel
  Issue Type: Bug
  Components: camel-quartz
Affects Versions: 2.12.3
Reporter: Bob Browning
Assignee: Claus Ibsen
Priority: Minor
 Fix For: 2.12.4, 2.13.0


 When using the camel-quartz component in an unmanged context with multiple 
 camel contexts, for example in a JUnit test case, causes the scheduler to be 
 created with the instance name DefaultQuartzScheduler which is then shared 
 across all camel context's within the same jvm.
 This is in contradiction of the previous behaviour that uses 
 `getCamelContext.getName()` which isolates the scheduler by denoting that the 
 default instance is specific to the camel context.
 {code}
 package org.apache.camel.component.quartz;
 import org.apache.camel.CamelContext;
 import org.apache.camel.impl.DefaultCamelContext;
 import org.apache.camel.management.JmxSystemPropertyKeys;
 import org.junit.Test;
 import org.quartz.Scheduler;
 import org.quartz.SchedulerException;
 import static org.junit.Assert.assertNotEquals;
 import static org.junit.Assert.assertNotSame;
 /**
  * Test regression of camel-context isolation of default scheduler instance 
 introduced in CAMEL-7034.
  */
 public class QuartzComponentCamelContextSchedulerIsolationTest {
   @Test
   public void testSchedulerIsolation_unmanaged() throws Exception {
 disableJMX();
 testSchedulerIsolation();
   }
   @Test
   public void testSchedulerIsolation_managed() throws Exception {
 enableJMX();
 testSchedulerIsolation();
   }
   private void testSchedulerIsolation() throws Exception {
 CamelContext context = createCamelContext();
 context.start();
 CamelContext anotherContext = createCamelContext();
 assertNotEquals(anotherContext.getName(), context.getName());
 assertNotEquals(anotherContext, context);
 assertNotSame(getDefaultScheduler(context), 
 getDefaultScheduler(anotherContext));
   }
   /**
* Create a new camel context instance.
*/
   private DefaultCamelContext createCamelContext() {
 return new DefaultCamelContext();
   }
   /**
* Get the quartz component for the provided camel context.
*/
   private QuartzComponent getQuartzComponent(CamelContext context) {
 return context.getComponent(quartz, QuartzComponent.class);
   }
   /**
* Get the default scheduler for the provided camel context.
*/
   private Scheduler getDefaultScheduler(CamelContext context) throws 
 SchedulerException {
 return getQuartzComponent(context).getFactory().getScheduler();
   }
   /**
* Disables the JMX agent.
*/
   private void disableJMX() {
 System.setProperty(JmxSystemPropertyKeys.DISABLED, true);
   }
   /**
* Enables the JMX agent.
*/
   private void enableJMX() {
 System.setProperty(JmxSystemPropertyKeys.DISABLED, false);
   }
 }
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Created] (CAMEL-7280) camel-quartz2 - Add options to configure job as durable

2014-03-08 Thread Claus Ibsen (JIRA)
Claus Ibsen created CAMEL-7280:
--

 Summary: camel-quartz2 - Add options to configure job as durable
 Key: CAMEL-7280
 URL: https://issues.apache.org/jira/browse/CAMEL-7280
 Project: Camel
  Issue Type: Improvement
  Components: camel-quartz2
Affects Versions: 2.12.3
Reporter: Claus Ibsen
Assignee: Claus Ibsen
 Fix For: 2.12.4, 2.13.0


See nabble
http://camel.465427.n5.nabble.com/Camel-Quartz2-Clustering-fails-due-to-durable-jobs-has-anyone-got-td5741030.html#a5748096

We need a way to configure the job builder to use durable jobs. As you cannot 
do as in quartz 1.x with job.durable=true - due the new builder api in quartz 
2.0.



--
This message was sent by Atlassian JIRA
(v6.2#6252)