Re: [HEADS UP] - camel-scr for OSGi with pure Java in Camel 2.15

[Grzegorz Grzybek]

Great!
I'll sure have a look too!

regards
Grzegorz Grzybek

2014-11-09 11:02 GMT+01:00 Jean-Baptiste Onofré :

> Hi Claude
>
> Thanks for the update. I will take a look ASAP.
>
> Regards
> JB
>
>
> Sent from my Samsung Galaxy smartphone.
>
>
>  Original message 
> From: Claus Ibsen 
> Date:09/11/2014  09:42  (GMT+01:00)
> To: users@camel.apache.org
> Cc:
> Subject: [HEADS UP] - camel-scr for OSGi with pure Java in Camel 2.15
>
> Hi
>
> There is a great contribution for a new camel-scr module that allows
> end users to use OSGi declarative services instead of spring-dm /
> blueprint.
>
> The code has just been pushed to master branch, but there is still
> some work to finish and polish the code.
>
> But I wanted to bring this to attention, so we can have more eyes on
> this - especially for the OSGi folks.
>
> The JIRA ticket is, with some bullets to look at:
> https://issues.apache.org/jira/browse/CAMEL-7997
>
> And the code is in the camel-scr module. And there is a camel-scr
> feature to install the module.
>
>
>
>
>
> --
> Claus Ibsen
> -
> Red Hat, Inc.
> Email: cib...@redhat.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
> hawtio: http://hawt.io/
> fabric8: http://fabric8.io/
>

Camel 2.13.0 PGP encryption issue

[vincent.wong]

Hello, I am trying to transfer file from one folder to another using camel
with PGP encryption(using Camel-Crypto extension).

It compiles fine but unfortunately when I run it as a service, it keeps
producing the following error:

Stacktrace
---
org.bouncycastle.openpgp.PGPException: Exception creating cipher
at org.bouncycastle.openpgp.PGPEncryptedDataGenerator.open(Unknown 
Source)
~[/:na]
at org.bouncycastle.openpgp.PGPEncryptedDataGenerator.open(Unknown 
Source)
~[/:na]
at
org.apache.camel.converter.crypto.PGPKeyAccessDataFormat.marshal(PGPKeyAccessDataFormat.java:223)
~[/:na]
at
org.apache.camel.processor.MarshalProcessor.process(MarshalProcessor.java:81)
~[/:na]
at
org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
[/:na]
at
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:398)
[/:na]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
[/:na]
at org.apache.camel.processor.Pipeline.process(Pipeline.java:118)
[/:na]
at org.apache.camel.processor.Pipeline.process(Pipeline.java:80) 
[/:na]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
[/:na]
at
org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:51)
[/:na]
at 
org.apache.camel.processor.SendProcessor.process(SendProcessor.java:120)
[/:na]
at
org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
[/:na]
at
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:398)
[/:na]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
[/:na]
at org.apache.camel.processor.Pipeline.process(Pipeline.java:118)
[/:na]
at org.apache.camel.processor.Pipeline.process(Pipeline.java:80) 
[/:na]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
[/:na]
at
org.apache.camel.component.file.GenericFileConsumer.processExchange(GenericFileConsumer.java:423)
[/:na]
at
org.apache.camel.component.file.GenericFileConsumer.processBatch(GenericFileConsumer.java:211)
[/:na]
at
org.apache.camel.component.file.GenericFileConsumer.poll(GenericFileConsumer.java:175)
[/:na]
at
org.apache.camel.impl.ScheduledPollConsumer.doRun(ScheduledPollConsumer.java:187)
[/:na]
at
org.apache.camel.impl.ScheduledPollConsumer.run(ScheduledPollConsumer.java:114)
[/:na]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[na:1.8.0]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
[na:1.8.0]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
[na:1.8.0]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
[na:1.8.0]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[na:1.8.0]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[na:1.8.0]
at java.lang.Thread.run(Thread.java:744) [na:1.8.0]
Caused by: java.lang.SecurityException: JCE cannot authenticate the provider
BC
at javax.crypto.Cipher.getInstance(Cipher.java:652) ~[na:1.8.0]
at javax.crypto.Cipher.getInstance(Cipher.java:591) ~[na:1.8.0]
at org.bouncycastle.jcajce.NamedJcaJceHelper.createCipher(Unknown 
Source)
~[/:na]
at
org.bouncycastle.openpgp.operator.jcajce.OperatorHelper.createCipher(Unknown
Source) ~[/:na]
at
org.bouncycastle.openpgp.operator.jcajce.OperatorHelper.createStreamCipher(Unknown
Source) ~[/:na]
at
org.bouncycastle.openpgp.operator.jcajce.JcePGPDataEncryptorBuilder$MyPGPDataEncryptor.(Unknown
Source) ~[/:na]
at
org.bouncycastle.openpgp.operator.jcajce.JcePGPDataEncryptorBuilder.build(Unknown
Source) ~[/:na]
... 30 common frames omitted
Caused by: java.lang.SecurityException: Cannot verify jar:file:/D://!/
at javax.crypto.JarVerifier.verifySingleJar(JarVerifier.java:407)
~[na:1.8.0]
at javax.crypto.JarVerifier.verifyJars(JarVerifier.java:322) ~[na:1.8.0]
at javax.crypto.JarVerifier.verify(JarVerifier.java:250) ~[na:1.8.0]
at javax.crypto.JceSecurity.verifyProviderJar(JceSecurity.java:160)
~[na:1.8.0]
at javax.crypto.JceSecurity.getVerificationResult(JceSecurity.java:186)
~[na:1.8.0]
at javax.crypto.Cipher.getInstance(Cipher.java:648) ~[na:1.8.0]
... 36 common frames om

Re: Quartz job data deletion in clustered quartz2

[lakshmi.prashant]

Hi Claus,

  There is a mis-communication - we need not have a special classloader
helper, I think. 

  The issue was because on the un-deployment of 1 camel blueprint bundle
(with camel quartz2 route),* the quartz job data is not deleted from db - if
it is clustered quartz.*

 Unfortunately, we do not want to delete the job data, when the route is
stopped using RoutePolicySupport class, as the main intent from clustered
quartz is job recovery.
  - The scheduler will be shut down (QuartzComponent: doStop()) if there are
no more jobs (if the scheduler is not shared across camel context bundles) &
it works fine.
  - But if the scheduler configuration / scheduler instance is shared across
camel quartz routes / bundles, the scheduler continues to run.
  - When the scheduler acquires next trigger, the trigger related to
undeployed bundle is also obtained & then it tries to execute that trigger
by executing CamelJob class from uninstalled bundle, using
CascadingClassLoaderHelper.
  - If it cannot load the class for that trigger, it throws exception and
the rest of the triggers do not get executed at that time - So we get
misfires.

Please refer to  line no. 876 in 
org.quartz.impl.jdbcjobstore.StdJDBCDelegate.java - this quartz class throws
exception, if job class is not loaded and does not proceed further.
 job.setJobClass(loadHelper.loadClass(rs  .getString(COL_JOB_CLASS)));

  1. I have written an osgi EventHandler service that will listen to 'bundle
undeploy' events, that get published.
  2. If the osgi bundle related to camel quartz2 is undeployed, it will
remove the corresponding job data from DB.

If this can be handled by camel quartz2, it will become simple for
end-users.
 
a) There is an issue in camel QuartzEndpoint.java in addJobInScheduler(). We
were getting misfires in some nodes of the cluster, due to below issue.

   a) If the trigger does not exist in DB, it tries to schedule the job
   b) But this is not an atomic transaction - After the call to find a
trigger from DB  is made, some other node in the cluster could have created
the trigger, resulting in ObjectAlreadyExistsException when call to schedule
job is made
  c) Then misfires happen in that cluster node, as the Quartz component /
camel context itself does not get started. 

  private void addJobInScheduler() throws Exception {
// Add or use existing trigger to/from scheduler
Scheduler scheduler = getComponent().getScheduler();
JobDetail jobDetail;
Trigger trigger = scheduler.getTrigger(triggerKey);
if (trigger == null) {
jobDetail = createJobDetail();
trigger = createTrigger(jobDetail);

updateJobDataMap(jobDetail);

// Schedule it now. Remember that scheduler might not be started
it, but we can schedule now.
try{
Date nextFireDate = scheduler.scheduleJob(jobDetail, 
trigger);
if (LOG.isInfoEnabled()) {
LOG.info("Job {} (triggerType={}, jobClass={}) is
scheduled. Next fire date is {}",
 new Object[] {trigger.getKey(),
trigger.getClass().getSimpleName(),
  
jobDetail.getJobClass().getSimpleName(), nextFireDate});
}
}
   * catch(ObjectAlreadyExistsException e){
//double-check if Some other VM might has already stored the
job & trigger in clustered mode
if(!(getComponent().isClustered())){
throw e;
}
else{
trigger = scheduler.getTrigger(triggerKey);
if(trigger==null){
  throw new SchedulerException("Trigger could 
not be found in
quartz scheduler.");
}
}
}*
} else {
ensureNoDupTriggerKey();
}

Can the above correction in QuartzComponent.java be made?

Thanks,
Lakshmi



--
View this message in context: 
http://camel.465427.n5.nabble.com/Quartz-job-data-deletion-in-clustered-quartz2-tp5757508p5758806.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Camel 2.13.0 PGP encryption issue

[vincent.wong]

It works fine if I run it using maven:
D:\Development\Java\>"D:\development\apache-maven-3.2.3\bin\mvn.bat"
-Dexec.args="-Djava.net.preferIPv4Stack=true -classpath %classpath
au.com...App" -Dexec.executable="C:\Program
Files\Java\jdk1.8.0\bin\java.exe"-Dfile.encoding=UTF-8
org.codehaus.mojo:exec-maven-plugin:1.2.1:exec

But somehow it doesn't work if I use:
java -Dfile.encoding=UTF-8 -Djava.net.preferIPv4Stack=true  -cp
D:\LumoCamelService au.com.lumoenergy.camelxml.App





--
View this message in context: 
http://camel.465427.n5.nabble.com/Camel-2-13-0-PGP-encryption-issue-tp5758803p5758805.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Setting rest response json directly

[Gary Kennedy]

I changed the way I used the servlet/rest component and it works for me now.

I'm still using the same bean setup as before:









But now I've dropped the rest part, and using servlet endpoints to start the
routes:







< !-- lots of magic -->

net.me.MyException
true
< !-- more magic -->

application/json


{ "error": "${exception.message}" }





The bonus to using this method is that the unmarshalling is covered by the
in-route onException block as well.

The downside is that now I have to work on the http method filtering (ie,
making the route POST/GET specific). It might be easier to play with the
consumes/produces part of the rest dsl to bring the above theory used above
into the rest dsl. Anyways,

Cheers,
Gary



--
View this message in context: 
http://camel.465427.n5.nabble.com/Setting-rest-response-json-directly-tp5758518p5758801.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Camel's tps

[Frans Thamura]

Hi all

Reading the Vodafone presentation in slideshare.net regarding Fuse and
jboss and netty confuse me.

Anyone have a case regarding camel in tps,  transaction persecond,

Does this tps case relevant in route?

Frans

Re: executing PL/SQL script

[Christian Müller]

And have a look at the Camel MyBatis/IBatis component.

Best,
Christian
Am 07.11.2014 18:03 schrieb "Preben.Asmussen" :

> Hi M
>
> You can always uses a regular java bean for executing custom logic. See
> Bean binding 
>
> The custom bean could execute your PLSQL using eg. Springs JdbcTemplate
>
> /Preben
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/executing-PL-SQL-script-tp5758616p5758708.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>

Re: [ANNOUNCE] Apache Camel 2.13.3 Released

[Christian Müller]

Thanks for reporting James!

There was a typo in the title which I have fixed now. The link should work
in a few hours, after the WIKI page [1] is exported.

[1] https://cwiki.apache.org/confluence/display/CAMEL/Camel+2.13.3+Release

Best,

Christian
-

Software Integration Specialist

Apache Member
V.P. Apache Camel | Apache Camel PMC Member | Apache Camel committer
Apache Incubator PMC Member

https://www.linkedin.com/pub/christian-mueller/11/551/642

On Wed, Nov 5, 2014 at 12:20 PM, James Green 
wrote:

> The [4] link below does not exist.
>
> The download page shows 2.13.3 but is linked to 2.13.2.
>
> On 1 November 2014 07:53, Christian Mueller  wrote:
>
> > The Apache Camel project [1] is a powerful open source integration
> > framework based on known Enterprise Integration Patterns [2].
> >
> > The Camel community announces the immediate availability of the new patch
> > release camel-2.13.3.
> >
> > The artifacts are published and ready for you to download [3] either from
> > the Apache mirrors or from the Central Maven repository.
> > For more details please take a look at the release notes [4].
> >
> > Many thanks to the Camel community for the hard work.
> >
> > Christian
> >
> > [1]http://camel.apache.org/
> > [2]http://camel.apache.org/enterprise-integration-patterns.html
> > [3]http://camel.apache.org/download.html
> > [4]http://camel.apache.org/camel-2133-release.html
> >
>

RE: [HEADS UP] - camel-scr for OSGi with pure Java in Camel 2.15

[Jean-Baptiste Onofré]

Hi Claude

Thanks for the update. I will take a look ASAP. 

Regards
JB


Sent from my Samsung Galaxy smartphone.


 Original message 
From: Claus Ibsen  
Date:09/11/2014  09:42  (GMT+01:00) 
To: users@camel.apache.org 
Cc:  
Subject: [HEADS UP] - camel-scr for OSGi with pure Java in Camel 2.15 

Hi

There is a great contribution for a new camel-scr module that allows
end users to use OSGi declarative services instead of spring-dm /
blueprint.

The code has just been pushed to master branch, but there is still
some work to finish and polish the code.

But I wanted to bring this to attention, so we can have more eyes on
this - especially for the OSGi folks.

The JIRA ticket is, with some bullets to look at:
https://issues.apache.org/jira/browse/CAMEL-7997

And the code is in the camel-scr module. And there is a camel-scr
feature to install the module.





-- 
Claus Ibsen
-
Red Hat, Inc.
Email: cib...@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
hawtio: http://hawt.io/
fabric8: http://fabric8.io/

[HEADS UP] - camel-scr for OSGi with pure Java in Camel 2.15

[Claus Ibsen]

Hi

There is a great contribution for a new camel-scr module that allows
end users to use OSGi declarative services instead of spring-dm /
blueprint.

The code has just been pushed to master branch, but there is still
some work to finish and polish the code.

But I wanted to bring this to attention, so we can have more eyes on
this - especially for the OSGi folks.

The JIRA ticket is, with some bullets to look at:
https://issues.apache.org/jira/browse/CAMEL-7997

And the code is in the camel-scr module. And there is a camel-scr
feature to install the module.





-- 
Claus Ibsen
-
Red Hat, Inc.
Email: cib...@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
hawtio: http://hawt.io/
fabric8: http://fabric8.io/