Re: sftp with privateKeyFile using camel-ftp
Claus, It seems I stumbled on a bug in Jsch - must be in my genes... I have a conversation on their mailing list. Here is a link to the archives. The latest messages are not yet in the archives but you can have a look in a day or two. http://sourceforge.net/mailarchive/forum.php?thread_name=201006231155.UAA11635%40jcraft.comforum_name=jsch-users Basically, it seems like Jsch cannot handle situations where the server requires more than one authentication method. In my case I required both a private key AND a password. If I only require a private key or only require a password then Jsch (and camel-ftp) works. Hope they will fix this promptly but I have no insight as to how quick they release new versions of Jsch. /Bengt 2010/6/23 Bengt Rodehav be...@rodehav.com Logging patch is now attached to the JIRA. /Bengt 2010/6/23 Bengt Rodehav be...@rodehav.com Claus, I'll try to get some help regarding this on the Jsch mailing list. Remember I told you nothing turns up in the log. I've looked at the source code for camel-ftp (SftpOperations.java) and there is no logger attached to Jsch. I created a JIRA for that: https://issues.apache.org/activemq/browse/CAMEL-2842 https://issues.apache.org/activemq/browse/CAMEL-2842I have a patch that I'll attach to the JIRA. I need to do a SVN update locally to be able to create a diff file but I cant currently connect to the SVN repository. I'll attach the patch as soon as possible. /Bengt 2010/6/23 Bengt Rodehav be...@rodehav.com Hi Claus, Unfortunately I get nothing in the log. If it were the 256 limit I was kind of expecting some kind of Exception. I've also been bitten by it in the past and normally you get some kind of security related exception. Maybe it's caught somewhere... To be sure I'll download the updated policy files and also try a separate client like you suggest. Thanks, /Bengt 2010/6/23 Claus Ibsen claus.ib...@gmail.com Hi The key length restriction have bitten me in the past. You had to download a special extension and override some files in the JRE to be able to use longer keys. I think the restriction was very low at the time, like 256 or so. Since its JCraft that does the SFTP stuff you may have to google a bit and try reading some of their documentation how to do this. Maybe there is some help there. And I assume you dont get any errors or the likes in the log / console? And have you tried outside OSGi, eg from a plain unit test also? On Tue, Jun 22, 2010 at 11:08 PM, Bengt Rodehav be...@rodehav.com wrote: I'm trying to get sftp private key authentication to work with sftp with no luck. I have a route similar to the following: from(file:datadir).to(sftp://u...@localhost /datadir?password=passwordprivateKeyFile=user.key); The sftp server is Serv-U. I generate key pairs using Serv-U. The public key is used by Serv-U while camel-ftp is configured with the private key. Camel manages to connect to Serv-U but never to log in. The key type is DSA and the key length is 1024. The private key looks lilke this: -BEGIN DSA PRIVATE KEY- MIIBugIBAAKBgQCR+zLyBwj0gcvNh6xmauvc2YdYYEjjoXdIUpzb01zmwFzqia9q nWCTL5t3iwqgBrZIxOa75M322OsG99+7JsBn1YaTxDJ4hSnX0dyheS620HsMFbP1 27LjYFX2mee8jeZN8GIUAdPLDHPkvGnlGfFFvj8f/IKfjAexECrBhlyhyQIVAI+1 CU2hfXqiLDuIPKruy17wrzyVAoGAB7qCoD8vJPq4jMZ77Scv4dfWgz6F+LMImcl8 QOIh+3f3JhJvR9f+hw1MGsg3l/z57GlfgXkqt420vTPI6OghELv/hauFNSExCKqv kJW+J7Hyoa0sGuf7Ihy9vC6PJnoNkopqqecwpAUUpvKahcZ1uvNnGfRDc5SGmuzn ZhKHy5ICgYBv94YBWdxGXWwcUKAmJrC+u3Xdnb8t1RY0RcrbKYqQe5Eekza4gh8B iGdLMBdX3CZlXINJRhsK0UU7E+edEIk+aCtAnFE2+S4zPqtpFGOLIjOQ+i2W5XZv MOHoxrse7qNvstZRc0BMaEKuKd9DW4wy9JMMZC7xChF8590rCaWA5gIURVR0jghL lZpwVaJtN6Yo7kUe9S8= -END DSA PRIVATE KEY- Is this a format that camel-ftp recognises? Can anyone suggest how to create a key pair that camel-ftp will recognise. I can then try to see if Serv-U also supports that? To verify that Serv-U works, I tried connecting with Filezilla client. It converted the private key to Putty format but then it worked. Could it have anything to do with US export limitations? Is the key to long? /Bengt -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
Re: sftp with privateKeyFile using camel-ftp
Hi Bengt Thanks for sharing this information. Nice that you got the attention from JCraft. Then they may fix this in the near future. And thanks for helping out with the FTP component of Camel. Its now better thanks to you. On Thu, Jun 24, 2010 at 8:53 AM, Bengt Rodehav be...@rodehav.com wrote: Claus, It seems I stumbled on a bug in Jsch - must be in my genes... I have a conversation on their mailing list. Here is a link to the archives. The latest messages are not yet in the archives but you can have a look in a day or two. http://sourceforge.net/mailarchive/forum.php?thread_name=201006231155.UAA11635%40jcraft.comforum_name=jsch-users Basically, it seems like Jsch cannot handle situations where the server requires more than one authentication method. In my case I required both a private key AND a password. If I only require a private key or only require a password then Jsch (and camel-ftp) works. Hope they will fix this promptly but I have no insight as to how quick they release new versions of Jsch. /Bengt 2010/6/23 Bengt Rodehav be...@rodehav.com Logging patch is now attached to the JIRA. /Bengt 2010/6/23 Bengt Rodehav be...@rodehav.com Claus, I'll try to get some help regarding this on the Jsch mailing list. Remember I told you nothing turns up in the log. I've looked at the source code for camel-ftp (SftpOperations.java) and there is no logger attached to Jsch. I created a JIRA for that: https://issues.apache.org/activemq/browse/CAMEL-2842 https://issues.apache.org/activemq/browse/CAMEL-2842I have a patch that I'll attach to the JIRA. I need to do a SVN update locally to be able to create a diff file but I cant currently connect to the SVN repository. I'll attach the patch as soon as possible. /Bengt 2010/6/23 Bengt Rodehav be...@rodehav.com Hi Claus, Unfortunately I get nothing in the log. If it were the 256 limit I was kind of expecting some kind of Exception. I've also been bitten by it in the past and normally you get some kind of security related exception. Maybe it's caught somewhere... To be sure I'll download the updated policy files and also try a separate client like you suggest. Thanks, /Bengt 2010/6/23 Claus Ibsen claus.ib...@gmail.com Hi The key length restriction have bitten me in the past. You had to download a special extension and override some files in the JRE to be able to use longer keys. I think the restriction was very low at the time, like 256 or so. Since its JCraft that does the SFTP stuff you may have to google a bit and try reading some of their documentation how to do this. Maybe there is some help there. And I assume you dont get any errors or the likes in the log / console? And have you tried outside OSGi, eg from a plain unit test also? On Tue, Jun 22, 2010 at 11:08 PM, Bengt Rodehav be...@rodehav.com wrote: I'm trying to get sftp private key authentication to work with sftp with no luck. I have a route similar to the following: from(file:datadir).to(sftp://u...@localhost /datadir?password=passwordprivateKeyFile=user.key); The sftp server is Serv-U. I generate key pairs using Serv-U. The public key is used by Serv-U while camel-ftp is configured with the private key. Camel manages to connect to Serv-U but never to log in. The key type is DSA and the key length is 1024. The private key looks lilke this: -BEGIN DSA PRIVATE KEY- MIIBugIBAAKBgQCR+zLyBwj0gcvNh6xmauvc2YdYYEjjoXdIUpzb01zmwFzqia9q nWCTL5t3iwqgBrZIxOa75M322OsG99+7JsBn1YaTxDJ4hSnX0dyheS620HsMFbP1 27LjYFX2mee8jeZN8GIUAdPLDHPkvGnlGfFFvj8f/IKfjAexECrBhlyhyQIVAI+1 CU2hfXqiLDuIPKruy17wrzyVAoGAB7qCoD8vJPq4jMZ77Scv4dfWgz6F+LMImcl8 QOIh+3f3JhJvR9f+hw1MGsg3l/z57GlfgXkqt420vTPI6OghELv/hauFNSExCKqv kJW+J7Hyoa0sGuf7Ihy9vC6PJnoNkopqqecwpAUUpvKahcZ1uvNnGfRDc5SGmuzn ZhKHy5ICgYBv94YBWdxGXWwcUKAmJrC+u3Xdnb8t1RY0RcrbKYqQe5Eekza4gh8B iGdLMBdX3CZlXINJRhsK0UU7E+edEIk+aCtAnFE2+S4zPqtpFGOLIjOQ+i2W5XZv MOHoxrse7qNvstZRc0BMaEKuKd9DW4wy9JMMZC7xChF8590rCaWA5gIURVR0jghL lZpwVaJtN6Yo7kUe9S8= -END DSA PRIVATE KEY- Is this a format that camel-ftp recognises? Can anyone suggest how to create a key pair that camel-ftp will recognise. I can then try to see if Serv-U also supports that? To verify that Serv-U works, I tried connecting with Filezilla client. It converted the private key to Putty format but then it worked. Could it have anything to do with US export limitations? Is the key to long? /Bengt -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
Re: sftp with privateKeyFile using camel-ftp
Glad to be of help - as others help me. BTW just got an answer from Atsuhiko at Jcraft. He will try to fix this tonight while watching Japan vs Denmark. Had to wish him good luck against Denmark - sorry... Being Swedish I normally support Denmark and Norway when we're not represented ourselves. But this time you were the ones who kicked us out of the world cup :-) /Bengt 2010/6/24 Claus Ibsen claus.ib...@gmail.com Hi Bengt Thanks for sharing this information. Nice that you got the attention from JCraft. Then they may fix this in the near future. And thanks for helping out with the FTP component of Camel. Its now better thanks to you. On Thu, Jun 24, 2010 at 8:53 AM, Bengt Rodehav be...@rodehav.com wrote: Claus, It seems I stumbled on a bug in Jsch - must be in my genes... I have a conversation on their mailing list. Here is a link to the archives. The latest messages are not yet in the archives but you can have a look in a day or two. http://sourceforge.net/mailarchive/forum.php?thread_name=201006231155.UAA11635%40jcraft.comforum_name=jsch-users Basically, it seems like Jsch cannot handle situations where the server requires more than one authentication method. In my case I required both a private key AND a password. If I only require a private key or only require a password then Jsch (and camel-ftp) works. Hope they will fix this promptly but I have no insight as to how quick they release new versions of Jsch. /Bengt 2010/6/23 Bengt Rodehav be...@rodehav.com Logging patch is now attached to the JIRA. /Bengt 2010/6/23 Bengt Rodehav be...@rodehav.com Claus, I'll try to get some help regarding this on the Jsch mailing list. Remember I told you nothing turns up in the log. I've looked at the source code for camel-ftp (SftpOperations.java) and there is no logger attached to Jsch. I created a JIRA for that: https://issues.apache.org/activemq/browse/CAMEL-2842 https://issues.apache.org/activemq/browse/CAMEL-2842I have a patch that I'll attach to the JIRA. I need to do a SVN update locally to be able to create a diff file but I cant currently connect to the SVN repository. I'll attach the patch as soon as possible. /Bengt 2010/6/23 Bengt Rodehav be...@rodehav.com Hi Claus, Unfortunately I get nothing in the log. If it were the 256 limit I was kind of expecting some kind of Exception. I've also been bitten by it in the past and normally you get some kind of security related exception. Maybe it's caught somewhere... To be sure I'll download the updated policy files and also try a separate client like you suggest. Thanks, /Bengt 2010/6/23 Claus Ibsen claus.ib...@gmail.com Hi The key length restriction have bitten me in the past. You had to download a special extension and override some files in the JRE to be able to use longer keys. I think the restriction was very low at the time, like 256 or so. Since its JCraft that does the SFTP stuff you may have to google a bit and try reading some of their documentation how to do this. Maybe there is some help there. And I assume you dont get any errors or the likes in the log / console? And have you tried outside OSGi, eg from a plain unit test also? On Tue, Jun 22, 2010 at 11:08 PM, Bengt Rodehav be...@rodehav.com wrote: I'm trying to get sftp private key authentication to work with sftp with no luck. I have a route similar to the following: from(file:datadir).to(sftp://u...@localhost /datadir?password=passwordprivateKeyFile=user.key); The sftp server is Serv-U. I generate key pairs using Serv-U. The public key is used by Serv-U while camel-ftp is configured with the private key. Camel manages to connect to Serv-U but never to log in. The key type is DSA and the key length is 1024. The private key looks lilke this: -BEGIN DSA PRIVATE KEY- MIIBugIBAAKBgQCR+zLyBwj0gcvNh6xmauvc2YdYYEjjoXdIUpzb01zmwFzqia9q nWCTL5t3iwqgBrZIxOa75M322OsG99+7JsBn1YaTxDJ4hSnX0dyheS620HsMFbP1 27LjYFX2mee8jeZN8GIUAdPLDHPkvGnlGfFFvj8f/IKfjAexECrBhlyhyQIVAI+1 CU2hfXqiLDuIPKruy17wrzyVAoGAB7qCoD8vJPq4jMZ77Scv4dfWgz6F+LMImcl8 QOIh+3f3JhJvR9f+hw1MGsg3l/z57GlfgXkqt420vTPI6OghELv/hauFNSExCKqv kJW+J7Hyoa0sGuf7Ihy9vC6PJnoNkopqqecwpAUUpvKahcZ1uvNnGfRDc5SGmuzn ZhKHy5ICgYBv94YBWdxGXWwcUKAmJrC+u3Xdnb8t1RY0RcrbKYqQe5Eekza4gh8B iGdLMBdX3CZlXINJRhsK0UU7E+edEIk+aCtAnFE2+S4zPqtpFGOLIjOQ+i2W5XZv MOHoxrse7qNvstZRc0BMaEKuKd9DW4wy9JMMZC7xChF8590rCaWA5gIURVR0jghL lZpwVaJtN6Yo7kUe9S8= -END DSA PRIVATE KEY- Is this a format that camel-ftp recognises? Can anyone suggest how to create a key pair that camel-ftp will recognise. I can then try to see if Serv-U also supports that? To verify that Serv-U works, I tried connecting with Filezilla client. It converted the private key to Putty format but then it worked.
Re: Email character encoding?
On Wed, Jun 23, 2010 at 8:16 AM, Mattias Severson mat...@gmail.com wrote: Hi, I am having trouble sending ISO-8859-1 characters, e.g. åäö, in emails. I have tried to set the defaultEncoding option of the http://camel.apache.org/mail.html Camel Mail component to ISO-8859-1, but that did not solve the problem. Where is the problem in the mail? - the subject - the mail body And are you sending plain/txt mails or something like xml or html? I assume you see the character problems using a mail client which receives the email? eg Outlook or the likes? You can enable some java mail debug (debugMode=true) and you should be able to see the actual mail message being send to the mail server. The sender is implemented as producerTemplate.sendBodyAndHeaders(emailRecipientUri, emailBody, camelEmailHeaders); and I am using Camel 2.3.0 Any ideas? /Mattias -- View this message in context: http://camel.465427.n5.nabble.com/Email-character-encoding-tp510814p510814.html Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
Re: Email character encoding?
Mattias Severson wrote:
Hi,
I am having trouble sending ISO-8859-1 characters, e.g. åäö, in emails. I
have tried to set the defaultEncoding option of the
http://camel.apache.org/mail.html Camel Mail component to ISO-8859-1, but
that did not solve the problem.
The sender is implemented as
producerTemplate.sendBodyAndHeaders(emailRecipientUri, emailBody,
camelEmailHeaders);
Maybe you need to set the Exchange.property for the charset like this
producerTemplate.send(emailRecipientUri, new Processor() {
void process(Exchange exchange) throws Exception {
exchange.getIn().setBody(emailBody);
exchange.getIn().setHeaders(camelEmailHeaders);
exchange.setProperty(Exchange.CHARSET_NAME, ISO-8859-1);
}
}
Willem
--
Apache Camel, Apache CXF committer
Open SOA http://www.fusesource.com
Blog http://willemjiang.blogspot.com
Tiwtter http://twitter.com/willemjiang
and I am using Camel 2.3.0
Any ideas?
/Mattias
Re: Email character encoding?
Hi,
I just check the Java document of MimeMessage[1], the message subject
*must* contain only US-ASCII characters, maybe that cause your problem.
[1]http://java.sun.com/products/javamail/javadocs/javax/mail/internet/MimeMessage.html
Willem Jiang wrote:
Mattias Severson wrote:
Hi,
I am having trouble sending ISO-8859-1 characters, e.g. åäö, in emails. I
have tried to set the defaultEncoding option of the
http://camel.apache.org/mail.html Camel Mail component to ISO-8859-1,
but
that did not solve the problem.
The sender is implemented as
producerTemplate.sendBodyAndHeaders(emailRecipientUri, emailBody,
camelEmailHeaders);
Maybe you need to set the Exchange.property for the charset like this
producerTemplate.send(emailRecipientUri, new Processor() {
void process(Exchange exchange) throws Exception {
exchange.getIn().setBody(emailBody);
exchange.getIn().setHeaders(camelEmailHeaders);
exchange.setProperty(Exchange.CHARSET_NAME, ISO-8859-1);
}
}
Willem
--
Apache Camel, Apache CXF committer
Open SOA http://www.fusesource.com
Blog http://willemjiang.blogspot.com
Tiwtter http://twitter.com/willemjiang
and I am using Camel 2.3.0
Any ideas?
/Mattias
Re: Email character encoding?
Claus Ibsen wrote:
On Thu, Jun 24, 2010 at 2:52 PM, Willem Jiang willem.ji...@gmail.com wrote:
Hi,
I just check the Java document of MimeMessage[1], the message subject *must*
contain only US-ASCII characters, maybe that cause your problem.
[1]http://java.sun.com/products/javamail/javadocs/javax/mail/internet/MimeMessage.html
Ah there is an overloaded setSubject which accepts a charset. Do we
use that in the camel-mail code?
Yes, we used it in camel 2.3, but I think there could be something wrong
with getting the default charset from the exchange.
Willem Jiang wrote:
Mattias Severson wrote:
Hi,
I am having trouble sending ISO-8859-1 characters, e.g. åäö, in emails. I
have tried to set the defaultEncoding option of the
http://camel.apache.org/mail.html Camel Mail component to ISO-8859-1, but
that did not solve the problem.
The sender is implemented as
producerTemplate.sendBodyAndHeaders(emailRecipientUri, emailBody,
camelEmailHeaders);
Maybe you need to set the Exchange.property for the charset like this
producerTemplate.send(emailRecipientUri, new Processor() {
void process(Exchange exchange) throws Exception {
exchange.getIn().setBody(emailBody);
exchange.getIn().setHeaders(camelEmailHeaders);
exchange.setProperty(Exchange.CHARSET_NAME, ISO-8859-1);
}
}
Willem
--
Apache Camel, Apache CXF committer
Open SOA http://www.fusesource.com
Blog http://willemjiang.blogspot.com
Tiwtter http://twitter.com/willemjiang
and I am using Camel 2.3.0
Any ideas?
/Mattias
Re: Email character encoding?
On Thu, Jun 24, 2010 at 3:37 PM, Willem Jiang willem.ji...@gmail.com wrote:
Claus Ibsen wrote:
On Thu, Jun 24, 2010 at 2:52 PM, Willem Jiang willem.ji...@gmail.com
wrote:
Hi,
I just check the Java document of MimeMessage[1], the message subject
*must*
contain only US-ASCII characters, maybe that cause your problem.
[1]http://java.sun.com/products/javamail/javadocs/javax/mail/internet/MimeMessage.html
Ah there is an overloaded setSubject which accepts a charset. Do we
use that in the camel-mail code?
Yes, we used it in camel 2.3, but I think there could be something wrong
with getting the default charset from the exchange.
Ah yeah you change some code to fallback to use UTF-8 or JVM default
or something.
This may cause that issue?
Willem Jiang wrote:
Mattias Severson wrote:
Hi,
I am having trouble sending ISO-8859-1 characters, e.g. едц, in emails.
I
have tried to set the defaultEncoding option of the
http://camel.apache.org/mail.html Camel Mail component to ISO-8859-1,
but
that did not solve the problem.
The sender is implemented as
producerTemplate.sendBodyAndHeaders(emailRecipientUri, emailBody,
camelEmailHeaders);
Maybe you need to set the Exchange.property for the charset like this
producerTemplate.send(emailRecipientUri, new Processor() {
void process(Exchange exchange) throws Exception {
exchange.getIn().setBody(emailBody);
exchange.getIn().setHeaders(camelEmailHeaders);
exchange.setProperty(Exchange.CHARSET_NAME, ISO-8859-1);
}
}
Willem
--
Apache Camel, Apache CXF committer
Open SOA http://www.fusesource.com
Blog http://willemjiang.blogspot.com
Tiwtter http://twitter.com/willemjiang
and I am using Camel 2.3.0
Any ideas?
/Mattias
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: Email character encoding?
Yes, I also read about the US-ASCII encoding. Consequently, I tried to use http://java.sun.com/products/javamail/javadocs/javax/mail/internet/MimeUtility.html#encodeText%28java.lang.String,%20java.lang.String,%20java.lang.String%29 MimeUtility.encodeText(...) with B encoding to base 64 encode the message. The message is encoded, but the recipients are unable to decode it. /Mattias -- View this message in context: http://camel.465427.n5.nabble.com/Email-character-encoding-tp510814p511108.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Email character encoding?
Spring has a interface called http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/mail/javamail/JavaMailSender.html JavaMailSender . With it one can create a http://java.sun.com/products/javamail/javadocs/javax/mail/internet/MimeMessage.html MimeMessage that allows charsets to be specified in conjunction with the subject and the message: MimeMessage mailMessage = mailSender.createMimeMessage(); mailMessage.setSubject(Email subject, ISO-8859-1); mailMessage.setText(This is the email message, ISO-8859-1); // add sender, receiver, etc mailSender.sendMessage(mailMessage); -- View this message in context: http://camel.465427.n5.nabble.com/Email-character-encoding-tp510814p51.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Email character encoding?
And there is more: The http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/mail/javamail/MimeMessageHelper.html MimeMessageHelper gives more options to send both plain text and html formatted mail in the same message (to support all kinds of email clients), as well as inline content and email attachments: MimeMessage message = mailSender.createMimeMessage(); // add recipient, sender and subject MimeMessageHelper helper = new MimeMessageHelper(message, true, charset); helper.setText(plainMessage, htmlMessage); helper.addInline(someImage, new ClassPathResource(img/someImage.jpg)); helper.addAttachment(document.pdf, new ClassPathResource(doc/document.pdf)); /Mattias -- View this message in context: http://camel.465427.n5.nabble.com/Email-character-encoding-tp510814p58.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Clustering with camel-quartz
Hello, I found still some issues about clustering camel-quartz component (based on the current trunk version) First, why are stateful triggers are unscheduled on a graceful shutdown. I guess this causes, that the trigger is deleted within the database. So not only the node that is shutting down loses the triggers also the other nodes in the cluster will lost their triggers. Maybe checking if the trigger is stateful before removing on shutdown will help. Second, see the log below. It seems that the default trigger is fired before it is resumed. Any suggestions? Regards Ingo INFO - TestContextManager - @TestExecutionListeners is not present for class [class crowdcode.quartz.cluster.demo.QuartzClusterTest]: using defaults. INFO - XmlBeanDefinitionReader- Loading XML bean definitions from class path resource [context-test.xml] INFO - CamelNamespaceHandler - camel-osgi.jar/camel-spring-osgi.jar not detected in classpath DEBUG - CamelNamespaceHandler - Using org.apache.camel.spring.CamelContextFactoryBean as CamelContextBeanDefinitionParser DEBUG - CamelNamespaceHandler - Registered default: org.apache.camel.spring.CamelProducerTemplateFactoryBean with id: template on camel context: camel-quartz DEBUG - CamelNamespaceHandler - Registered default: org.apache.camel.spring.CamelConsumerTemplateFactoryBean with id: consumerTemplate on camel context: camel-quartz INFO - GenericApplicationContext - Refreshing org.springframework.context.support.genericapplicationcont...@46dd75a4: display name [org.springframework.context.support.genericapplicationcont...@46dd75a4]; startup date [Thu Jun 24 19:20:18 CEST 2010]; root of context hierarchy INFO - GenericApplicationContext - Bean factory for application context [org.springframework.context.support.genericapplicationcont...@46dd75a4]: org.springframework.beans.factory.support.defaultlistablebeanfact...@28caea19 DEBUG - SpringCamelContext - Set the application context classloader to: sun.misc.launcher$appclassloa...@32f4a24a DEBUG - AbstractCamelContextFactoryBean - Found JAXB created routes: [] INFO - DefaultListableBeanFactory - Pre-instantiating singletons in org.springframework.beans.factory.support.defaultlistablebeanfact...@28caea19: defining beans [template,consumerTemplate,camel-quartz:beanPostProcessor,camel-quartz,org.springframework.context.annotation.internalCommonAnnotationProcessor,org.springframework.context.annotation.internalAutowiredAnnotationProcessor,org.springframework.context.annotation.internalRequiredAnnotationProcessor]; root of factory hierarchy DEBUG - SpringCamelContext - onApplicationEvent: org.springframework.context.event.contextrefreshedevent[source=org.springframework.context.support.genericapplicationcont...@46dd75a4: display name [org.springframework.context.support.genericapplicationcont...@46dd75a4]; startup date [Thu Jun 24 19:20:18 CEST 2010]; root of context hierarchy] INFO - DefaultCamelContext- Apache Camel 2.4-SNAPSHOT (CamelContext: camel-quartz) is starting INFO - DefaultCamelContext- JMX enabled. Using ManagedManagementStrategy. DEBUG - DefaultManagementAgent - Starting JMX agent on server: com.sun.jmx.mbeanserver.jmxmbeanser...@4aa0c486 DEBUG - DefaultManagementAgent - Registered MBean with objectname: org.apache.camel:context=MacHal.local/camel-quartz,type=context,name=camel-quartz DEBUG - DefaultManagementAgent - Registered MBean with objectname: org.apache.camel:context=MacHal.local/camel-quartz,type=services,name=DefaultTypeConverter(0x2bbef4c6) DEBUG - DefaultTypeConverter - Loading type converters ... INFO - AnnotationTypeConverterLoader - Loading file META-INF/services/org/apache/camel/TypeConverter to retrieve list of packages, from url: jar:file:/Users/idueppe/.m2/repository/org/apache/camel/camel-core/2.4-SNAPSHOT/camel-core-2.4-SNAPSHOT.jar!/META-INF/services/org/apache/camel/TypeConverter DEBUG - DefaultPackageScanClassResolver - Searching for annotations of org.apache.camel.Converter in packages: [org.apache.camel.component.file, org.apache.camel.component.bean, org.apache.camel.converter] DEBUG - DefaultPackageScanClassResolver - Found: [class org.apache.camel.component.file.GenericFileConverter, class org.apache.camel.component.bean.BeanConverter, class org.apache.camel.converter.CamelConverter, class org.apache.camel.converter.CollectionConverter, class org.apache.camel.converter.IOConverter, class org.apache.camel.converter.NIOConverter, class org.apache.camel.converter.ObjectConverter, class org.apache.camel.converter.TimePatternConverter, class org.apache.camel.converter.jaxp.DomConverter, class org.apache.camel.converter.jaxp.StaxConverter, class org.apache.camel.converter.jaxp.StreamSourceConverter, class org.apache.camel.converter.jaxp.XmlConverter, class org.apache.camel.converter.stream.StreamCacheConverter] INFO -
Re: Problem with maintaining a JMS subscription after waking from sleep
Claus Ibsen-2 wrote: I think we can fix the issue with a custom exceptionListener which fixes the null message. Can you test it by creating a custom javax.jms.ExceptionListener class and then set the message to a non null value. And in Camel you can register the listener using the exceptionListener=#myListener configuration in the endpoint uri. If it fixes it we can create a listener to be shipped out of the box. Hi Claus, I can expend the effort to do this however I've now moved and tested my application in UAT based on Spring 3 (I had to move quickly). In addition an exception listener sounds like a hack. Can we not move to Spring 3 and provide a Spring 2 profile (swap the profile situation around?). That way any AMQ and SMX dependency issue is resolved as they can build their own distributions from source. BTW: I don't see much value in shipping Camel with AMQ nowadays; I appreciate the history, but they're really two very independent things. I can't imagine why someone would prefer to use an AMQ bundled Camel vs. the one generally available. Also, given SMX's relationship to OSGi and thus its great handling at dependencies I'm not sure I get why Camel needs to be strongly coupled there either. Let's not have other projects constrain what we do here. -- View this message in context: http://camel.465427.n5.nabble.com/Problem-with-maintaining-a-JMS-subscription-after-waking-from-sleep-tp510193p511190.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Clustering with camel-quartz
On Thu, Jun 24, 2010 at 7:29 PM, Ingo Düppe mailing-li...@dueppe.com wrote: Hello, I found still some issues about clustering camel-quartz component (based on the current trunk version) First, why are stateful triggers are unscheduled on a graceful shutdown. I guess this causes, that the trigger is deleted within the database. So not only the node that is shutting down loses the triggers also the other nodes in the cluster will lost their triggers. Maybe checking if the trigger is stateful before removing on shutdown will help. Thanks for reporting. I have just committed a fix to trunk which only removes the job if its volatile. trunk: 957796. Volatile is the information according to the quartz API which dictates if the job should be kept in the DB or not. http://www.quartz-scheduler.org/docs/api/1.8.1/index.html Please give it a test on your system. Second, see the log below. It seems that the default trigger is fired before it is resumed. Any suggestions? Regards Ingo INFO - TestContextManager - @TestExecutionListeners is not present for class [class crowdcode.quartz.cluster.demo.QuartzClusterTest]: using defaults. INFO - XmlBeanDefinitionReader - Loading XML bean definitions from class path resource [context-test.xml] INFO - CamelNamespaceHandler - camel-osgi.jar/camel-spring-osgi.jar not detected in classpath DEBUG - CamelNamespaceHandler - Using org.apache.camel.spring.CamelContextFactoryBean as CamelContextBeanDefinitionParser DEBUG - CamelNamespaceHandler - Registered default: org.apache.camel.spring.CamelProducerTemplateFactoryBean with id: template on camel context: camel-quartz DEBUG - CamelNamespaceHandler - Registered default: org.apache.camel.spring.CamelConsumerTemplateFactoryBean with id: consumerTemplate on camel context: camel-quartz INFO - GenericApplicationContext - Refreshing org.springframework.context.support.genericapplicationcont...@46dd75a4: display name [org.springframework.context.support.genericapplicationcont...@46dd75a4]; startup date [Thu Jun 24 19:20:18 CEST 2010]; root of context hierarchy INFO - GenericApplicationContext - Bean factory for application context [org.springframework.context.support.genericapplicationcont...@46dd75a4]: org.springframework.beans.factory.support.defaultlistablebeanfact...@28caea19 DEBUG - SpringCamelContext - Set the application context classloader to: sun.misc.launcher$appclassloa...@32f4a24a DEBUG - AbstractCamelContextFactoryBean - Found JAXB created routes: [] INFO - DefaultListableBeanFactory - Pre-instantiating singletons in org.springframework.beans.factory.support.defaultlistablebeanfact...@28caea19: defining beans [template,consumerTemplate,camel-quartz:beanPostProcessor,camel-quartz,org.springframework.context.annotation.internalCommonAnnotationProcessor,org.springframework.context.annotation.internalAutowiredAnnotationProcessor,org.springframework.context.annotation.internalRequiredAnnotationProcessor]; root of factory hierarchy DEBUG - SpringCamelContext - onApplicationEvent: org.springframework.context.event.contextrefreshedevent[source=org.springframework.context.support.genericapplicationcont...@46dd75a4: display name [org.springframework.context.support.genericapplicationcont...@46dd75a4]; startup date [Thu Jun 24 19:20:18 CEST 2010]; root of context hierarchy] INFO - DefaultCamelContext - Apache Camel 2.4-SNAPSHOT (CamelContext: camel-quartz) is starting INFO - DefaultCamelContext - JMX enabled. Using ManagedManagementStrategy. DEBUG - DefaultManagementAgent - Starting JMX agent on server: com.sun.jmx.mbeanserver.jmxmbeanser...@4aa0c486 DEBUG - DefaultManagementAgent - Registered MBean with objectname: org.apache.camel:context=MacHal.local/camel-quartz,type=context,name=camel-quartz DEBUG - DefaultManagementAgent - Registered MBean with objectname: org.apache.camel:context=MacHal.local/camel-quartz,type=services,name=DefaultTypeConverter(0x2bbef4c6) DEBUG - DefaultTypeConverter - Loading type converters ... INFO - AnnotationTypeConverterLoader - Loading file META-INF/services/org/apache/camel/TypeConverter to retrieve list of packages, from url: jar:file:/Users/idueppe/.m2/repository/org/apache/camel/camel-core/2.4-SNAPSHOT/camel-core-2.4-SNAPSHOT.jar!/META-INF/services/org/apache/camel/TypeConverter DEBUG - DefaultPackageScanClassResolver - Searching for annotations of org.apache.camel.Converter in packages: [org.apache.camel.component.file, org.apache.camel.component.bean, org.apache.camel.converter] DEBUG - DefaultPackageScanClassResolver - Found: [class org.apache.camel.component.file.GenericFileConverter, class org.apache.camel.component.bean.BeanConverter, class org.apache.camel.converter.CamelConverter, class org.apache.camel.converter.CollectionConverter, class
Re: Clustering with camel-quartz
On Thu, Jun 24, 2010 at 7:29 PM, Ingo Düppe mailing-li...@dueppe.com wrote: Hello, I found still some issues about clustering camel-quartz component (based on the current trunk version) First, why are stateful triggers are unscheduled on a graceful shutdown. I guess this causes, that the trigger is deleted within the database. So not only the node that is shutting down loses the triggers also the other nodes in the cluster will lost their triggers. Maybe checking if the trigger is stateful before removing on shutdown will help. Second, see the log below. It seems that the default trigger is fired before it is resumed. Any suggestions? I think the reason is the scheduler is started before the other routes has been fully started. And quartz starts very quick. We could add an option so you can configure a delay option so it can be started with delay. It has a startDelayed method: http://www.quartz-scheduler.org/docs/api/1.8.1/org/quartz/Scheduler.html However a better solution is to offer this as a feature in Camel which allows component to register callbacks to be invoked when all the other stuff have been started, so they can start last. I have created a ticket to track that https://issues.apache.org/activemq/browse/CAMEL-2855 -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
