from:"Christopher Hunt \(JIRA\)"

[jira] Updated: (CAMEL-3117) cxfbean and cxfrs components should honour jax-rs providers in the bean registry

2010-09-13 Thread Christopher Hunt (JIRA)


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

Christopher Hunt updated CAMEL-3117:


Attachment: (was: providers.diff)

 cxfbean and cxfrs components should honour jax-rs providers in the bean 
 registry
 

 Key: CAMEL-3117
 URL: https://issues.apache.org/activemq/browse/CAMEL-3117
 Project: Apache Camel
  Issue Type: Improvement
  Components: camel-cxf
Affects Versions: 2.4.0
 Environment: cxfrs and cxfbean
Reporter: Christopher Hunt
Assignee: Willem Jiang
 Attachments: providers.diff


 The cxfbean component does not presently provide a means of using custom 
 providers i.e. those customised JAX-RS classes that are annotated with the 
 @Provider declaration. 
 My recommendation is that objects instantiated in the bean container from 
 classes annotated with @Provider are automatically registered for use by the 
 cxfrs and cxfbean components. This includes message body writers/readers and 
 parameter handlers i.e. anything that can be presently expressed in the 
 cxf:rsServer/providers element.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (CAMEL-3117) cxfbean and cxfrs components should honour jax-rs providers in the bean registry

2010-09-13 Thread Christopher Hunt (JIRA)


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

Christopher Hunt resolved CAMEL-3117.
-

Fix Version/s: 2.5.0
   Resolution: Fixed

My patch resolves this issue and now provides a unit test. However I did just 
look at the unit test again and I think that line 36 of CxfBeanTest could 
benefit from a not-null check (even though no issue presented itself) i.e.

{code}
if (beanEndpoint.getProviders() != null) {
if (beanEndpoint.getProviders().size() == 2) {
testedEndpointWithProviders = true;
break;
} else if (beanEndpoint.getProviders().size() != 0) {
fail(Unexpected number of providers present);
}
}
{code}

 cxfbean and cxfrs components should honour jax-rs providers in the bean 
 registry
 

 Key: CAMEL-3117
 URL: https://issues.apache.org/activemq/browse/CAMEL-3117
 Project: Apache Camel
  Issue Type: Improvement
  Components: camel-cxf
Affects Versions: 2.4.0
 Environment: cxfrs and cxfbean
Reporter: Christopher Hunt
Assignee: Willem Jiang
 Fix For: 2.5.0

 Attachments: providers.diff


 The cxfbean component does not presently provide a means of using custom 
 providers i.e. those customised JAX-RS classes that are annotated with the 
 @Provider declaration. 
 My recommendation is that objects instantiated in the bean container from 
 classes annotated with @Provider are automatically registered for use by the 
 cxfrs and cxfbean components. This includes message body writers/readers and 
 parameter handlers i.e. anything that can be presently expressed in the 
 cxf:rsServer/providers element.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (CAMEL-3117) cxfbean and cxfrs components should honour jax-rs providers in the bean registry

2010-09-11 Thread Christopher Hunt (JIRA)


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

Christopher Hunt commented on CAMEL-3117:
-

I've subsequently thought that it'd be easier (and consistent) for the 
component to have a list of providers specified; in a similar fashion to how 
handlers are specified for the jetty component. For example:

.to(cxfbean:mybean?providers=#myprovider1,#myprovider2);

I'll attach the code required to make this happen.

 cxfbean and cxfrs components should honour jax-rs providers in the bean 
 registry
 

 Key: CAMEL-3117
 URL: https://issues.apache.org/activemq/browse/CAMEL-3117
 Project: Apache Camel
  Issue Type: Improvement
  Components: camel-cxf
Affects Versions: 2.4.0
 Environment: cxfrs and cxfbean
Reporter: Christopher Hunt

 The cxfbean component does not presently provide a means of using custom 
 providers i.e. those customised JAX-RS classes that are annotated with the 
 @Provider declaration. 
 My recommendation is that objects instantiated in the bean container from 
 classes annotated with @Provider are automatically registered for use by the 
 cxfrs and cxfbean components. This includes message body writers/readers and 
 parameter handlers i.e. anything that can be presently expressed in the 
 cxf:rsServer/providers element.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Issue Comment Edited: (CAMEL-3117) cxfbean and cxfrs components should honour jax-rs providers in the bean registry

2010-09-11 Thread Christopher Hunt (JIRA)

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

Christopher Hunt edited comment on CAMEL-3117 at 9/11/10 11:15 AM:
---

I've subsequently thought that it'd be easier (and consistent) for the
component to have a list of providers specified; in a similar fashion to how
handlers are specified for the jetty component. For example:

.to(cxfbean:mybean?providers=#myprovider1,#myprovider2);

This also means that I'm constraining the provider specification in the manner
above to the cxfbean component. This is because the cxfrs component already
allows the specification of providers via the cxf:rsServer element.

I'll attach the code required to make this happen for the cxfbean component now.

was (Author: hu...@internode.on.net):
I've subsequently thought that it'd be easier (and consistent) for the
component to have a list of providers specified; in a similar fashion to how
handlers are specified for the jetty component. For example:

.to(cxfbean:mybean?providers=#myprovider1,#myprovider2);

I'll attach the code required to make this happen.

cxfbean and cxfrs components should honour jax-rs providers in the bean
registry

Key: CAMEL-3117
URL: https://issues.apache.org/activemq/browse/CAMEL-3117
Project: Apache Camel
Issue Type: Improvement
Components: camel-cxf
Affects Versions: 2.4.0
Environment: cxfrs and cxfbean
Reporter: Christopher Hunt

The cxfbean component does not presently provide a means of using custom
providers i.e. those customised JAX-RS classes that are annotated with the
@Provider declaration.
My recommendation is that objects instantiated in the bean container from
classes annotated with @Provider are automatically registered for use by the
cxfrs and cxfbean components. This includes message body writers/readers and
parameter handlers i.e. anything that can be presently expressed in the
cxf:rsServer/providers element.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (CAMEL-3117) cxfbean and cxfrs components should honour jax-rs providers in the bean registry

2010-09-11 Thread Christopher Hunt (JIRA)


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

Christopher Hunt updated CAMEL-3117:


Attachment: providers.diff

Code modifications to the cxfbean component so that the declaration of JAX-RS 
providers is made possible.

 cxfbean and cxfrs components should honour jax-rs providers in the bean 
 registry
 

 Key: CAMEL-3117
 URL: https://issues.apache.org/activemq/browse/CAMEL-3117
 Project: Apache Camel
  Issue Type: Improvement
  Components: camel-cxf
Affects Versions: 2.4.0
 Environment: cxfrs and cxfbean
Reporter: Christopher Hunt
 Attachments: providers.diff


 The cxfbean component does not presently provide a means of using custom 
 providers i.e. those customised JAX-RS classes that are annotated with the 
 @Provider declaration. 
 My recommendation is that objects instantiated in the bean container from 
 classes annotated with @Provider are automatically registered for use by the 
 cxfrs and cxfbean components. This includes message body writers/readers and 
 parameter handlers i.e. anything that can be presently expressed in the 
 cxf:rsServer/providers element.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (CAMEL-3117) cxfbean and cxfrs components should honour jax-rs providers in the bean registry

2010-09-10 Thread Christopher Hunt (JIRA)


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

Christopher Hunt updated CAMEL-3117:


Summary: cxfbean and cxfrs components should honour jax-rs providers in the 
bean registry  (was: cxfrs components should honour providers in the bean 
registry)

 cxfbean and cxfrs components should honour jax-rs providers in the bean 
 registry
 

 Key: CAMEL-3117
 URL: https://issues.apache.org/activemq/browse/CAMEL-3117
 Project: Apache Camel
  Issue Type: Improvement
  Components: camel-cxf
Affects Versions: 2.4.0
 Environment: cxfrs and cxfbean
Reporter: Christopher Hunt

 The cxfbean component does not presently provide a means of using custom 
 providers i.e. those customised JAX-RS classes that are annotated with the 
 @Provider declaration. 
 My recommendation is that objects instantiated in the bean container from 
 classes annotated with @Provider are automatically registered for use by the 
 cxfrs and cxfbean components. This includes message body writers/readers and 
 parameter handlers i.e. anything that can be presently expressed in the 
 cxf:rsServer/providers element.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (CAMEL-2231) Exception during mail connection requires folder to be reset

2009-11-29 Thread Christopher Hunt (JIRA)


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

Christopher Hunt commented on CAMEL-2231:
-

Looks as though your patch fixed things up. I had a 2.1-SNAPSHOT service 
running over the weekend. There was an outage with the POP service which showed 
itself in the log file. I was then able to send an email subsequently (a day or 
so later) and all was well.

 Exception during mail connection requires folder to be reset
 

 Key: CAMEL-2231
 URL: https://issues.apache.org/activemq/browse/CAMEL-2231
 Project: Apache Camel
  Issue Type: Bug
  Components: camel-mail
Affects Versions: 1.6.2, 2.0.0
 Environment: 2.1-SNAPSHOT
Reporter: Christopher Hunt
Assignee: Claus Ibsen
 Fix For: 1.6.3, 2.1.0

 Attachments: camel-mail-2.1-SNAPSHOT.jar

   Original Estimate: 2 hours
  Remaining Estimate: 2 hours

 I think that this problem may still be around with 2.1-SNAPSHOT:
 http://fusesource.com/forums/thread.jspa?threadID=746tstart=0
 I noticed that I had a pop3 server outage and then subsequently had a similar 
 problem i.e. IllegalStateException, folder not open.
 Here's when the outage started.
 {code}
 2009-11-26 11:57:55,316 [: MailComponent] WARN  
 ultPollingConsumerPollStrategy - Consumer Consumer[pop3://...] could not poll 
 endpoint: pop3://... caused by: Connect failed
 javax.mail.MessagingException: Connect failed;
   nested exception is:
 java.net.NoRouteToHostException: No route to host
 at com.sun.mail.pop3.POP3Store.protocolConnect(POP3Store.java:161)
 at javax.mail.Service.connect(Service.java:288)
 at 
 org.apache.camel.component.mail.MailConsumer.ensureIsConnected(MailConsumer.java:241)
 at 
 org.apache.camel.component.mail.MailConsumer.poll(MailConsumer.java:79)
 at 
 org.apache.camel.impl.ScheduledPollConsumer.run(ScheduledPollConsumer.java:108)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
 at 
 java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
 at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:619)
 Caused by: java.net.NoRouteToHostException: No route to host
 at java.net.PlainSocketImpl.socketConnect(Native Method)
 at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
 at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
 at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
 at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
 at java.net.Socket.connect(Socket.java:519)
 at java.net.Socket.connect(Socket.java:469)
 at 
 com.sun.mail.util.SocketFetcher.createSocket(SocketFetcher.java:233)
 at com.sun.mail.util.SocketFetcher.getSocket(SocketFetcher.java:189)
 at com.sun.mail.pop3.Protocol.init(Protocol.java:94)
 at com.sun.mail.pop3.POP3Store.getPort(POP3Store.java:214)
 at com.sun.mail.pop3.POP3Store.protocolConnect(POP3Store.java:157)
 ... 13 more
 {code}
 This went on for about a minute or so and there was no more in the log file 
 until several hours later - in fact when an email appeared in the INBOX. I 
 know this because my personal email account was copied on the email and so I 
 have the timestamp.
 I then get the following message every time I poll the server and have to 
 re-start my application to get over it:
 {code}
 2009-11-26 19:19:57,293 [: MailComponent] ERROR MailConsumer  
  - Folder not open
 java.lang.IllegalStateException: Folder not open
 at javax.mail.Folder.getMessages(Folder.java:938)
 at javax.mail.Folder.search(Folder.java:1226)
 at 
 org.apache.camel.component.mail.MailConsumer.poll(MailConsumer.java:107)
 at 
 org.apache.camel.impl.ScheduledPollConsumer.run(ScheduledPollConsumer.java:108)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
 at 
 java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
 at

[jira] Created: (CAMEL-2231) Exception during mail connection requires folder to be reset

2009-11-26 Thread Christopher Hunt (JIRA)

Exception during mail connection requires folder to be reset


 Key: CAMEL-2231
 URL: https://issues.apache.org/activemq/browse/CAMEL-2231
 Project: Apache Camel
  Issue Type: Bug
  Components: camel-mail
Affects Versions: 2.0.0, 1.6.2
 Environment: 2.1-SNAPSHOT
Reporter: Christopher Hunt


I think that this problem may still be around with 2.1-SNAPSHOT:

http://fusesource.com/forums/thread.jspa?threadID=746tstart=0

I noticed that I had a pop3 server outage and then subsequently had a similar 
problem i.e. IllegalStateException, folder not open.

Here's when the outage started.

{code}
2009-11-26 11:57:55,316 [: MailComponent] WARN  ultPollingConsumerPollStrategy 
- Consumer Consumer[pop3://...] could not poll endpoint: pop3://... caused by: 
Connect failed
javax.mail.MessagingException: Connect failed;
  nested exception is:
java.net.NoRouteToHostException: No route to host
at com.sun.mail.pop3.POP3Store.protocolConnect(POP3Store.java:161)
at javax.mail.Service.connect(Service.java:288)
at 
org.apache.camel.component.mail.MailConsumer.ensureIsConnected(MailConsumer.java:241)
at 
org.apache.camel.component.mail.MailConsumer.poll(MailConsumer.java:79)
at 
org.apache.camel.impl.ScheduledPollConsumer.run(ScheduledPollConsumer.java:108)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at 
java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.net.NoRouteToHostException: No route to host
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:519)
at java.net.Socket.connect(Socket.java:469)
at com.sun.mail.util.SocketFetcher.createSocket(SocketFetcher.java:233)
at com.sun.mail.util.SocketFetcher.getSocket(SocketFetcher.java:189)
at com.sun.mail.pop3.Protocol.init(Protocol.java:94)
at com.sun.mail.pop3.POP3Store.getPort(POP3Store.java:214)
at com.sun.mail.pop3.POP3Store.protocolConnect(POP3Store.java:157)
... 13 more
{code}

This went on for about a minute or so and there was no more in the log file 
until several hours later - in fact when an email appeared in the INBOX. I know 
this because my personal email account was copied on the email and so I have 
the timestamp.

I then get the following message every time I poll the server and have to 
re-start my application to get over it:

{code}
2009-11-26 19:19:57,293 [: MailComponent] ERROR MailConsumer   
- Folder not open
java.lang.IllegalStateException: Folder not open
at javax.mail.Folder.getMessages(Folder.java:938)
at javax.mail.Folder.search(Folder.java:1226)
at 
org.apache.camel.component.mail.MailConsumer.poll(MailConsumer.java:107)
at 
org.apache.camel.impl.ScheduledPollConsumer.run(ScheduledPollConsumer.java:108)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at 
java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
{code}

I took a look at MailConsumer.java and note the following code:

{code}
236 if

[jira] Commented: (CAMEL-2231) Exception during mail connection requires folder to be reset

2009-11-26 Thread Christopher Hunt (JIRA)


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

Christopher Hunt commented on CAMEL-2231:
-

Gee that was a quick fix! Will this get automatically included in the next site 
build? I can rebuild my project in about 10 hours (late at night now). Should 
it not pick up your mod in the latest 2.1-snapshot?

 Exception during mail connection requires folder to be reset
 

 Key: CAMEL-2231
 URL: https://issues.apache.org/activemq/browse/CAMEL-2231
 Project: Apache Camel
  Issue Type: Bug
  Components: camel-mail
Affects Versions: 1.6.2, 2.0.0
 Environment: 2.1-SNAPSHOT
Reporter: Christopher Hunt
Assignee: Claus Ibsen
 Fix For: 1.6.3, 2.1.0

   Original Estimate: 2 hours
  Remaining Estimate: 2 hours

 I think that this problem may still be around with 2.1-SNAPSHOT:
 http://fusesource.com/forums/thread.jspa?threadID=746tstart=0
 I noticed that I had a pop3 server outage and then subsequently had a similar 
 problem i.e. IllegalStateException, folder not open.
 Here's when the outage started.
 {code}
 2009-11-26 11:57:55,316 [: MailComponent] WARN  
 ultPollingConsumerPollStrategy - Consumer Consumer[pop3://...] could not poll 
 endpoint: pop3://... caused by: Connect failed
 javax.mail.MessagingException: Connect failed;
   nested exception is:
 java.net.NoRouteToHostException: No route to host
 at com.sun.mail.pop3.POP3Store.protocolConnect(POP3Store.java:161)
 at javax.mail.Service.connect(Service.java:288)
 at 
 org.apache.camel.component.mail.MailConsumer.ensureIsConnected(MailConsumer.java:241)
 at 
 org.apache.camel.component.mail.MailConsumer.poll(MailConsumer.java:79)
 at 
 org.apache.camel.impl.ScheduledPollConsumer.run(ScheduledPollConsumer.java:108)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
 at 
 java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
 at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:619)
 Caused by: java.net.NoRouteToHostException: No route to host
 at java.net.PlainSocketImpl.socketConnect(Native Method)
 at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
 at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
 at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
 at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
 at java.net.Socket.connect(Socket.java:519)
 at java.net.Socket.connect(Socket.java:469)
 at 
 com.sun.mail.util.SocketFetcher.createSocket(SocketFetcher.java:233)
 at com.sun.mail.util.SocketFetcher.getSocket(SocketFetcher.java:189)
 at com.sun.mail.pop3.Protocol.init(Protocol.java:94)
 at com.sun.mail.pop3.POP3Store.getPort(POP3Store.java:214)
 at com.sun.mail.pop3.POP3Store.protocolConnect(POP3Store.java:157)
 ... 13 more
 {code}
 This went on for about a minute or so and there was no more in the log file 
 until several hours later - in fact when an email appeared in the INBOX. I 
 know this because my personal email account was copied on the email and so I 
 have the timestamp.
 I then get the following message every time I poll the server and have to 
 re-start my application to get over it:
 {code}
 2009-11-26 19:19:57,293 [: MailComponent] ERROR MailConsumer  
  - Folder not open
 java.lang.IllegalStateException: Folder not open
 at javax.mail.Folder.getMessages(Folder.java:938)
 at javax.mail.Folder.search(Folder.java:1226)
 at 
 org.apache.camel.component.mail.MailConsumer.poll(MailConsumer.java:107)
 at 
 org.apache.camel.impl.ScheduledPollConsumer.run(ScheduledPollConsumer.java:108)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
 at 
 java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
 at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
 at

[jira] Reopened: (CAMEL-825) async endpoints like SEDA and VM do not work with InOut and Spring Remoting - as the caller does not wait for the exchange to be completed

2009-05-25 Thread Christopher Hunt (JIRA)


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

Christopher Hunt reopened CAMEL-825:



I see the seda queue as being very similar to a jms queue in Camel with the 
main difference being no persistence; which is fine. In fact I would probably 
use a seda endpoint pretty much everywhere I'd use a JMS queue endpoint where I 
do not require persistence.

I think that request reply should therefore be supported for seda.

 async endpoints like SEDA and VM do not work with InOut and Spring Remoting - 
 as the caller does not wait for the exchange to be completed
 --

 Key: CAMEL-825
 URL: https://issues.apache.org/activemq/browse/CAMEL-825
 Project: Apache Camel
  Issue Type: Bug
Reporter: James Strachan
 Fix For: 2.0.0




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (CAMEL-1570) Jetty component is unable to be configured for security

2009-05-07 Thread Christopher Hunt (JIRA)


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

Christopher Hunt commented on CAMEL-1570:
-

Hi Claus,

1.x patches attached. I have not addressed 2.0. With regards to:

_In Camel 2.0 however I was wondering if we should endorse the # notation 
lookup that is used in the URI to refer to a bean in the registry with this id._

I think so.

_And if we just added the type on the endpoint as: ListHandler handlers with 
getter/setter then we can improve the DefaultComponent to support lists for its 
automatic # lookup._

Do you mean ListString not ListHandler? Or do you think that the 
DefaultComponent could resolve the type from the bean's name?

_Today it only supports a single # property. If so we get a general solution. 
So I would like that we took the time to look into this in Camel 2.0._

How would a list be expressed in the URI? The same way as for 1.x i.e. using a 
comma?

_See method setReferenceProperties in DefaultComponent in Camel 2.0._

I'm going to need your help on this one I think.

 Jetty component is unable to be configured for security
 ---

 Key: CAMEL-1570
 URL: https://issues.apache.org/activemq/browse/CAMEL-1570
 Project: Apache Camel
  Issue Type: Improvement
  Components: camel-jetty
Affects Versions: 1.6.0, 2.0-M1
 Environment: NA
Reporter: Christopher Hunt
 Attachments: jetty-handlers-test.txt, jetty-handlers.txt


 The Jetty component is presently unable to be configured for security. A 
 general purpose mechanism so that the Jetty component can be configured would 
 be useful. The following URI based option is proposed:
 ||Name||Default Value||Description||
 |handlers|null| Specifies a comma delimited set of instances in your Registry 
 (such as your Spring ApplicationContext). These instances are added to the 
 Jetty servlet context|
 Here is an example URI:
 {code}
 jetty:http://0.0.0.0:9080/MyService?handlers=securityHandler
 {code}
 This could refer to something like the following Spring configuration:
 {code}
   !-- Jetty Security handling --
   bean id=userRealm class=org.mortbay.jetty.plus.jaas.JAASUserRealm
   property name=name value=tracker-users /
   property name=loginModuleName value=ldaploginmodule /
   /bean
   bean id=constraint class=org.mortbay.jetty.security.Constraint
   property name=name value=BASIC /
   property name=roles value=tracker-users /
   property name=authenticate value=true /
   /bean
   bean id=constraintMapping 
 class=org.mortbay.jetty.security.ConstraintMapping
   property name=constraint ref=constraint /
   property name=pathSpec value=/* /
   /bean
   bean id=securityHandler 
 class=org.mortbay.jetty.security.SecurityHandler
   property name=userRealm ref=userRealm /
   property name=constraintMappings ref=constraintMapping /
   /bean
 {code}
 I have attached proposed changes to the 1.6 branch. I imagine that 2.0 should 
 be quite similar.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (CAMEL-1570) Jetty component is unable to be configured for security

2009-05-07 Thread Christopher Hunt (JIRA)


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

Christopher Hunt updated CAMEL-1570:


Attachment: jetty-handlers-test.txt
jetty-handlers.txt

1.x changes.

I have deleted the previous patches given that there was an error. Previously I 
attached the handlers to the first context that the server could provide (as is 
done for the session - is that a bug also?). What is now done is that the 
handlers are attached to the context created at the time the servlet is created.

I have included a new unit test to test out the handler functionality. I use a 
Jetty supplied statistics handler to ensure that it counts my requests coming 
through. Naturally if the handler was not added to the context then no requests 
would be counted.

In addition the unit test exercises multiple handlers being included for a 
different context. This tests that multiple handlers are catered for and that 
one context's handlers are not invoked for another's.

I have also tidied up the test cases so that they are able to:

(i) execute on a file system that has spaces in the path name; and
(ii) execute on a system that is not running postgres.

On the latter I noticed that port 5432 was being used for some of the tests. 
This port is used by postgres. Given that I had postgres running on my machine 
the tests could not complete. All tests now use a port number around 9080.

 Jetty component is unable to be configured for security
 ---

 Key: CAMEL-1570
 URL: https://issues.apache.org/activemq/browse/CAMEL-1570
 Project: Apache Camel
  Issue Type: Improvement
  Components: camel-jetty
Affects Versions: 1.6.0, 2.0-M1
 Environment: NA
Reporter: Christopher Hunt
 Attachments: jetty-handlers-test.txt, jetty-handlers.txt


 The Jetty component is presently unable to be configured for security. A 
 general purpose mechanism so that the Jetty component can be configured would 
 be useful. The following URI based option is proposed:
 ||Name||Default Value||Description||
 |handlers|null| Specifies a comma delimited set of instances in your Registry 
 (such as your Spring ApplicationContext). These instances are added to the 
 Jetty servlet context|
 Here is an example URI:
 {code}
 jetty:http://0.0.0.0:9080/MyService?handlers=securityHandler
 {code}
 This could refer to something like the following Spring configuration:
 {code}
   !-- Jetty Security handling --
   bean id=userRealm class=org.mortbay.jetty.plus.jaas.JAASUserRealm
   property name=name value=tracker-users /
   property name=loginModuleName value=ldaploginmodule /
   /bean
   bean id=constraint class=org.mortbay.jetty.security.Constraint
   property name=name value=BASIC /
   property name=roles value=tracker-users /
   property name=authenticate value=true /
   /bean
   bean id=constraintMapping 
 class=org.mortbay.jetty.security.ConstraintMapping
   property name=constraint ref=constraint /
   property name=pathSpec value=/* /
   /bean
   bean id=securityHandler 
 class=org.mortbay.jetty.security.SecurityHandler
   property name=userRealm ref=userRealm /
   property name=constraintMappings ref=constraintMapping /
   /bean
 {code}
 I have attached proposed changes to the 1.6 branch. I imagine that 2.0 should 
 be quite similar.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (CAMEL-1570) Jetty component is unable to be configured for security

2009-05-06 Thread Christopher Hunt (JIRA)


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

Christopher Hunt updated CAMEL-1570:


Attachment: (was: JettyHttpEndpoint.java.diff)

 Jetty component is unable to be configured for security
 ---

 Key: CAMEL-1570
 URL: https://issues.apache.org/activemq/browse/CAMEL-1570
 Project: Apache Camel
  Issue Type: Improvement
  Components: camel-jetty
Affects Versions: 1.6.0, 2.0-M1
 Environment: NA
Reporter: Christopher Hunt

 The Jetty component is presently unable to be configured for security. A 
 general purpose mechanism so that the Jetty component can be configured would 
 be useful. The following URI based option is proposed:
 ||Name||Default Value||Description||
 |handlers|null| Specifies a comma delimited set of instances in your Registry 
 (such as your Spring ApplicationContext). These instances are added to the 
 Jetty servlet context|
 Here is an example URI:
 {code}
 jetty:http://0.0.0.0:9080/MyService?handlers=securityHandler
 {code}
 This could refer to something like the following Spring configuration:
 {code}
   !-- Jetty Security handling --
   bean id=userRealm class=org.mortbay.jetty.plus.jaas.JAASUserRealm
   property name=name value=tracker-users /
   property name=loginModuleName value=ldaploginmodule /
   /bean
   bean id=constraint class=org.mortbay.jetty.security.Constraint
   property name=name value=BASIC /
   property name=roles value=tracker-users /
   property name=authenticate value=true /
   /bean
   bean id=constraintMapping 
 class=org.mortbay.jetty.security.ConstraintMapping
   property name=constraint ref=constraint /
   property name=pathSpec value=/* /
   /bean
   bean id=securityHandler 
 class=org.mortbay.jetty.security.SecurityHandler
   property name=userRealm ref=userRealm /
   property name=constraintMappings ref=constraintMapping /
   /bean
 {code}
 I have attached proposed changes to the 1.6 branch. I imagine that 2.0 should 
 be quite similar.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (CAMEL-1570) Jetty component is unable to be configured for security

2009-05-06 Thread Christopher Hunt (JIRA)


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

Christopher Hunt updated CAMEL-1570:


Attachment: (was: JettyHttpComponent.java.diff)

 Jetty component is unable to be configured for security
 ---

 Key: CAMEL-1570
 URL: https://issues.apache.org/activemq/browse/CAMEL-1570
 Project: Apache Camel
  Issue Type: Improvement
  Components: camel-jetty
Affects Versions: 1.6.0, 2.0-M1
 Environment: NA
Reporter: Christopher Hunt

 The Jetty component is presently unable to be configured for security. A 
 general purpose mechanism so that the Jetty component can be configured would 
 be useful. The following URI based option is proposed:
 ||Name||Default Value||Description||
 |handlers|null| Specifies a comma delimited set of instances in your Registry 
 (such as your Spring ApplicationContext). These instances are added to the 
 Jetty servlet context|
 Here is an example URI:
 {code}
 jetty:http://0.0.0.0:9080/MyService?handlers=securityHandler
 {code}
 This could refer to something like the following Spring configuration:
 {code}
   !-- Jetty Security handling --
   bean id=userRealm class=org.mortbay.jetty.plus.jaas.JAASUserRealm
   property name=name value=tracker-users /
   property name=loginModuleName value=ldaploginmodule /
   /bean
   bean id=constraint class=org.mortbay.jetty.security.Constraint
   property name=name value=BASIC /
   property name=roles value=tracker-users /
   property name=authenticate value=true /
   /bean
   bean id=constraintMapping 
 class=org.mortbay.jetty.security.ConstraintMapping
   property name=constraint ref=constraint /
   property name=pathSpec value=/* /
   /bean
   bean id=securityHandler 
 class=org.mortbay.jetty.security.SecurityHandler
   property name=userRealm ref=userRealm /
   property name=constraintMappings ref=constraintMapping /
   /bean
 {code}
 I have attached proposed changes to the 1.6 branch. I imagine that 2.0 should 
 be quite similar.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (CAMEL-1499) LDAP documentation could be improved

2009-05-05 Thread Christopher Hunt (JIRA)

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

Christopher Hunt resolved CAMEL-1499.
-

Resolution: Fixed
Fix Version/s: 1.6.0
2.0-M1

Documentation has been updated.

LDAP documentation could be improved

Key: CAMEL-1499
URL: https://issues.apache.org/activemq/browse/CAMEL-1499
Project: Apache Camel
Issue Type: Improvement
Components: camel-ldap
Affects Versions: 1.6.0, 2.0-M1
Environment: Wiki pages
Reporter: Christopher Hunt
Fix For: 2.0-M1, 1.6.0

On familiarising myself with the ldap component I found that I had to trawl
through the source code to gain a good understanding of how it should be used.
For example (http://camel.apache.org/ldap.html):
In the sample below we fetch the rows from the customer table.
First we register our datasource in the Camel registry as testdb:
is entirely incorrect. Perhaps it should say:
In the sample below we create a JNDI DirContext and register it with our
Camel context's JNDI registry. The key used for registration is the remaining
part of the ldap URI i.e. the part without the ldap: and URI parameters. The
DirContext should establish any authentication requirements with the LDAP
repository.
I then think that the example should illustrate how an anonymous DirContext
can be established outside of any ApacheDS dependencies e.g.:
{code}
HashtableObject, Object env = new HashtableObject, Object();
env.put(Context.INITIAL_CONTEXT_FACTORY, initialContextFactory);
env.put(Context.PROVIDER_URL, providerURL);
env.put(Context.SECURITY_AUTHENTICATION, none);
DirContext ctx = new InitialDirContext(env);
{code}

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (CAMEL-1583) ldap component is not thread safe

2009-05-04 Thread Christopher Hunt (JIRA)

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

Christopher Hunt commented on CAMEL-1583:
-

I forgot to mention that I ran the ldap unit tests and all was well. In
addition I used the modified class within my application and confiirmed (using
the debugger) that a new context instance was being used each time.

ldap component is not thread safe
-

Key: CAMEL-1583
URL: https://issues.apache.org/activemq/browse/CAMEL-1583
Project: Apache Camel
Issue Type: Bug
Components: camel-ldap
Affects Versions: 1.6.0, 2.0-M1
Environment: N/A
Reporter: Christopher Hunt
Attachments: LdapProducer.java.diff

JNDI context objects are not thread-safe. The LDAP component shares a
directory context across all threads that use the component. This is not safe.
In addition the LDAP component will attempt to establish a connection on
instantiation of the component, and not when the component is required to
process requests. If the LDAP server is not ready e.g. temporarily
unavailable then the entire Camel application will stop.
JNDI directory contexts should be established when a consuming thread needs
it and should be released when the thread is finished with the component i.e.:
{code}
ctx = new InitialDirContext(env);
try {
...
} finally {
ctx.close();
}
{code}
The above will release the connection with the LDAP server as soon as
possible. The existing component relies on JNDI to release the socket in its
own time (several seconds later).

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Issue Comment Edited: (CAMEL-1583) ldap component is not thread safe

2009-05-04 Thread Christopher Hunt (JIRA)

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

Christopher Hunt edited comment on CAMEL-1583 at 5/4/09 1:56 AM:
-

Changes to the 1.6.1 branch.

In essence a context is retrieved from the registry each time that an exchange
is to be produced.

Given that the contract for an InitialContext states:

_An InitialContext instance is not synchronized against concurrent access by
multiple threads. Multiple threads each manipulating a different InitialContext
instance need not synchronize. Threads that need to access a single
InitialContext instance concurrently should synchronize amongst themselves and
provide the necessary locking._

...the registry entry should either: (a) provide an InitialContext that is
known to be thread safe; or (b) ensure that the registry instantiates a new
bean each time that the bean is looked up. The latter will be the general
situation and so, for example with Spring IOC, use a bean declaration similar
to:

{code}
!-- Directory Context --
bean id=ldapserver class=javax.naming.directory.InitialDirContext
scope=prototype
constructor-arg
props
prop
key=java.naming.factory.initialcom.sun.jndi.ldap.LdapCtxFactory/prop
prop
key=java.naming.provider.urlldap://localhost:10389/prop
prop
key=java.naming.security.authenticationnone/prop
/props
/constructor-arg
/bean
{code}

It is important to use a prototype scope to ensure that a new directory context
is obtained for each exchange produced.

was (Author: hu...@internode.on.net):
Changes to the 1.6.1 branch.

In essence a context is retrieved from the registry each time that an exchange
is to be produced.

Given that the contract for an InitialContext states:

The registry entry should either: (a) provide an InitialContext that is known
to be thread safe; or (b) ensure that the registry instantiates a new bean each
time that the bean is looked up. The latter will be the general situation and
so, for example with Spring IOC, use a bean declaration similar to:

It is important to use a prototype scope to ensure that a new directory context
is obtained for each exchange produced.

ldap component is not thread safe
-

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (CAMEL-1583) ldap component is not thread safe

2009-05-03 Thread Christopher Hunt (JIRA)

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

Christopher Hunt updated CAMEL-1583:

Attachment: LdapProducer.java.diff

Changes to the 1.6.1 branch.

In essence a context is retrieved from the registry each time that an exchange
is to be produced.

Given that the contract for an InitialContext states:

It is important to use a prototype scope to ensure that a new directory context
is obtained for each exchange produced.

ldap component is not thread safe
-

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (CAMEL-1583) ldap component is not thread safe

2009-05-02 Thread Christopher Hunt (JIRA)

ldap component is not thread safe
-

 Key: CAMEL-1583
 URL: https://issues.apache.org/activemq/browse/CAMEL-1583
 Project: Apache Camel
  Issue Type: Bug
  Components: camel-ldap
Affects Versions: 2.0-M1, 1.6.0
 Environment: N/A
Reporter: Christopher Hunt


JNDI context objects are not thread-safe. The LDAP component shares a directory 
context across all threads that use the component. This is not safe.

In addition the LDAP component will attempt to establish a connection on 
instantiation of the component, and not when the component is required to 
process requests. If the LDAP server is not ready e.g. temporarily unavailable 
then the entire Camel application will stop.

JNDI directory contexts should be established when a consuming thread needs it 
and should be released when the thread is finished with the component i.e.:

{code}
ctx = new InitialDirContext(env);
try {
  ...
} finally {
  ctx.close();
}
{code}

The above will release the connection with the LDAP server as soon as possible. 
The existing component relies on JNDI to release the socket in its own time 
(several seconds later).


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (CAMEL-1570) Jetty component is unable to be configured for security

2009-04-30 Thread Christopher Hunt (JIRA)


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

Christopher Hunt commented on CAMEL-1570:
-

Hi Claus,

I'm happy develop a unit test for this of course. In the first  
instance, can you please review my proposal and code submission? If it  
looks good then I'll proceed with the unit test and update the wiki  
once committed.

Kind regards,
Christopher


 Jetty component is unable to be configured for security
 ---

 Key: CAMEL-1570
 URL: https://issues.apache.org/activemq/browse/CAMEL-1570
 Project: Apache Camel
  Issue Type: Improvement
  Components: camel-jetty
Affects Versions: 1.6.0, 2.0-M1
 Environment: NA
Reporter: Christopher Hunt
 Attachments: JettyHttpComponent.java.diff, JettyHttpEndpoint.java.diff


 The Jetty component is presently unable to be configured for security. A 
 general purpose mechanism so that the Jetty component can be configured would 
 be useful. The following URI based option is proposed:
 ||Name||Default Value||Description||
 |handlers|null| Specifies a comma delimited set of instances in your Registry 
 (such as your Spring ApplicationContext). These instances are added to the 
 Jetty servlet context|
 Here is an example URI:
 {code}
 jetty:http://0.0.0.0:9080/MyService?handlers=securityHandler
 {code}
 This could refer to something like the following Spring configuration:
 {code}
   !-- Jetty Security handling --
   bean id=userRealm class=org.mortbay.jetty.plus.jaas.JAASUserRealm
   property name=name value=tracker-users /
   property name=loginModuleName value=ldaploginmodule /
   /bean
   bean id=constraint class=org.mortbay.jetty.security.Constraint
   property name=name value=BASIC /
   property name=roles value=tracker-users /
   property name=authenticate value=true /
   /bean
   bean id=constraintMapping 
 class=org.mortbay.jetty.security.ConstraintMapping
   property name=constraint ref=constraint /
   property name=pathSpec value=/* /
   /bean
   bean id=securityHandler 
 class=org.mortbay.jetty.security.SecurityHandler
   property name=userRealm ref=userRealm /
   property name=constraintMappings ref=constraintMapping /
   /bean
 {code}
 I have attached proposed changes to the 1.6 branch. I imagine that 2.0 should 
 be quite similar.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (CAMEL-1176) Add support for jetty user security realms

2009-04-30 Thread Christopher Hunt (JIRA)


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

Christopher Hunt commented on CAMEL-1176:
-

Hi Ramon,

Can you please look at 
[CAMEL-1570|https://issues.apache.org/activemq/browse/CAMEL-1570] as I think 
it'll solve this problem and much more.

Kind regards,
Christopher

 Add support for jetty user security realms
 --

 Key: CAMEL-1176
 URL: https://issues.apache.org/activemq/browse/CAMEL-1176
 Project: Apache Camel
  Issue Type: New Feature
  Components: camel-jetty
Reporter: Ramon Buckland
Priority: Minor

 Add the ability to provide a user realm into jetty to configure 
 authentication, by whatever means jetty provides.
 See Jetty for details 
 http://docs.codehaus.org/display/JETTY/How+to+Configure+Security+with+Embedded+Jetty

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (CAMEL-1570) Jetty component is unable to be configured for security

2009-04-28 Thread Christopher Hunt (JIRA)


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

Christopher Hunt updated CAMEL-1570:


Description: 
The Jetty component is presently unable to be configured for security. A 
general purpose mechanism so that the Jetty component can be configured would 
be useful. The following URI based option is proposed:

||Name||Default Value||Description||
|handlers|null| Specifies a comma delimited set of instances in your Registry 
(such as your Spring ApplicationContext). These instances are added to the 
Jetty servlet context|

Here is an example URI:

{code}
jetty:http://0.0.0.0:9080/MyService?handlers=securityHandler
{code}

This could refer to something like the following Spring configuration:

{code}
!-- Jetty Security handling --
bean id=userRealm class=org.mortbay.jetty.plus.jaas.JAASUserRealm
property name=name value=tracker-users /
property name=loginModuleName value=ldaploginmodule /
/bean
bean id=constraint class=org.mortbay.jetty.security.Constraint
property name=name value=BASIC /
property name=roles value=tracker-users /
property name=authenticate value=true /
/bean
bean id=constraintMapping 
class=org.mortbay.jetty.security.ConstraintMapping
property name=constraint ref=constraint /
property name=pathSpec value=/* /
/bean
bean id=securityHandler 
class=org.mortbay.jetty.security.SecurityHandler
property name=userRealm ref=userRealm /
property name=constraintMappings ref=constraintMapping /
/bean
{code}

I have attached proposed changes to the 1.6 branch. I imagine that 2.0 should 
be quite similar.

  was:
The Jetty component is presently unable to be configured for security. A 
general purpose mechanism so that the Jetty component can be configured would 
be useful. The following URI based option is proposed:

||Name||Default Value||Description||
|handlers|null| Specifies a comma delimited set of instances in your Registry 
(such as your Spring ApplicationContext). This instances are added to the Jetty 
servlet context|

Here is an example URI:

{code}
jetty:http://0.0.0.0:9080/MyService?handlers=securityHandler
{code}

This could refer to something like the following Spring configuration:

{code}
!-- Jetty Security handling --
bean id=userRealm class=org.mortbay.jetty.plus.jaas.JAASUserRealm
property name=name value=tracker-users /
property name=loginModuleName value=ldaploginmodule /
/bean
bean id=constraint class=org.mortbay.jetty.security.Constraint
property name=name value=BASIC /
property name=roles value=tracker-users /
property name=authenticate value=true /
/bean
bean id=constraintMapping 
class=org.mortbay.jetty.security.ConstraintMapping
property name=constraint ref=constraint /
property name=pathSpec value=/* /
/bean
bean id=securityHandler 
class=org.mortbay.jetty.security.SecurityHandler
property name=userRealm ref=userRealm /
property name=constraintMappings ref=constraintMapping /
/bean
{code}

I have attached proposed changes to the 1.6 branch. I imagine that 2.0 should 
be quite similar.


 Jetty component is unable to be configured for security
 ---

 Key: CAMEL-1570
 URL: https://issues.apache.org/activemq/browse/CAMEL-1570
 Project: Apache Camel
  Issue Type: Improvement
  Components: camel-jetty
Affects Versions: 1.6.0, 2.0-M1
 Environment: NA
Reporter: Christopher Hunt

 The Jetty component is presently unable to be configured for security. A 
 general purpose mechanism so that the Jetty component can be configured would 
 be useful. The following URI based option is proposed:
 ||Name||Default Value||Description||
 |handlers|null| Specifies a comma delimited set of instances in your Registry 
 (such as your Spring ApplicationContext). These instances are added to the 
 Jetty servlet context|
 Here is an example URI:
 {code}
 jetty:http://0.0.0.0:9080/MyService?handlers=securityHandler
 {code}
 This could refer to something like the following Spring configuration:
 {code}
   !-- Jetty Security handling --
   bean id=userRealm class=org.mortbay.jetty.plus.jaas.JAASUserRealm
   property name=name value=tracker-users /
   property name=loginModuleName value=ldaploginmodule /
   /bean
   bean id=constraint class=org.mortbay.jetty.security.Constraint
   property name=name value=BASIC /
   property name=roles value=tracker-users /

[jira] Issue Comment Edited: (CAMEL-1510) BatchProcessor interrupt has side effects

2009-04-16 Thread Christopher Hunt (JIRA)


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

Christopher Hunt edited comment on CAMEL-1510 at 4/16/09 5:03 PM:
--

Reduced locking further:

BatchProcessor-lockmin.java.20.diff


  was (Author: hu...@internode.on.net):
Reduced locking further.
  
 BatchProcessor interrupt has side effects
 -

 Key: CAMEL-1510
 URL: https://issues.apache.org/activemq/browse/CAMEL-1510
 Project: Apache Camel
  Issue Type: Bug
  Components: camel-core
Affects Versions: 1.6.0, 2.0-M1
 Environment: Mac OS X
Reporter: Christopher Hunt
Assignee: William Tam
Priority: Critical
 Fix For: 2.0.0, 1.6.1

 Attachments: BatchProcessor-lockmin.java.20.diff, 
 BatchProcessor.java.20.diff, camel-core-1.x.patch, camel-core-2.x.patch


 I have noticed that the BatchProcessor class uses the Thread class interrupt 
 method to wake the run loop from sleeping within the enqueueExchange method.
 The unfortunate side effect of this is that if the run loop is in the middle 
 of processing exchanges, and the processing involves something slow like 
 establishing a JMS connection over SSL or queuing to an asynchronous 
 processor, then the processing can become interrupted. The consequence of 
 this side effect is that the batch sender thread rarely gets the opportunity 
 to complete properly and exceptions regarding the interrupt are thrown.
 This all became apparent during some performance testing that resulted in 
 continuously adding exchanges to the aggregator, the threshold becoming 
 reached, and then trying to enqueue the aggregated result to a JMS queue.
 If my analysis of the BatchProcessor is correct then I would recommend finer 
 grained concurrency controls being used instead of relying upon interrupting 
 a thread. Perhaps something like the following (untested) re-write of the 
 sender:
 {code}
 private class BatchSender extends Thread {
 private QueueExchange queue;
 private boolean exchangeQueued = false;
 private Lock queueMutex = new ReentrantLock();
 private Condition queueCondition = queueMutex.newCondition();
 public BatchSender() {
 super(Batch Sender);
 this.queue = new LinkedListExchange();
 }
 public void cancel() {
 interrupt();
 }
 private void drainQueueTo(CollectionExchange collection, int 
 batchSize) {
 for (int i = 0; i  batchSize; ++i) {
 Exchange e = queue.poll();
 if (e != null) {
 collection.add(e);
 } else {
 break;
 }
 }
 }
 public void enqueueExchange(Exchange exchange) {
 queueMutex.lock();
 try {
 queue.add(exchange);
 exchangeQueued = true;
 queueCondition.signal();
 } finally {
 queueMutex.unlock();
 }
 }
 @Override
 public void run() {
 queueMutex.lock();
 try {
 do {
 try {
 if (!exchangeQueued) {
 queueCondition.await(batchTimeout,
 TimeUnit.MILLISECONDS);
 if (!exchangeQueued) {
 drainQueueTo(collection, batchSize);
 }
 }
 if (exchangeQueued) {
 exchangeQueued = false;
 queueMutex.unlock();
 try {
 while (isInBatchCompleted(queue.size())) {
 queueMutex.lock();
 try {
 drainQueueTo(collection, batchSize);
 } finally {
 queueMutex.unlock();
 }
 }
 if (!isOutBatchCompleted()) {
 continue;
 }
 } finally {
 queueMutex.lock();
 }
 }
 queueMutex.unlock();
 try {
 try {
 sendExchanges();
 } catch (Exception e) {

[jira] Updated: (CAMEL-1510) BatchProcessor interrupt has side effects

2009-04-15 Thread Christopher Hunt (JIRA)


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

Christopher Hunt updated CAMEL-1510:


Patch Info: [Patch Available]

 BatchProcessor interrupt has side effects
 -

 Key: CAMEL-1510
 URL: https://issues.apache.org/activemq/browse/CAMEL-1510
 Project: Apache Camel
  Issue Type: Bug
  Components: camel-core
Affects Versions: 1.6.0, 2.0-M1
 Environment: Mac OS X
Reporter: Christopher Hunt
Priority: Critical

 I have noticed that the BatchProcessor class uses the Thread class interrupt 
 method to wake the run loop from sleeping within the enqueueExchange method.
 The unfortunate side effect of this is that if the run loop is in the middle 
 of processing exchanges, and the processing involves something slow like 
 establishing a JMS connection over SSL or queuing to an asynchronous 
 processor, then the processing can become interrupted. The consequence of 
 this side effect is that the batch sender thread rarely gets the opportunity 
 to complete properly and exceptions regarding the interrupt are thrown.
 This all became apparent during some performance testing that resulted in 
 continuously adding exchanges to the aggregator, the threshold becoming 
 reached, and then trying to enqueue the aggregated result to a JMS queue.
 If my analysis of the BatchProcessor is correct then I would recommend finer 
 grained concurrency controls being used instead of relying upon interrupting 
 a thread. Perhaps something like the following (untested) re-write of the 
 sender:
 {code}
 private class BatchSender extends Thread {
 private QueueExchange queue;
 private boolean exchangeQueued = false;
 private Lock queueMutex = new ReentrantLock();
 private Condition queueCondition = queueMutex.newCondition();
 public BatchSender() {
 super(Batch Sender);
 this.queue = new LinkedListExchange();
 }
 public void cancel() {
 interrupt();
 }
 private void drainQueueTo(CollectionExchange collection, int 
 batchSize) {
 for (int i = 0; i  batchSize; ++i) {
 Exchange e = queue.poll();
 if (e != null) {
 collection.add(e);
 } else {
 break;
 }
 }
 }
 public void enqueueExchange(Exchange exchange) {
 queueMutex.lock();
 try {
 queue.add(exchange);
 exchangeQueued = true;
 queueCondition.signal();
 } finally {
 queueMutex.unlock();
 }
 }
 @Override
 public void run() {
 queueMutex.lock();
 try {
 do {
 try {
 if (!exchangeQueued) {
 queueCondition.await(batchTimeout,
 TimeUnit.MILLISECONDS);
 if (!exchangeQueued) {
 drainQueueTo(collection, batchSize);
 }
 }
 if (exchangeQueued) {
 exchangeQueued = false;
 queueMutex.unlock();
 try {
 while (isInBatchCompleted(queue.size())) {
 queueMutex.lock();
 try {
 drainQueueTo(collection, batchSize);
 } finally {
 queueMutex.unlock();
 }
 }
 if (!isOutBatchCompleted()) {
 continue;
 }
 } finally {
 queueMutex.lock();
 }
 }
 queueMutex.unlock();
 try {
 try {
 sendExchanges();
 } catch (Exception e) {
 getExceptionHandler().handleException(e);
 }
 } finally {
 queueMutex.lock();
 }
 } catch (InterruptedException e) {
 break;
 }
 } while (true);
 } finally {
 queueMutex.unlock();
 }
 }
 private void

[jira] Updated: (CAMEL-1510) BatchProcessor interrupt has side effects

2009-04-15 Thread Christopher Hunt (JIRA)


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

Christopher Hunt updated CAMEL-1510:


Attachment: BatchProcessor.java.20.diff

Batch file attached for the trunk (v2) build.

I have tested this by running AggregatorTest - do you think that is sufficient?

I have not had the time yet to update the v.1.x branch.

 BatchProcessor interrupt has side effects
 -

 Key: CAMEL-1510
 URL: https://issues.apache.org/activemq/browse/CAMEL-1510
 Project: Apache Camel
  Issue Type: Bug
  Components: camel-core
Affects Versions: 1.6.0, 2.0-M1
 Environment: Mac OS X
Reporter: Christopher Hunt
Priority: Critical
 Attachments: BatchProcessor.java.20.diff


 I have noticed that the BatchProcessor class uses the Thread class interrupt 
 method to wake the run loop from sleeping within the enqueueExchange method.
 The unfortunate side effect of this is that if the run loop is in the middle 
 of processing exchanges, and the processing involves something slow like 
 establishing a JMS connection over SSL or queuing to an asynchronous 
 processor, then the processing can become interrupted. The consequence of 
 this side effect is that the batch sender thread rarely gets the opportunity 
 to complete properly and exceptions regarding the interrupt are thrown.
 This all became apparent during some performance testing that resulted in 
 continuously adding exchanges to the aggregator, the threshold becoming 
 reached, and then trying to enqueue the aggregated result to a JMS queue.
 If my analysis of the BatchProcessor is correct then I would recommend finer 
 grained concurrency controls being used instead of relying upon interrupting 
 a thread. Perhaps something like the following (untested) re-write of the 
 sender:
 {code}
 private class BatchSender extends Thread {
 private QueueExchange queue;
 private boolean exchangeQueued = false;
 private Lock queueMutex = new ReentrantLock();
 private Condition queueCondition = queueMutex.newCondition();
 public BatchSender() {
 super(Batch Sender);
 this.queue = new LinkedListExchange();
 }
 public void cancel() {
 interrupt();
 }
 private void drainQueueTo(CollectionExchange collection, int 
 batchSize) {
 for (int i = 0; i  batchSize; ++i) {
 Exchange e = queue.poll();
 if (e != null) {
 collection.add(e);
 } else {
 break;
 }
 }
 }
 public void enqueueExchange(Exchange exchange) {
 queueMutex.lock();
 try {
 queue.add(exchange);
 exchangeQueued = true;
 queueCondition.signal();
 } finally {
 queueMutex.unlock();
 }
 }
 @Override
 public void run() {
 queueMutex.lock();
 try {
 do {
 try {
 if (!exchangeQueued) {
 queueCondition.await(batchTimeout,
 TimeUnit.MILLISECONDS);
 if (!exchangeQueued) {
 drainQueueTo(collection, batchSize);
 }
 }
 if (exchangeQueued) {
 exchangeQueued = false;
 queueMutex.unlock();
 try {
 while (isInBatchCompleted(queue.size())) {
 queueMutex.lock();
 try {
 drainQueueTo(collection, batchSize);
 } finally {
 queueMutex.unlock();
 }
 }
 if (!isOutBatchCompleted()) {
 continue;
 }
 } finally {
 queueMutex.lock();
 }
 }
 queueMutex.unlock();
 try {
 try {
 sendExchanges();
 } catch (Exception e) {
 getExceptionHandler().handleException(e);
 }
 } finally {
 queueMutex.lock();
 }

[jira] Commented: (CAMEL-1510) BatchProcessor interrupt has side effects

2009-04-14 Thread Christopher Hunt (JIRA)


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

Christopher Hunt commented on CAMEL-1510:
-

Hi guys,

Thanks for this great dialogue.

With regards to:

_I think that's also an issue in the original code (i.e. in the codebase, not 
Christopher's proposal): the batch sender has always been interrupted whenever 
a message was enequeued. From a user's perspective there's no noticable batch 
timeout, for example, when the batchTimout is set to 1000 ms and every 300 ms 
there is a message coming in (assuming the batch size is 100). Normally, the 
batch processor should send 3 messages after the timout occurs but using the 
original code it would send more (I'd expect 100 messages)_

I do not believe that is the case with the original code or my proposal. The 
queue is only drained into the collection if the batch times out. Using my code 
to illustrate:

{code}
if (!exchangeQueued) {
  drainQueueTo(collection, batchSize);
}
{code}

Furthermore sendExchanges would not even be called unless the batch is complete 
given the following block:

{code}
  if (exchangeQueued) {
   exchangeQueued = false;
   queueMutex.unlock();
   try {
   while (isInBatchCompleted(queue.size())) {
   queueMutex.lock();
   try {
   drainQueueTo(collection, batchSize);
   } finally {
   queueMutex.unlock();
   }
   }

   if (!isOutBatchCompleted()) {
   continue;
   }
   } finally {
   queueMutex.lock();
   }

   }

{code}

... if the batch is not completed then the loop will continue.

On the re-factoring, please bear in mind that in essence, all that I have done 
is moved blocks of existing code around and used a condition to signal when 
adding to the queue.

 BatchProcessor interrupt has side effects
 -

 Key: CAMEL-1510
 URL: https://issues.apache.org/activemq/browse/CAMEL-1510
 Project: Apache Camel
  Issue Type: Bug
  Components: camel-core
Affects Versions: 1.6.0, 2.0-M1
 Environment: Mac OS X
Reporter: Christopher Hunt
Priority: Critical

 I have noticed that the BatchProcessor class uses the Thread class interrupt 
 method to wake the run loop from sleeping within the enqueueExchange method.
 The unfortunate side effect of this is that if the run loop is in the middle 
 of processing exchanges, and the processing involves something slow like 
 establishing a JMS connection over SSL or queuing to an asynchronous 
 processor, then the processing can become interrupted. The consequence of 
 this side effect is that the batch sender thread rarely gets the opportunity 
 to complete properly and exceptions regarding the interrupt are thrown.
 This all became apparent during some performance testing that resulted in 
 continuously adding exchanges to the aggregator, the threshold becoming 
 reached, and then trying to enqueue the aggregated result to a JMS queue.
 If my analysis of the BatchProcessor is correct then I would recommend finer 
 grained concurrency controls being used instead of relying upon interrupting 
 a thread. Perhaps something like the following (untested) re-write of the 
 sender:
 {code}
 private class BatchSender extends Thread {
 private QueueExchange queue;
 private boolean exchangeQueued = false;
 private Lock queueMutex = new ReentrantLock();
 private Condition queueCondition = queueMutex.newCondition();
 public BatchSender() {
 super(Batch Sender);
 this.queue = new LinkedListExchange();
 }
 public void cancel() {
 interrupt();
 }
 private void drainQueueTo(CollectionExchange collection, int 
 batchSize) {
 for (int i = 0; i  batchSize; ++i) {
 Exchange e = queue.poll();
 if (e != null) {
 collection.add(e);
 } else {
 break;
 }
 }
 }
 public void enqueueExchange(Exchange exchange) {
 queueMutex.lock();
 try {
 queue.add(exchange);
 exchangeQueued = true;
 queueCondition.signal();
 } finally {
 queueMutex.unlock();
 }
 }
 @Override
 public void run() {
 queueMutex.lock();
 try {
 do {
 try {
 if (!exchangeQueued) {
 queueCondition.await(batchTimeout,
 TimeUnit.MILLISECONDS);
 if (!exchangeQueued) {

[jira] Commented: (CAMEL-1510) BatchProcessor interrupt has side effects

2009-04-14 Thread Christopher Hunt (JIRA)


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

Christopher Hunt commented on CAMEL-1510:
-

Sure thing. I should be able to do this tomorrow - shall I work off the 2.0 
trunk?

 BatchProcessor interrupt has side effects
 -

 Key: CAMEL-1510
 URL: https://issues.apache.org/activemq/browse/CAMEL-1510
 Project: Apache Camel
  Issue Type: Bug
  Components: camel-core
Affects Versions: 1.6.0, 2.0-M1
 Environment: Mac OS X
Reporter: Christopher Hunt
Priority: Critical

 I have noticed that the BatchProcessor class uses the Thread class interrupt 
 method to wake the run loop from sleeping within the enqueueExchange method.
 The unfortunate side effect of this is that if the run loop is in the middle 
 of processing exchanges, and the processing involves something slow like 
 establishing a JMS connection over SSL or queuing to an asynchronous 
 processor, then the processing can become interrupted. The consequence of 
 this side effect is that the batch sender thread rarely gets the opportunity 
 to complete properly and exceptions regarding the interrupt are thrown.
 This all became apparent during some performance testing that resulted in 
 continuously adding exchanges to the aggregator, the threshold becoming 
 reached, and then trying to enqueue the aggregated result to a JMS queue.
 If my analysis of the BatchProcessor is correct then I would recommend finer 
 grained concurrency controls being used instead of relying upon interrupting 
 a thread. Perhaps something like the following (untested) re-write of the 
 sender:
 {code}
 private class BatchSender extends Thread {
 private QueueExchange queue;
 private boolean exchangeQueued = false;
 private Lock queueMutex = new ReentrantLock();
 private Condition queueCondition = queueMutex.newCondition();
 public BatchSender() {
 super(Batch Sender);
 this.queue = new LinkedListExchange();
 }
 public void cancel() {
 interrupt();
 }
 private void drainQueueTo(CollectionExchange collection, int 
 batchSize) {
 for (int i = 0; i  batchSize; ++i) {
 Exchange e = queue.poll();
 if (e != null) {
 collection.add(e);
 } else {
 break;
 }
 }
 }
 public void enqueueExchange(Exchange exchange) {
 queueMutex.lock();
 try {
 queue.add(exchange);
 exchangeQueued = true;
 queueCondition.signal();
 } finally {
 queueMutex.unlock();
 }
 }
 @Override
 public void run() {
 queueMutex.lock();
 try {
 do {
 try {
 if (!exchangeQueued) {
 queueCondition.await(batchTimeout,
 TimeUnit.MILLISECONDS);
 if (!exchangeQueued) {
 drainQueueTo(collection, batchSize);
 }
 }
 if (exchangeQueued) {
 exchangeQueued = false;
 queueMutex.unlock();
 try {
 while (isInBatchCompleted(queue.size())) {
 queueMutex.lock();
 try {
 drainQueueTo(collection, batchSize);
 } finally {
 queueMutex.unlock();
 }
 }
 if (!isOutBatchCompleted()) {
 continue;
 }
 } finally {
 queueMutex.lock();
 }
 }
 queueMutex.unlock();
 try {
 try {
 sendExchanges();
 } catch (Exception e) {
 getExceptionHandler().handleException(e);
 }
 } finally {
 queueMutex.lock();
 }
 } catch (InterruptedException e) {
 break;
 }
 } while (true);
 }

[jira] Updated: (CAMEL-1510) BatchProcessor interrupt has side effects

2009-04-13 Thread Christopher Hunt (JIRA)


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

Christopher Hunt updated CAMEL-1510:


Description: 
I have noticed that the BatchProcessor class uses the Thread class interrupt 
method to wake the run loop from sleeping within the enqueueExchange method.

The unfortunate side effect of this is that if the run loop is in the middle of 
processing exchanges, and the processing involves something slow like 
establishing a JMS connection over SSL or queuing to an asynchronous processor, 
then the processing can become interrupted. The consequence of this side effect 
is that the batch sender thread rarely gets the opportunity to complete 
properly and exceptions regarding the interrupt are thrown.

This all became apparent during some performance testing that resulted in 
continuously adding exchanges to the aggregator, the threshold becoming 
reached, and then trying to enqueue the aggregated result to a JMS queue.

If my analysis of the BatchProcessor is correct then I would recommend finer 
grained concurrency controls being used instead of relying upon interrupting a 
thread. Perhaps something like the following (untested) re-write of the sender:

{code}
private class BatchSender extends Thread {
private QueueExchange queue;
private boolean exchangeQueued = false;
private Lock queueMutex = new ReentrantLock();
private Condition queueCondition = queueMutex.newCondition();

public BatchSender() {
super(Batch Sender);
this.queue = new LinkedListExchange();
}

public void cancel() {
interrupt();
}

private void drainQueueTo(CollectionExchange collection, int 
batchSize) {
for (int i = 0; i  batchSize; ++i) {
Exchange e = queue.poll();
if (e != null) {
collection.add(e);
} else {
break;
}
}
}

public void enqueueExchange(Exchange exchange) {
queueMutex.lock();
try {
queue.add(exchange);
exchangeQueued = true;
queueCondition.signal();
} finally {
queueMutex.unlock();
}
}

@Override
public void run() {
queueMutex.lock();
try {
do {
try {
if (!exchangeQueued) {
queueCondition.await(batchTimeout,
TimeUnit.MILLISECONDS);
if (!exchangeQueued) {
drainQueueTo(collection, batchSize);
}
}

if (exchangeQueued) {
exchangeQueued = false;
queueMutex.unlock();
try {
while (isInBatchCompleted(queue.size())) {
queueMutex.lock();
try {
drainQueueTo(collection, batchSize);
} finally {
queueMutex.unlock();
}
}

if (!isOutBatchCompleted()) {
continue;
}
} finally {
queueMutex.lock();
}

}

queueMutex.unlock();
try {
try {
sendExchanges();
} catch (Exception e) {
getExceptionHandler().handleException(e);
}
} finally {
queueMutex.lock();
}
} catch (InterruptedException e) {
break;
}
} while (true);
} finally {
queueMutex.unlock();
}
}

private void sendExchanges() throws Exception {
IteratorExchange iter = collection.iterator();
while (iter.hasNext()) {
Exchange exchange = iter.next();
iter.remove();
processExchange(exchange);
}
}
}
{code}

I have replaced the concurrent queue with a regular linked list and mutexed its 
access. In addition any queuing of exchanges is noted. This should result in 
less locking.

The main change though is that queuing an exchange does not interrupt

[jira] Commented: (CAMEL-1510) BatchProcessor interrupt has side effects

2009-04-13 Thread Christopher Hunt (JIRA)


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

Christopher Hunt commented on CAMEL-1510:
-

My feedback on Martin's proposal:

1. cancelRequested is not required.
2. Line 19: move the lock before the while statement so that the block becomes 
(also using do instead of while) - less locking i.e.:

{code}
queueMutex.lock();
try {
  do {
try {
  boolean signalled = queueCondition.await(batchTimeout,
  TimeUnit.MILLISECONDS);
  processEnqueuedExchanges(signalled);
} catch (InterruptedException e) {
  break;
} catch (Exception e) {
  // TODO: handle exception ...
  e.printStackTrace();
}

  } while (true);
} finally {
  queueMutex.unlock();
}
{code}

3. Preserve the existing code for the cancel method i.e. it should continue 
performing an interrupt i.e.:

{code}
public void cancel() {
  interrupt();
}
{code}

4. enqueueExchange needs to add to the queue while the queue is locked i.e.:

{code}
  public void enqueueExchange(Exchange exchange) {
queueMutex.lock();
try {
  queue.add(exchange);
  if (isInBatchCompleted(queue.size())) {
queueCondition.signal();
  }
} finally {
  queueMutex.unlock();
}
  }
{code}

NOTE: isInBatchCompleted is called while the queue is locked - my example did 
not do this. My focus was on keeping the locks locked minimally given the goal 
of performance and throughput.

5. processEnqueuedExchanges does not need to check if the batch is cancelled as 
the interrupt would have previously called an exception i.e.:

{code}
  private void processEnqueuedExchanges(boolean signalled) throws Exception {

if (!signalled) {
  drainQueueTo(collection, batchSize);
} else {
  while (isInBatchCompleted(queue.size())) {
drainQueueTo(collection, batchSize);
  }

  if (!isOutBatchCompleted()) {
return;
  }
}

try {
  sendExchanges();
} catch (Exception e) {
  getExceptionHandler().handleException(e);
}

  }
{code}

NOTE: isInBatchCompleted is now being called a second time - once inside 
enqueueExchange and now here.

NOTE: sendExchanges is being called while the queue is locked. If there is some 
slow IO occurring (as was indeed the case with my determining this issue 
originally) then nothing can be added to the queue during sendExchanges.

My focus with the original code submission was on minimising lock contentions 
while retaining a structure that built on proven code.

 BatchProcessor interrupt has side effects
 -

 Key: CAMEL-1510
 URL: https://issues.apache.org/activemq/browse/CAMEL-1510
 Project: Apache Camel
  Issue Type: Bug
  Components: camel-core
Affects Versions: 1.6.0, 2.0-M1
 Environment: Mac OS X
Reporter: Christopher Hunt
Priority: Critical

 I have noticed that the BatchProcessor class uses the Thread class interrupt 
 method to wake the run loop from sleeping within the enqueueExchange method.
 The unfortunate side effect of this is that if the run loop is in the middle 
 of processing exchanges, and the processing involves something slow like 
 establishing a JMS connection over SSL or queuing to an asynchronous 
 processor, then the processing can become interrupted. The consequence of 
 this side effect is that the batch sender thread rarely gets the opportunity 
 to complete properly and exceptions regarding the interrupt are thrown.
 This all became apparent during some performance testing that resulted in 
 continuously adding exchanges to the aggregator, the threshold becoming 
 reached, and then trying to enqueue the aggregated result to a JMS queue.
 If my analysis of the BatchProcessor is correct then I would recommend finer 
 grained concurrency controls being used instead of relying upon interrupting 
 a thread. Perhaps something like the following (untested) re-write of the 
 sender:
 {code}
 private class BatchSender extends Thread {
 private QueueExchange queue;
 private boolean exchangeQueued = false;
 private Lock queueMutex = new ReentrantLock();
 private Condition queueCondition = queueMutex.newCondition();
 public BatchSender() {
 super(Batch Sender);
 this.queue = new LinkedListExchange();
 }
 public void cancel() {
 interrupt();
 }
 private void drainQueueTo(CollectionExchange collection, int 
 batchSize) {
 for (int i = 0; i  batchSize; ++i) {
 Exchange e = queue.poll();
 if (e != null) {
 collection.add(e);
 } else {
 break;

[jira] Created: (CAMEL-1528) id method needs to be re-instated from being deprecated

2009-04-13 Thread Christopher Hunt (JIRA)

id method needs to be re-instated from being deprecated
---

 Key: CAMEL-1528
 URL: https://issues.apache.org/activemq/browse/CAMEL-1528
 Project: Apache Camel
  Issue Type: Improvement
  Components: camel-core
Affects Versions: 2.0-M1, 1.6.0
 Environment: n/a
Reporter: Christopher Hunt


Please re-instate the .id method of OptionalIdentifiedType so that JMX nodes 
can be easily identified from within the Java DSL.

In addition please provide an option for Camel to only add JMX route nodes 
where there is an id - this should then reduce the clutter of JMX consoles.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (CAMEL-1510) BatchProcessor interrupt has side effects

2009-04-12 Thread Christopher Hunt (JIRA)


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

Christopher Hunt commented on CAMEL-1510:
-

Hi Martin,

Thank you for replying.

I presume by synchronised you mean that the enqueueExchange and sendExchanges 
lock on some shared mutex.

I wonder with your suggestion if you might also have to try synchronising with 
other things that can then be overloaded e.g. isInBatchCompleted and 
isOutBatchCompleted. Who would know what these methods could eventually be 
doing?

Personally I prefer to see the batch sender awake from known conditions i.e. 
timeout or exchange enqueued. For some reason I also feel that Interrupts are a 
little brutal and should be used sparingly.

In addition I think that what I have proposed (albeit untested) would be more 
efficient as there is only one lock in play. The present solution has the lock 
associated within the blocking queue. You would of course being adding another 
lock with the potential for a deadlock.

Thanks for the continued dialogue.

Kind regards,
Christopher

 BatchProcessor interrupt has side effects
 -

 Key: CAMEL-1510
 URL: https://issues.apache.org/activemq/browse/CAMEL-1510
 Project: Apache Camel
  Issue Type: Bug
  Components: camel-core
Affects Versions: 1.6.0, 2.0-M1
 Environment: Mac OS X
Reporter: Christopher Hunt
Priority: Critical

 I have noticed that the BatchProcessor class uses the Thread class interrupt 
 method to wake the run loop from sleeping within the enqueueExchange method.
 The unfortunate side effect of this is that if the run loop is in the middle 
 of processing exchanges, and the processing involves something slow like 
 establishing a JMS connection over SSL or queuing to an asynchronous 
 processor, then the processing can become interrupted. The consequence of 
 this side effect is that the batch sender thread rarely gets the opportunity 
 to complete properly and exceptions regarding the interrupt are thrown.
 This all became apparent during some performance testing that resulted in 
 continuously adding exchanges to the aggregator, the threshold becoming 
 reached, and then trying to enqueue the aggregated result to a JMS queue.
 If my analysis of the BatchProcessor is correct then I would recommend finer 
 grained concurrency controls being used instead of relying upon interrupting 
 a thread. Perhaps something like the following (untested) re-write of the 
 sender:
 {code}
 private class BatchSender extends Thread {
 private QueueExchange queue;
 private boolean exchangeQueued = false;
 private Lock queueMutex = new ReentrantLock();
 private Condition queueCondition = queueMutex.newCondition();
 public BatchSender() {
 super(Batch Sender);
 this.queue = new LinkedListExchange();
 }
 public void cancel() {
 interrupt();
 }
 private void drainQueueTo(CollectionExchange collection, int 
 batchSize) {
 for (int i = 0; i  batchSize; ++i) {
 Exchange e = queue.poll();
 if (e != null) {
 collection.add(e);
 } else {
 break;
 }
 }
 }
 public void enqueueExchange(Exchange exchange) {
 queueMutex.lock();
 try {
 queue.add(exchange);
 exchangeQueued = true;
 } finally {
 queueMutex.unlock();
 }
 }
 @Override
 public void run() {
 queueMutex.lock();
 try {
 do {
 try {
 if (!exchangeQueued) {
 queueCondition.await(batchTimeout,
 TimeUnit.MILLISECONDS);
 if (!exchangeQueued) {
 drainQueueTo(collection, batchSize);
 }
 }
 if (exchangeQueued) {
 exchangeQueued = false;
 queueMutex.unlock();
 try {
 while (isInBatchCompleted(queue.size())) {
 queueMutex.lock();
 try {
 drainQueueTo(collection, batchSize);
 } finally {
 queueMutex.unlock();
 }
 }
 if (!isOutBatchCompleted()) {

[jira] Commented: (CAMEL-1510) BatchProcessor interrupt has side effects

2009-04-12 Thread Christopher Hunt (JIRA)


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

Christopher Hunt commented on CAMEL-1510:
-

Hi Martin,

I'm still leaning to the patch that I provided... I think that it closely 
resembles the code that is already there which is essentially flawed only in 
the sense that it interrupts when adding an exchange. 

A couple of observations with your changes:
- cancel still needs to interrupt - you really want to interrupt with 
cancellations.
- cancelRequested is not being protected within the cancel method.
- cancelRequested wouldn't be required if cancel interrupts.
- drainQueueTo will need to protect the queue also.

... my code did do all of the above.

Kind regards,
Christopher

 BatchProcessor interrupt has side effects
 -

 Key: CAMEL-1510
 URL: https://issues.apache.org/activemq/browse/CAMEL-1510
 Project: Apache Camel
  Issue Type: Bug
  Components: camel-core
Affects Versions: 1.6.0, 2.0-M1
 Environment: Mac OS X
Reporter: Christopher Hunt
Priority: Critical

 I have noticed that the BatchProcessor class uses the Thread class interrupt 
 method to wake the run loop from sleeping within the enqueueExchange method.
 The unfortunate side effect of this is that if the run loop is in the middle 
 of processing exchanges, and the processing involves something slow like 
 establishing a JMS connection over SSL or queuing to an asynchronous 
 processor, then the processing can become interrupted. The consequence of 
 this side effect is that the batch sender thread rarely gets the opportunity 
 to complete properly and exceptions regarding the interrupt are thrown.
 This all became apparent during some performance testing that resulted in 
 continuously adding exchanges to the aggregator, the threshold becoming 
 reached, and then trying to enqueue the aggregated result to a JMS queue.
 If my analysis of the BatchProcessor is correct then I would recommend finer 
 grained concurrency controls being used instead of relying upon interrupting 
 a thread. Perhaps something like the following (untested) re-write of the 
 sender:
 {code}
 private class BatchSender extends Thread {
 private QueueExchange queue;
 private boolean exchangeQueued = false;
 private Lock queueMutex = new ReentrantLock();
 private Condition queueCondition = queueMutex.newCondition();
 public BatchSender() {
 super(Batch Sender);
 this.queue = new LinkedListExchange();
 }
 public void cancel() {
 interrupt();
 }
 private void drainQueueTo(CollectionExchange collection, int 
 batchSize) {
 for (int i = 0; i  batchSize; ++i) {
 Exchange e = queue.poll();
 if (e != null) {
 collection.add(e);
 } else {
 break;
 }
 }
 }
 public void enqueueExchange(Exchange exchange) {
 queueMutex.lock();
 try {
 queue.add(exchange);
 exchangeQueued = true;
 } finally {
 queueMutex.unlock();
 }
 }
 @Override
 public void run() {
 queueMutex.lock();
 try {
 do {
 try {
 if (!exchangeQueued) {
 queueCondition.await(batchTimeout,
 TimeUnit.MILLISECONDS);
 if (!exchangeQueued) {
 drainQueueTo(collection, batchSize);
 }
 }
 if (exchangeQueued) {
 exchangeQueued = false;
 queueMutex.unlock();
 try {
 while (isInBatchCompleted(queue.size())) {
 queueMutex.lock();
 try {
 drainQueueTo(collection, batchSize);
 } finally {
 queueMutex.unlock();
 }
 }
 if (!isOutBatchCompleted()) {
 continue;
 }
 } finally {
 queueMutex.lock();
 }
 }
 queueMutex.unlock();
 try {
 try {

[jira] Updated: (CAMEL-1510) BatchProcessor interrupt has side effects

2009-04-11 Thread Christopher Hunt (JIRA)


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

Christopher Hunt updated CAMEL-1510:


Affects Version/s: 2.0-M1

Upon inspecting the 2.0 trunk I see that this problem will be carried through.

Is there any interest in fixing this problem?

 BatchProcessor interrupt has side effects
 -

 Key: CAMEL-1510
 URL: https://issues.apache.org/activemq/browse/CAMEL-1510
 Project: Apache Camel
  Issue Type: Bug
  Components: camel-core
Affects Versions: 1.6.0, 2.0-M1
 Environment: Mac OS X
Reporter: Christopher Hunt
Priority: Critical

 I have noticed that the BatchProcessor class uses the Thread class interrupt 
 method to wake the run loop from sleeping within the enqueueExchange method.
 The unfortunate side effect of this is that if the run loop is in the middle 
 of processing exchanges, and the processing involves something slow like 
 establishing a JMS connection over SSL or queuing to an asynchronous 
 processor, then the processing can become interrupted. The consequence of 
 this side effect is that the batch sender thread rarely gets the opportunity 
 to complete properly and exceptions regarding the interrupt are thrown.
 This all became apparent during some performance testing that resulted in 
 continuously adding exchanges to the aggregator, the threshold becoming 
 reached, and then trying to enqueue the aggregated result to a JMS queue.
 If my analysis of the BatchProcessor is correct then I would recommend finer 
 grained concurrency controls being used instead of relying upon interrupting 
 a thread. Perhaps something like the following (untested) re-write of the 
 sender:
 {code}
 private class BatchSender extends Thread {
 private QueueExchange queue;
 private boolean exchangeQueued = false;
 private Lock queueMutex = new ReentrantLock();
 private Condition queueCondition = queueMutex.newCondition();
 public BatchSender() {
 super(Batch Sender);
 this.queue = new LinkedListExchange();
 }
 public void cancel() {
 interrupt();
 }
 private void drainQueueTo(CollectionExchange collection, int 
 batchSize) {
 for (int i = 0; i  batchSize; ++i) {
 Exchange e = queue.poll();
 if (e != null) {
 collection.add(e);
 } else {
 break;
 }
 }
 }
 public void enqueueExchange(Exchange exchange) {
 queueMutex.lock();
 try {
 queue.add(exchange);
 exchangeQueued = true;
 } finally {
 queueMutex.unlock();
 }
 }
 @Override
 public void run() {
 queueMutex.lock();
 try {
 do {
 try {
 if (!exchangeQueued) {
 queueCondition.await(batchTimeout,
 TimeUnit.MILLISECONDS);
 if (!exchangeQueued) {
 drainQueueTo(collection, batchSize);
 }
 }
 if (exchangeQueued) {
 exchangeQueued = false;
 queueMutex.unlock();
 try {
 while (isInBatchCompleted(queue.size())) {
 queueMutex.lock();
 try {
 drainQueueTo(collection, batchSize);
 } finally {
 queueMutex.unlock();
 }
 }
 if (!isOutBatchCompleted()) {
 continue;
 }
 } finally {
 queueMutex.lock();
 }
 }
 queueMutex.unlock();
 try {
 try {
 sendExchanges();
 } catch (Exception e) {
 getExceptionHandler().handleException(e);
 }
 } finally {
 queueMutex.lock();
 }
 } catch (InterruptedException e) {
 break;
 }
 } while (true);
 } finally {

[jira] Commented: (CAMEL-1510) BatchProcessor interrupt has side effects

2009-04-01 Thread Christopher Hunt (JIRA)


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

Christopher Hunt commented on CAMEL-1510:
-

Just wondering... the batch processor's collection should always be a 
thread-safe type of collection. Is this the case in practice? If the collection 
is not thread safe then the batch sender run method will contend with the 
processor's isOutBatchCompleted(), doStop() and getCollection() methods.


 BatchProcessor interrupt has side effects
 -

 Key: CAMEL-1510
 URL: https://issues.apache.org/activemq/browse/CAMEL-1510
 Project: Apache Camel
  Issue Type: Bug
  Components: camel-core
Affects Versions: 1.6.0
 Environment: Mac OS X
Reporter: Christopher Hunt
Priority: Critical

 I have noticed that the BatchProcessor class uses the Thread class interrupt 
 method to wake the run loop from sleeping within the enqueueExchange method.
 The unfortunate side effect of this is that if the run loop is in the middle 
 of processing exchanges, and the processing involves something slow like 
 establishing a JMS connection over SSL or queuing to an asynchronous 
 processor, then the processing can become interrupted. The consequence of 
 this side effect is that the batch sender thread rarely gets the opportunity 
 to complete properly and exceptions regarding the interrupt are thrown.
 This all became apparent during some performance testing that resulted in 
 continuously adding exchanges to the aggregator, the threshold becoming 
 reached, and then trying to enqueue the aggregated result to a JMS queue.
 If my analysis of the BatchProcessor is correct then I would recommend finer 
 grained concurrency controls being used instead of relying upon interrupting 
 a thread. Perhaps something like the following (untested) re-write of the 
 sender:
 {code}
 private class BatchSender extends Thread {
 private QueueExchange queue;
 private boolean exchangeQueued = false;
 private Lock queueMutex = new ReentrantLock();
 private Condition queueCondition = queueMutex.newCondition();
 public BatchSender() {
 super(Batch Sender);
 this.queue = new LinkedListExchange();
 }
 public void cancel() {
 interrupt();
 }
 private void drainQueueTo(CollectionExchange collection, int 
 batchSize) {
 for (int i = 0; i  batchSize; ++i) {
 Exchange e = queue.poll();
 if (e != null) {
 collection.add(e);
 } else {
 break;
 }
 }
 }
 public void enqueueExchange(Exchange exchange) {
 queueMutex.lock();
 try {
 queue.add(exchange);
 exchangeQueued = true;
 } finally {
 queueMutex.unlock();
 }
 }
 @Override
 public void run() {
 queueMutex.lock();
 try {
 do {
 try {
 if (!exchangeQueued) {
 queueCondition.await(batchTimeout,
 TimeUnit.MILLISECONDS);
 if (!exchangeQueued) {
 drainQueueTo(collection, batchSize);
 }
 }
 if (exchangeQueued) {
 exchangeQueued = false;
 queueMutex.unlock();
 try {
 while (isInBatchCompleted(queue.size())) {
 queueMutex.lock();
 try {
 drainQueueTo(collection, batchSize);
 } finally {
 queueMutex.unlock();
 }
 }
 if (!isOutBatchCompleted()) {
 continue;
 }
 } finally {
 queueMutex.lock();
 }
 }
 queueMutex.unlock();
 try {
 try {
 sendExchanges();
 } catch (Exception e) {
 getExceptionHandler().handleException(e);
 }
 } finally {
 queueMutex.lock();

[jira] Created: (CAMEL-1499) LDAP documentation could be improved

2009-03-29 Thread Christopher Hunt (JIRA)

LDAP documentation could be improved


 Key: CAMEL-1499
 URL: https://issues.apache.org/activemq/browse/CAMEL-1499
 Project: Apache Camel
  Issue Type: Improvement
  Components: camel-ldap
Affects Versions: 2.0-M1, 1.6.0
 Environment: Wiki pages
Reporter: Christopher Hunt


On familiarising myself with the ldap component I found that I had to trawl 
through the source code to gain a good understanding of how it should be used.

For example (http://camel.apache.org/ldap.html):

In the sample below we fetch the rows from the customer table.
First we register our datasource in the Camel registry as testdb:

is entirely incorrect. Perhaps it should say:

In the sample below we create a JNDI DirContext and register it with our Camel 
context's JNDI registry. The key used for registration is the remaining part of 
the ldap URI i.e. the part without the ldap: and URI parameters. The DirContext 
should establish any authentication requirements with the LDAP repository.

I then think that the example should illustrate how an anonymous DirContext can 
be established outside of any ApacheDS dependencies e.g.:

{code}
HashtableObject, Object env = new HashtableObject, Object();
env.put(Context.INITIAL_CONTEXT_FACTORY, initialContextFactory);
env.put(Context.PROVIDER_URL, providerURL);
env.put(Context.SECURITY_AUTHENTICATION, none);

DirContext ctx = new InitialDirContext(env);
{code}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (CAMEL-1379) Mina configuration is shared between endpoints

2009-02-24 Thread Christopher Hunt (JIRA)

Mina configuration is shared between endpoints
--

 Key: CAMEL-1379
 URL: https://issues.apache.org/activemq/browse/CAMEL-1379
 Project: Apache Camel
  Issue Type: Bug
  Components: camel-mina
Affects Versions: 1.5.0
 Environment: All
Reporter: Christopher Hunt


Establishing a MINA endpoint with a custom codec, and then establishing another 
without a custom codec is a problem. The second endpoint inherits the first 
endpoint's codec.

My recommendation is to not share configuration data between endpoint creation. 
I recommend that the MINA component instantiate a new configuration for each 
new endpoint instead of copying the previous configuration.

As a workaround the user can specify codec as a URI parameter with no value.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (CAMEL-3117) cxfbean and cxfrs components should honour jax-rs providers in the bean registry

[jira] Resolved: (CAMEL-3117) cxfbean and cxfrs components should honour jax-rs providers in the bean registry

[jira] Commented: (CAMEL-3117) cxfbean and cxfrs components should honour jax-rs providers in the bean registry

[jira] Issue Comment Edited: (CAMEL-3117) cxfbean and cxfrs components should honour jax-rs providers in the bean registry

[jira] Updated: (CAMEL-3117) cxfbean and cxfrs components should honour jax-rs providers in the bean registry

[jira] Updated: (CAMEL-3117) cxfbean and cxfrs components should honour jax-rs providers in the bean registry

[jira] Commented: (CAMEL-2231) Exception during mail connection requires folder to be reset

[jira] Created: (CAMEL-2231) Exception during mail connection requires folder to be reset

[jira] Commented: (CAMEL-2231) Exception during mail connection requires folder to be reset

[jira] Reopened: (CAMEL-825) async endpoints like SEDA and VM do not work with InOut and Spring Remoting - as the caller does not wait for the exchange to be completed

[jira] Commented: (CAMEL-1570) Jetty component is unable to be configured for security

[jira] Updated: (CAMEL-1570) Jetty component is unable to be configured for security

[jira] Updated: (CAMEL-1570) Jetty component is unable to be configured for security

[jira] Updated: (CAMEL-1570) Jetty component is unable to be configured for security

[jira] Resolved: (CAMEL-1499) LDAP documentation could be improved

[jira] Commented: (CAMEL-1583) ldap component is not thread safe

[jira] Issue Comment Edited: (CAMEL-1583) ldap component is not thread safe

[jira] Updated: (CAMEL-1583) ldap component is not thread safe

[jira] Created: (CAMEL-1583) ldap component is not thread safe

[jira] Commented: (CAMEL-1570) Jetty component is unable to be configured for security

[jira] Commented: (CAMEL-1176) Add support for jetty user security realms

[jira] Updated: (CAMEL-1570) Jetty component is unable to be configured for security

[jira] Issue Comment Edited: (CAMEL-1510) BatchProcessor interrupt has side effects

[jira] Updated: (CAMEL-1510) BatchProcessor interrupt has side effects

[jira] Updated: (CAMEL-1510) BatchProcessor interrupt has side effects

[jira] Commented: (CAMEL-1510) BatchProcessor interrupt has side effects

[jira] Commented: (CAMEL-1510) BatchProcessor interrupt has side effects

[jira] Updated: (CAMEL-1510) BatchProcessor interrupt has side effects

[jira] Commented: (CAMEL-1510) BatchProcessor interrupt has side effects

[jira] Created: (CAMEL-1528) id method needs to be re-instated from being deprecated

[jira] Commented: (CAMEL-1510) BatchProcessor interrupt has side effects

[jira] Commented: (CAMEL-1510) BatchProcessor interrupt has side effects

[jira] Updated: (CAMEL-1510) BatchProcessor interrupt has side effects

[jira] Commented: (CAMEL-1510) BatchProcessor interrupt has side effects

[jira] Created: (CAMEL-1499) LDAP documentation could be improved

[jira] Created: (CAMEL-1379) Mina configuration is shared between endpoints

36 matches

Site Navigation

Mail list logo

Footer information