[HEADS UP] - Adjustments to ExecutorServiceManager on trunk

[Claus Ibsen]

Hi

Recently the ExecutorServiceStrategy had a bigger refactor
(https://issues.apache.org/jira/browse/CAMEL-4244)
Such as renaming the class to a better name ExecutorServiceManager.
Also introducing a ThreadPoolFactory, ThreadFactory among others. The
ThreadPoolFactory is a great addition, which makes it easier for 3rd
party to just implement a custom factory, and then reply on the
default manager.

However the refactoring introduced a few issues such as configuring
thread pools on EIPs was flawed. Well it also revealed we were short
of an unit test to cover this. So I created a ticket, and committed a
test to the 2.8 branch.
https://issues.apache.org/jira/browse/CAMEL-4328

The refactoring did also make backwards compatibility an issue, so we
will restore that but mark the old API as @deprecated.

The changes are summarized as follows
- ThreadPoolFactory is the light weight and easier for SPI
implementators to create a custom thread pool provider, such as JEE
servers with a WorkManager API. This API has much fewer methods and
they have been adjusted to be 100% JDK API (There is no Camel API in
there, such as ThreadPoolProfile).
- ExecutorServiceManager is the full fledged SPI in case you need 100%
control. But it has Camel APIs such as ThreadPoolProfiles and a number
of more methods. Its is encouraged to just implement a custom
ThreadPoolFactory instead. And keep using the
DefaultExecutorServiceManager.
- ThreadPoolBuilder is adjusted to create a thread pool on the build
method. This is how end users would expect. A builder to create what
its name implies. This also removes entanglement of ThreadPool and
ThreadPoolProfile. The latter is Camel specific and is only part of
the ExecutorServiceManager which manges a list of profiles. To help
uniform and make it easy to adjust thread pool settings at a higher
level. So ThreadPoolProfiles should only be party of the manager.
- EIPs configured using an explicit thread pool by an
executorServiceRef, will now act as expected. If the reference could
not be found, an exception is thrown, stating the reference is not
found
- Will add the ExecutorServiceStrategy SPI to have Camel 2.9 being
backwards compatible, but mark it as @deprecated. This gives end users
some time to adjust their custom Camel components, and source code if
needed.
- Naming of the methods will use the naming convention used by the
JDK. xxxThreadPool for a pool of threads, xxxExecutor if its a single
threaded (eg used for background tasks)
- Made the API of ExecutorServiceManager more similar to the old
ExecutorServiceStrategy so migrating is a breeze, usually just change
the getExecutorServiceStrategy() to getExecutorServiceManager() and
you are settled.

I ran a complete unit test on my local laptop before commiting the changes.
There is a few TODO in the code, which I will work on as well, so
expect a few more commits. The TODO is minor/cosmetic changes I have
spotted, that can be improved.



-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: [DISCUSS] remove the commons-dbcp dependency from the Camel feature file

[Claus Ibsen]

On Fri, Aug 12, 2011 at 11:59 PM, Christian Müller
christian.muel...@gmail.com wrote:
 My comments inline.

 Best,
 Christian



 Installing the commons-dbcp in karaf would be as easy as just doing a
 osgi:install right?

 Yes.


 I would prefer if Karaf / SMX had some sort of jdbc features you could
 install and leverage out of the box. A bit similar to what you see in
 JEE servers for setting up connection pools, and having management and
 monitoring out of the box. AFAIR there is no such service. And thus
 people have to rely on commons-dbcp or other connection pooling. But
 then they have a bit hazzle to monitor and manage that at runtime.

 Yeah, this would be an interesting feature (monitoring the pool size and so
 on at runtime...). But I think this needs a bit more work...


 If Karaf / SMX had such a jdbc feature then I would be +1 for removing
 it from the Camel features files. I wonder if any existing users rely
 on the commons-dbcp and thus in case of an upgrade would hit any
 trouble? I guess not everyone would read release notes / upgrade
 guides etc. But just go for it, and then hit an issue with
 commons-dbcp not present anymore.

 This means you are -1 for removing it right now (because Karaf/SMX doesn't
 have this feature right now)?


I am 0.5+ okay for removing it from the Camel features file.
If Karaf had such a jdbc feature out of the box, then I would be +1.

Its just that many people just do a feature:install camel-jdbc /
camel-jms / camel-xxx
And then many of the things they need is installed out of the box.

I just wonder how widespread the usage of the commons-dbcp is out there?
And if anyone uses any alternatives? For example I dont recall I have
seen anyone use eg c3po in production.






 --
 Claus Ibsen
 -
 FuseSource
 Email: cib...@fusesource.com
 Web: http://fusesource.com
 Twitter: davsclaus, fusenews
 Blog: http://davsclaus.blogspot.com/
 Author of Camel in Action: http://www.manning.com/ibsen/





-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: [HEADS UP] - Adjustments to ExecutorServiceManager on trunk

[Claus Ibsen]

 they use.
But people use 3rd party components from camel-extra, githib, inhouse
developed, etc. And with a non backwards change, they would have to
support multiple branches to support Camel 2.8 or older. And Camel
2.9+. That dont give them confidence in the Apache Camel project.

And it is possible to keep the old API in place and mark it
@deprecated and give people amble time to adjust if we really want to
remove the deprecated API. In fact know its a just a facade which
delegates to the new ExecutorServiceManager who does the real work.
Also a testimony that the new API does indeed fully cover the old API
as the old unit test was copied and it passes.


 Christian



All together Christian I think you should create a wiki page with your
ideas for API changes in this area.
And then we can look at this for Camel 3.0 where the API is open for
changes. Not in a minor Camel release such as 2.8 - 2.9.
And especially now that Camel 2.x is 2+ years old and the API should
be stable so people can keep enjoy using Camel.





 Am 12.08.2011 17:29, schrieb Claus Ibsen:

 Hi

 Recently the ExecutorServiceStrategy had a bigger refactor
 (https://issues.apache.org/jira/browse/CAMEL-4244)
 Such as renaming the class to a better name ExecutorServiceManager.
 Also introducing a ThreadPoolFactory, ThreadFactory among others. The
 ThreadPoolFactory is a great addition, which makes it easier for 3rd
 party to just implement a custom factory, and then reply on the
 default manager.

 However the refactoring introduced a few issues such as configuring
 thread pools on EIPs was flawed. Well it also revealed we were short
 of an unit test to cover this. So I created a ticket, and committed a
 test to the 2.8 branch.
 https://issues.apache.org/jira/browse/CAMEL-4328

 The refactoring did also make backwards compatibility an issue, so we
 will restore that but mark the old API as @deprecated.

 The changes are summarized as follows
 - ThreadPoolFactory is the light weight and easier for SPI
 implementators to create a custom thread pool provider, such as JEE
 servers with a WorkManager API. This API has much fewer methods and
 they have been adjusted to be 100% JDK API (There is no Camel API in
 there, such as ThreadPoolProfile).
 - ExecutorServiceManager is the full fledged SPI in case you need 100%
 control. But it has Camel APIs such as ThreadPoolProfiles and a number
 of more methods. Its is encouraged to just implement a custom
 ThreadPoolFactory instead. And keep using the
 DefaultExecutorServiceManager.
 - ThreadPoolBuilder is adjusted to create a thread pool on the build
 method. This is how end users would expect. A builder to create what
 its name implies. This also removes entanglement of ThreadPool and
 ThreadPoolProfile. The latter is Camel specific and is only part of
 the ExecutorServiceManager which manges a list of profiles. To help
 uniform and make it easy to adjust thread pool settings at a higher
 level. So ThreadPoolProfiles should only be party of the manager.
 - EIPs configured using an explicit thread pool by an
 executorServiceRef, will now act as expected. If the reference could
 not be found, an exception is thrown, stating the reference is not
 found
 - Will add the ExecutorServiceStrategy SPI to have Camel 2.9 being
 backwards compatible, but mark it as @deprecated. This gives end users
 some time to adjust their custom Camel components, and source code if
 needed.
 - Naming of the methods will use the naming convention used by the
 JDK. xxxThreadPool for a pool of threads, xxxExecutor if its a single
 threaded (eg used for background tasks)
 - Made the API of ExecutorServiceManager more similar to the old
 ExecutorServiceStrategy so migrating is a breeze, usually just change
 the getExecutorServiceStrategy() to getExecutorServiceManager() and
 you are settled.

 I ran a complete unit test on my local laptop before commiting the
 changes.
 There is a few TODO in the code, which I will work on as well, so
 expect a few more commits. The TODO is minor/cosmetic changes I have
 spotted, that can be improved.




 --
 Christian Schneider
 http://www.liquid-reality.de

 Open Source Architect
 http://www.talend.com





-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: [HEADS UP] - Adjustments to ExecutorServiceManager on trunk

[Claus Ibsen]

I took the liberty of adding some notes to the Camel 3.0 roadmap
https://cwiki.apache.org/confluence/display/CAMEL/Camel+3.0+-+Roadmap

See the section - Improvements to ThreadPoolProfile for thread management

In fact I think we could possible make a compromise with the changes
from Christian and the old/current API in the next Camel 2.9 release.


A minor API change IMHO could be to move the ThreadPoolProfile from
the spi package to the root package.
This is to empower its importance. Also its a class now, it used to be
an interface.
We can make it final and serializable as well.

I would be okay with this API change between 2.8 - 2.9 as no Camel
components or 3rd party components were using them to create thread
pools and thus no really breakage here. The XML DSL will not be
affected as the factory beans in camel-core-xml can just be adjusted
accordingly.

However it could also be okay to leave it as is. But its a bit odd
since ThreadPoolProfile is now a class in the SPI package. SPI is
really only for interfaces, for 3rd party to plugin custom behavior.


As Christian noted a bit that the ThreadPoolBuilder should have been
named ThreadPoolProfileBuilder.
In fact why not introduced a new ThreadPoolProfileBuilder that only
creates profiles. And keep the existing ThreadPoolBuilder as is.
And then people can use this ThreadPoolProfileBuilder builder to
create profiles, which they can use the new ExecutorServiceManager to
create thread pools. Then people can pick and chose. And there is no
backwards compatibility issues as old and new API can co-exist.


Also as Christian noted he wanted the threads DSL to accept a
ThreadPoolProfile. We can add that to the fluent builder, so you can
do this from the Java DSL. (XML DSL can already support this using the
executorServiceRef).

So in Java DSL you can do

ThreadPoolProfile myProfile = ...
.threads(myProfile)


Will this help Christian?


-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

[DISCUSS] - Adjust Apache Camel product descriptions

[Claus Ibsen]

Hi

I noticed the README.txt file in the distribution kit starts as follows:
Apache Camel is a powerful Spring based Integration Framework.

And our website starts as follows:
Apache Camel is a powerful open source integration framework based on
known Enterprise Integration Patterns with powerful Bean Integration.


I think we should align the product descriptions on the web site and
the README.txt file.
There may be other places the product description is present, and
could use a bit upgrade.


For example I think the README.txt file is a bit outdated as it gives
the impression that Camel requires Spring and is Spring based.
As we all know Camel is more than that and we try to be neutral and
let people use and run Camel in any kind of environment.
Whether its Spring, OSGi, Karaf, ServiceMix, WebSphere, Cloud, Scala,
Standalone etc.


So anyone got suggestions/feedback to have the product description
updated a bit to reflect where we are today with Apache Camel?

For example we may want to mention Apache Karaf on the front page as a
product that Camel runs with out of the box. etc.



-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: [DISCUSS] Supporting our users to be more involved with our project

[Claus Ibsen]

On Fri, Aug 12, 2011 at 8:10 PM, Christian Müller
christian.muel...@gmail.com wrote:
 The easy to resolve issues have the Novices annotation.
 Dan created and shared the new JIRA view which is called Camel-Novice [1].
 I have linked this page from our contribution page [2].

 I hope our users/contributors will like it and are more easily involved.

 [1]
 https://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hiderequestId=12316782
 [2] http://camel.apache.org/contributing.html

 Best,
 Christian


Nice the contributing page is updated, and the link works with the new
easy to resolve issue JIRA page.



-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

[DISCUSS] - Dropping Maven 2.x support

[Claus Ibsen]

Hi

I wonder if we should consider dropping any official support for Maven
2.x on the Apache Camel project?
I guess most people is now migrated to Maven 3.0. And the last number
of releases has been done using Maven 3.0.x.

Also in light of JDK 7 is now GA, and thus there could be issues with
old Maven 2.x to use that to build Apache Camel.
And the maintainers of Maven is most likely to focus on Maven 3.x to
fix any JDK 7 issues and whatnot.

We may want to coordinate this with some of the Apache projects that
we work closely with such as
- Apache ServiceMix
- Apache Karaf
- Apache CXF
- Apache ActiveMQ

As some people use Maven to build all the projects from the source.


For example for Camel 2.9 we could put out in the release notes that
Maven 2.x supports is being @deprecated and expected
to be dropped in a future release. Then at least we have put out the
word that Maven 2.x is to be dropped.


Any thoughts?



-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: SFTP via proxy not possible?

[Claus Ibsen]

On Wed, Aug 17, 2011 at 2:42 AM, AnujK reacha...@gmail.com wrote:
 For SFTP, JSCH allows connection through HTTP proxy.

 However, per the documentation, there seems no support for specifying proxy
 Host and proxy port via the camel FTP2 component.

 Our code needs to talk to an SFTP server via an HTTP server proxy.

 Any options?


You can help by contributing
http://camel.apache.org/contributing.html

For example can you point to the JSCH documentation how to configure
the HTTP proxy.

You may consider providing a patch for the camel-ftp component with
this new feature.
And log a JIRA ticket as well.





 --
 View this message in context: 
 http://camel.465427.n5.nabble.com/SFTP-via-proxy-not-possible-tp4706296p4706296.html
 Sent from the Camel Development mailing list archive at Nabble.com.




-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: [DISCUSS] - Dropping Maven 2.x support

[Claus Ibsen]

Hi

I have noted in the Camel 2.9 release notes that Maven 2.x is deprecated.

I have logged a JIRA ticket scheduled for Camel 2.10 to drop the 2.x support
https://issues.apache.org/jira/browse/CAMEL-4341


On Mon, Aug 15, 2011 at 6:34 PM, Rob Davies rajdav...@gmail.com wrote:
 Seems a sensible approach
 On 14 Aug 2011, at 10:35, Claus Ibsen wrote:

 Hi

 I wonder if we should consider dropping any official support for Maven
 2.x on the Apache Camel project?
 I guess most people is now migrated to Maven 3.0. And the last number
 of releases has been done using Maven 3.0.x.

 Also in light of JDK 7 is now GA, and thus there could be issues with
 old Maven 2.x to use that to build Apache Camel.
 And the maintainers of Maven is most likely to focus on Maven 3.x to
 fix any JDK 7 issues and whatnot.

 We may want to coordinate this with some of the Apache projects that
 we work closely with such as
 - Apache ServiceMix
 - Apache Karaf
 - Apache CXF
 - Apache ActiveMQ

 As some people use Maven to build all the projects from the source.


 For example for Camel 2.9 we could put out in the release notes that
 Maven 2.x supports is being @deprecated and expected
 to be dropped in a future release. Then at least we have put out the
 word that Maven 2.x is to be dropped.


 Any thoughts?



 --
 Claus Ibsen
 -
 FuseSource
 Email: cib...@fusesource.com
 Web: http://fusesource.com
 Twitter: davsclaus, fusenews
 Blog: http://davsclaus.blogspot.com/
 Author of Camel in Action: http://www.manning.com/ibsen/





-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Camel http sample program

[Claus Ibsen]

Hi

Please use the @user mailing list for such questions about Apache Camel.


On Wed, Aug 17, 2011 at 7:16 AM, khinvra khin...@yahoo.com wrote:
 Hi all,

 I want to call an external web service using camel Java Dsl. If anybody
 knows sample code to call an external web service and get some xml out put
 and store it on local please share it..

 Thanks in advance

 --
 View this message in context: 
 http://camel.465427.n5.nabble.com/Camel-http-sample-program-tp4706867p4706867.html
 Sent from the Camel Development mailing list archive at Nabble.com.




-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: [DISCUSS] - Adjust Apache Camel product descriptions

[Claus Ibsen]

Hi

I have polished the readme.txt file in the source code to be similar
to the text on the public Apache Camel website
http://camel.apache.org/


On Sat, Aug 13, 2011 at 1:14 PM, Claus Ibsen claus.ib...@gmail.com wrote:
 Hi

 I noticed the README.txt file in the distribution kit starts as follows:
 Apache Camel is a powerful Spring based Integration Framework.

 And our website starts as follows:
 Apache Camel is a powerful open source integration framework based on
 known Enterprise Integration Patterns with powerful Bean Integration.


 I think we should align the product descriptions on the web site and
 the README.txt file.
 There may be other places the product description is present, and
 could use a bit upgrade.


 For example I think the README.txt file is a bit outdated as it gives
 the impression that Camel requires Spring and is Spring based.
 As we all know Camel is more than that and we try to be neutral and
 let people use and run Camel in any kind of environment.
 Whether its Spring, OSGi, Karaf, ServiceMix, WebSphere, Cloud, Scala,
 Standalone etc.


 So anyone got suggestions/feedback to have the product description
 updated a bit to reflect where we are today with Apache Camel?

 For example we may want to mention Apache Karaf on the front page as a
 product that Camel runs with out of the box. etc.



 --
 Claus Ibsen
 -
 FuseSource
 Email: cib...@fusesource.com
 Web: http://fusesource.com
 Twitter: davsclaus, fusenews
 Blog: http://davsclaus.blogspot.com/
 Author of Camel in Action: http://www.manning.com/ibsen/




-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Camel Apache in Jboss

[Claus Ibsen]

:/servers/jboss-5.1.0.GA/common/lib/jboss.jar!/:5.1.0.GA
 (build: SVNTag=JBoss_5_1_0_GA date=200905221053)]
  at
 org.jboss.web.deployers.WebModule.startModule(WebModule.java:118)[jar:file:/servers/jboss-5.1.0.GA/common/lib/jboss.jar!/:5.1.0.GA
 (build: SVNTag=JBoss_5_1_0_GA date=200905221053)]
  at
 org.jboss.web.deployers.WebModule.start(WebModule.java:97)[jar:file:/servers/jboss-5.1.0.GA/common/lib/jboss.jar!/:5.1.0.GA
 (build: SVNTag=JBoss_5_1_0_GA date=200905221053)]
  at sun.reflect.NativeMet

 *Please let me know the dependencies of Camel using JDK 1.5 and JBoss 5.1.0
 GA.*
 Here is my application context:

 ?xml version=1.0 encoding=UTF-8?
 beans xmlns=http://www.springframework.org/schema/beans;
        xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
 xmlns:camel=http://camel.apache.org/schema/spring;
        xsi:schemaLocation=
         http://www.springframework.org/schema/beans
 http://www.springframework.org/schema/beans/spring-beans.xsd
         http://camel.apache.org/schema/spring
 http://camel.apache.org/schema/spring/camel-spring.xsd;



                bean id=jbossResolver
 class=org.apache.camel.jboss.JBossPackageScanClassResolver /

        bean id=urlProcessor class=URLProcessor /


        camelContext xmlns=http://camel.apache.org/schema/spring;
                dataFormats
                        json id=addressVO library=Jackson
                                unmarshalTypeName=AddressServiceRequestVO /
                        json id=mapUrlResponseVO library=Jackson
                                unmarshalTypeName=MapURLResponseVO /
                /dataFormats




                route

                        from uri=servlet:///mapUrl /
                        unmarshal ref=addressVO /
                        process ref=urlProcessor /
                        marshal ref=mapUrlResponseVO /
                /route


        /camelContext


 /beans


 Thanks,
 Abhi




 --
 View this message in context: 
 http://camel.465427.n5.nabble.com/Camel-Apache-in-Jboss-tp4707916p4707916.html
 Sent from the Camel Development mailing list archive at Nabble.com.




-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: svn commit: r1158749 - in /camel/branches/camel-2.8.x: components/camel-mail/ components/camel-rss/ components/camel-web/ examples/camel-example-reportincident-wssecurity/ examples/camel-example-r

[Claus Ibsen]

/mail/${javax-mail-version}/bundle
     bundle 
 dependency=truemvn:org.apache.geronimo.specs/geronimo-jms_1.1_spec/${geronimo-jms-spec-version}/bundle
     bundle 
 dependency=truemvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.smack/${smack-bundle-version}/bundle
     bundle 
 dependency=truemvn:org.springframework/spring-jms/${spring-version}/bundle






-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Chmod files after upload via sftp

[Claus Ibsen]

Hi

You did the right thing to create a JIRA and attach the patch.

How to contribute is documented here
http://camel.apache.org/contributing.html

To speedup, well you can send beers to the Apache team :)

However usually it helps with the speed if unit tests is provided as well.
However as your patch has been used in production since Camel 2.2, I
am sure its fine.

I added an unit test and polished the code a bit.

Its all in trunk now, and will be part of Camel 2.9.


On Thu, Aug 18, 2011 at 10:19 AM, Jan-Philipp Niewerth
niewe...@invencom.de wrote:
 Hi All,

 first of all I would like to thank you for your great work in Apache Camel.
 It has become the swiss army knife for my integration tasks. A recurring
 requirement is to chmod files after uploading them to a communication
 partner's sftp server. Unfortunately this isn't supported by camel-ftp out
 of the box. So I keep a patch around and now have to apply it to every new
 camel version (since 2.2.0). I would love to see it upstream. I already
 created issue (CAMEL-4346) and attached the 5 lines patch. Do you have any
 suggestions what I can do to raise the chance it get's accepted?

 Kind Regards,

 Jan-Philipp Niewerth



 --
 View this message in context: 
 http://camel.465427.n5.nabble.com/Chmod-files-after-upload-via-sftp-tp4711276p4711276.html
 Sent from the Camel Development mailing list archive at Nabble.com.




-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: [HEADS UP] - Adjustments to ExecutorServiceManager on trunk

[Claus Ibsen]

On Thu, Aug 18, 2011 at 1:25 PM, Christian Schneider
ch...@die-schneider.net wrote:
 Hi Claus,

 I just saw that you also changed the ThreadPoolFactory interface to not use
 the profiles and instead have several methods again. This completely defeats
 the purpose of having a small factory interface.
 I will revert that back.


The ThreadPoolFactory has an API that is fully non Camel specific.
There is no Camel API at all in that interface.

package org.apache.camel.spi;

import java.util.concurrent.ExecutorService;
import java.util.concurrent.RejectedExecutionHandler;
import java.util.concurrent.ScheduledExecutorService;
import java.util.concurrent.ThreadFactory;
import java.util.concurrent.TimeUnit;

/**
 * Factory to crate {@link ExecutorService} and {@link
ScheduledExecutorService} instances
 * p/
 * This interface allows to customize the creation of these objects to
adapt Camel
 * for application servers and other environments where thread pools should
 * not be created with the JDK methods, as provided by the {@link
org.apache.camel.impl.DefaultThreadPoolFactory}.
 *
 * @see ExecutorServiceManager
 */
public interface ThreadPoolFactory {



It relies purely on well known JDK terms for thread pools and thus
makes it much easier for 3rd party to implement a custom factory if
they need.

All 4 methods are similar to the JDK Executors API and therefore easy
for people to understand and implement.

Your API was a Camel thingy with the ThreadPoolProfile (API from
Camel) and thus people would have to drag Camel API in their custom
implementations. Likewise when people needed a cached thread pool,
then the ThreadPoolProfile would not be able to indicate that.

I would oppose against putting Camel's API into the SPI when its not necessary.



 I worked on these changes quite a long time so the fact that you simply
 changed things back after we discussed on them and agreed on the changes
 makes me a bit sad. It also causes me a lot of unplanned work now. I agree
 with you on some of the things you mentioned.
 Like for example that it makes sense to offer an API on the
 ExecutorServiceManager that people are familiar with. So I think using the
 almost same API as in java is a good thing. I also like the fact that the
 change on the components is now really small after your change and also that
 there is a completely compatible ExecutorServiceStrategy as a fallback. That
 really makes sense for all external components.

 The problem is that with your changes you also rolled back good things I did
 that I now have to spend a lot of time bringing in again.


The trunk is not an experimental branch where people can commit big
refactorings or changes that break backwards compatible.
Likewise there is nobody in the community that requires a change in
the ExecutorServiceStrategy API. This is something you
came up with because you wanted to adjust the API. This is sometimes
tempting to do, but is very dangerous. The API should be kept
stable, especially for Camel 2.x that is 2+ years old, and for a
feature that has been in there for 18+ months.


We have Camel 3.0 where the API can be more open for changes.



 Christian

 Am 12.08.2011 17:29, schrieb Claus Ibsen:

 Hi

 Recently the ExecutorServiceStrategy had a bigger refactor
 (https://issues.apache.org/jira/browse/CAMEL-4244)
 Such as renaming the class to a better name ExecutorServiceManager.
 Also introducing a ThreadPoolFactory, ThreadFactory among others. The
 ThreadPoolFactory is a great addition, which makes it easier for 3rd
 party to just implement a custom factory, and then reply on the
 default manager.

 However the refactoring introduced a few issues such as configuring
 thread pools on EIPs was flawed. Well it also revealed we were short
 of an unit test to cover this. So I created a ticket, and committed a
 test to the 2.8 branch.
 https://issues.apache.org/jira/browse/CAMEL-4328

 The refactoring did also make backwards compatibility an issue, so we
 will restore that but mark the old API as @deprecated.

 The changes are summarized as follows
 - ThreadPoolFactory is the light weight and easier for SPI
 implementators to create a custom thread pool provider, such as JEE
 servers with a WorkManager API. This API has much fewer methods and
 they have been adjusted to be 100% JDK API (There is no Camel API in
 there, such as ThreadPoolProfile).
 - ExecutorServiceManager is the full fledged SPI in case you need 100%
 control. But it has Camel APIs such as ThreadPoolProfiles and a number
 of more methods. Its is encouraged to just implement a custom
 ThreadPoolFactory instead. And keep using the
 DefaultExecutorServiceManager.
 - ThreadPoolBuilder is adjusted to create a thread pool on the build
 method. This is how end users would expect. A builder to create what
 its name implies. This also removes entanglement of ThreadPool and
 ThreadPoolProfile. The latter is Camel specific and is only part of
 the ExecutorServiceManager which manges a list

Re: [HEADS UP] - Adjustments to ExecutorServiceManager on trunk

[Claus Ibsen]

On Thu, Aug 18, 2011 at 1:50 PM, Claus Ibsen claus.ib...@gmail.com wrote:
 On Thu, Aug 18, 2011 at 1:25 PM, Christian Schneider
 ch...@die-schneider.net wrote:
 Hi Claus,

 I just saw that you also changed the ThreadPoolFactory interface to not use
 the profiles and instead have several methods again. This completely defeats
 the purpose of having a small factory interface.
 I will revert that back.


 The ThreadPoolFactory has an API that is fully non Camel specific.
 There is no Camel API at all in that interface.

 package org.apache.camel.spi;

 import java.util.concurrent.ExecutorService;
 import java.util.concurrent.RejectedExecutionHandler;
 import java.util.concurrent.ScheduledExecutorService;
 import java.util.concurrent.ThreadFactory;
 import java.util.concurrent.TimeUnit;

 /**
  * Factory to crate {@link ExecutorService} and {@link
 ScheduledExecutorService} instances
  * p/
  * This interface allows to customize the creation of these objects to
 adapt Camel
  * for application servers and other environments where thread pools should
  * not be created with the JDK methods, as provided by the {@link
 org.apache.camel.impl.DefaultThreadPoolFactory}.
  *
  * @see ExecutorServiceManager
  */
 public interface ThreadPoolFactory {



 It relies purely on well known JDK terms for thread pools and thus
 makes it much easier for 3rd party to implement a custom factory if
 they need.

 All 4 methods are similar to the JDK Executors API and therefore easy
 for people to understand and implement.

 Your API was a Camel thingy with the ThreadPoolProfile (API from
 Camel) and thus people would have to drag Camel API in their custom
 implementations. Likewise when people needed a cached thread pool,
 then the ThreadPoolProfile would not be able to indicate that.

 I would oppose against putting Camel's API into the SPI when its not 
 necessary.


That said, since ThreadPoolFactory is a *new* API, then I would be +0
if you changed it to
your needs to make this as a compromise. However I personally thing
that using the JDK terms
is the best.

Likewise the ThreadPoolProfile is a simple getter/setter bean, and
people can easily configure it as such.
So I dont think it needs a builder either.

ThreadPoolProfile profile = new ...
profile.setQueueSize(200);
profile.setXXX
profile.setYYY

And in light of this I think the ThreadPoolFactory should be kept as
is, its using the JDK terms.

Then people can use the ExecutorServiceManager to create a thread pool
from their ThreadPoolProfile.
There is already API for that.

ExecutorService newThreadPool(Object source, String name,
ThreadPoolProfile profile);

It may lack a newScheduledThreadPool method.


So all together what I could see being changed
- the API of ThreadPoolFactory since its a *new* API. However I prefer
it to not use Camel API but rely on JDK terms
- add newScheduledThreadPool to ExecutorServiceManager to create a
scheduler from a ThreadPoolProfile

I do not see a reason for changing/adding
- ThreadPoolBuilder
- ThreadPoolProfileBuilder (as ThreadPoolProfile is a simple get/set
bean, and thus very easy to build manually)




 I worked on these changes quite a long time so the fact that you simply
 changed things back after we discussed on them and agreed on the changes
 makes me a bit sad. It also causes me a lot of unplanned work now. I agree
 with you on some of the things you mentioned.
 Like for example that it makes sense to offer an API on the
 ExecutorServiceManager that people are familiar with. So I think using the
 almost same API as in java is a good thing. I also like the fact that the
 change on the components is now really small after your change and also that
 there is a completely compatible ExecutorServiceStrategy as a fallback. That
 really makes sense for all external components.

 The problem is that with your changes you also rolled back good things I did
 that I now have to spend a lot of time bringing in again.


 The trunk is not an experimental branch where people can commit big
 refactorings or changes that break backwards compatible.
 Likewise there is nobody in the community that requires a change in
 the ExecutorServiceStrategy API. This is something you
 came up with because you wanted to adjust the API. This is sometimes
 tempting to do, but is very dangerous. The API should be kept
 stable, especially for Camel 2.x that is 2+ years old, and for a
 feature that has been in there for 18+ months.


 We have Camel 3.0 where the API can be more open for changes.



 Christian

 Am 12.08.2011 17:29, schrieb Claus Ibsen:

 Hi

 Recently the ExecutorServiceStrategy had a bigger refactor
 (https://issues.apache.org/jira/browse/CAMEL-4244)
 Such as renaming the class to a better name ExecutorServiceManager.
 Also introducing a ThreadPoolFactory, ThreadFactory among others. The
 ThreadPoolFactory is a great addition, which makes it easier for 3rd
 party to just implement a custom factory, and then reply on the
 default manager

Re: [HEADS UP] - Adjustments to ExecutorServiceManager on trunk

[Claus Ibsen]

On Thu, Aug 18, 2011 at 2:07 PM, Christian Schneider
ch...@die-schneider.net wrote:
 Am 18.08.2011 13:50, schrieb Claus Ibsen:

 On Thu, Aug 18, 2011 at 1:25 PM, Christian Schneider
 ch...@die-schneider.net  wrote:

 Hi Claus,

 I just saw that you also changed the ThreadPoolFactory interface to not
 use
 the profiles and instead have several methods again. This completely
 defeats
 the purpose of having a small factory interface.
 I will revert that back.

 The ThreadPoolFactory has an API that is fully non Camel specific.
 There is no Camel API at all in that interface.

 It relies purely on well known JDK terms for thread pools and thus
 makes it much easier for 3rd party to implement a custom factory if
 they need.

 All 4 methods are similar to the JDK Executors API and therefore easy
 for people to understand and implement.

 Your API was a Camel thingy with the ThreadPoolProfile (API from
 Camel) and thus people would have to drag Camel API in their custom
 implementations. Likewise when people needed a cached thread pool,
 then the ThreadPoolProfile would not be able to indicate that.

 I would oppose against putting Camel's API into the SPI when its not
 necessary.

 The class ThreadPoolProfile is not much more than a c struct to combine the
 attributes of a thread pool into a class.
 The implementor of a camel spi always has a dependency to the camel API as
 the  spi interface is part of the API. So I see no real problem in having
 this in the interface.
 Most spi interfaces reference other camel api classes and many of those
 classes are much more problematic. The ThreadPoolProfile is self contained
 so I see absolutely no problem in having it there.
 The similarity to the jdk is important for the ExecutorServiceManager as
 very many people use this. The spi factory will only be used very seldomly.
 So I don´t think the similarity is very important.
 In fact it rather hurts as the user has to implement more methods.


 I worked on these changes quite a long time so the fact that you simply
 changed things back after we discussed on them and agreed on the changes
 makes me a bit sad. It also causes me a lot of unplanned work now. I
 agree
 with you on some of the things you mentioned.
 Like for example that it makes sense to offer an API on the
 ExecutorServiceManager that people are familiar with. So I think using
 the
 almost same API as in java is a good thing. I also like the fact that the
 change on the components is now really small after your change and also
 that
 there is a completely compatible ExecutorServiceStrategy as a fallback.
 That
 really makes sense for all external components.

 The problem is that with your changes you also rolled back good things I
 did
 that I now have to spend a lot of time bringing in again.

 The trunk is not an experimental branch where people can commit big
 refactorings or changes that break backwards compatible.
 Likewise there is nobody in the community that requires a change in
 the ExecutorServiceStrategy API. This is something you
 came up with because you wanted to adjust the API. This is sometimes
 tempting to do, but is very dangerous. The API should be kept
 stable, especially for Camel 2.x that is 2+ years old, and for a
 feature that has been in there for 18+ months.

 Your arguments are true and I have no problems with the fact that you want
 the camel 2.x branch to be quite compatible. The problem I had was rather
 with the way you did this. You changed the code and then asked for a heads
 up. For my changes I first offered a patch and we discussed it.


The refactoring of the threading API has not been requested by the community.
To my recollection there has been no questions on the @user list, or
JIRA tickets, or tweets,
blog posts etc. where people have said. Hey I think this API should be
changed to Y.

For a product that is 2+ years old, its important to keep the API stable.
We should refrain from changing the API because we just fell like it.
Of course there is a balance, and sometimes it makes sense to change API.
However backwards compatibility is important for a 2+ year old product.


What I dont like is the fact you attach a 265kb patch and expect
people to be able to
review and understand what you are doing. We all have busy work days
and have trust in our peers.

And then you commit the changes not long before you go on holiday.

When asked to keep the old API to ensure backwards compatible, you said, it was
on purpose the old API was removed. Giving us no impression that you
would do something
about to restore backwards compatibility. In fact you seem to not care
about that.

Because of your changes I spent the greater of a day to restore
backwards compatibility and
ensure an API that makes migration from the @deprecated ExecutorServiceStrategy
to ExecutorServiceManager much easier, in most cases by just changing
from strategy to manager.
And in other cases the method name have a slight name change. The
orders

Re: [HEADS UP] - Adjustments to ExecutorServiceManager on trunk

[Claus Ibsen]

On Thu, Aug 18, 2011 at 2:07 PM, Christian Schneider
ch...@die-schneider.net wrote:
 Am 18.08.2011 13:50, schrieb Claus Ibsen:

 On Thu, Aug 18, 2011 at 1:25 PM, Christian Schneider
 ch...@die-schneider.net  wrote:

 Hi Claus,

 I just saw that you also changed the ThreadPoolFactory interface to not
 use
 the profiles and instead have several methods again. This completely
 defeats
 the purpose of having a small factory interface.
 I will revert that back.

 The ThreadPoolFactory has an API that is fully non Camel specific.
 There is no Camel API at all in that interface.

 It relies purely on well known JDK terms for thread pools and thus
 makes it much easier for 3rd party to implement a custom factory if
 they need.

 All 4 methods are similar to the JDK Executors API and therefore easy
 for people to understand and implement.

 Your API was a Camel thingy with the ThreadPoolProfile (API from
 Camel) and thus people would have to drag Camel API in their custom
 implementations. Likewise when people needed a cached thread pool,
 then the ThreadPoolProfile would not be able to indicate that.

 I would oppose against putting Camel's API into the SPI when its not
 necessary.

 The class ThreadPoolProfile is not much more than a c struct to combine the
 attributes of a thread pool into a class.
 The implementor of a camel spi always has a dependency to the camel API as
 the  spi interface is part of the API. So I see no real problem in having
 this in the interface.
 Most spi interfaces reference other camel api classes and many of those
 classes are much more problematic. The ThreadPoolProfile is self contained
 so I see absolutely no problem in having it there.
 The similarity to the jdk is important for the ExecutorServiceManager as
 very many people use this. The spi factory will only be used very seldomly.
 So I don´t think the similarity is very important.
 In fact it rather hurts as the user has to implement more methods.


That is a fair argument. I will be okay with that. Also considering
ThreadPoolFactory is a new API and thus no backwards issue.
Fell free to change it to your needs.

Btw even if user have to implement more methods, they are more precise
what they are asking for: fixed vs cached etc.
Also people can often delegate to another method with defaults. So the
implementation is easy. See for example the JDK source
code in the Executors which is the JDK factory for thread pools. It
have many methods and there is a lot of delegates.





 I worked on these changes quite a long time so the fact that you simply
 changed things back after we discussed on them and agreed on the changes
 makes me a bit sad. It also causes me a lot of unplanned work now. I
 agree
 with you on some of the things you mentioned.
 Like for example that it makes sense to offer an API on the
 ExecutorServiceManager that people are familiar with. So I think using
 the
 almost same API as in java is a good thing. I also like the fact that the
 change on the components is now really small after your change and also
 that
 there is a completely compatible ExecutorServiceStrategy as a fallback.
 That
 really makes sense for all external components.

 The problem is that with your changes you also rolled back good things I
 did
 that I now have to spend a lot of time bringing in again.

 The trunk is not an experimental branch where people can commit big
 refactorings or changes that break backwards compatible.
 Likewise there is nobody in the community that requires a change in
 the ExecutorServiceStrategy API. This is something you
 came up with because you wanted to adjust the API. This is sometimes
 tempting to do, but is very dangerous. The API should be kept
 stable, especially for Camel 2.x that is 2+ years old, and for a
 feature that has been in there for 18+ months.

 Your arguments are true and I have no problems with the fact that you want
 the camel 2.x branch to be quite compatible. The problem I had was rather
 with the way you did this. You changed the code and then asked for a heads
 up. For my changes I first offered a patch and we discussed it.


 We have Camel 3.0 where the API can be more open for changes.

 The problem with incompatible changes in major versions only is that they
 accumulate and make the major version very fragile and makes the development
 on that version take a very long time. So I think we should try to do as
 much in minor versions as we can and accept some minor incompatiblities. Of
 course it is very diffcult to judge what is minor.


 Christian


 --
 --
 Christian Schneider
 http://www.liquid-reality.de

 Open Source Architect
 Talend Application Integration Division http://www.talend.com





-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: [HEADS UP] - Adjustments to ExecutorServiceManager on trunk

[Claus Ibsen]

The latest commits look good.

Only a few cosmetic changes that would be nice to do
- Add missing/fix javadoc to ExecutorServiceManager (its a SPI
interface so full javadoc shows professionalism)
- Add missing/fix javadoc to ThreadPoolFactory (its a SPI interface so
full javadoc shows professionalism)
- ThreadPoolProfile as you override clone() you could consider
implementing Cloneable interface as well
- The parameter name for addDefaults could imho be improved to be
other instead of defaultProfile2 which seems a bit odd name
   Also the javadoc parameter is not described


-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: [HEADS UP] - Adjustments to ExecutorServiceManager on trunk

[Claus Ibsen]

On Fri, Aug 19, 2011 at 2:22 PM, Christian Schneider
ch...@die-schneider.net wrote:
 Committed the changes.

 I even built before I committed to show extra professionalism :-)


Ah that is maybe too professional. Sometimes you have to leave easy
mistakes in for others to fix :)


 Christian

 Am 19.08.2011 10:00, schrieb Claus Ibsen:

 The latest commits look good.

 Only a few cosmetic changes that would be nice to do
 - Add missing/fix javadoc to ExecutorServiceManager (its a SPI
 interface so full javadoc shows professionalism)
 - Add missing/fix javadoc to ThreadPoolFactory (its a SPI interface so
 full javadoc shows professionalism)
 - ThreadPoolProfile as you override clone() you could consider
 implementing Cloneable interface as well
 - The parameter name for addDefaults could imho be improved to be
 other instead of defaultProfile2 which seems a bit odd name
    Also the javadoc parameter is not described




 --
 --
 Christian Schneider
 http://www.liquid-reality.de

 Open Source Architect
 Talend Application Integration Division http://www.talend.com





-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: [HEADS UP] Moving org.apache.camel.Main to org.apache.camel.main.Main

[Claus Ibsen]

On Fri, Aug 19, 2011 at 3:40 PM, Christian Schneider
ch...@die-schneider.net wrote:
 Hi All,

 I am currently looking into the dependencies betwen packages in camel-core.
 The packages org.apache.camel and org.apache.camel.spi form the camel api.
 So I am trying to make them not depend on other packages from camel-core.
 One problem there is the starter class Main.

 It needs access to impl packages as it needs to start camel. So it should
 not live in org.apache.camel.

 I propose to move it to org.apache.camel.main. To not break anything right
 now I will create a deprecated class Main in org.apache.camel. We can remove
 the deprecated version in camel 3.0

 See https://issues.apache.org/jira/browse/CAMEL-4357


I wonder if the impl package had been named core instead, if that
would make the tangles more tolerable?
As depending on core for me always seems okay :)

Anyway we have ServiceSupport in impl which IMHO should have been in
util. That would have been nice as its a good base
class to extend if your class need to be a Camel Service. I wonder if
an experiment by moving it from impl to util will reduce some tangles.






 Christian


 --
 --
 Christian Schneider
 http://www.liquid-reality.de

 Open Source Architect
 Talend Application Integration Division http://www.talend.com





-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: [HEADS UP] Moving org.apache.camel.Main to org.apache.camel.main.Main

[Claus Ibsen]

I am not sure moving Main to a main package is a good idea.
As you would lock yourself into only having the Main class there.

What about adding a org.apache.camel.support package.

And then have more commonly used Camel classes by end users in there.
Such as the Main class.
But by naming it support we give us legroom to put in other useful classes.


On Fri, Aug 19, 2011 at 4:31 PM, Christian Schneider
ch...@die-schneider.net wrote:
 The problem is absolutely not about naming. The problem is that camel-core
 contains about 70k lines of code.

 So what we need is to have a small subset of this code that components can
 depend on. The smaller the better.
 Currently any change in camel-core could break any component. If we had a
 proper API then only API changes could break the components.

 Am 19.08.2011 15:59, schrieb Claus Ibsen:

 I wonder if the impl package had been named core instead, if that
 would make the tangles more tolerable?
 As depending on core for me always seems okay :)

 Depending on core is not ok. It means depending on implementation details.
 Only very few classes should need to depend on impl or core. Typically the
 code to initialize camel has to depend on it but
 components and the bulk of customer code should only depend on the API. In
 OSGi we can even completely hide the initialization code from users by using
 services.

 Anyway we have ServiceSupport in impl which IMHO should have been in
 util. That would have been nice as its a good base
 class to extend if your class need to be a Camel Service. I wonder if
 an experiment by moving it from impl to util will reduce some tangles.

 I am not sure if util is a good place. But you are right it should not be in
 impl. If it is needed by components it should either be in org.apache.camel
 or we need an additional package with classes that are widely used.
 Util could be used but then util may not be used by any API package as it
 would create a cycle.

 Christian



 --
 --
 Christian Schneider
 http://www.liquid-reality.de

 Open Source Architect
 Talend Application Integration Division http://www.talend.com





-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: [HEADS UP] Moving org.apache.camel.Main to org.apache.camel.main.Main

[Claus Ibsen]

On Fri, Aug 19, 2011 at 4:54 PM, Christian Schneider
ch...@die-schneider.net wrote:
 We could do something like that but the problem is the scope and dependency
 rules for this new package.
 Main needs access to all inner details of camel. So you only would like to
 put classes in that package that also need such details. On the other hand
 this package should
 be accessed by nothing else as it would easily create tangles over most of
 camel.


I guess main is a corner case and moving it to .main could make sense
in that case.


 For example the ServiceSupport class should not go in the same package as
 Main as ServiceSupport will be needed by many other classes.

 Christian


 Am 19.08.2011 16:43, schrieb Claus Ibsen:

 I am not sure moving Main to a main package is a good idea.
 As you would lock yourself into only having the Main class there.

 What about adding a org.apache.camel.support package.

 And then have more commonly used Camel classes by end users in there.
 Such as the Main class.
 But by naming it support we give us legroom to put in other useful
 classes.




 --
 --
 Christian Schneider
 http://www.liquid-reality.de

 Open Source Architect
 Talend Application Integration Division http://www.talend.com





-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: svn commit: r1160547 - in /camel/trunk/components: camel-spring/src/main/java/org/apache/camel/spring/ camel-test/src/main/java/org/apache/camel/test/junit4/ camel-test/src/test/java/org/apache/ca

[Claus Ibsen]

 or agreed to in writing, software
 + * distributed under the License is distributed on an AS IS BASIS,
 + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 + * See the License for the specific language governing permissions and
 + * limitations under the License.
 + */
 +package org.apache.camel.testng.patterns;
 +
 +import org.apache.camel.Exchange;
 +import org.apache.camel.Processor;
 +import org.apache.camel.builder.RouteBuilder;
 +import org.apache.camel.model.ProcessorDefinition;
 +import org.apache.camel.testng.CamelSpringTestSupport;
 +import org.junit.Test;
 +import org.springframework.context.support.AbstractApplicationContext;
 +import org.springframework.context.support.GenericApplicationContext;
 +
 +public class DebugSpringTest extends CamelSpringTestSupport {
 +    private boolean debugged;
 +
 +    @Override
 +    public boolean isUseDebugger() {
 +        // must enable debugger
 +        return true;
 +    }
 +
 +    @Override
 +    protected void debugBefore(Exchange exchange, Processor processor,
 +                               ProcessorDefinition definition, String id, 
 String shortName) {
 +        // this method is invoked before we are about to enter the given 
 processor
 +        // from your Java editor you can just add a breakpoint in the code 
 line below
 +        log.info(Before  + definition +  with body  + 
 exchange.getIn().getBody());
 +        debugged = true;
 +    }
 +
 +
 +    @Test
 +    public void testDebugger() throws Exception {
 +        // set mock expectations
 +        getMockEndpoint(mock:a).expectedMessageCount(1);
 +        getMockEndpoint(mock:b).expectedMessageCount(1);
 +
 +        // send a message
 +        template.sendBody(direct:start, World);
 +
 +        // assert mocks
 +        assertMockEndpointsSatisfied();
 +        assertTrue(debugged, The debugger is not called!);
 +    }
 +
 +    @Override
 +    protected RouteBuilder createRouteBuilder() throws Exception {
 +        return new RouteBuilder() {
 +            @Override
 +            public void configure() throws Exception {
 +                // this is the route we want to debug
 +                from(direct:start)
 +                    .to(mock:a)
 +                    .transform(body().prepend(Hello ))
 +                    .to(mock:b);
 +            }
 +        };
 +    }
 +
 +
 +    @Override
 +    protected AbstractApplicationContext createApplicationContext() {
 +        return new GenericApplicationContext();
 +    }
 +
 +}

 Propchange: 
 camel/trunk/components/camel-testng/src/test/java/org/apache/camel/testng/patterns/DebugSpringTest.java
 --
    svn:eol-style = native

 Propchange: 
 camel/trunk/components/camel-testng/src/test/java/org/apache/camel/testng/patterns/DebugSpringTest.java
 --
    svn:keywords = Rev Date






-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Scope of org.apache.camel.spi

[Claus Ibsen]

On Tue, Aug 23, 2011 at 12:38 PM, Christian Schneider
ch...@die-schneider.net wrote:
 I wonder what our scope for the org.apache.camel.spi package is vs the
 org.apache.camel (API) package.

 I know two valid definitions for API vs SPI:

 1) API interfaces are called by the user to invoke functionality of the
 framework. So API interfaces are implemented by the framework. SPI
 interfaces are implemented by the user to change functionality of the
 framework or for callbacks
 2) SPI interfaces are for third party modules while API interfaces are for
 users

 So the current case for me is the new JMX annotations. Are they SPI
 interfaces or API interfaces?


They are API interfaces. Just like @Consumer, @Produce and any of the
other API Camel annotations we have.
Its just that these annotations is for management enabling your
business logic / custom components or whatnot.



 So what is your opinion about the specific and the general case.

 As a side question: The org.apache.camel package has grown quite large. I
 think we should create specialized packages for it. As we are talking about
 the camel API org.apache.camel.api.* would be a good name in my opinion. So
 the questions are: Should we create such specialized packages? Should we
 move API parts there? Should we only use the new packages for new stuff?

 Christian


 --
 --
 Christian Schneider
 http://www.liquid-reality.de

 Open Source Architect
 Talend Application Integration Division http://www.talend.com





-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Scope of org.apache.camel.spi

[Claus Ibsen]

On Wed, Aug 24, 2011 at 3:04 PM, Christian Schneider
ch...@die-schneider.net wrote:
 So where do you propose to put them?

 1. org.apache.camel
 2. org.apache.camel.api.management


I propose to put them here, where they where already
3. org.apache.camel.management

These annotations are part of the management API in Camel and IMHO
should be in that package.



 I propose to go with 2 and create an api package with subpackages so we can
 structure org.apache.camel better. In the long run I would like to also move
 the whole camel api into an api package to make it clearer but that will
 probably create too much incompatibility.

 Christian


 Am 24.08.2011 14:13, schrieb Claus Ibsen:

 On Tue, Aug 23, 2011 at 12:38 PM, Christian Schneider
 ch...@die-schneider.net  wrote:

 I wonder what our scope for the org.apache.camel.spi package is vs the
 org.apache.camel (API) package.

 I know two valid definitions for API vs SPI:

 1) API interfaces are called by the user to invoke functionality of the
 framework. So API interfaces are implemented by the framework. SPI
 interfaces are implemented by the user to change functionality of the
 framework or for callbacks
 2) SPI interfaces are for third party modules while API interfaces are
 for
 users

 So the current case for me is the new JMX annotations. Are they SPI
 interfaces or API interfaces?

 They are API interfaces. Just like @Consumer, @Produce and any of the
 other API Camel annotations we have.
 Its just that these annotations is for management enabling your
 business logic / custom components or whatnot.



 So what is your opinion about the specific and the general case.

 As a side question: The org.apache.camel package has grown quite large. I
 think we should create specialized packages for it. As we are talking
 about
 the camel API org.apache.camel.api.* would be a good name in my opinion.
 So
 the questions are: Should we create such specialized packages? Should we
 move API parts there? Should we only use the new packages for new stuff?

 Christian


 --
 --
 Christian Schneider
 http://www.liquid-reality.de

 Open Source Architect
 Talend Application Integration Division http://www.talend.com






 --
 --
 Christian Schneider
 http://www.liquid-reality.de

 Open Source Architect
 Talend Application Integration Division http://www.talend.com





-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Scope of org.apache.camel.spi

[Claus Ibsen]

On Wed, Aug 24, 2011 at 6:17 PM, Christian Schneider
ch...@die-schneider.net wrote:
 Hi Claus,

 we can do that but then we have to move the impl classes somewhere else. We
 may not mix impl and api in the same package. This is what leads to cycles.


That is actually common. For example look at the JDK
Map (API) and HashMap (Impl) are both in java.util package.

However these annotations are not regular interfaces, that end users
is supposed to implement.
Or for example that we in the Apache Camel provides 2+ different
implements of those annotations.

As an end user I would feel natural these annotations are in the
mangement package as they are part of the management
(end user) API in Camel.


The Spring framework put these annotations at
http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/jmx/export/annotation/ManagedOperation.html

We could also have a annotation subpackage
(org.apache.camel.management.annotation)
but we usually dont have that, eg there are no annotation package for
@Consume, @Produce, @EndpointInject etc.

Alternatively we could move them in the root package, but as you said
there is already plenty of APIs in that package.

Putting them in org.apache.camel.api seems a bit weird, as they would
be the only pieces in there.
And for Camel 2.x we should keep the API stable and not move around
stuff all the time.



 Christian


 Am 24.08.2011 17:53, schrieb Claus Ibsen:

 On Wed, Aug 24, 2011 at 3:04 PM, Christian Schneider
 ch...@die-schneider.net  wrote:

 So where do you propose to put them?

 1. org.apache.camel
 2. org.apache.camel.api.management

 I propose to put them here, where they where already
 3. org.apache.camel.management

 These annotations are part of the management API in Camel and IMHO
 should be in that package.



 I propose to go with 2 and create an api package with subpackages so we
 can
 structure org.apache.camel better. In the long run I would like to also
 move
 the whole camel api into an api package to make it clearer but that will
 probably create too much incompatibility.

 Christian


 Am 24.08.2011 14:13, schrieb Claus Ibsen:

 On Tue, Aug 23, 2011 at 12:38 PM, Christian Schneider
 ch...@die-schneider.net    wrote:

 I wonder what our scope for the org.apache.camel.spi package is vs the
 org.apache.camel (API) package.

 I know two valid definitions for API vs SPI:

 1) API interfaces are called by the user to invoke functionality of the
 framework. So API interfaces are implemented by the framework. SPI
 interfaces are implemented by the user to change functionality of the
 framework or for callbacks
 2) SPI interfaces are for third party modules while API interfaces are
 for
 users

 So the current case for me is the new JMX annotations. Are they SPI
 interfaces or API interfaces?

 They are API interfaces. Just like @Consumer, @Produce and any of the
 other API Camel annotations we have.
 Its just that these annotations is for management enabling your
 business logic / custom components or whatnot.



 So what is your opinion about the specific and the general case.

 As a side question: The org.apache.camel package has grown quite large.
 I
 think we should create specialized packages for it. As we are talking
 about
 the camel API org.apache.camel.api.* would be a good name in my
 opinion.
 So
 the questions are: Should we create such specialized packages? Should
 we
 move API parts there? Should we only use the new packages for new
 stuff?

 Christian


 --
 --
 Christian Schneider
 http://www.liquid-reality.de

 Open Source Architect
 Talend Application Integration Division http://www.talend.com




 --
 --
 Christian Schneider
 http://www.liquid-reality.de

 Open Source Architect
 Talend Application Integration Division http://www.talend.com





 --
 Christian Schneider
 http://www.liquid-reality.de

 Open Source Architect
 http://www.talend.com





-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

[DISCUSS] - Apache Camel 2.8.1 release

[Claus Ibsen]

Hi

Its been 1 month since Camel 2.8.0 was released.
And we have a 2.8 branch where we have merged bug fixes.

I suggest that we consider doing a 2.8.1 release in the near term, for
example in about 1 - 2 weeks.

Apache ActiveMQ 5.6.0 is upgrading to Apache Camel 2.8.x. And as we
have a bug fixed in 2.8.1, I would love that AMQ could upgrade and use
2.8.1 instead of 2.8.0.

Likewise SMX 4.4 is to be released with Camel 2.8.0. And I guess it
would be great if SMX included 2.8.1.
There is not so often a new SMX release so it would be good if we
included an as most bug free version of 2.8 which would be 2.8.1
release.

Any feedback?



-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: [DISCUSS] - Apache Camel 2.8.1 release

[Claus Ibsen]

On Thu, Aug 25, 2011 at 10:05 AM, Jean-Baptiste Onofré j...@nanthrax.net 
wrote:
 Hi Claus,

 +1,

 I guess that we could merge some fixes in this release (for instance, the
 xstream 1.4.1 update, etc).WDYT ?


I would actually discourage against bigger dependency updates such as
xstream 1.3 - 1.4.
There was already some issues in xstream 1.4 so they had to do a 1.4.1.

However if there is an update like groovy 1.8.0 - 1.8.1 we may consider that.
Likewise I guess possible CXF 2.4.1 - 2.4.2

But yeah we should go over the JIRA tickets which has been fixed for
2.9 and backport bug fixes which can be easily backported.


 I will update ServiceMix to include Camel 2.8.1.

 Regards
 JB

 On 08/25/2011 09:58 AM, Claus Ibsen wrote:

 Hi

 Its been 1 month since Camel 2.8.0 was released.
 And we have a 2.8 branch where we have merged bug fixes.

 I suggest that we consider doing a 2.8.1 release in the near term, for
 example in about 1 - 2 weeks.

 Apache ActiveMQ 5.6.0 is upgrading to Apache Camel 2.8.x. And as we
 have a bug fixed in 2.8.1, I would love that AMQ could upgrade and use
 2.8.1 instead of 2.8.0.

 Likewise SMX 4.4 is to be released with Camel 2.8.0. And I guess it
 would be great if SMX included 2.8.1.
 There is not so often a new SMX release so it would be good if we
 included an as most bug free version of 2.8 which would be 2.8.1
 release.

 Any feedback?




 --
 Jean-Baptiste Onofré
 jbono...@apache.org
 http://blog.nanthrax.net
 Talend - http://www.talend.com




-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Scope of org.apache.camel.spi

[Claus Ibsen]

On Thu, Aug 25, 2011 at 9:40 AM, Christian Schneider
ch...@die-schneider.net wrote:
 I have another proposal that could work better and is quite near to what we
 have.

 org.apache.camel.management.api
 org.apache.camel.management.event
 org.apache.camel.management.impl


This kind of split into fine grained sub packages is a neat idea.
However I suggest to keep this for Camel 3.0 where the camel-core can
be possible be split into smaller JARs and separate API vs default
impl.

As I have said many times. Camel 2.x is 2+ years old, and we are in
the 9th release, and we have a large end user base who depend upon the
API is
kept stable as is.



 eventually we could have
 org.apache.camel.management.api.annotations


I actually dont like the .annotation package. For me an annotation is
just like any other API, whether its an interface, enum, exception,
etc.


 So the idea in this case is to have the module management on top level.
 Basically I like this even more than a technical split (api, impl) at the
 top level.

 The main change would be to leave the org.apache.management package empty.
 So a split of api+event in one jar and impl in another would be easier.
 This would also match very well with how osgi jars work.  Where you can have
 the whole management in one jar and only publish the api+event packages.


Yeah that seems like a good plane for Camel 3.0.

And talking about Camel 3.0, we may start a [DISCUSS] thread to start
talking about when we should go about doing it.
In terms of your work on the API in the camel-core, we may push
forward and get sooner started on Camel 3.0.



 Christian

 Am 24.08.2011 23:45, schrieb Hadrian Zbarcea:

 Actually I think it would be better to put annotations in their own
 package:

 org.apache.camel.annotation
 org.apache.camel.annotation.management
 org.apache.camel.annotation.etc...

 Then it won't feel weird that
 org.apache.camel.management is not there

 My $0.02,
 Hadrian


 On 08/24/2011 01:55 PM, Christian Schneider wrote:

 Actually JDk and spring are two very good examples how to not do it :-)

 I guess in the JDK no one cared as you will always have it. Btw. I guess
 everyone agrees that the JDK is a mess architecturally. Btw. he JDK
 extensions ship separate API jars like JAXB api. So they seem to have
 learned.

 In spring I suspect it is on purpose. They could provide API jars that
 make you independent of their implementation. By combining API and impl
 they force you into having a hard dependency on spring.
 You had to remove the spring JMX annotations as we did not want to have
 their impl. If they had cleanly separated their API from the impl we
 could have kept the one API jar with the annotations and just
 implemented them ourself when running outside of spring.

 So having the annotations in the management package is a very bad idea.
 A subpackage would work on a pure simple package perspective but I think
 it would be bad to have a top level package with implementations and a
 subpackage with the API.

 We can move around the management stuff at the moment as my commit
 changed it anyway. So before Camel 2.9 comes out we are free to move
 them.

 api.management of course only makes sense if we intend to put more stuff
 there but I think it would be a good idea to do so.
 Having a top level api package will also make it easier to create a pure
 API jar for camel 3.0. I think it would be strange if the API jar would
 contain

 org.apache.camel
 org.apache.camel.spi
 org.apache.camel.management.annotation

 but not
 org.apache.camel.management

 Btw management.annotation is not enough anyway as we have more
 management interfaces that have to live in the API space. So
 management.api would be better but I would prefer to have api at the top
 level so the user can clearly see that everything api.* is part of the
 API.

 In any case we need to separate the management API from the management
 impl classes. If we do not do it then we have no chance to avoid cycles.
 Besides that how should we make it possible that the components only
 need to depend on the API if we mix things. For example a component may
 want to use the management annotations or another management interface
 but it should not know the impl.

 Btw. the event classes should also be part of the API as they are
 necessary to understand management events. As they live in a separate
 package already the does not depend on the management impl I did not
 move them but they would be better placed in api.management.events.

 Christian




 Am 24.08.2011 19:12, schrieb Claus Ibsen:

 On Wed, Aug 24, 2011 at 6:17 PM, Christian Schneider
 ch...@die-schneider.net wrote:

 Hi Claus,

 we can do that but then we have to move the impl classes somewhere
 else. We
 may not mix impl and api in the same package. This is what leads to
 cycles.

 That is actually common. For example look at the JDK
 Map (API) and HashMap (Impl) are both in java.util package.

 However these annotations are not regular

Re: Scope of org.apache.camel.spi

[Claus Ibsen]

On Wed, Aug 24, 2011 at 7:55 PM, Christian Schneider
ch...@die-schneider.net wrote:
 Actually JDk and spring are two very good examples how to not do it :-)


Yeah I guess using them as an example was too easy and it was late
last evening.

But often people would refer and look at giants such as the JDK and Spring.
If you talk with the spring core team they always praise themselves as
great API builders.
And yeah they have succeeded IMHO to have a long line of releases with
a stable API and making it very/fairly easy for end user to upgrade.
For example many Spring 2.x apps would run fine in 3.x. Even older
releases as well.

But that said, the illusion with Spring is that its all or nothing.
So if you depend on one piece of Spring, you usually end up taking in
X+ JARs.
Just as the JMX example with Camel. I guess the Spring Expression
Language would be another such example.

And Spring is not as friendly for other framework builders, so there
is not so many hooks we can leverage to influence spring.
For example their property placeholder mechanism is a prime example.



 I guess in the JDK no one cared as you will always have it. Btw. I guess
 everyone agrees that the JDK is a mess architecturally. Btw. he JDK
 extensions ship separate API jars like JAXB api. So they seem to have
 learned.

Yeah Oracle is looking into project jigsaw to try to refactor the JDK.
That said the JDK has a remarkable backwards compatibility.
Even so extreme that people have suggested to create a new Java, and
dump the old cruft / @deprecated stuff etc.

But that is another story that isn't very relevant in this thread.

And of course Apache Camel should not be this extreme.
Yes we have changed the API a bit between minor releases. Especially
in the earlier releases of Camel 2.x where the API need to settle
down.
But now in 9th release and going for 10th (Camel 2.9), the API ought
to be stable.

The changes you have done so far on trunk is IMHO good and fine.
eg ServiceSupport into the support package. And have the old API
marked as @deprecated.
Even its not an absolute 100% backwards compatible change, as the impl
is now using ServiceSupport from support package and not the old
@deprecated one.
So end users who oddly would type cast to ServiceSupport would have a
type cast exception now. In fact one unit test in camel-ftp did that.
But that is very uncommon for end users to do so I think the change is fine.




 In spring I suspect it is on purpose. They could provide API jars that make
 you independent of their implementation. By combining API and impl they
 force you into having a hard dependency on spring.
 You had to remove the spring JMX annotations as we did not want to have
 their impl. If they had cleanly separated their API from the impl we could
 have kept the one API jar with the annotations and just implemented them
 ourself when running outside of spring.

 So having the annotations in the management package is a very bad idea. A
 subpackage would work on a pure simple package perspective but I think it
 would be bad to have a top level package with implementations and a
 subpackage with the API.

 We can move around the management stuff at the moment as my commit changed
 it anyway. So before Camel 2.9 comes out we are free to move them.

 api.management of course only makes sense if we intend to put more stuff
 there but I think it would be a good idea to do so.
 Having a top level api package will also make it easier to create a pure API
 jar for camel 3.0. I think it would be strange if the API jar would contain

 org.apache.camel
 org.apache.camel.spi
 org.apache.camel.management.annotation

 but not
 org.apache.camel.management

 Btw management.annotation is not enough anyway as we have more management
 interfaces that have to live in the API space. So management.api would be
 better but I would prefer to have api at the top level so the user can
 clearly see that everything api.* is part of the API.

 In any case we need to separate the management API from the management impl
 classes. If we do not do it then we have no chance to avoid cycles. Besides
 that how should we make it possible that the components only need to depend
 on the API if we mix things. For example a component may want to use the
 management annotations or another management interface but it should not
 know the impl.

 Btw. the event classes should also be part of the API as they are necessary
 to understand management events. As they live in a separate package already
 the does not depend on the management impl I did not move them but they
 would be better placed in api.management.events.

 Christian




 Am 24.08.2011 19:12, schrieb Claus Ibsen:

 On Wed, Aug 24, 2011 at 6:17 PM, Christian Schneider
 ch...@die-schneider.net  wrote:

 Hi Claus,

 we can do that but then we have to move the impl classes somewhere else.
 We
 may not mix impl and api in the same package. This is what leads to
 cycles.

 That is actually common. For example

Re: Scope of org.apache.camel.spi

[Claus Ibsen]

On Thu, Aug 25, 2011 at 10:17 AM, Claus Ibsen claus.ib...@gmail.com wrote:
 On Thu, Aug 25, 2011 at 9:40 AM, Christian Schneider
 ch...@die-schneider.net wrote:
 I have another proposal that could work better and is quite near to what we
 have.

 org.apache.camel.management.api

We could consider placing the new ManagedXXX annotations in this
package in light of that this is the package structure we want
to go with in the future, eg Camel 3.0.

And then lave the current API as is, so there is no trouble for out
existing user base.


 org.apache.camel.management.event
 org.apache.camel.management.impl


 This kind of split into fine grained sub packages is a neat idea.
 However I suggest to keep this for Camel 3.0 where the camel-core can
 be possible be split into smaller JARs and separate API vs default
 impl.

 As I have said many times. Camel 2.x is 2+ years old, and we are in
 the 9th release, and we have a large end user base who depend upon the
 API is
 kept stable as is.



 eventually we could have
 org.apache.camel.management.api.annotations


 I actually dont like the .annotation package. For me an annotation is
 just like any other API, whether its an interface, enum, exception,
 etc.


 So the idea in this case is to have the module management on top level.
 Basically I like this even more than a technical split (api, impl) at the
 top level.

 The main change would be to leave the org.apache.management package empty.
 So a split of api+event in one jar and impl in another would be easier.
 This would also match very well with how osgi jars work.  Where you can have
 the whole management in one jar and only publish the api+event packages.


 Yeah that seems like a good plane for Camel 3.0.

 And talking about Camel 3.0, we may start a [DISCUSS] thread to start
 talking about when we should go about doing it.
 In terms of your work on the API in the camel-core, we may push
 forward and get sooner started on Camel 3.0.



 Christian

 Am 24.08.2011 23:45, schrieb Hadrian Zbarcea:

 Actually I think it would be better to put annotations in their own
 package:

 org.apache.camel.annotation
 org.apache.camel.annotation.management
 org.apache.camel.annotation.etc...

 Then it won't feel weird that
 org.apache.camel.management is not there

 My $0.02,
 Hadrian


 On 08/24/2011 01:55 PM, Christian Schneider wrote:

 Actually JDk and spring are two very good examples how to not do it :-)

 I guess in the JDK no one cared as you will always have it. Btw. I guess
 everyone agrees that the JDK is a mess architecturally. Btw. he JDK
 extensions ship separate API jars like JAXB api. So they seem to have
 learned.

 In spring I suspect it is on purpose. They could provide API jars that
 make you independent of their implementation. By combining API and impl
 they force you into having a hard dependency on spring.
 You had to remove the spring JMX annotations as we did not want to have
 their impl. If they had cleanly separated their API from the impl we
 could have kept the one API jar with the annotations and just
 implemented them ourself when running outside of spring.

 So having the annotations in the management package is a very bad idea.
 A subpackage would work on a pure simple package perspective but I think
 it would be bad to have a top level package with implementations and a
 subpackage with the API.

 We can move around the management stuff at the moment as my commit
 changed it anyway. So before Camel 2.9 comes out we are free to move
 them.

 api.management of course only makes sense if we intend to put more stuff
 there but I think it would be a good idea to do so.
 Having a top level api package will also make it easier to create a pure
 API jar for camel 3.0. I think it would be strange if the API jar would
 contain

 org.apache.camel
 org.apache.camel.spi
 org.apache.camel.management.annotation

 but not
 org.apache.camel.management

 Btw management.annotation is not enough anyway as we have more
 management interfaces that have to live in the API space. So
 management.api would be better but I would prefer to have api at the top
 level so the user can clearly see that everything api.* is part of the
 API.

 In any case we need to separate the management API from the management
 impl classes. If we do not do it then we have no chance to avoid cycles.
 Besides that how should we make it possible that the components only
 need to depend on the API if we mix things. For example a component may
 want to use the management annotations or another management interface
 but it should not know the impl.

 Btw. the event classes should also be part of the API as they are
 necessary to understand management events. As they live in a separate
 package already the does not depend on the management impl I did not
 move them but they would be better placed in api.management.events.

 Christian




 Am 24.08.2011 19:12, schrieb Claus Ibsen:

 On Wed, Aug 24, 2011 at 6:17 PM, Christian Schneider
 ch

Re: svn commit: r1161953 - in /camel/trunk/camel-core/src: main/java/org/apache/camel/component/ main/java/org/apache/camel/component/bean/ main/java/org/apache/camel/component/browse/ main/java/org/a

[Claus Ibsen]

();
         ctx.disableJMX();
 -        ctx.addEndpoint(mock://foo, new MockEndpoint(mock://foo));
 +        ctx.getEndpoint(mock://foo);

         assertNotNull(ctx.hasEndpoint(mock://foo));
         assertNull(ctx.hasEndpoint(mock://bar));

 +        MapString, Endpoint map = ctx.getEndpointMap();
 +        assertEquals(1, map.size());
 +
         try {
             Endpoint endpoint = ctx.hasEndpoint(null);
             assertNull(Should not have endpoint, endpoint);

 Modified: 
 camel/trunk/camel-core/src/test/java/org/apache/camel/processor/Endpoint2MustBeStartedBeforeSendProcessorTest.java
 URL: 
 http://svn.apache.org/viewvc/camel/trunk/camel-core/src/test/java/org/apache/camel/processor/Endpoint2MustBeStartedBeforeSendProcessorTest.java?rev=1161953r1=1161952r2=1161953view=diff
 ==
 --- 
 camel/trunk/camel-core/src/test/java/org/apache/camel/processor/Endpoint2MustBeStartedBeforeSendProcessorTest.java
  (original)
 +++ 
 camel/trunk/camel-core/src/test/java/org/apache/camel/processor/Endpoint2MustBeStartedBeforeSendProcessorTest.java
  Fri Aug 26 01:07:17 2011
 @@ -119,7 +119,10 @@ public class Endpoint2MustBeStartedBefor
     private final class MyEndpoint extends DefaultEndpoint {

         private MyEndpoint(String endpointUri, CamelContext camelContext) {
 -            super(endpointUri, camelContext);
 +               // FIXME: another endpoint that works without a Component
 +            super();
 +            this.setCamelContext(camelContext);
 +            this.setEndpointUri(endpointUri);
         }

         public Producer createProducer() throws Exception {

 Modified: 
 camel/trunk/camel-core/src/test/java/org/apache/camel/processor/EndpointMustBeStartedBeforeSendProcessorTest.java
 URL: 
 http://svn.apache.org/viewvc/camel/trunk/camel-core/src/test/java/org/apache/camel/processor/EndpointMustBeStartedBeforeSendProcessorTest.java?rev=1161953r1=1161952r2=1161953view=diff
 ==
 --- 
 camel/trunk/camel-core/src/test/java/org/apache/camel/processor/EndpointMustBeStartedBeforeSendProcessorTest.java
  (original)
 +++ 
 camel/trunk/camel-core/src/test/java/org/apache/camel/processor/EndpointMustBeStartedBeforeSendProcessorTest.java
  Fri Aug 26 01:07:17 2011
 @@ -118,7 +118,10 @@ public class EndpointMustBeStartedBefore
     private final class MyEndpoint extends DefaultEndpoint {

         private MyEndpoint(String endpointUri, CamelContext camelContext) {
 -            super(endpointUri, camelContext);
 +               // FIXME: another endpoint that works without a Component
 +            super();
 +            this.setCamelContext(camelContext);
 +            this.setEndpointUri(endpointUri);
         }

         public Producer createProducer() throws Exception {

 Modified: 
 camel/trunk/camel-core/src/test/java/org/apache/camel/processor/enricher/EnricherRefTest.java
 URL: 
 http://svn.apache.org/viewvc/camel/trunk/camel-core/src/test/java/org/apache/camel/processor/enricher/EnricherRefTest.java?rev=1161953r1=1161952r2=1161953view=diff
 ==
 --- 
 camel/trunk/camel-core/src/test/java/org/apache/camel/processor/enricher/EnricherRefTest.java
  (original)
 +++ 
 camel/trunk/camel-core/src/test/java/org/apache/camel/processor/enricher/EnricherRefTest.java
  Fri Aug 26 01:07:17 2011
 @@ -58,8 +58,8 @@ public class EnricherRefTest extends Con
         return new RouteBuilder() {
             @Override
             public void configure() throws Exception {
 -                cool.setEndpointUriIfNotSpecified(cool);
                 cool.setCamelContext(context);
 +                cool.setEndpointUriIfNotSpecified(cool);

                 from(direct:start).enrichRef(cool, agg);
             }






-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

camel-core - Checkstyle issues on trunk

[Claus Ibsen]

Hi

There is a fair number of checkstyle issues on trunk on camel-core. I
suspect its due some of the latest refactorings.


-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: camel-core - Checkstyle issues on trunk

[Claus Ibsen]

On Sat, Aug 27, 2011 at 6:39 PM, Christian Schneider
ch...@die-schneider.net wrote:
 Ok will check on Monday.
 Can the issues be seen somewhere on the web or only in eclipse?


The issues is reported on the command line using
mvn compile -Psourcecheck

Its a maven plugin, so there could be some maven reporting web tooling
being able to display them.
However its just much easier to run the cmd from the command line once
in a while.



 Christian


 Am 27.08.2011 18:29, schrieb Claus Ibsen:

 Hi

 There is a fair number of checkstyle issues on trunk on camel-core. I
 suspect its due some of the latest refactorings.



 --
 Christian Schneider
 http://www.liquid-reality.de

 Open Source Architect
 http://www.talend.com





-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

[HEADS UP] - A prototype of an improved Simple language for Apache Camel

[Claus Ibsen]

Hi

The current Simple language in camel-core has reached its potential in
terms of maintenance and how easy it would be, for example to add new
functions and operators. Likewise the current error reporting is not
precise to point out where in the expression String the problem is.

The implementation is using regular expressions, and that is one of
the key problems. I think we have grown to the limit how it is to
maintain.

So I have experimented this weekend to build a prototype based on the
principle of a recursive descent parser
http://en.wikipedia.org/wiki/Recursive_descent_parser

I at first looked into using a parser framework such as JavaCC and
ANTLR. The former would be able to parse the input, but building the
AST nodes would require to use its tree compiler, which was not maven
exposed. Likewise JavaCC is not really maintained anymore. People on
stackoverflow recommended ANTLR. It has more bells ans whistles, but
as far as I could see ANTLR requires JAR files in the runtime.

And frankly I just wanted a fairly simple code, that anybody, would be
able to look into and help with.

So I cracked up some prototype code based on the principle from that
wikipedia article above.

So far I got a working prototype that is much better at parsing and
reporting exactly where the problem is.
For example suppose you do a predicate in a content based router, such as:

simple${header.high} = true/simple

Notice how I have mistyped the == operator, as there is only one = sign.

In the old code, the reg exp parser would not catch this problem, and
the predicate would be evaluated to true, at runtime. There is two
reasons for that. The old parser is not good at detecting errors and
being able to pin point the problem. The grammer is not really defined
that well, as its based on a somewhat complicated regular expression.
The 2nd issues is the old parser would evaluate both predicates and
expressions, as expressions first, and then convert the expression to
a predicate. So in that given example above, it would be rendered as
someHeaderValue = true as an expression. And when converted to a
predicate it would be true, as the expression is not empty.

The new parser in the prototype is improved as it
- runs in two modes: predicate or expression
- has a grammer and is able to parse the input, and report precisely
where the problem is.

So for example what you see now is

org.apache.camel.language.simple.SimpleIllegalSyntaxException:
unexpected character symbol at location 15
${header.high} = true
   *

And then there is a * sign below where the problem is. Now if you
would show above text using monospaced font, you would see the star
below the = sign.

The exception message can be improved even more, as we could say
something about an unknown operator, etc.

Likewise I decided to let the new simple language be more restrictive
in terms of function placeholders. I decided that you now must always
use ${ } placeholders, as it makes the parsing easier, as well as for
end users, there is no confusion.

header.high == true
Should be written as
${header.high} == true


The prototype is currently in my github at
https://github.com/davsclaus/camel-simple2


There is still some work to do
- implement the remainder binary operators (basically copy code from
old and adjust a little bit)
- add support for and and or grouping operators, I am inclined to
rename them to  and || which is the operators you would use in
Java code etc.
- add support for ++ and -- unary operators, so people for example
can use that to increment a counter in XML DSL without using any java
code
- possible add support for ( ) groups so you can define precedences
- possible add support for math operators if they would make sense
- refine error messages just a tad
- the parser is currently not thread safe, so we may want to refine
this (it stores some state during parsing)
- after parsing there is a bit logic to prepare the AST before we turn
it into Camel expression/predicates. Especially due to blocks and
binary operators. We may relax this as the binary operators could
potential whirl through the whitespace noise and be able to detect
its right and left hand side expressions. Currently I am removing any
in between noise, so the right/left hand side is exactly next-to the
operator.


So if anyone wanna help out, or have ideas for improvements, or have
any grief with the old simple language, that we can fix in the new
code, then fell free to help out.




-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: [HEADS UP] - A prototype of an improved Simple language for Apache Camel

[Claus Ibsen]

On Mon, Aug 29, 2011 at 11:14 AM, Christian Schneider
ch...@die-schneider.net wrote:
 Hi Claus,

 the parser looks quite good as far as I looked into it. In any case much
 better than regex. Before we replace the old parser we should also think
 about tooling though. Some longer time ago I thought about using Xtext for
 the camel DSL and also the languages. The advantage would be that it is
 quite easy to build real good Editor for the IDE. I guess with the aproach
 you followed this is not so easy. Of ocurse the initial effort of Xtext
 would be a lot higher but perhaps it can pay off in the long run.

 Christian


I wanted something that was simple ;). Well in the sense that it does
not add any extra JARs to the runtime.
So if the tooling can generate plain java source code, then that would be nice.
Also the tooling should be active maintained, so we dont end up using
a dead end project in camel-core.

Another goal is that anyone would be able to understand plain java
code, and with a little reading of the code,
be able to contribute and, eg. add a new function, or operator etc.

I understand that XText is part of Eclipse, and it seems that it uses
ANTLR under the covers.
I would like to not go down a road to add any runtime deps to camel-core.

At camel-extra there is a very old xtext project
http://code.google.com/a/apache-extras.org/p/camel-extra/wiki/CamelSpit

That said, we could possible add some grammar file to camel-core,
which describes the grammer.
Then any 3rd party tooling can use the grammar file to generate a
parser for its tooling.





 Am 29.08.2011 10:18, schrieb Claus Ibsen:

 Hi

 The current Simple language in camel-core has reached its potential in
 terms of maintenance and how easy it would be, for example to add new
 functions and operators. Likewise the current error reporting is not
 precise to point out where in the expression String the problem is.

 The implementation is using regular expressions, and that is one of
 the key problems. I think we have grown to the limit how it is to
 maintain.

 So I have experimented this weekend to build a prototype based on the
 principle of a recursive descent parser
 http://en.wikipedia.org/wiki/Recursive_descent_parser

 I at first looked into using a parser framework such as JavaCC and
 ANTLR. The former would be able to parse the input, but building the
 AST nodes would require to use its tree compiler, which was not maven
 exposed. Likewise JavaCC is not really maintained anymore. People on
 stackoverflow recommended ANTLR. It has more bells ans whistles, but
 as far as I could see ANTLR requires JAR files in the runtime.

 And frankly I just wanted a fairly simple code, that anybody, would be
 able to look into and help with.

 So I cracked up some prototype code based on the principle from that
 wikipedia article above.



 --
 --
 Christian Schneider
 http://www.liquid-reality.de

 Open Source Architect
 Talend Application Integration Division http://www.talend.com





-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: [HEADS UP] - A prototype of an improved Simple language for Apache Camel

[Claus Ibsen]

On Mon, Aug 29, 2011 at 10:18 AM, Claus Ibsen claus.ib...@gmail.com wrote:
 Hi

 The current Simple language in camel-core has reached its potential in
 terms of maintenance and how easy it would be, for example to add new
 functions and operators. Likewise the current error reporting is not
 precise to point out where in the expression String the problem is.

 The implementation is using regular expressions, and that is one of
 the key problems. I think we have grown to the limit how it is to
 maintain.

 So I have experimented this weekend to build a prototype based on the
 principle of a recursive descent parser
 http://en.wikipedia.org/wiki/Recursive_descent_parser

 I at first looked into using a parser framework such as JavaCC and
 ANTLR. The former would be able to parse the input, but building the
 AST nodes would require to use its tree compiler, which was not maven
 exposed. Likewise JavaCC is not really maintained anymore. People on
 stackoverflow recommended ANTLR. It has more bells ans whistles, but
 as far as I could see ANTLR requires JAR files in the runtime.

 And frankly I just wanted a fairly simple code, that anybody, would be
 able to look into and help with.

 So I cracked up some prototype code based on the principle from that
 wikipedia article above.

 So far I got a working prototype that is much better at parsing and
 reporting exactly where the problem is.
 For example suppose you do a predicate in a content based router, such as:

 simple${header.high} = true/simple

 Notice how I have mistyped the == operator, as there is only one = sign.

 In the old code, the reg exp parser would not catch this problem, and
 the predicate would be evaluated to true, at runtime. There is two
 reasons for that. The old parser is not good at detecting errors and
 being able to pin point the problem. The grammer is not really defined
 that well, as its based on a somewhat complicated regular expression.
 The 2nd issues is the old parser would evaluate both predicates and
 expressions, as expressions first, and then convert the expression to
 a predicate. So in that given example above, it would be rendered as
 someHeaderValue = true as an expression. And when converted to a
 predicate it would be true, as the expression is not empty.

 The new parser in the prototype is improved as it
 - runs in two modes: predicate or expression
 - has a grammer and is able to parse the input, and report precisely
 where the problem is.

 So for example what you see now is

 org.apache.camel.language.simple.SimpleIllegalSyntaxException:
 unexpected character symbol at location 15
 ${header.high} = true
               *

 And then there is a * sign below where the problem is. Now if you
 would show above text using monospaced font, you would see the star
 below the = sign.

 The exception message can be improved even more, as we could say
 something about an unknown operator, etc.

 Likewise I decided to let the new simple language be more restrictive
 in terms of function placeholders. I decided that you now must always
 use ${ } placeholders, as it makes the parsing easier, as well as for
 end users, there is no confusion.

 header.high == true
    Should be written as
 ${header.high} == true


 The prototype is currently in my github at
 https://github.com/davsclaus/camel-simple2


 There is still some work to do
 - implement the remainder binary operators (basically copy code from
 old and adjust a little bit)

All the existing binary operators is now implemented and unit test
from camel-core passes.


 - add support for and and or grouping operators, I am inclined to
 rename them to  and || which is the operators you would use in

The logical operators and|or have been added, but named  and || to
be more inline with other languages.


 Java code etc.
 - add support for ++ and -- unary operators, so people for example
 can use that to increment a counter in XML DSL without using any java
 code

Unary operators ++ and -- have been implemented. You can also use them
in expressions so you can auto inc a header counter etc.

setHeader headerName=counter
   simple${header.counter}++/simple
/setHeader

Which have been requested in the community.


 - possible add support for ( ) groups so you can define precedences
 - possible add support for math operators if they would make sense
 - refine error messages just a tad

 - the parser is currently not thread safe, so we may want to refine
 this (it stores some state during parsing)
 - after parsing there is a bit logic to prepare the AST before we turn
 it into Camel expression/predicates. Especially due to blocks and
 binary operators. We may relax this as the binary operators could
 potential whirl through the whitespace noise and be able to detect
 its right and left hand side expressions. Currently I am removing any
 in between noise, so the right/left hand side is exactly next-to the
 operator.


 So if anyone wanna help out, or have ideas for improvements

Re: [HEADS UP] - A prototype of an improved Simple language for Apache Camel

[Claus Ibsen]

On Mon, Aug 29, 2011 at 3:52 PM, Willem Jiang willem.ji...@gmail.com wrote:
 It could be handy if we leverage the other lib in the other camel-module. If
 the user need the module, it will not be a burden for him to include a third
 part lib.


There is already other scripting languages you can use if you want a
more powerful language.
For example camel-groovy, or use camel-script so you can use JavaScript etc.
All these languages have support by IDEs



 On 8/29/11 8:19 PM, Claus Ibsen wrote:

 On Mon, Aug 29, 2011 at 11:14 AM, Christian Schneider
 ch...@die-schneider.net  wrote:

 Hi Claus,

 the parser looks quite good as far as I looked into it. In any case much
 better than regex. Before we replace the old parser we should also think
 about tooling though. Some longer time ago I thought about using Xtext
 for
 the camel DSL and also the languages. The advantage would be that it is
 quite easy to build real good Editor for the IDE. I guess with the
 aproach
 you followed this is not so easy. Of ocurse the initial effort of Xtext
 would be a lot higher but perhaps it can pay off in the long run.

 Christian


 I wanted something that was simple ;). Well in the sense that it does
 not add any extra JARs to the runtime.
 So if the tooling can generate plain java source code, then that would be
 nice.
 Also the tooling should be active maintained, so we dont end up using
 a dead end project in camel-core.

 Another goal is that anyone would be able to understand plain java
 code, and with a little reading of the code,
 be able to contribute and, eg. add a new function, or operator etc.

 I understand that XText is part of Eclipse, and it seems that it uses
 ANTLR under the covers.
 I would like to not go down a road to add any runtime deps to camel-core.

 At camel-extra there is a very old xtext project
 http://code.google.com/a/apache-extras.org/p/camel-extra/wiki/CamelSpit

 That said, we could possible add some grammar file to camel-core,
 which describes the grammer.
 Then any 3rd party tooling can use the grammar file to generate a
 parser for its tooling.





 Am 29.08.2011 10:18, schrieb Claus Ibsen:

 Hi

 The current Simple language in camel-core has reached its potential in
 terms of maintenance and how easy it would be, for example to add new
 functions and operators. Likewise the current error reporting is not
 precise to point out where in the expression String the problem is.

 The implementation is using regular expressions, and that is one of
 the key problems. I think we have grown to the limit how it is to
 maintain.

 So I have experimented this weekend to build a prototype based on the
 principle of a recursive descent parser
 http://en.wikipedia.org/wiki/Recursive_descent_parser

 I at first looked into using a parser framework such as JavaCC and
 ANTLR. The former would be able to parse the input, but building the
 AST nodes would require to use its tree compiler, which was not maven
 exposed. Likewise JavaCC is not really maintained anymore. People on
 stackoverflow recommended ANTLR. It has more bells ans whistles, but
 as far as I could see ANTLR requires JAR files in the runtime.

 And frankly I just wanted a fairly simple code, that anybody, would be
 able to look into and help with.

 So I cracked up some prototype code based on the principle from that
 wikipedia article above.



 --
 --
 Christian Schneider
 http://www.liquid-reality.de

 Open Source Architect
 Talend Application Integration Division http://www.talend.com







 --
 Willem
 --
 FuseSource
 Web: http://www.fusesource.com
 Blog:    http://willemjiang.blogspot.com (English)
         http://jnn.javaeye.com (Chinese)
 Twitter: willemjiang
 Weibo: willemjiang




-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

WrappedFile

[Claus Ibsen]

Hi

The WrappedFile seems like when people create a facade for another facade.

public interface WrappedFileT {
T getFile();
}

That WrappedFile is not specific for a File, it could in fact be anything.
So I suggest to come up with a more generic name and API. I bet it
could come handy in another place in the jigsaw.

Could be

public interface WrappedObjectT {
T getObject();
}

Or

public interface WrappedEntityT {
T getEntity();
}

Or

public interface FacadeT {
T getTarget();
}

Or something else.

Also any API in the root package should have javadoc, stating its
purpose and what it does.


-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

BytesSource and StringSource

[Claus Ibsen]

Hi

Its a pita that these classes is moved to the root package of Camel.
The root package is an API having only interfaces, exceptions, enums,
annotations etc. Then we got those two stranded whales here which
seems misplaced.

The JDK have its xxxSource implementations in sub packages:
javax.xml.transform.stream.StreamSource

So why can't we in Camel? It seems too dramatic as a solution to move
stuff into the root package.
Also these classes do *not* implement any Camel interface, but they
are JDK xxxSource specific helpers in Camel.

Instead I suggest they are placed in the org.apache.camel.util.stream package



-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: svn commit: r1163153 - in /camel/trunk/components/camel-cxf/src: main/java/org/apache/camel/component/cxf/ main/java/org/apache/camel/component/cxf/spring/ test/java/org/apache/camel/component/cxf

[Claus Ibsen]

://org.apache.camel.component.cxf}myEndpoint
 +wsdlURL=wsdl/test.wsdl
 \ No newline at end of file

 Propchange: 
 camel/trunk/components/camel-cxf/src/test/resources/org/apache/camel/component/cxf/spring/testEndpoint.properties
 --
    svn:eol-style = native

 Propchange: 
 camel/trunk/components/camel-cxf/src/test/resources/org/apache/camel/component/cxf/spring/testEndpoint.properties
 --
    svn:keywords = Rev Date

 Propchange: 
 camel/trunk/components/camel-cxf/src/test/resources/org/apache/camel/component/cxf/spring/testEndpoint.properties
 --
    svn:mime-type = text/plain






-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: [DISCUSS] - Apache Camel 2.8.1 release

[Claus Ibsen]

Anyone got cycles to take a look at the bug fixes in Camel 2.9, which
may not have been backported. And then merge any bug fixes which seems
reasonable to be backported?

I guess this is the current bug fixed on 2.9
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+CAMEL+AND+issuetype+%3D+Bug+AND+resolution+%3D+Fixed+AND+fixVersion+%3D+12316374+AND+status+%3D+Resolved+ORDER+BY+updated+DESC%2C+key+DESC

There is 37 bugs fixed, and there may be some fixes which havent been
backported.


-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Jenkins dependency in camel-core pom.xml for SNAPSHOTs

[Claus Ibsen]

Hi

Take a look at the pom.xml for camel-core that the CI server at Apache produces
https://repository.apache.org/content/repositories/snapshots/org/apache/camel/camel-core/2.9-SNAPSHOT/camel-core-2.9-SNAPSHOT.pom

If you notice then it adds a dependency to jenkins
dependency
groupIdcom.sun/groupId
artifactIdtools/artifactId
version1.5.0/version
scopesystem/scope
systemPath
/home/jenkins/tools/java/jdk1.6.0_20-32/jre/../lib/tools.jar
/systemPath
/dependency
/dependencies

I have not been able to figure out why it does that, and where you can
disable it from doing this.

Anyone seen this before? And know a reason for doing this.



-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Jenkins dependency in camel-core pom.xml for SNAPSHOTs

[Claus Ibsen]

Maybe we need to add this profile in camel-core
http://maven.apache.org/general.html#tools-jar-dependency

Also discussed here
http://jenkins.361315.n4.nabble.com/com-sun-tools-jar-1-5-is-missing-td390964.html




On Tue, Aug 30, 2011 at 11:49 AM, Claus Ibsen claus.ib...@gmail.com wrote:
 Hi

 Take a look at the pom.xml for camel-core that the CI server at Apache 
 produces
 https://repository.apache.org/content/repositories/snapshots/org/apache/camel/camel-core/2.9-SNAPSHOT/camel-core-2.9-SNAPSHOT.pom

 If you notice then it adds a dependency to jenkins
 dependency
 groupIdcom.sun/groupId
 artifactIdtools/artifactId
 version1.5.0/version
 scopesystem/scope
 systemPath
 /home/jenkins/tools/java/jdk1.6.0_20-32/jre/../lib/tools.jar
 /systemPath
 /dependency
 /dependencies

 I have not been able to figure out why it does that, and where you can
 disable it from doing this.

 Anyone seen this before? And know a reason for doing this.



 --
 Claus Ibsen
 -
 FuseSource
 Email: cib...@fusesource.com
 Web: http://fusesource.com
 Twitter: davsclaus, fusenews
 Blog: http://davsclaus.blogspot.com/
 Author of Camel in Action: http://www.manning.com/ibsen/




-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

[IMPORTANT] - Changing API - Must document changes in release notes

[Claus Ibsen]

Hi

The API in camel-core have changed on trunk recently by the works of
Christian S.

I just to remind that its important to notice all the API breaking
changes in the API section in the release notes.
I have noticed that the release notes hasn't been updated accordingly
to changes.

I suggest to update the release notes at the time when you commit
changes, as then you wont forget.

What we need to put in there, is for example when a class has been
*moved* to a new package, which mean
there is not even an old @deprecated class. We ought also to mention
important classe which may have
been @deprecated in favor of some other class etc.

Our user base should have this information up-front so they can take
that into account, in their migration plans.



-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: What is the purpose of camel-core-xml? Move the code to camel-core?

[Claus Ibsen]

On Wed, Aug 31, 2011 at 5:40 PM, Christian Schneider
ch...@die-schneider.net wrote:
 Hi all,

 can someone tell me what the purpose of camel-core-xml is and why it has to
 be a spearate project?
 It does not seem to have any other dependencies than camel-core.

 So if there is no good reason to keep it separate I propose to move that
 code into camel-core.


No.

Its an abstract component which has base classes used by XML DSLs such
as camel-spring and camel-blueprint.
This ensures that code is reused between the 2 XML DSLs and make it
easier to keep them in sync and whatnot.



 Christian

 --
 --
 Christian Schneider
 http://www.liquid-reality.de

 Open Source Architect
 Talend Application Integration Division http://www.talend.com





-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: What is the purpose of camel-core-xml? Move the code to camel-core?

[Claus Ibsen]

On Wed, Aug 31, 2011 at 5:51 PM, Christian Schneider
ch...@die-schneider.net wrote:
 That sounds to me like it would fit nicely in camel-core.


No as that is just bloat to the core.


 Btw. is there a reason why camel-core-xml is scope provided in camel-spring?
 This gives me errors in some tests of other components in eclipse as these
 classes can not be found.


There is no problem at all in IDEA.


Yes one of the reasons is osgi. By having the camel-core-xml .class
files included directly into the camel-spring and camel-blueprint
wo dont have any osgi hickups due JAR files not being loaded and
whatnot. That was a pain in the past.



 Christian

 Am 31.08.2011 17:43, schrieb Claus Ibsen:

 On Wed, Aug 31, 2011 at 5:40 PM, Christian Schneider
 ch...@die-schneider.net  wrote:

 Hi all,

 can someone tell me what the purpose of camel-core-xml is and why it has
 to
 be a spearate project?
 It does not seem to have any other dependencies than camel-core.

 So if there is no good reason to keep it separate I propose to move that
 code into camel-core.

 No.

 Its an abstract component which has base classes used by XML DSLs such
 as camel-spring and camel-blueprint.
 This ensures that code is reused between the 2 XML DSLs and make it
 easier to keep them in sync and whatnot.



 --
 --
 Christian Schneider
 http://www.liquid-reality.de

 Open Source Architect
 Talend Application Integration Division http://www.talend.com





-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: What is the purpose of camel-core-xml? Move the code to camel-core?

[Claus Ibsen]

On Wed, Aug 31, 2011 at 7:45 PM, Christian Schneider
ch...@die-schneider.net wrote:
 The camel-core is already bloated anyway. I see no reason to not include
 those classes.

I may have posted the bloated word before which would be overstating
what I meant. What I was to say
is that camel-core-xml does not belong in camel-core, as it adds
dependency and features which the camel-core does not need.
Only the XML DSL capable components need those pieces and thus they
are in their own module. Those modules is not testable unless
you use camel-spring or camel-blueprint, and hence you would end up
with code in the camel-core which cannot be tested.


But frankly I think you are out of line and being disrespectful to the
project, the community, and the people who have
worked hard on this project. I would never call the camel-core bloated
in any negative way as you do.

The core is 1.6mb which is not bloated. In fact with the core you can
do really a lot with Camel, which impress
a lot of people, and help make the project a success it is today.

The camel-core has grown 200kb in 2.9 due that Google Code Map we
embed directly now, for improving
concurrency issues with the endpoint registry.

 The current mechanism of directly including the classes in camel-spring and
 camel-blueprint is really strange and I think having some classes in core
 that are not needed in some cases is much better then what we have now.


It is not strange. It was discussed and designed in the past. We
worked together with OSGi experts such as gnodet.
And Johan on the blueprint pieces etc.

We have two such modules:
camel-core-xml
camel-core-osgi

is core module for XML DSL and for running Camel in OSGi frameworks.

It just happens to be that both camel-spring and camel-blueprint uses
both of these two as
- camel-spring has a XML DSL and supports both plain Spring as well as Spring-DM
- camel-blueprint has a XML DSL and support OSGi blueprint.

And thus we have shared and common code for those 2 components in the
camel-core-XXX components.



 We will need to split the core anyway for 3.0 so reintegrating
 camel-core-xml would reduce the number of jars again which is good.


That is still to be decided. And to be discussed later when Camel 3.0
is starting to take form.


 Christian


 Am 31.08.2011 17:54, schrieb Claus Ibsen:

 On Wed, Aug 31, 2011 at 5:51 PM, Christian Schneider
 ch...@die-schneider.net  wrote:

 That sounds to me like it would fit nicely in camel-core.

 No as that is just bloat to the core.


 Btw. is there a reason why camel-core-xml is scope provided in
 camel-spring?
 This gives me errors in some tests of other components in eclipse as
 these
 classes can not be found.

 There is no problem at all in IDEA.


 Yes one of the reasons is osgi. By having the camel-core-xml .class
 files included directly into the camel-spring and camel-blueprint
 wo dont have any osgi hickups due JAR files not being loaded and
 whatnot. That was a pain in the past.



 Christian

 Am 31.08.2011 17:43, schrieb Claus Ibsen:

 On Wed, Aug 31, 2011 at 5:40 PM, Christian Schneider
 ch...@die-schneider.net    wrote:

 Hi all,

 can someone tell me what the purpose of camel-core-xml is and why it
 has
 to
 be a spearate project?
 It does not seem to have any other dependencies than camel-core.

 So if there is no good reason to keep it separate I propose to move
 that
 code into camel-core.

 No.

 Its an abstract component which has base classes used by XML DSLs such
 as camel-spring and camel-blueprint.
 This ensures that code is reused between the 2 XML DSLs and make it
 easier to keep them in sync and whatnot.


 --
 --
 Christian Schneider
 http://www.liquid-reality.de

 Open Source Architect
 Talend Application Integration Division http://www.talend.com





 --
 Christian Schneider
 http://www.liquid-reality.de

 Open Source Architect
 http://www.talend.com





-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: [Discuss] Remove generics and special message from file component

[Claus Ibsen]

On Wed, Aug 31, 2011 at 3:28 PM, Christian Schneider
ch...@die-schneider.net wrote:
 Currently the file component uses a special message GenericFile to send
 files into camel routes.
 This is bad as several other parts of camel need to deal with this type. It
 is already a bit better now that I introduced WrappedFile as an abstraction
 of GenericFile so other parts of camel do not have to know details about the
 file component.


This is not bad as its an abstract the component offered. So if you
use file/ftp/xxx you would have that GenericFile at your disposal.
Now the Camel type converters would make it easy to get a java.io.File
(if its a file component), a InputStream (which is what the ftp
components offers), or some X other object that contains access to the
underlying file implementation.

Frankly by introducing WrappedFile in the root package, which is,
according to you, a temporary solution, is a bad idea.
You now add more confusion to the mix. Just because a structure 101
diagram should have one less arrow less.
Instead you end up pushing more and more to the root package, and make
it more and more general. Abstract over abstraction :(


 The big question is though can we get rid of this completely?

 So my proposal is:

 - Send files as File objects in the body of a regular DefaultMessage. We
 could also think about sending a FileInputStream
 - Send other details as headers
 - Also get rid of FileBinding

 So what are your thoughts about that?


Camel 2.x should be kept backwards compatible and API stable.
We have end users who build custom components on top of the Camel file
component and rely on the API being as is.

The camel-ftp component is built on top of the file component and the
generics help making this possible.

Back in the days when the file component was created for camel 2.0, it
was meant to be a building block for file based components such as
- ftp
- commons-vfs
- a webdav component

It still makes sense to have it as a base component for file based
components. Today commons-vfs is a dead project. But we frankly still
miss a webdav component.



For Camel 3.0 we may consider adjusting pieces of it, if it makes sense.

So to re-iterate my thoughts. Keep the 2.x as is.
Consider changes for Camel 3.0 if it makes sense and is feasible.



 Christian

 --
 --
 Christian Schneider
 http://www.liquid-reality.de

 Open Source Architect
 Talend Application Integration Division http://www.talend.com





-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: svn commit: r1163705 - in /camel/trunk/camel-core/src: main/java/org/apache/camel/impl/converter/PropertyEditorTypeConverter.java test/java/org/apache/camel/component/bean/BeanComponentCustomCreat

[Claus Ibsen]

-core/src/test/java/org/apache/camel/component/bean/BeanComponentCustomCreateEndpointTest.java
  (original)
 +++ 
 camel/trunk/camel-core/src/test/java/org/apache/camel/component/bean/BeanComponentCustomCreateEndpointTest.java
  Wed Aug 31 17:10:53 2011
 @@ -47,11 +47,11 @@ public class BeanComponentCustomCreateEn

     public void testCreateEndpointUri() throws Exception {
         BeanComponent bc = context.getComponent(bean, BeanComponent.class);
 -        ProcessorEndpoint pe = bc.createEndpoint(new MyFooBean(), cheese);
 +        ProcessorEndpoint pe = bc.createEndpoint(new MyFooBean(), 
 bean:cheese);
         assertNotNull(pe);

         String uri = pe.getEndpointUri();
 -        assertEquals(cheese, uri);
 +        assertEquals(bean:cheese, uri);

         Producer producer = pe.createProducer();
         Exchange exchange = producer.createExchange();






-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: What is the purpose of camel-core-xml? Move the code to camel-core?

[Claus Ibsen]

On Wed, Aug 31, 2011 at 10:15 PM, Donald Whytock dwhyt...@gmail.com wrote:
 On Wed, Aug 31, 2011 at 3:26 PM, Claus Ibsen claus.ib...@gmail.com wrote:
 The core is 1.6mb which is not bloated. In fact with the core you can
 do really a lot with Camel, which impress
 a lot of people, and help make the project a success it is today.

 In all fairness, 1.6 mb is bigger than the entire Felix framework,
 including the documentation.  The camel-core jar represents two-thirds
 of the volume of my deployed Felix OSGI application.


In all fairness you are comparing apples to oranges. Is it not a goal
for the Felix project
to be a micro container and very small, and being embeddable into
small devices and whatnot.

Thats not necessarily the same goal for Camel.


Instead you ought to compare Camel with equal projects such as
- Spring Integration
- Apache Synapse
- Mule
- and possible others

Spring Integration is about 500kb. But then you must use Spring
Framework also. So thats about 2-3mb extra, depending on your choice
of their JARs.

Apache Synpase has a ton of JARs. I am actually not aware which one is
the bare you need to run. The dist is 40+mb.
Mule is about the same story as Synapse. However Mule is designed to
be an ESB and thus bigger. But the Mule people
also like to compare against Camel and say they can embed and run Mule
standalone, or in WARs etc. Mule and OSGi,
well we all may know what Ross said about that.

Yes the camel-core could be splitted up but it may just add more
confusion and trouble to the mix. We got a lot of new and less
experienced users to Apache Camel, as they need help with integration.
So for them being able to pick camel-core and be able to run out of
the box is great. They dont need to fiddle with adding 8-15 JARs as
you would do when using Spring or other which have fine grained JARs
for the project.

The 1.6 - 1.7mb in camel-core is roughly taking up space as follows
- default implementation = 500kb
- model = 400kb
- eips = 400kb
- components = 300kb
- jmx = 100kb
- other stuff = the rest

In the components there is 3 which take up some size
- bean, file and mock
The rest of the components is minimal, some one one class, and others
maybe 10-20kb

The bean component is a core piece of camel and ought to be in camel-core.
Mock is used heavily for unit testing camel itself. But also for end
users as well.

It could be moved to camel-mock, but then we would need to build
camel-mock before camel-core to be able to test camel-core.
Would that not cause trouble, as camel-mock depends on camel-core?

Then file is not, and could be in a camel-file JAR. But then again
when people get started
with Camel they often try out with files. So having  that work out of
the box is nice.

And for management, Christian have prepared the API for that. And it
would be possible to split that out in camel-core-management
or what a component name could be for the future. If it makes sense.


So the big pieces to split Camel would be the eips and the model. But
those are key concepts for Camel.
The routing and EIPs.




 Yes, the core does a lot, but how many people genuinely use all the
 features and built-in components?  Not that I'm necessarily advocating
 splitting it into all separate modules, since it would probably take
 up more space that way, what with the extra manifests and activators
 and all.

 But still, even if not bloated, I might call it non-trivially sized.

 Don




-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Got my ICLA

[Claus Ibsen]

On Thu, Sep 1, 2011 at 1:10 PM, Mathieu Lalonde mrlalo...@live.ca wrote:
 Hi,

 My name is now on the list. :)
 I am ready to get karma to edit the wiki.  My preferred id was mrlalonde.

 Let me know if you need more info.


This is great. I can see the ICLA as well.

Hi you need to create the user account on the confluence yourself.
Then tell us your userid and we can then give you karma.


 Thanks!
 Mathieu





-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Got my ICLA

[Claus Ibsen]

On Thu, Sep 1, 2011 at 1:59 PM, Mathieu Lalonde mrlalo...@live.ca wrote:

 Hi Claus,

 Just created the account with userid: mrlalonde


Hi I have granted you karma.

Thanks for helping with this project.


 Thanks!
 Mathieu

 
 From: claus.ib...@gmail.com
 Date: Thu, 1 Sep 2011 13:24:41 +0200
 Subject: Re: Got my ICLA
 To: dev@camel.apache.org

 On Thu, Sep 1, 2011 at 1:10 PM, Mathieu Lalonde mrlalo...@live.ca wrote:
  Hi,
 
  My name is now on the list. :)
  I am ready to get karma to edit the wiki.  My preferred id was mrlalonde.
 
  Let me know if you need more info.
 

 This is great. I can see the ICLA as well.

 Hi you need to create the user account on the confluence yourself.
 Then tell us your userid and we can then give you karma.


  Thanks!
  Mathieu
 
 



 --
 Claus Ibsen
 -
 FuseSource
 Email: cib...@fusesource.com
 Web: http://fusesource.com
 Twitter: davsclaus, fusenews
 Blog: http://davsclaus.blogspot.com/
 Author of Camel in Action: http://www.manning.com/ibsen/




-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: svn commit: r1164334 - in /camel/trunk/components: camel-cache/src/test/java/org/apache/camel/component/cache/ camel-exec/src/main/java/org/apache/camel/component/exec/ camel-exec/src/test/java/or

[Claus Ibsen]

());






-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: What is the purpose of camel-core-xml? Move the code to camel-core?

[Claus Ibsen]

 such changes from professional products
such as Spring Framework.
Which has become a key infrastructure in many organizations. It would
be great for Apache
and the Camel community, that Camel 2.x (could become / already is)
key in their integration needs.


Okay I really didnt mean to write a long email, as we all have alot to
do in our daily work and lives.

One last point. I am not trying to be the devils advocate. But from a
community point of view.
They would possible like that all the API changes would be rolled
back. No API changes in an old
product is what they wish for.

However what is done is done. I will lobby for that we do not repart
this in the future.
Okay I take of the community hat. I guess there were a few parts
which had the Camel team hat.


Okay good weekend.
And no hard feelings. We are all working in the interrest of the community.



On Thu, Sep 1, 2011 at 8:06 AM, Christian Schneider
ch...@die-schneider.net wrote:
 Hi Claus,

 I did not intend to be disrespectful. It is natural that things become
 bloated when a project grows. In fact it is very difficult to avoid.

 So I think camel-core is too complex. That does not mean it is too big in
 size. Even more important is that the parts of the core are not separated.
 They are highly entangled.

 For example the file component. You would expect that the file component
 knows about the api but the rest of core does not know about the file
 component. In reality the GenericFile
 class was used in several places outside the file component. So the core had
 knowledge about file component internals. In the case of the file component
 it was wasy to change that.

 The other components are similar. The bean component is the worst example.
 The connections between bean component classes and core are many and
 complicated and I am not yet sure how to
 solve that one.

 So these are just two example there are many more. The problem with
 camel-core is not the size. The problem is that it is not nicely separated
 logically. If the parts of the core had minimal dependencies among each
 other then camel-core would be much easier to use and change and also to
 test. So the minimal thing we need is a real architecture people know and
 agree with - with rules that make sure that things keep manageable.
 Splitting the core would be the easiest way to make the rules visible but it
 is not the only way to go.

 Your example of the mock component shows the problem nicely. It uses the
 core but is also used to test the core. This is in fact a problem. As soon
 as we have a camel-api the mock component can only depend on the api.
 Then the core can depend on api and on mock for testing. That will then make
 it nicely spearated.

 We can then still create a big jar in the build for beginners to give them
 an easy start but logically the parts of camel-core need to be nicely
 separated.

 Christian



 Am 31.08.2011 21:26, schrieb Claus Ibsen:

 On Wed, Aug 31, 2011 at 7:45 PM, Christian Schneider
 ch...@die-schneider.net  wrote:

 The camel-core is already bloated anyway. I see no reason to not include
 those classes.

 I may have posted the bloated word before which would be overstating
 what I meant. What I was to say
 is that camel-core-xml does not belong in camel-core, as it adds
 dependency and features which the camel-core does not need.
 Only the XML DSL capable components need those pieces and thus they
 are in their own module. Those modules is not testable unless
 you use camel-spring or camel-blueprint, and hence you would end up
 with code in the camel-core which cannot be tested.


 But frankly I think you are out of line and being disrespectful to the
 project, the community, and the people who have
 worked hard on this project. I would never call the camel-core bloated
 in any negative way as you do.

 The core is 1.6mb which is not bloated. In fact with the core you can
 do really a lot with Camel, which impress
 a lot of people, and help make the project a success it is today.

 The camel-core has grown 200kb in 2.9 due that Google Code Map we
 embed directly now, for improving
 concurrency issues with the endpoint registry.

 The current mechanism of directly including the classes in camel-spring
 and
 camel-blueprint is really strange and I think having some classes in core
 that are not needed in some cases is much better then what we have now.

 It is not strange. It was discussed and designed in the past. We
 worked together with OSGi experts such as gnodet.
 And Johan on the blueprint pieces etc.

 We have two such modules:
 camel-core-xml
 camel-core-osgi

 is core module for XML DSL and for running Camel in OSGi frameworks.

 It just happens to be that both camel-spring and camel-blueprint uses
 both of these two as
 - camel-spring has a XML DSL and supports both plain Spring as well as
 Spring-DM
 - camel-blueprint has a XML DSL and support OSGi blueprint.

 And thus we have shared and common code for those 2 components in the
 camel

Re: [DISCUSS] - Apache Camel 2.8.1 release

[Claus Ibsen]

On Tue, Aug 30, 2011 at 3:29 PM, Hadrian Zbarcea hzbar...@gmail.com wrote:
 I will and get ready for the 2.8.1 release.
 Hadrian


Did you have a change to do this?

A new ESB and AMQ releases is on the way and they would like to use
2.8.1 with the needed bug fixes.
Would be great to, yeah if possible, lets take the opportunity and get
the RC cut so we could get a release our the door
for the benefit for our sister projects at Apache.


 On 08/30/2011 05:44 AM, Claus Ibsen wrote:

 Anyone got cycles to take a look at the bug fixes in Camel 2.9, which
 may not have been backported. And then merge any bug fixes which seems
 reasonable to be backported?

 I guess this is the current bug fixed on 2.9

 https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+CAMEL+AND+issuetype+%3D+Bug+AND+resolution+%3D+Fixed+AND+fixVersion+%3D+12316374+AND+status+%3D+Resolved+ORDER+BY+updated+DESC%2C+key+DESC

 There is 37 bugs fixed, and there may be some fixes which havent been
 backported.






-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: [DISCUSS] - Apache Camel 2.8.1 release

[Claus Ibsen]

On Fri, Sep 2, 2011 at 10:11 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote:
 Hi guys,

 I would like to release SMX 4.4 soon. For now, the target is Camel 2.8.0. We
 still have some time in SMX to update to Camel 2.8.1, but I think we
 shouldn't wait too long ;)


I am backporting the fixes now. I would like Camel 2.8.1 as part of
the new SMX 4.4 release.
There is not so often a new SMX release so we should put in the best
Camel version we can do.


 Regards
 JB

 On 09/02/2011 10:00 AM, Claus Ibsen wrote:

 On Tue, Aug 30, 2011 at 3:29 PM, Hadrian Zbarceahzbar...@gmail.com
  wrote:

 I will and get ready for the 2.8.1 release.
 Hadrian


 Did you have a change to do this?

 A new ESB and AMQ releases is on the way and they would like to use
 2.8.1 with the needed bug fixes.
 Would be great to, yeah if possible, lets take the opportunity and get
 the RC cut so we could get a release our the door
 for the benefit for our sister projects at Apache.


 On 08/30/2011 05:44 AM, Claus Ibsen wrote:

 Anyone got cycles to take a look at the bug fixes in Camel 2.9, which
 may not have been backported. And then merge any bug fixes which seems
 reasonable to be backported?

 I guess this is the current bug fixed on 2.9


 https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+CAMEL+AND+issuetype+%3D+Bug+AND+resolution+%3D+Fixed+AND+fixVersion+%3D+12316374+AND+status+%3D+Resolved+ORDER+BY+updated+DESC%2C+key+DESC

 There is 37 bugs fixed, and there may be some fixes which havent been
 backported.







 --
 Jean-Baptiste Onofré
 jbono...@apache.org
 http://blog.nanthrax.net
 Talend - http://www.talend.com




-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: [DISCUSS] - Apache Camel 2.8.1 release

[Claus Ibsen]

On Fri, Sep 2, 2011 at 11:18 AM, Claus Ibsen claus.ib...@gmail.com wrote:
 On Fri, Sep 2, 2011 at 10:11 AM, Jean-Baptiste Onofré j...@nanthrax.net 
 wrote:
 Hi guys,

 I would like to release SMX 4.4 soon. For now, the target is Camel 2.8.0. We
 still have some time in SMX to update to Camel 2.8.1, but I think we
 shouldn't wait too long ;)


 I am backporting the fixes now. I would like Camel 2.8.1 as part of
 the new SMX 4.4 release.
 There is not so often a new SMX release so we should put in the best
 Camel version we can do.


Okay I have backported the bug fixes.

And kicked off a 2.8.1 deploy build
https://builds.apache.org/job/Camel-2.8.x/

And kicking off a 2.8.1 full test as well
https://builds.apache.org/job/Camel.2.8.x.fulltest/



 Regards
 JB

 On 09/02/2011 10:00 AM, Claus Ibsen wrote:

 On Tue, Aug 30, 2011 at 3:29 PM, Hadrian Zbarceahzbar...@gmail.com
  wrote:

 I will and get ready for the 2.8.1 release.
 Hadrian


 Did you have a change to do this?

 A new ESB and AMQ releases is on the way and they would like to use
 2.8.1 with the needed bug fixes.
 Would be great to, yeah if possible, lets take the opportunity and get
 the RC cut so we could get a release our the door
 for the benefit for our sister projects at Apache.


 On 08/30/2011 05:44 AM, Claus Ibsen wrote:

 Anyone got cycles to take a look at the bug fixes in Camel 2.9, which
 may not have been backported. And then merge any bug fixes which seems
 reasonable to be backported?

 I guess this is the current bug fixed on 2.9


 https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+CAMEL+AND+issuetype+%3D+Bug+AND+resolution+%3D+Fixed+AND+fixVersion+%3D+12316374+AND+status+%3D+Resolved+ORDER+BY+updated+DESC%2C+key+DESC

 There is 37 bugs fixed, and there may be some fixes which havent been
 backported.







 --
 Jean-Baptiste Onofré
 jbono...@apache.org
 http://blog.nanthrax.net
 Talend - http://www.talend.com




 --
 Claus Ibsen
 -
 FuseSource
 Email: cib...@fusesource.com
 Web: http://fusesource.com
 Twitter: davsclaus, fusenews
 Blog: http://davsclaus.blogspot.com/
 Author of Camel in Action: http://www.manning.com/ibsen/




-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: svn commit: r1164334 - in /camel/trunk/components: camel-cache/src/test/java/org/apache/camel/component/cache/ camel-exec/src/main/java/org/apache/camel/component/exec/ camel-exec/src/test/java/or

[Claus Ibsen]

On Fri, Sep 2, 2011 at 2:20 PM, Hadrian Zbarcea hzbar...@gmail.com wrote:
 Not sure I understand your request, please clarify.


Can you post on @dev what you see as problems with the endpoint uris.
You create a number of tickets and mark then as critical bugs, without
much details. People
have been using this without of problems for years.

You then change many unit tests to url encode, also tests which are
used for wiki documentation.
Which makes it a bit confusing for end users, as there is no
documentation why they have to do this now.

For example when they use camel-exec



 Hadrian


 On 09/02/2011 01:59 AM, Claus Ibsen wrote:

 This seems over reacting.

 Can you post on @dev why you suddenly change all the working unit
 tests like this?
 Camel end users have been using these components without problems, and
 they are easier to use without having to do URL encoding!


 On Fri, Sep 2, 2011 at 4:36 AM,hadr...@apache.org  wrote:

 Author: hadrian
 Date: Fri Sep  2 02:36:12 2011
 New Revision: 1164334

 URL: http://svn.apache.org/viewvc?rev=1164334view=rev
 Log:
 More URI encoding fixes

 Modified:

  camel/trunk/components/camel-cache/src/test/java/org/apache/camel/component/cache/CacheProducerTest.java

  camel/trunk/components/camel-exec/src/main/java/org/apache/camel/component/exec/ExecComponent.java

  camel/trunk/components/camel-exec/src/test/java/org/apache/camel/component/exec/ExecEndpointTest.java

 Modified:
 camel/trunk/components/camel-cache/src/test/java/org/apache/camel/component/cache/CacheProducerTest.java
 URL:
 http://svn.apache.org/viewvc/camel/trunk/components/camel-cache/src/test/java/org/apache/camel/component/cache/CacheProducerTest.java?rev=1164334r1=1164333r2=1164334view=diff

 ==
 ---
 camel/trunk/components/camel-cache/src/test/java/org/apache/camel/component/cache/CacheProducerTest.java
 (original)
 +++
 camel/trunk/components/camel-cache/src/test/java/org/apache/camel/component/cache/CacheProducerTest.java
 Fri Sep  2 02:36:12 2011
 @@ -133,7 +133,7 @@ public class CacheProducerTest extends C
             public void configure() {
                 onException(CacheException.class).
                         handled(true).
 -                        to(log:*** LOGGER).
 +                        to(log:LOGGER).
                         to(mock:CacheProducerTest.cacheException);

                 from(direct:a).
 @@ -185,7 +185,7 @@ public class CacheProducerTest extends C
             public void configure() {
                 onException(CacheException.class).
                         handled(true).
 -                        to(log:*** LOGGER).
 +                        to(log:LOGGER).
                         to(mock:CacheProducerTest.cacheException);

                 from(direct:a).
 @@ -222,7 +222,7 @@ public class CacheProducerTest extends C
             public void configure() {
                 onException(CacheException.class).
                         handled(true).
 -                        to(log:*** LOGGER).
 +                        to(log:LOGGER).
                         to(mock:CacheProducerTest.cacheException);

                 from(direct:a).
 @@ -258,7 +258,7 @@ public class CacheProducerTest extends C
             public void configure() {
                 onException(CacheException.class).
                         handled(true).
 -                        to(log:*** LOGGER).
 +                        to(log:LOGGER).
                         to(mock:CacheProducerTest.cacheException);

                 from(direct:a).
 @@ -279,7 +279,7 @@ public class CacheProducerTest extends C
             public void configure() {
                 onException(CacheException.class).
                         handled(true).
 -                        to(log:*** LOGGER).
 +                        to(log:LOGGER).
                         to(mock:CacheProducerTest.cacheException);

                 from(direct:a).
 @@ -305,7 +305,7 @@ public class CacheProducerTest extends C
                 onException(CacheException.class).
                         handled(true).

 choice().when(exceptionMessage().isEqualTo(CacheConstants.CACHE_OPERATION +
  UNKNOWN is not supported.)).
 -                        to(log:*** LOGGER).
 +                        to(log:LOGGER).

 to(mock:CacheProducerTest.cacheException).end();

                 from(direct:a).
 @@ -332,7 +332,7 @@ public class CacheProducerTest extends C
             public void configure() {
                 onException(CacheException.class).
                         handled(true).
 -                        to(log:*** LOGGER).
 +                        to(log:LOGGER).
                         to(mock:CacheProducerTest.cacheException);

                 from(direct:a).
 @@ -360,7 +360,7 @@ public class CacheProducerTest extends C
             public void configure() {
                 onException(CacheException.class).
                         handled

Re: svn commit: r1163705 - in /camel/trunk/camel-core/src: main/java/org/apache/camel/impl/converter/PropertyEditorTypeConverter.java test/java/org/apache/camel/component/bean/BeanComponentCustomCreat

[Claus Ibsen]

On Thu, Sep 1, 2011 at 3:16 AM, Hadrian Zbarcea hzbar...@gmail.com wrote:
 Yes, I agree with that, reason why Registries that use caches *are* and
 should stay as Services. The PropertyEditorTypeConverter in particular
 doesn't need to be a Service, but the EndpointRegisty, ConsumerCache and
 ProducerCache should be and are Services.

 So you are correct about not leaving memory leaks, etc. Owners of caches
 that hold Service(s) should and do shut them down before the cache clear()
 since that's not the job of the cache itself (plus caches may not hold
 Services in which case all the iteration over, dunno, hundreds, thousands of
 object to check for (item instanceof Service) is kinda useless anyway.
 Services are something that have a life cycle, the LRUCache is a handy data
 structure. All in all I was quite careful about my changes, I hope I didn't
 miss anything. I am sure that if anybody spots something he'll point it out
 and we'll fix it. Needless to say, all tests pass after my changes and I am
 fairly comfortable with the fix.

 Cheers,
 Hadrian


There is still a leaking problem.

For example try run
PropertyEditorTypeConverterIssueTest

And then revert the change on PropertyEditorTypeConverterIssue to the
previous commit (eg its a Service).
And then for example do a System.out in doStop

For example when I do this
Starting org.apache.camel.impl.converter.PropertyEditorTypeConverter@6a8c436b
Stopping org.apache.camel.impl.converter.PropertyEditorTypeConverter@6a8c436b
with 0 in cache and 1 misses

eg I can see that when Camel is shutdown this type converter is as
well, where I then would be able to clear the caches.
And thus not leak resources.





 On 08/31/2011 03:55 PM, Claus Ibsen wrote:

 I wonder if there wont be a problem when you shutdown camel, or run
 Camel in a hot deployment environment.
 As before the service would ensure start|stop callbacks, where we
 could clear the caches when stopping.

 That is now gone, which means we can just hope the GC eventually will
 be able to reclaim the objects.

 So I suggest to use Service for classes that has caches or any map
 store which can hold possible a lot of data.
 Then being able to properly clean/stop those cachen when stopping
 Camel is a good citizen to avoid eating memory or leaking in any way.



 On Wed, Aug 31, 2011 at 7:10 PM,hadr...@apache.org  wrote:

 Author: hadrian
 Date: Wed Aug 31 17:10:53 2011
 New Revision: 1163705

 URL: http://svn.apache.org/viewvc?rev=1163705view=rev
 Log:
 CAMEL-4392. Fix side effect of LRUCache not a service.

 Modified:

  camel/trunk/camel-core/src/main/java/org/apache/camel/impl/converter/PropertyEditorTypeConverter.java

  camel/trunk/camel-core/src/test/java/org/apache/camel/component/bean/BeanComponentCustomCreateEndpointTest.java

 Modified:
 camel/trunk/camel-core/src/main/java/org/apache/camel/impl/converter/PropertyEditorTypeConverter.java
 URL:
 http://svn.apache.org/viewvc/camel/trunk/camel-core/src/main/java/org/apache/camel/impl/converter/PropertyEditorTypeConverter.java?rev=1163705r1=1163704r2=1163705view=diff

 ==
 ---
 camel/trunk/camel-core/src/main/java/org/apache/camel/impl/converter/PropertyEditorTypeConverter.java
 (original)
 +++
 camel/trunk/camel-core/src/main/java/org/apache/camel/impl/converter/PropertyEditorTypeConverter.java
 Wed Aug 31 17:10:53 2011
 @@ -22,11 +22,9 @@ import java.util.HashMap;
  import java.util.Map;

  import org.apache.camel.Exchange;
 -import org.apache.camel.Service;
  import org.apache.camel.TypeConverter;
  import org.apache.camel.util.LRUSoftCache;
  import org.apache.camel.util.ObjectHelper;
 -import org.apache.camel.util.ServiceHelper;
  import org.slf4j.Logger;
  import org.slf4j.LoggerFactory;

 @@ -36,14 +34,14 @@ import org.slf4j.LoggerFactory;
  *
  * @version
  */
 -public class PropertyEditorTypeConverter implements TypeConverter,
 Service {
 +public class PropertyEditorTypeConverter implements TypeConverter {

     private static final Logger LOG =
 LoggerFactory.getLogger(PropertyEditorTypeConverter.class);
     // use a soft bound cache to avoid using too much memory in case a
 lot of different classes
     // is being converted to string
 -    private final MapClass, Class  misses = new LRUSoftCacheClass,
 Class(1000);
 +    private final MapClass?, Class?  misses = new
 LRUSoftCacheClass?, Class?(1000);
     // we don't anticipate so many property editors so we have unbounded
 map
 -    private final MapClass, PropertyEditor  cache = new HashMapClass,
 PropertyEditor();
 +    private final MapClass?, PropertyEditor  cache = new
 HashMapClass?, PropertyEditor();

     publicT  T convertTo(ClassT  type, Object value) {
         // We can't convert null values since we can't figure out a
 property
 @@ -58,14 +56,14 @@ public class PropertyEditorTypeConverter
                 return ObjectHelper.cast(type, value);
             }

 -            Class key = type

Re: Re: svn commit: r1164515 - /camel/trunk/camel-core/src/main/java/org/apache/camel/impl/converter/PropertyEditorTypeConverter.java

[Claus Ibsen]

On Fri, Sep 2, 2011 at 4:50 PM, Hadrian Zbarcea hzbar...@gmail.com wrote:
 Moving to dev@.

 -1. Please revert your change and let's fix it properly. In the future
 please do not revert my changes without discussing that with me, even if
  you believe it's the right thing to do. The PropertyEditoryTypeConverter
 and being a Service and leaks are two separate issues.


Fix it properly? Well you introduced bugs in the core in the first place!
The existing code works fine.

A service is a lifecycle callback that allows to do code in starting
and stopping.
And being able to clear the maps when stopping is what the service
solves for us.

I dont see a point reverting this. In fact if we talk about -1 then we
should consider
-1 your commits at first then.




 Hadrian


 On 09/02/2011 08:51 AM, davscl...@apache.org wrote:

 Author: davsclaus
 Date: Fri Sep  2 12:51:57 2011
 New Revision: 1164515

 URL: http://svn.apache.org/viewvc?rev=1164515view=rev
 Log:
 CAMEL-4392. Clear cache maps when stopping Camel to avoid leaks

 Modified:

 camel/trunk/camel-core/src/main/java/org/apache/camel/impl/converter/PropertyEditorTypeConverter.java

 Modified:
 camel/trunk/camel-core/src/main/java/org/apache/camel/impl/converter/PropertyEditorTypeConverter.java
 URL:
 http://svn.apache.org/viewvc/camel/trunk/camel-core/src/main/java/org/apache/camel/impl/converter/PropertyEditorTypeConverter.java?rev=1164515r1=1164514r2=1164515view=diff

 ==
 ---
 camel/trunk/camel-core/src/main/java/org/apache/camel/impl/converter/PropertyEditorTypeConverter.java
 (original)
 +++
 camel/trunk/camel-core/src/main/java/org/apache/camel/impl/converter/PropertyEditorTypeConverter.java
 Fri Sep  2 12:51:57 2011
 @@ -22,6 +22,7 @@ import java.util.HashMap;
  import java.util.Map;

  import org.apache.camel.Exchange;
 +import org.apache.camel.Service;
  import org.apache.camel.TypeConverter;
  import org.apache.camel.util.LRUSoftCache;
  import org.apache.camel.util.ObjectHelper;
 @@ -34,7 +35,7 @@ import org.slf4j.LoggerFactory;
   *
   * @version
   */
 -public class PropertyEditorTypeConverter implements TypeConverter {
 +public class PropertyEditorTypeConverter implements TypeConverter,
 Service {

      private static final Logger LOG =
 LoggerFactory.getLogger(PropertyEditorTypeConverter.class);
      // use a soft bound cache to avoid using too much memory in case a
 lot of different classes
 @@ -113,4 +114,15 @@ public class PropertyEditorTypeConverter
      publicT  T mandatoryConvertTo(ClassT  type, Exchange exchange,
 Object value) {
          return convertTo(type, value);
      }
 +
 +    public void start() throws Exception {
 +        // noop
 +    }
 +
 +    public void stop() throws Exception {
 +        // clear caches so we dont leak
 +        cache.clear();
 +        misses.clear();
 +    }
 +
  }






-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Re: svn commit: r1164515 - /camel/trunk/camel-core/src/main/java/org/apache/camel/impl/converter/PropertyEditorTypeConverter.java

[Claus Ibsen]

Okay I got a bit upset here.

But I cant understand why you want to turn the blind eye to the fact
you introduced a leak, despite being careful.
What is the problem with that class being a service, which then have
callbacks (start/stop) where it can ensure
the cache is cleared when stopping.

What do you want to do instead? Introduce a clear() or reset() method,
and then need to invoke that from the
type converter registry.

You need to do something to ensure the caches is cleared, so we dont leak.

Using service is the preferred way in Camel.


On Fri, Sep 2, 2011 at 5:02 PM, Claus Ibsen claus.ib...@gmail.com wrote:
 On Fri, Sep 2, 2011 at 4:50 PM, Hadrian Zbarcea hzbar...@gmail.com wrote:
 Moving to dev@.

 -1. Please revert your change and let's fix it properly. In the future
 please do not revert my changes without discussing that with me, even if
  you believe it's the right thing to do. The PropertyEditoryTypeConverter
 and being a Service and leaks are two separate issues.


 Fix it properly? Well you introduced bugs in the core in the first place!
 The existing code works fine.

 A service is a lifecycle callback that allows to do code in starting
 and stopping.
 And being able to clear the maps when stopping is what the service
 solves for us.

 I dont see a point reverting this. In fact if we talk about -1 then we
 should consider
 -1 your commits at first then.




 Hadrian


 On 09/02/2011 08:51 AM, davscl...@apache.org wrote:

 Author: davsclaus
 Date: Fri Sep  2 12:51:57 2011
 New Revision: 1164515

 URL: http://svn.apache.org/viewvc?rev=1164515view=rev
 Log:
 CAMEL-4392. Clear cache maps when stopping Camel to avoid leaks

 Modified:

 camel/trunk/camel-core/src/main/java/org/apache/camel/impl/converter/PropertyEditorTypeConverter.java

 Modified:
 camel/trunk/camel-core/src/main/java/org/apache/camel/impl/converter/PropertyEditorTypeConverter.java
 URL:
 http://svn.apache.org/viewvc/camel/trunk/camel-core/src/main/java/org/apache/camel/impl/converter/PropertyEditorTypeConverter.java?rev=1164515r1=1164514r2=1164515view=diff

 ==
 ---
 camel/trunk/camel-core/src/main/java/org/apache/camel/impl/converter/PropertyEditorTypeConverter.java
 (original)
 +++
 camel/trunk/camel-core/src/main/java/org/apache/camel/impl/converter/PropertyEditorTypeConverter.java
 Fri Sep  2 12:51:57 2011
 @@ -22,6 +22,7 @@ import java.util.HashMap;
  import java.util.Map;

  import org.apache.camel.Exchange;
 +import org.apache.camel.Service;
  import org.apache.camel.TypeConverter;
  import org.apache.camel.util.LRUSoftCache;
  import org.apache.camel.util.ObjectHelper;
 @@ -34,7 +35,7 @@ import org.slf4j.LoggerFactory;
   *
   * @version
   */
 -public class PropertyEditorTypeConverter implements TypeConverter {
 +public class PropertyEditorTypeConverter implements TypeConverter,
 Service {

      private static final Logger LOG =
 LoggerFactory.getLogger(PropertyEditorTypeConverter.class);
      // use a soft bound cache to avoid using too much memory in case a
 lot of different classes
 @@ -113,4 +114,15 @@ public class PropertyEditorTypeConverter
      publicT  T mandatoryConvertTo(ClassT  type, Exchange exchange,
 Object value) {
          return convertTo(type, value);
      }
 +
 +    public void start() throws Exception {
 +        // noop
 +    }
 +
 +    public void stop() throws Exception {
 +        // clear caches so we dont leak
 +        cache.clear();
 +        misses.clear();
 +    }
 +
  }






 --
 Claus Ibsen
 -
 FuseSource
 Email: cib...@fusesource.com
 Web: http://fusesource.com
 Twitter: davsclaus, fusenews
 Blog: http://davsclaus.blogspot.com/
 Author of Camel in Action: http://www.manning.com/ibsen/




-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: svn commit: r1164334 - in /camel/trunk/components: camel-cache/src/test/java/org/apache/camel/component/cache/ camel-exec/src/main/java/org/apache/camel/component/exec/ camel-exec/src/test/java/or

[Claus Ibsen]

Frankly people have been using Camel for 4.5 years with url's just
like that without any problems.

I think its bad judgment to create JIRA tickets with critical bugs
and mark them as fix for 2.8.1 etc,
as if the sky is falling down on people.

Instead as you write somewhere, it could be put as a goal for Camel
3.0 to have URL validation more strict,
and to start throwing exception if the uris is not 100% according to that spec.

But for 2.x that is 2+ years old and in light of this is how Camel has
been doing it since its birth, eg 4.5 years
then it would IMHO be better to keep it as is in 1.x/2.x and put up
for 3.0 roadmap instead.




On Fri, Sep 2, 2011 at 3:50 PM, Hadrian Zbarcea hzbar...@gmail.com wrote:
 Still not sure how to answer, but let me try. The issue(s) I created and
 partially fixed are related to passing invalid URIs to Camel to create
 endpoints. I could understand the questions in the following ways:

 1. I don't see any problem.
 2. I see a problem, but:
 a. No need to fix it because it worked like that for a long time
 b. It needs to be fixed, but it's not critical

 1. From the beginning of the project we said that Camel uses URIs for both
 identifying and configuring endpoint. All the presentations, books,
 webinars, you name it said the same thing. What represents a URI is clearly
 defined [1] and unambiguous. We never said that we take something that looks
 like a URI but it's not a URI. As such we would expect the users to pass in
 valid URIs, nothing new there.
 The fact that in DefaultComponent.createEndpoint(String) we use
 UnsafeUriCharactersEncoder.encode when creating/parsing the URI was a
 mistake that hid the issue. Even worse, we designed components (see 2b) that
 *only* accept invalid URIs for some scenarios. How retarded it that?

 2a. This logic applied to any bug with see. Camel worked for so many years
 with this bug, why fix it now?

 2b. Designing components in ways that only work with invalid data (URIs) is
 a critical design issue, imho. Another reason I made it critical is to draw
 attention (which it did, that's good). Please note that I mentioned that we
 need to find a fix (I have one) *and* workaround that does not force users
 to fix their URIs immediately, and the usage of bad URIs should be
 deprecated and removed in 3.0

 I hope that clarifies it,
 Hadrian

 [1] http://www.ietf.org/rfc/rfc2396.txt


 On 09/02/2011 08:32 AM, Claus Ibsen wrote:

 On Fri, Sep 2, 2011 at 2:20 PM, Hadrian Zbarceahzbar...@gmail.com
  wrote:

 Not sure I understand your request, please clarify.


 Can you post on @dev what you see as problems with the endpoint uris.
 You create a number of tickets and mark then as critical bugs, without
 much details. People
 have been using this without of problems for years.

 You then change many unit tests to url encode, also tests which are
 used for wiki documentation.
 Which makes it a bit confusing for end users, as there is no
 documentation why they have to do this now.

 For example when they use camel-exec



 Hadrian


 On 09/02/2011 01:59 AM, Claus Ibsen wrote:

 This seems over reacting.

 Can you post on @dev why you suddenly change all the working unit
 tests like this?
 Camel end users have been using these components without problems, and
 they are easier to use without having to do URL encoding!


 On Fri, Sep 2, 2011 at 4:36 AM,hadr...@apache.org    wrote:

 Author: hadrian
 Date: Fri Sep  2 02:36:12 2011
 New Revision: 1164334

 URL: http://svn.apache.org/viewvc?rev=1164334view=rev
 Log:
 More URI encoding fixes

 Modified:


  camel/trunk/components/camel-cache/src/test/java/org/apache/camel/component/cache/CacheProducerTest.java


  camel/trunk/components/camel-exec/src/main/java/org/apache/camel/component/exec/ExecComponent.java


  camel/trunk/components/camel-exec/src/test/java/org/apache/camel/component/exec/ExecEndpointTest.java

 Modified:

 camel/trunk/components/camel-cache/src/test/java/org/apache/camel/component/cache/CacheProducerTest.java
 URL:

 http://svn.apache.org/viewvc/camel/trunk/components/camel-cache/src/test/java/org/apache/camel/component/cache/CacheProducerTest.java?rev=1164334r1=1164333r2=1164334view=diff


 ==
 ---

 camel/trunk/components/camel-cache/src/test/java/org/apache/camel/component/cache/CacheProducerTest.java
 (original)
 +++

 camel/trunk/components/camel-cache/src/test/java/org/apache/camel/component/cache/CacheProducerTest.java
 Fri Sep  2 02:36:12 2011
 @@ -133,7 +133,7 @@ public class CacheProducerTest extends C
             public void configure() {
                 onException(CacheException.class).
                         handled(true).
 -                        to(log:*** LOGGER).
 +                        to(log:LOGGER).
                         to(mock:CacheProducerTest.cacheException);

                 from(direct:a).
 @@ -185,7 +185,7 @@ public class CacheProducerTest extends C

Re: [HEADS UP] - A prototype of an improved Simple language for Apache Camel

[Claus Ibsen]

Hi

Just an update on the status.

I discovered an issue in the scala DSL, which I managed to fix
yesterday. The problem was the scala DSL would cause all languages to
be evaluated as Expression, and then converted to Predicate if
applicable. This was wrong, as the DSL indicate whether it should be a
Predicate or Expression. This level of indirection would cause an
issue as first being an Expression and then a Predicate. And also
cause a slight difference between Scala DSL and Java DSL etc.

The problem was identified due the improved Simple language prototype
as it parse the input depending on its a Expression or Predicate. The
latter has all the operators and whatnot. Where as the former is the
template style which was the origin roots of the Simple language - A
very simple expression language for dynamic templates, eg to say
Hello ${body} how are you?.

The old simple language did support a style by which you could be lazy
and omit the ${ } tokens, and just indicate body or header.foo.
The new simple language prefers to use ${body} and ${header.foo}
as its consistent and also stands out to the user, that this is a
function, and not plain text. However the old style is supported using
a SimpleBackwardsCompatibleParser which have been marked as
@deprecated, and to be removed in Camel 3.0.

I have been running with the simple prototype for a week on my laptop,
and have identified some minor mistakes in the Camel source code due
the old simple language. I have corrected them.

So it would be a matter of time before the prototype is ready as a
donation to Apache and to be included in Camel 2.9.

the prototype is located here
https://github.com/davsclaus/camel-simple2


-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: [Discuss] How to create Exchanges?

[Claus Ibsen]

Hi

Just to be clear when I wear the watchdog of the community hat.

The API in Camel 2.x should be kept to a minimum changes. For example
we cannot move DefaultEndpoint, DefaultExchange etc. They should stay
to ensure 100% backwards compatibility and not cause more trouble in
the community. These classes is central for people creating custom
components.

The community expect Camel 2.x API to be stable.



On Mon, Sep 5, 2011 at 3:04 PM, Christian Schneider
ch...@die-schneider.net wrote:
 Hi all,

 I am currently trying to minimize the use of impl classes in components and
 check how to completely hide impl classes for 3.0.

 So I will have to move several classes from impl to support as they are used
 as base classes anyway (e.g. DefaultEndpoint). A special case is
 DefaultExchange. It is not a base class, in fact it is the only
 implementation of Exchange.
 So the big question is how do we want to handle exchange creation. There are
 two main solutions I can think of:

 - Hide the implementation and offer factory methods on camelContext
 - Move the implementation to support and so allow new DefaultExchange from
 any class

 We also have factory methods for Exchange on Endpoint and DefaultEndpoint.
 The question is do we need these? DefaultEndpoint would not be able to hide
 the impl of DefaultExchange as it has to reside in support and is a base
 class. So if we want to hide DefaultExchange the factory impl must be in a
 real impl class like DefaultCamelContext.

 Christian

 --
 --
 Christian Schneider
 http://www.liquid-reality.de

 Open Source Architect
 Talend Application Integration Division http://www.talend.com





-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

[DISCUSS] - API stability in Camel 2.x

[Claus Ibsen]

Hi

I am writing this mail with a community hat as well being a very
concerned Camel team member.

The API in camel-core had a fair number of changes recently, which is
a strong concern from a community point of view.
Basically the community views Camel 2.x as an mature and well
established project, but also an old and stable product because of
Camel 2.x being 2+ years old.

In summary the community wants in Camel 2.x
- NO CHANGES IN API

The community do not care if class is named X or placed in Y etc. The
community care about that the class is kept named X and kept placed in
Y.

That said, API changes is needed from time to time, and this is why
you accumulate API change ideas in roadmap wiki pages, TODO in the
source code etc. And possible some JIRA tickets.

Then when a new major version is in the works such as Camel 3.0, then
those API changes can be executed.
In fact designing an API is a bigger challenge than at first thought.
Today you feel class X should be named and placed in Y package. To
days later it should be named X2 and placed in Z package instead. To
give amble time for API changes to settled down, and see how it works
out then milestone releases of the 3.0 is being released. This gives
the community and early adopters a changes to help out and give
feedback. This is common practice and how other projects do.

The Apache Camel 2.x project is a very successful project and its
usage have reached beyond what you may see as a typical situation. We
have many other open source projects which integrate directly with
Camel in their products. We have other open source projects and
commercial products that is based on top of Camel, or using Camel
heavily internally. Their most likely use
the API in ways the typical end user does not. So bottom line the
exposed API is in use out there.

The Camel team ove to the community to keep the API stable regardless
if a class could be renamed to X to have a bit better name etc.

Likewise it does not give confort in the community if the API is kept
changing and their use of the API keeps being @deprecated.
So when they compile or upgrade to a new version, they get scared
because of the sheer number of @deprecate warnings.
It is a costly $$$ for any organization to change source code, as
often rigors testing and procedures kicks in, when the source code
must be changed.

Likewise the Apache Camel subversion repository on trunk, is not a
personal * experiment* branch where the Camel committers should play
and move around with classes and whatnot. It would be better to setup
a branch or a personal project on github etc to work on the expriment
(for example as I did with the simple language improvements project).


From community point of view. Keep the API stable in our old and
beloved Camel 2.x product.

From community point of view. Start a discussion about Camel 3.0, as
we think the Camel 2.x product is old and stable.
But the community would like a brand new Camel 3.0 in early 2012.





-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: [DISCUSS] - API stability in Camel 2.x

[Claus Ibsen]

On Mon, Sep 5, 2011 at 5:16 PM, Zbarcea Hadrian hzbar...@gmail.com wrote:
 Claus,

 How exactly did you get to figure out what the community wants NO CHANGES 
 in the the API an via what process were you nominated to express that opinion?


I guess writing all caps was a way of getting attention.
The phrase should possible have been: KEEP API CHANGES TO A MINIMUM!

I am not the spokesman as we *all* get exposed to the community.
But here is a few points from my exposure.

I have been around the Camel community for a long time. I work on
Camel every day for a long time. I have been around at conferences
giving talks on Camel and being in touch with many exiting Camel
users, and new users as well. Likewise I get in touch with other
communities who integrates or want to integrate with Camel. Likewise
commercial companies of all sort get in touch with me via my employeer
to discuss Camel etc.

Likewise we have the long term history of the Camel project and how
things works the usual way. Back in the days when we did Camel 1.x to
2.0 we did *not* change the API in 1.x, but crafted a new 2.0 API and
released milestone releases and whatnot.
Prior to this we discussed the key API changes we wanted to do for
2.0, such as removing the specialized exchanges, and only keen one =
DefaultExchange. Likewise the removal of the FaultMessage, and so on.

What I hear from people and vendors is that they love Camel when the
API in 2.x started to settle down from Camel 2.4 onwards. We had a few
bumpy releases in the earlier Camel 2.x lifetime. Some of this can be
expected in a new major release etc.
They do not expect this to happen again now that Camel 2.x has been
around for 2+ years, the API is settled down, and the project is very
successful and they can rely on the API being as is.


 The reality is that the API did change in every single minor release of 
 Camel, and my understanding is that this is an effort to actually clean it up 
 and make sure it does not happen anymore after 3.0. The changes put on now 
 are the painless ones that could be done before that. Afaik, you provided 
 some useful feedback for some of these changes.


Yes some changes in the API is okay. For example if there is issues
reported by the community. Or that we can archive major wins such as
better performance, reduced memory footprint and whatnot. Also API
changes in the DSL may be more tolerable, as the DSL is very end user
targeted, and end users would often recompile the Camel apps with the
new Camel version. Where as changes in component API is harder, as end
users may very well use 3rd party components which they dont recompile
or maintain themselves. Or the component maintainers dont want to keep
maintaing their components because Camel API changes every time.
Also we have other open source projects which integrates with Camel
and rely on API being stable etc. If we keep changing it, we just
loose those other open source projects, as they can't always spend
time and energy to keep up with Camel API changes.


Also Christian just started this out of the blue without any
consensus from the Camel team, prior discussions, request from the
community, as well the timing was a bit off, as he started during the
summer holiday.

I am sure the internal API refactorings is nice. But every time you
change something you risk introducing new bugs. In fact he did, which
some I was able to point out. However we have a lot of unit tests
which often help pickup against regressions. But there is always a
risk.

So if Christian could keep his toes to internal low risk refactorings
that would be nice.
The community would appreciate that the 2.x API is stable.

Then I would suggest Christian started a Camel 3.0 discussion, and he
could be a key figure in getting the new API settled down, and help
splitup the camel-core into smaller pieces where it makes sense. When
that API is settled a bit and takes form, then we could look at the
gap from 3.0 to 2.x and put in migration guides, and possible some
@deprecations in the 2.x API. We should not do it the wrong way
around by experimenting with the 2.x API.



 Hadrian



 On Sep 5, 2011, at 10:04 AM, Claus Ibsen wrote:

 Hi

 I am writing this mail with a community hat as well being a very
 concerned Camel team member.

 The API in camel-core had a fair number of changes recently, which is
 a strong concern from a community point of view.
 Basically the community views Camel 2.x as an mature and well
 established project, but also an old and stable product because of
 Camel 2.x being 2+ years old.

 In summary the community wants in Camel 2.x
 - NO CHANGES IN API

 The community do not care if class is named X or placed in Y etc. The
 community care about that the class is kept named X and kept placed in
 Y.

 That said, API changes is needed from time to time, and this is why
 you accumulate API change ideas in roadmap wiki pages, TODO in the
 source code etc. And possible some JIRA tickets.

 Then when a new

Re: [DISCUSS] - API stability in Camel 2.x

[Claus Ibsen]

On Mon, Sep 5, 2011 at 7:13 PM, Johan Edstrom seij...@gmail.com wrote:
 With deprecate changes, we'll have no issues at all, so there I do not see it 
 as a change at all.


Its not only deprecated changes. What we have is a mix of changes:
1) classes being deleted (without any prior warnings, they were not
@deprecated etc.)
2) classes being moved
3) classes being moved, including API changes
4) classes being moved, and leaving a stub class as @deprecated in
place of the old class

In terms of the item #4, then that is not a 100% backwards compatible
change. There is a couple of issues. The stub class is not active in
use and the stub class is not unit tested. For example if the Camel
API exposes an API which returns the given class, then with this
change, that API will now return the new class, which causes
ClassCastExceptions for end users who was depending on the old API.




 /je
 On Sep 5, 2011, at 9:16 AM, Zbarcea Hadrian wrote:

 Claus,

 How exactly did you get to figure out what the community wants NO CHANGES 
 in the the API an via what process were you nominated to express that 
 opinion?

 The reality is that the API did change in every single minor release of 
 Camel, and my understanding is that this is an effort to actually clean it 
 up and make sure it does not happen anymore after 3.0. The changes put on 
 now are the painless ones that could be done before that. Afaik, you 
 provided some useful feedback for some of these changes.

 Hadrian



 On Sep 5, 2011, at 10:04 AM, Claus Ibsen wrote:

 Hi

 I am writing this mail with a community hat as well being a very
 concerned Camel team member.

 The API in camel-core had a fair number of changes recently, which is
 a strong concern from a community point of view.
 Basically the community views Camel 2.x as an mature and well
 established project, but also an old and stable product because of
 Camel 2.x being 2+ years old.

 In summary the community wants in Camel 2.x
 - NO CHANGES IN API

 The community do not care if class is named X or placed in Y etc. The
 community care about that the class is kept named X and kept placed in
 Y.

 That said, API changes is needed from time to time, and this is why
 you accumulate API change ideas in roadmap wiki pages, TODO in the
 source code etc. And possible some JIRA tickets.

 Then when a new major version is in the works such as Camel 3.0, then
 those API changes can be executed.
 In fact designing an API is a bigger challenge than at first thought.
 Today you feel class X should be named and placed in Y package. To
 days later it should be named X2 and placed in Z package instead. To
 give amble time for API changes to settled down, and see how it works
 out then milestone releases of the 3.0 is being released. This gives
 the community and early adopters a changes to help out and give
 feedback. This is common practice and how other projects do.

 The Apache Camel 2.x project is a very successful project and its
 usage have reached beyond what you may see as a typical situation. We
 have many other open source projects which integrate directly with
 Camel in their products. We have other open source projects and
 commercial products that is based on top of Camel, or using Camel
 heavily internally. Their most likely use
 the API in ways the typical end user does not. So bottom line the
 exposed API is in use out there.

 The Camel team ove to the community to keep the API stable regardless
 if a class could be renamed to X to have a bit better name etc.

 Likewise it does not give confort in the community if the API is kept
 changing and their use of the API keeps being @deprecated.
 So when they compile or upgrade to a new version, they get scared
 because of the sheer number of @deprecate warnings.
 It is a costly $$$ for any organization to change source code, as
 often rigors testing and procedures kicks in, when the source code
 must be changed.

 Likewise the Apache Camel subversion repository on trunk, is not a
 personal * experiment* branch where the Camel committers should play
 and move around with classes and whatnot. It would be better to setup
 a branch or a personal project on github etc to work on the expriment
 (for example as I did with the simple language improvements project).


 From community point of view. Keep the API stable in our old and
 beloved Camel 2.x product.

 From community point of view. Start a discussion about Camel 3.0, as
 we think the Camel 2.x product is old and stable.
 But the community would like a brand new Camel 3.0 in early 2012.





 --
 Claus Ibsen
 -
 FuseSource
 Email: cib...@fusesource.com
 Web: http://fusesource.com
 Twitter: davsclaus, fusenews
 Blog: http://davsclaus.blogspot.com/
 Author of Camel in Action: http://www.manning.com/ibsen/






-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel

Re: [DISCUSS] - API stability in Camel 2.x

[Claus Ibsen]

On Mon, Sep 5, 2011 at 4:39 PM, Christian Schneider
ch...@die-schneider.net wrote:
 Hi Claus,

 I am trying to give the community a smooth transition to 3.0 by my current
 changes.

 Whereever possible I use a deprecated class in the old place. So someone who
 changes to camel 2.9.0 should have no problems.
 He will see deprecation warnings though and this is a good thing. It will
 allow him to then adapt to the changes while staying on 2.9.0. Then when
 he switches to 3.0.0 he will again have almost nothing to change.

 If we do not do changes now and do everything in 3.0 then people will have a
 very incompatible upgrade from 2.x to 3.0. So I think now with 2.9.x being
 the last 2.x minor version it is exactly the right time to do these changes.
 Of course you are right that it is very difficult to do the design right. So
 we should look at it together and discuss how things should look like. If we
 wait with this till 3.0 then it is too late. If I experiment in a private
 branch then no one will look at the changes
 and no discussion will occur.


What do you mean by 3.0 is too late?

So you would rather take the entire Camel community as hostage
(sorry I cant find a better word) by API changes directly on the
trunk? Than use a new branch which gives you, the Camel team and
people from the community time to work on the API without side
effects, of our existing community users.

Frankly this is how other projects do it. They create a new major
release where they do non backwards API changes,
key API changes which is needed to make the product better etc.

Apache ServiceMix team have created a branch for their upcoming SMX 5.0 release.
Apache Karaf team have created a branch for their upcoming Karaf 3.0 release.
Apache ActiveMQ created a new branch for their upcoming ActiveMQ 6.0
release. (This release is actually a total overhaul and based on a new
architecture)

Neither of those projects created a lot of API changes prior in the
current release branches, *before* they got started on their new major
release.

If you look outside Apache, the for example the Spring framework do
neither this. If we compare Camel and Spring then the releases would
roughly match up as below. Notice that we in the Camel team have this
history of doing a quarterly minor release, and hence why the versions
match up as below:

Camel 2.0 = Spring 3.0.0
Camel 2.1 = Spring 3.0.1
Camel 2.2 = Spring 3.0.2
Camel 2.3 = Spring 3.0.3
...

Not anytime in the Spring 3.0.x release have the Spring team started
to move around classes and mark the API as @deprecated and whatnot,
just because they want people a smooth transition to Spring 3.1.
They actually respect the community and keep the API stable.


Now imagine this use-case from which could be from the real life.

Developer: We need to upgrade Camel in this production application
Manager: Why?
Developer: It fixes this bug we have, and also it improved this issue as well
Manager: How long time will it take?
Developer: I do not know, as the release notes say, that there is many
API changes and non backwards compatible breakings
Manager: Has this happened before?
Developer: No this is the first time. I though Camel 2.x was an old,
mature and stable product.
Manager: Will this upgrade affect other products?
Developer: Yes possible. We have those 3 custom in-house Camel
components which most likely would be affected.
Developer: And these components is shared by the 5 other Camel
applications we have in production. And the 2 new projects we have in
development currently.
Manager: So you are saying that we need to upgrade Camel to fix this
bug. But we cannot upfront have a qualified overview of the
consequences?
Developer: Yes
Manager: So I need to quad-double my budget for this upgrade. And
impose changes and risks in other projects as well.
Manager: What would be the consequences for not upgrading?
Developer: We have this bug in production
Manager: Is there a workaround?
Developer: Possible as the bug is fixed in a later Camel release. We
may be able to patch the current version of Camel with the fix
Manager: How long time will this take?
Developer: Much less than upgrading Camel.
Manager: Okay I want you to look into patching that bug, instead of upgrading.
Manager: Hmm so you are saying that by relying on Camel in our
business, we have this risk of upgrade pains, that is hard to estimate
the consequences of, takes longer time, and costs more money
Manager: I want a new team setup tomorrow that starts looking for
alternatives for Camel. I don't want this problem in the future.





 Christian


 Am 05.09.2011 16:04, schrieb Claus Ibsen:

 Hi

 I am writing this mail with a community hat as well being a very
 concerned Camel team member.

 The API in camel-core had a fair number of changes recently, which is
 a strong concern from a community point of view.
 Basically the community views Camel 2.x as an mature and well
 established project, but also an old and stable product because of
 Camel

[BEWARE] - Moving classes - Keep SVN revision details

[Claus Ibsen]

Hi

When you refactor the code such as moving classes to new packages,
etc. Then try to make sure to use svn mv so so we keep the svn
revisions of this class. If you do a delete and add instead, we loose
all that details.

This is important to keep as it helps resolving issues as you can
compare with past versions, and also on a line by line bases see
who/when/commit logs what has been changed.

For example the class AsyncProcessorTypeConverter was moved in the
last commit. But the commit was a delete + add, which means all the
previous commit logs of that class is gone.


-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Problem with code to redirect jetty to http4

[Claus Ibsen]

$RequestHandler.headerComplete(HttpConnection.java:1042)
        at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:549)
        at 
 org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:211)
        at 
 org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:424)
        at
 org.eclipse.jetty.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:506)
        at
 org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:436)
        at java.lang.Thread.run(Thread.java:662)
 Caused by: java.lang.NoSuchMethodError:
 org.apache.camel.util.IOHelper.close(Ljava/io/Closeable;Ljava/lang/String;Lorg/apache/commons/logging/Log;)V
        at
 org.apache.camel.component.http4.HttpProducer.doExtractResponseBody(HttpProducer.java:244)
        at
 org.apache.camel.component.http4.HttpProducer.extractResponseBody(HttpProducer.java:231)
        at
 org.apache.camel.component.http4.HttpProducer.populateResponse(HttpProducer.java:128)
        at
 org.apache.camel.component.http4.HttpProducer.process(HttpProducer.java:105)
        at
 org.apache.camel.impl.converter.AsyncProcessorTypeConverter$ProcessorToAsyncProcessorBridge.process(AsyncProcessorTypeConverter.java:50)
        ... 43 more


 Any idea?

 thks

 Valery


 --
 View this message in context: 
 http://camel.465427.n5.nabble.com/Problem-with-code-to-redirect-jetty-to-http4-tp4782847p4782847.html
 Sent from the Camel Development mailing list archive at Nabble.com.




-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: [DISCUSS] - API stability in Camel 2.x

[Claus Ibsen]

On Thu, Sep 8, 2011 at 1:31 PM, Rob Davies rajdav...@gmail.com wrote:
 Mmm - seems still to be there (on SendDefinition). I'm deriving a class from 
 WireTapDefinition - which can no longer find getUriOrRef() moving from camel 
 2.7 to 2.8 :)

 On 8 Sep 2011, at 11:59, Rob Davies wrote:

 getUriOrRef() was removed from ProcessDefinition between Camel 2.7 and Camel 
 2.8  (not even deprecated) - what's the thinking behind that ?


Thet getUriOrRef() method is on SendDefinition, not on
ProcessDefinition. The method hasn't been removed, its frankly because
WireTapDefinition has changed. See a bit below.

The 2.8 release notes documents the model and API changes
http://camel.apache.org/camel-280-release.html

So the WireTapDefinition no long extend SendDefinition. Reasons are
two fold. It was improved to support new uses-cases asked by the
community. Also we had a look at the XSD from the model and found some
mismatches. In particular because 3rd party tooling and the likes did
surface some issues in the XSD, which end users did not discover when
they create Camel routes in XML. So we cleaned up those mistakes in
the 2.8 release. And we added a special DSL changes section to the
release notes.




 thanks,

 Rob

 On 6 Sep 2011, at 12:36, Christian Schneider wrote:

 Btw. I just compiled the unchanged camel-extra components against my 
 current camel trunk and they showed no compile or test failures.
 So I hope we can fix the problem you see quite fast.

 Christian


 Am 06.09.2011 12:50, schrieb Christian Schneider:
 Hi bvahdat,

 this is important feedback. Can you give me the compile failures. I will 
 make sure this will be compatible.
 We are currently at a snapshot. So stuff is not in release quality. Btw. 
 this is why I would like to do a release candidate.
 It is great you already tested this but many people will only do this with 
 some official release.

 Christian


 Am 06.09.2011 08:06, schrieb bvahdat:
 Hi All,

 the use-case Claus gave as an example in his last post indeed happened 
 today
 morning with my client to whom I've provided the application (running 
 stable
 since July 27th with camel 2.8.0 in the production).

 I wanted to give a try to the snapshot build of today morning at [1], and
 following what I see:

 - The code doesn't even compile, and maven-compile-plugin fails (while 
 doing
 'mvn install') with a bunch of compilation errors, however I didn't have
 time enough to see where/why these happen. I'll dig into it later.

 - And there're 14 test cases now suddenly failing, mostly by the own
 component (zls) which does logging of different events to the
 central-logging-system of the client as the payloads pass through 
 different
 endpoints (camel-jms, camel-jpa, camel-spring-ws, etc.), which at the same
 time is used for Auditing of the client applications.

 So at least to me this refactoring hysterie was not as smooth as it was
 claimed to be. Being a camel user in the last 10 months was really a great
 fun to me... And it's a pity to see what's going on by the camel community
 today!

 Regards, Babak

 [1]
 https://repository.apache.org/content/repositories/snapshots/org/apache/camel/camel/2.9-SNAPSHOT/

 --
 View this message in context: 
 http://camel.465427.n5.nabble.com/DISCUSS-API-stability-in-Camel-2-x-tp4770632p4773307.html
 Sent from the Camel Development mailing list archive at Nabble.com.





 --
 --
 Christian Schneider
 http://www.liquid-reality.de

 Open Source Architect
 Talend Application Integration Division http://www.talend.com







-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: [VOTE] Release Apache Camel 2.8.1

[Claus Ibsen]

+1

I have been told that the camel-example-spring-ws may have an issue
running out of the box on the dist.
But if you run it from the src instead, then it works.

This problem should also exist in 2.8.0 and possible earlier releases.
We may put a note about this in the release notes.


On Fri, Sep 9, 2011 at 10:39 AM, Willem Jiang willem.ji...@gmail.com wrote:
 Here is my +1,

 Willem

 On 9/7/11 3:27 AM, Zbarcea Hadrian wrote:

 A new patch release apache-camel-2.8.1 is out with approximately 45 issues
 resolved: improvements and bug fixes [1].

 Please find the staging repo here:
 https://repository.apache.org/content/repositories/orgapachecamel-037/

 The tarballs are here

 https://repository.apache.org/content/repositories/orgapachecamel-037/org/apache/camel/apache-camel/2.8.1/

 Tag:
 http://svn.apache.org/repos/asf/camel/tags/camel-2.8.1/

 Please review, test and vote to approve this release binary. Your vote
 counts!

 [ ] +1 Release the binary as Apache Camel 2.8.1
 [ ] -1 Veto the release (provide specific comments)
 Vote is open for at least 72 hours.

 Here's my +1
 Hadrian

 [1]
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311211version=12317152






-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Compilation error on trunk on windows on Apache Jenkins

[Claus Ibsen]

Hi

Apache Jenkins is reporting errors on Camel trunk on windows
https://builds.apache.org/job/Camel.trunk.fulltest.windows/11/

Its a compilation error in the model. We have seen this java generics
issues before on compiling to AIX, HP-UX, IBM JDKs and whatnot in the
past. Also sometimes it was a bug in the JDK version itself, so by
upgrading the JDK it would fix that.

On my XP Box I could not reproduce the compilation error on trunk.
Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Maven home: E:\maven\bin\..
Java version: 1.6.0_18, vendor: Sun Microsystems Inc.
Java home: C:\jdk1.6.0_18\jre
Default locale: en_GB, platform encoding: Cp1252
OS name: windows xp, version: 5.1, arch: x86, family: windows


I was not able to find details on Jenkins which windows and JDK
version was used.
Its a big PITA that Jenkins do not log this in the console, so you
have it easily available.


Anyone on a Windows box, could you try to compile camel-core from
trunk on your system.
To see if you have this issue as well?


The fix is often to have an explicit redundant type cast in the code,
to help the compiler.
We usually added a code comment in the code, that this type cast is
needed due to compilation issues on other platforms.




Caused by: org.apache.maven.plugin.CompilationFailureException:
Compilation failure
\hudson\hudson-slave\workspace\Camel.trunk.fulltest.windows\camel-trunk\camel-core\src\main\java\org\apache\camel\model\LoadBalanceDefinition.java:[134,16]
inconvertible types
found   : org.apache.camel.model.ProcessorDefinitioncapture#632 of ?
required: org.apache.camel.model.LoadBalanceDefinition

at 
org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:656)
at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:128)
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)


-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Compilation error on trunk on windows on Apache Jenkins

[Claus Ibsen]

Thanks

I committed a potential fix and kicked a CI server on Apache Jenkins
https://builds.apache.org/job/Camel.trunk.fulltest.windows/14/

I am not able on Apache Jenkins to see which JDK version is being used
on windows1 which is what
is used for the windows tests. Neither which Windows OS is being used
- WinXP, Win2000, Win7 etc.

I suspect it uses an older JDK and thus fails.



On Sun, Sep 11, 2011 at 3:07 PM, Christian Schneider
ch...@die-schneider.net wrote:
 My machine is a

 Intel Core i5
 Windows 7

 mvn -v
 Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
 Maven home: c:\Program Files (x86)\apache-maven-3.0.3
 Java version: 1.6.0_25, vendor: Sun Microsystems Inc.
 Java home: c:\Program Files\Java\jdk1.6.0_25\jre
 Default locale: de_DE, platform encoding: Cp1252
 OS name: windows 7, version: 6.1, arch: amd64, family: windows

 Christian


 Am 11.09.2011 12:44, schrieb Christian Schneider:

 Hi Claus,

 I also could not reproduce the error. Will send the details of my work
 machine later.
 I guess the most probable cause should be the jdk version.

 Christian


 Am 11.09.2011 09:33, schrieb Claus Ibsen:

 Hi

 Apache Jenkins is reporting errors on Camel trunk on windows
 https://builds.apache.org/job/Camel.trunk.fulltest.windows/11/

 Its a compilation error in the model. We have seen this java generics
 issues before on compiling to AIX, HP-UX, IBM JDKs and whatnot in the
 past. Also sometimes it was a bug in the JDK version itself, so by
 upgrading the JDK it would fix that.

 On my XP Box I could not reproduce the compilation error on trunk.
 Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
 Maven home: E:\maven\bin\..
 Java version: 1.6.0_18, vendor: Sun Microsystems Inc.
 Java home: C:\jdk1.6.0_18\jre
 Default locale: en_GB, platform encoding: Cp1252
 OS name: windows xp, version: 5.1, arch: x86, family: windows


 I was not able to find details on Jenkins which windows and JDK
 version was used.
 Its a big PITA that Jenkins do not log this in the console, so you
 have it easily available.


 Anyone on a Windows box, could you try to compile camel-core from
 trunk on your system.
 To see if you have this issue as well?


 The fix is often to have an explicit redundant type cast in the code,
 to help the compiler.
 We usually added a code comment in the code, that this type cast is
 needed due to compilation issues on other platforms.




 Caused by: org.apache.maven.plugin.CompilationFailureException:
 Compilation failure

 \hudson\hudson-slave\workspace\Camel.trunk.fulltest.windows\camel-trunk\camel-core\src\main\java\org\apache\camel\model\LoadBalanceDefinition.java:[134,16]
 inconvertible types
 found   : org.apache.camel.model.ProcessorDefinitioncapture#632 of ?
 required: org.apache.camel.model.LoadBalanceDefinition

    at
 org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:656)
    at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:128)
    at
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
    at
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)





 --
 --
 Christian Schneider
 http://www.liquid-reality.de

 Open Source Architect
 Talend Application Integration Division http://www.talend.com





-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Compilation error on trunk on windows on Apache Jenkins

[Claus Ibsen]

Okay the patch seems to work. Apache CI server can now compile and
test camel-core.

Its currently running a full test
https://builds.apache.org/job/Camel.trunk.fulltest.windows/15/console



On Mon, Sep 12, 2011 at 7:59 AM, Claus Ibsen claus.ib...@gmail.com wrote:
 Thanks

 I committed a potential fix and kicked a CI server on Apache Jenkins
 https://builds.apache.org/job/Camel.trunk.fulltest.windows/14/

 I am not able on Apache Jenkins to see which JDK version is being used
 on windows1 which is what
 is used for the windows tests. Neither which Windows OS is being used
 - WinXP, Win2000, Win7 etc.

 I suspect it uses an older JDK and thus fails.



 On Sun, Sep 11, 2011 at 3:07 PM, Christian Schneider
 ch...@die-schneider.net wrote:
 My machine is a

 Intel Core i5
 Windows 7

 mvn -v
 Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
 Maven home: c:\Program Files (x86)\apache-maven-3.0.3
 Java version: 1.6.0_25, vendor: Sun Microsystems Inc.
 Java home: c:\Program Files\Java\jdk1.6.0_25\jre
 Default locale: de_DE, platform encoding: Cp1252
 OS name: windows 7, version: 6.1, arch: amd64, family: windows

 Christian


 Am 11.09.2011 12:44, schrieb Christian Schneider:

 Hi Claus,

 I also could not reproduce the error. Will send the details of my work
 machine later.
 I guess the most probable cause should be the jdk version.

 Christian


 Am 11.09.2011 09:33, schrieb Claus Ibsen:

 Hi

 Apache Jenkins is reporting errors on Camel trunk on windows
 https://builds.apache.org/job/Camel.trunk.fulltest.windows/11/

 Its a compilation error in the model. We have seen this java generics
 issues before on compiling to AIX, HP-UX, IBM JDKs and whatnot in the
 past. Also sometimes it was a bug in the JDK version itself, so by
 upgrading the JDK it would fix that.

 On my XP Box I could not reproduce the compilation error on trunk.
 Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
 Maven home: E:\maven\bin\..
 Java version: 1.6.0_18, vendor: Sun Microsystems Inc.
 Java home: C:\jdk1.6.0_18\jre
 Default locale: en_GB, platform encoding: Cp1252
 OS name: windows xp, version: 5.1, arch: x86, family: windows


 I was not able to find details on Jenkins which windows and JDK
 version was used.
 Its a big PITA that Jenkins do not log this in the console, so you
 have it easily available.


 Anyone on a Windows box, could you try to compile camel-core from
 trunk on your system.
 To see if you have this issue as well?


 The fix is often to have an explicit redundant type cast in the code,
 to help the compiler.
 We usually added a code comment in the code, that this type cast is
 needed due to compilation issues on other platforms.




 Caused by: org.apache.maven.plugin.CompilationFailureException:
 Compilation failure

 \hudson\hudson-slave\workspace\Camel.trunk.fulltest.windows\camel-trunk\camel-core\src\main\java\org\apache\camel\model\LoadBalanceDefinition.java:[134,16]
 inconvertible types
 found   : org.apache.camel.model.ProcessorDefinitioncapture#632 of ?
 required: org.apache.camel.model.LoadBalanceDefinition

    at
 org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:656)
    at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:128)
    at
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
    at
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)





 --
 --
 Christian Schneider
 http://www.liquid-reality.de

 Open Source Architect
 Talend Application Integration Division http://www.talend.com





 --
 Claus Ibsen
 -
 FuseSource
 Email: cib...@fusesource.com
 Web: http://fusesource.com
 Twitter: davsclaus, fusenews
 Blog: http://davsclaus.blogspot.com/
 Author of Camel in Action: http://www.manning.com/ibsen/




-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: [RESULT][VOTE] Release Apache Camel 2.8.1

[Claus Ibsen]

On Mon, Sep 12, 2011 at 3:31 AM, Zbarcea Hadrian hzbar...@gmail.com wrote:
 The vote passes with:

 [6] +1 binding (janstey, cibsen, ningjiang, joed, cschneider, hadrian)
 [2] +1 non-binding
 [0] -1

 I will promote the artifacts to the central repo, upload the distro to the 
 apache site and update the main site.


Any news on updating the site?
The JARs is in central repo. But the main site is not updated.



 Many thanks to all who took the time to test this release and vote.
 Hadrian


 On Sep 6, 2011, at 3:27 PM, Zbarcea Hadrian wrote:

 A new patch release apache-camel-2.8.1 is out with approximately 45 issues 
 resolved: improvements and bug fixes [1].

 Please find the staging repo here:
 https://repository.apache.org/content/repositories/orgapachecamel-037/

 The tarballs are here
 https://repository.apache.org/content/repositories/orgapachecamel-037/org/apache/camel/apache-camel/2.8.1/

 Tag:
 http://svn.apache.org/repos/asf/camel/tags/camel-2.8.1/

 Please review, test and vote to approve this release binary. Your vote 
 counts!

 [ ] +1 Release the binary as Apache Camel 2.8.1
 [ ] -1 Veto the release (provide specific comments)
 Vote is open for at least 72 hours.

 Here's my +1
 Hadrian

 [1] 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311211version=12317152





-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: svn commit: r1170077 - in /camel/trunk: components/camel-jpa/pom.xml components/camel-jpa/src/main/java/org/apache/camel/component/jpa/JpaConsumer.java parent/pom.xml platforms/karaf/features/src/

[Claus Ibsen]

}/bundle
 @@ -383,7 +383,7 @@
      bundle
 dependency=truemvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.ant/${ant-bundle-version}/bundle
      bundle
 dependency=truemvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.serp/${serp-bundle-version}/bundle
      bundle
 dependency=truemvn:org.apache.geronimo.specs/geronimo-jms_1.1_spec/${geronimo-jms-spec-version}/bundle

 -bundlemvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.openjpa/${openjpa-bundle-version}/bundle
 +bundlemvn:org.apache.openjpa/openjpa/${openjpa-version}/bundle
      feature version=[3,4)spring-orm/feature
      feature version='${pom.version}'camel-core/feature
      bundlemvn:org.apache.camel/camel-jpa/${pom.version}/bundle

 Modified: camel/trunk/pom.xml
 URL:
 http://svn.apache.org/viewvc/camel/trunk/pom.xml?rev=1170077r1=1170076r2=1170077view=diff

 ==
 --- camel/trunk/pom.xml (original)
 +++ camel/trunk/pom.xml Tue Sep 13 08:18:08 2011
 @@ -49,7 +49,7 @@
      jaxb-api-version2.1/jaxb-api-version
      maven-bundle-version2.3.5/maven-bundle-version

 -openjpa-version1.2.2/openjpa-version
 +openjpa-version2.1.1/openjpa-version
    /properties

    mailingLists






-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: svn commit: r1170077 - in /camel/trunk: components/camel-jpa/pom.xml components/camel-jpa/src/main/java/org/apache/camel/component/jpa/JpaConsumer.java parent/pom.xml platforms/karaf/features/src/

[Claus Ibsen]

Okay I got it fixed now.

It passes on my win xp box now

[INFO]
[INFO] --- maven-install-plugin:2.3.1:install (default-install) @ camel-jpa ---
[INFO] Installing
E:\workspace\camel\components\camel-jpa\target\camel-jpa-2.9-SNAPSHOT.jar
to e:\maven-repo\org\apache\
camel\camel-jpa\2.9-SNAPSHOT\camel-jpa-2.9-SNAPSHOT.jar
[INFO] Installing E:\workspace\camel\components\camel-jpa\pom.xml to
e:\maven-repo\org\apache\camel\camel-jpa\2.9-SNAPSH
OT\camel-jpa-2.9-SNAPSHOT.pom
[INFO]
[INFO] --- maven-bundle-plugin:2.3.5:install (default-install) @ camel-jpa ---
[INFO] Installing
org/apache/camel/camel-jpa/2.9-SNAPSHOT/camel-jpa-2.9-SNAPSHOT.jar
[INFO] Writing OBR metadata
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 42.047s
[INFO] Finished at: Thu Sep 15 10:44:17 CEST 2011
[INFO] Final Memory: 11M/30M
[INFO] 


-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

[ANNOUNCE] - Apache Camel 2.8.1 Released

[Claus Ibsen]

The Camel PMC is glad to announce the availability of apache-camel
version 2.8.1.
This release resolved over 45 JIRA issues (mostly bugs) reported by users.

Download [1] Camel now, check out the release notes [2] and enjoy the ride!
The release is synced to Apache Maven central, and also available for
download from the Apache site [1].


[1] - http://camel.apache.org/download
[2] - http://camel.apache.org/camel-281-release.html


-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Apache ICLA sent

[Claus Ibsen]

Hi

On Sat, Sep 17, 2011 at 2:55 AM, David Tombs cyan.s...@gmail.com wrote:
 Hello Camel Developers,

 Below you will see that I have sent in my Apache ICLA to contribute to
 the Camel wiki. My Confluence and JIRA ID is 'dgtombs'.


I have granted you karma so you should be able to edit the documentation.


 Thanks,
 David

  Original Message 
 Subject: re: Apache ICLA
 Date: Thu, 15 Sep 2011 19:40:12 -0700
 From: Craig L Russell craig.russ...@sun.com
 To: David Tombs cyan.s...@gmail.com
 CC: secret...@apache.org,       priv...@camel.apache.org

 Dear David Tombs,

 This message acknowledges receipt of your ICLA, which has been filed in
 the Apache Software Foundation records.

 If you have been voted in as a committer, please advise the project PMC
 that your ICLA has been filed.

 Warm Regards,

 Craig L Russell
 Secretary, Apache Software Foundation






-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Camel 2.8.2 - Reason for the many backports?

[Claus Ibsen]

Hi

Dan what is the reason why you backport so many commits to 2.8.2 from 2.9?

The problem is that its a lot of new features, non trivial bug fixes
and whatnot.
People then may not have a safe upgrade from 2.8.0 / 2.8.1 to 2.8.2
because of the big difference.
People is more prepared for a little trouble when doing 2.8.0 to 2.9.0
upgrade. But not for an upgrade in 2.8.x branch.

Also for new features and whatnot we update the documentation to
indicate eg *Camel 2.9* that
this is a new feature in that version. These documentation changes is
not part of the SVN and thus
you lose this, and cannot keep the documentation - source code in sync.




-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Camel 2.8.2 - Reason for the many backports?

[Claus Ibsen]

Hi Dan

Do you care to discuss this?

You keep on backporting non bug fixes, new features and whatnot.

People who run Camel in production and they may want to upgrade to
2.8.2 due to a bug.
They frankly do not like a lot of changes. As any change in a
production system is not desireable.

So the gap from 2.8.0, 2.8.1 to 2.8.2 is now very big. This is not desireable.



On Tue, Sep 20, 2011 at 8:11 AM, Claus Ibsen claus.ib...@gmail.com wrote:
 Hi

 Dan what is the reason why you backport so many commits to 2.8.2 from 2.9?

 The problem is that its a lot of new features, non trivial bug fixes
 and whatnot.
 People then may not have a safe upgrade from 2.8.0 / 2.8.1 to 2.8.2
 because of the big difference.
 People is more prepared for a little trouble when doing 2.8.0 to 2.9.0
 upgrade. But not for an upgrade in 2.8.x branch.

 Also for new features and whatnot we update the documentation to
 indicate eg *Camel 2.9* that
 this is a new feature in that version. These documentation changes is
 not part of the SVN and thus
 you lose this, and cannot keep the documentation - source code in sync.




 --
 Claus Ibsen
 -
 FuseSource
 Email: cib...@fusesource.com
 Web: http://fusesource.com
 Twitter: davsclaus, fusenews
 Blog: http://davsclaus.blogspot.com/
 Author of Camel in Action: http://www.manning.com/ibsen/




-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Camel netty encode bug

[Claus Ibsen]

Hi

Its best to use the @user mailing list.

Anyway what version of Camel are you using?


On Wed, Sep 21, 2011 at 9:01 AM, stenver stenver1...@gmail.com wrote:
 we tried to set up a custom encoder with netty tcp.

 Here was our encoder class, for testing:

 @Component(EndOfLineEncoder)
 public class EndOfLineEncoder extends OneToOneEncoder{

    @Override
    protected Object encode(ChannelHandlerContext channelHandlerContext,
            Channel channel, Object msg) throws Exception {

        return msg;
    }

 }

 Here was our routing:

        from(stream:in)
            .to(log:response)

 .to(netty:tcp://localhost:10121?sync=trueencoder=#EndOfLineEncoder)
            .to(log:response);


 We tried to debug this problem for yours. We finally found out, that it
 works, if we change encoder to encoders:

 .to(netty:tcp://localhost:10121?sync=trueencoders=#EndOfLineEncoder)

 So i guess it may be a bug - it is a single encoder, but it doesnt work if
 we use encoder command.


 --
 View this message in context: 
 http://camel.465427.n5.nabble.com/Camel-netty-encode-bug-tp4825369p4825369.html
 Sent from the Camel Development mailing list archive at Nabble.com.




-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Camel 2.8.2 - Reason for the many backports?

[Claus Ibsen]

On Thu, Sep 22, 2011 at 4:08 AM, Christian Müller
christian.muel...@gmail.com wrote:
 May I miss something, but at the moment it's not really clear for me WHAT
 should be backported.

Me too.

 Do we backport EVERYTHING which doesn't break existing code (not only bugs)?
 Also new features and enhancements with the risk of introducing new bugs?
 Only to make it clear for me and may others...

I would not favor that as new code may introduce new bugs and other
side effects.
I would rather allow people to have a stable branch where bug fixes is
the primary reason for backporting.

There may be good reasons to backport a non-bug ticket, but then we
ought to be more careful when doing this.
For example I think the Karaf team discuss this on @dev which tickets
to backport.





 And by Awesome! - thanks Dan
 On 21 Sep 2011, at 15:23, Daniel Kulp wrote:

 On Wednesday, September 21, 2011 2:53:49 PM Rob Davies wrote:
 For my part it is the principle - at some point this will go wrong -
 doing
 what Chistian suggested makes a lot of sense. And, users in production
 want
 stability, fixes are good, new features leads naturally to concern about
 stability. It should be good practice to give a heads up at least,
 before
 backporting new features.

 I agree that I should have given a better hey, ton of stuff going to
 happen
 heads up Monday morning (or Friday).

 That said, I had complete intention after 2.8.0 was released to try and
 port
 things back more on a weekly basis or so. That makes things a LOT easier
 to
 do. Reviewing 380+ commits in one day is really not fun. :-) I've just
 been quite a bit busy on other things that the Camel porting kept falling
 off
 the bottom of my weekly todo list. :-(

 Going forward, I'm hoping to keep being able to port fixes and such back
 on a
 semi-weekly basis (+/- a little bit) much like I do for CXF. Obviously,
 any
 help from anyone else would be greatly appreciated. In CXF, over time,
 I've
 gotten more help from Sergey and Willem and Freeman and others and I
 greatly
 appreciate their efforts. I've seen Claus and Jon and others pulling
 things
 back here as well which is definitely appreciated.


 Dan


 On 21 Sep 2011, at 14:33, Hadrian Zbarcea wrote:
 This is an emotional non-discussion. The question in the title is what
 is the reason for the *many* backports. An explanation was also given:
 if they are *many* bugs (or improvements), they should be fixed, and in
 dkulp's opinion not only on the trunk but also on the maintained
 branches. There is also an expectation for the fixes to be backwards
 compatible, which is absolutely normal. From what I see the expectation
 was fulfilled.

 Rob seems to imply that he trusts Dan to do the right thing, but he's
 concerned about the precedent he sets for the less talented rest of us
 who might go wild and break things.

 Did I get it right? Is there a particular commit that triggered this
 question, or is more the principle?

 Hadrian

 On 09/21/2011 01:36 AM, Rob Davies wrote:
 Dan it admirable what you want to do but it would be better to
 encourage collective best practice - so we do not break backward
 compatibility on a released branch. That's why discussing adding new
 features, or changes to dependencies on the DEV list first is a good
 idea. it will set the pattern that others will follow. Its not that
 we expect that you will break anything, but others might do by
 accident.
 On 21 Sep 2011, at 04:08, Daniel Kulp wrote:
 On Tuesday, September 20, 2011 7:20:20 PM Claus Ibsen wrote:
 Hi Dan

 Do you care to discuss this?

 You keep on backporting non bug fixes, new features and whatnot.

 People who run Camel in production and they may want to upgrade to
 2.8.2 due to a bug.
 They frankly do not like a lot of changes. As any change in a
 production system is not desireable.

 And there are even more people that are trying to move their
 applications from development into testing or production and cannot
 because they are hitting specific bugs or require some trivial
 features or issues to be resolved.

 If a user reports a bug (and even better, provides a patch), we
 definitely owe it to them to get that fix pulled back relatively
 quickly. Camel has historically done a VERY poor job of doing
 that. I keep talking to people that have either had to fork Camel
 internally to get patches applied or go to a third party to demand
 various things ported back. In both cases, I just cringe as
 that shows that we, as a community, have failed our users.

 Likewise, if a user needs a trivial change in order to get Camel
 into
 production, we should try and get that change to them WITHOUT a huge
 upgrade hassle. Things like new methods, new config options (as
 long as the defaults remain as before), etc... that would have no
 impact on existing users, but makes it possible to use Camel by a
 wider audience.

 So the gap from 2.8.0, 2.8.1 to 2.8.2 is now very big. This is not
 desireable.

 Compared to any CXF patch release, it's

Re: Camel 2.8.2 - Reason for the many backports?

[Claus Ibsen]

On Thu, Sep 22, 2011 at 4:17 AM, Johan Edstrom seij...@gmail.com wrote:
 I'll step in here…

 Much of what Dan has done is in the corporate world very very much wanted.
 Dan offered his time to keep on back porting fixing and non api breaking 
 features.


Dan is not the only person doing this. We are already backporting to
the 2.8 branch. Also after the 2.8.1 release.

Well there were some API breakings in there, however on the small side
as they face internally,
but still. Some commits wasn't necessary to backport as they cases
these minor/micro API changes.


 That means we'll see (and we can debate that) done in 2.9, available in 
 2.8.5)

 I think Dan already said he should have said more of a hey, debating if we 
 need this is
 going to go in the insane bin, most customers I work with complain about the 
 lack of a
 stable train that provides fixes with no upgrades….


The 2.8.2 would have become more stable if there was not backported
soo many changes.


 /je

 On Sep 21, 2011, at 8:08 PM, Christian Müller wrote:

 May I miss something, but at the moment it's not really clear for me WHAT
 should be backported.
 Do we backport EVERYTHING which doesn't break existing code (not only bugs)?
 Also new features and enhancements with the risk of introducing new bugs?
 Only to make it clear for me and may others...

 And by Awesome! - thanks Dan
 On 21 Sep 2011, at 15:23, Daniel Kulp wrote:

 On Wednesday, September 21, 2011 2:53:49 PM Rob Davies wrote:
 For my part it is the principle - at some point this will go wrong -
 doing
 what Chistian suggested makes a lot of sense. And, users in production
 want
 stability, fixes are good, new features leads naturally to concern about
 stability. It should be good practice to give a heads up at least,
 before
 backporting new features.

 I agree that I should have given a better hey, ton of stuff going to
 happen
 heads up Monday morning (or Friday).

 That said, I had complete intention after 2.8.0 was released to try and
 port
 things back more on a weekly basis or so. That makes things a LOT easier
 to
 do. Reviewing 380+ commits in one day is really not fun. :-) I've just
 been quite a bit busy on other things that the Camel porting kept falling
 off
 the bottom of my weekly todo list. :-(

 Going forward, I'm hoping to keep being able to port fixes and such back
 on a
 semi-weekly basis (+/- a little bit) much like I do for CXF. Obviously,
 any
 help from anyone else would be greatly appreciated. In CXF, over time,
 I've
 gotten more help from Sergey and Willem and Freeman and others and I
 greatly
 appreciate their efforts. I've seen Claus and Jon and others pulling
 things
 back here as well which is definitely appreciated.


 Dan


 On 21 Sep 2011, at 14:33, Hadrian Zbarcea wrote:
 This is an emotional non-discussion. The question in the title is what
 is the reason for the *many* backports. An explanation was also given:
 if they are *many* bugs (or improvements), they should be fixed, and in
 dkulp's opinion not only on the trunk but also on the maintained
 branches. There is also an expectation for the fixes to be backwards
 compatible, which is absolutely normal. From what I see the expectation
 was fulfilled.

 Rob seems to imply that he trusts Dan to do the right thing, but he's
 concerned about the precedent he sets for the less talented rest of us
 who might go wild and break things.

 Did I get it right? Is there a particular commit that triggered this
 question, or is more the principle?

 Hadrian

 On 09/21/2011 01:36 AM, Rob Davies wrote:
 Dan it admirable what you want to do but it would be better to
 encourage collective best practice - so we do not break backward
 compatibility on a released branch. That's why discussing adding new
 features, or changes to dependencies on the DEV list first is a good
 idea. it will set the pattern that others will follow. Its not that
 we expect that you will break anything, but others might do by
 accident.
 On 21 Sep 2011, at 04:08, Daniel Kulp wrote:
 On Tuesday, September 20, 2011 7:20:20 PM Claus Ibsen wrote:
 Hi Dan

 Do you care to discuss this?

 You keep on backporting non bug fixes, new features and whatnot.

 People who run Camel in production and they may want to upgrade to
 2.8.2 due to a bug.
 They frankly do not like a lot of changes. As any change in a
 production system is not desireable.

 And there are even more people that are trying to move their
 applications from development into testing or production and cannot
 because they are hitting specific bugs or require some trivial
 features or issues to be resolved.

 If a user reports a bug (and even better, provides a patch), we
 definitely owe it to them to get that fix pulled back relatively
 quickly. Camel has historically done a VERY poor job of doing
 that. I keep talking to people that have either had to fork Camel
 internally to get patches applied or go to a third party to demand
 various things ported back. In both cases, I just

Re: Camel 2.8.2 - Reason for the many backports?

[Claus Ibsen]

On Wed, Sep 21, 2011 at 4:23 PM, Daniel Kulp dk...@apache.org wrote:
 On Wednesday, September 21, 2011 2:53:49 PM Rob Davies wrote:
 For my part it is the principle - at some point this will go wrong - doing
 what Chistian suggested makes a lot of sense. And, users in production want
 stability, fixes are good, new features leads naturally to concern about
 stability. It should be good practice to give a heads up at least, before
 backporting new features.

 I agree that I should have given a better hey, ton of stuff going to happen
 heads up Monday morning (or Friday).


Thanks. We are not accustomed to see 70-100 backports on the 2.x
branch overnight.
So we were wonder what happened. If some auto tool have been enabled or whatnot?


 That said, I had complete intention after 2.8.0 was released to try and port
 things back more on a weekly basis or so.   That makes things a LOT easier to
 do.   Reviewing 380+ commits in one day is really not fun.  :-)     I've just
 been quite a bit busy on other things that the Camel porting kept falling off
 the bottom of my weekly todo list.    :-(


I think its better to have the person who worked on the ticket
backport the ticket.
For example as myself, Willem and some others already do. After the
changes is committed
to trunk, we take time to backport it as well.

The reason is that we know best if that ticket would be good to packport or not.
Going forward, it may be a good idea to put a note in the JIRA ticket
if the ticket is not ideal to backport.



 Going forward, I'm hoping to keep being able to port fixes and such back on a
 semi-weekly basis (+/- a little bit) much like I do for CXF.    Obviously, any
 help from anyone else would be greatly appreciated.   In CXF, over time, I've
 gotten more help from Sergey and Willem and Freeman and others and I greatly
 appreciate their efforts.   I've seen Claus and Jon and others pulling things
 back here as well which is definitely appreciated.


Good idea, but see above. We should do both. Have the habit of
backport the change at the same
time you commit to trunk. Then its fresh in memory and we get it done
at the best time.

Having a semi-weekly basis as well, helps make sure we catch tickets
which for some reason wasn't,
or there has come up good cause to backport some tickets etc.



 Dan


 On 21 Sep 2011, at 14:33, Hadrian Zbarcea wrote:
  This is an emotional non-discussion. The question in the title is what
  is the reason for the *many* backports. An explanation was also given:
  if they are *many* bugs (or improvements), they should be fixed, and in
  dkulp's opinion not only on the trunk but also on the maintained
  branches. There is also an expectation for the fixes to be backwards
  compatible, which is absolutely normal. From what I see the expectation
  was fulfilled.
 
  Rob seems to imply that he trusts Dan to do the right thing, but he's
  concerned about the precedent he sets for the less talented rest of us
  who might go wild and break things.
 
  Did I get it right? Is there a particular commit that triggered this
  question, or is more the principle?
 
  Hadrian
 
  On 09/21/2011 01:36 AM, Rob Davies wrote:
  Dan it admirable what you want to do but it would be better to
  encourage collective best practice - so we do not break backward
  compatibility on a released branch. That's why discussing adding new
  features, or changes to dependencies on the DEV list first is a good
  idea. it will set the pattern that others will follow. Its not that
  we expect that you will break anything, but others might do by
  accident.
  On 21 Sep 2011, at 04:08, Daniel Kulp wrote:
  On Tuesday, September 20, 2011 7:20:20 PM Claus Ibsen wrote:
  Hi Dan
 
  Do you care to discuss this?
 
  You keep on backporting non bug fixes, new features and whatnot.
 
  People who run Camel in production and they may want to upgrade to
  2.8.2 due to a bug.
  They frankly do not like a lot of changes. As any change in a
  production system is not desireable.
 
  And there are even more people that are trying to move their
  applications from development into testing or production and cannot
  because they are hitting specific bugs or require some trivial
  features or issues to be resolved.
 
  If a user reports a bug (and even better, provides a patch), we
  definitely owe it to them to get that fix pulled back relatively
  quickly.   Camel has historically done a VERY poor job of doing
  that.  I keep talking to people that have either had to fork Camel
  internally to get patches applied or go to a third party to demand
  various things ported back.     In both cases, I just cringe as
  that shows that we, as a community, have failed our users.
 
  Likewise, if a user needs a trivial change in order to get Camel
  into
  production, we should try and get that change to them WITHOUT a huge
  upgrade hassle.   Things like new methods, new config options (as
  long as the defaults remain as before), etc...  that would have

Merging to Camel 2.7 branch issue

[Claus Ibsen]

Hi

I am in need to backport CAMEL-3962 to the Camel 2.7 branch.

The commit has svn rev: 1124595

But when I check the svnmerge.py avail list, then that commit number
is not in that range.


davsclaus:(svn)camel-2.7[camel-2.7.x:1174069]/$ svn info
Path: .
URL: https://svn.apache.org/repos/asf/camel/branches/camel-2.7.x
Repository Root: https://svn.apache.org/repos/asf

So when I run
svnmerge.py merge -r 1124595

It cannot merge that fix to the 2.7 branch.

I know some of you guys are svnmerge.py experts, and maybe can check it out.


-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Merging to Camel 2.7 branch issue

[Claus Ibsen]

On Thu, Sep 22, 2011 at 3:25 PM, Jon Anstey jans...@gmail.com wrote:
 Hmm.. looks like the svnmerge metadata is messed up. First off the 2.7
 branch is set up to merge from the 2.8 branch. Next, it says all revs from
 1-1146127 are merged in - which isn't the case for sure. I've merged this
 fix manually for you... not sure the best way to fix this up...


Thanks Jon.

Yeah that seems messed up. We should be looking into backport some of
the important issues we have found
recently which may also affect the 2.7 branch.



 On Thu, Sep 22, 2011 at 9:29 AM, Claus Ibsen claus.ib...@gmail.com wrote:

 Hi

 I am in need to backport CAMEL-3962 to the Camel 2.7 branch.

 The commit has svn rev: 1124595

 But when I check the svnmerge.py avail list, then that commit number
 is not in that range.


 davsclaus:(svn)camel-2.7[camel-2.7.x:1174069]/$ svn info
 Path: .
 URL: https://svn.apache.org/repos/asf/camel/branches/camel-2.7.x
 Repository Root: https://svn.apache.org/repos/asf

 So when I run
 svnmerge.py merge -r 1124595

 It cannot merge that fix to the 2.7 branch.

 I know some of you guys are svnmerge.py experts, and maybe can check it
 out.


 --
 Claus Ibsen
 -
 FuseSource
 Email: cib...@fusesource.com
 Web: http://fusesource.com
 Twitter: davsclaus, fusenews
 Blog: http://davsclaus.blogspot.com/
 Author of Camel in Action: http://www.manning.com/ibsen/




 --
 Cheers,
 Jon
 ---
 FuseSource
 Email: j...@fusesource.com
 Web: fusesource.com
 Twitter: jon_anstey
 Blog: http://janstey.blogspot.com
 Author of Camel in Action: http://manning.com/ibsen




-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Merging to Camel 2.7 branch issue

[Claus Ibsen]

On Thu, Sep 22, 2011 at 3:42 PM, Daniel Kulp dk...@apache.org wrote:
 On Thursday, September 22, 2011 10:55:58 AM Jon Anstey wrote:
 Hmm.. looks like the svnmerge metadata is messed up. First off the 2.7
 branch is set up to merge from the 2.8 branch.

 That part is correct.    Fixes flow from trunk to the first branch to the next
 branch       2.7.x is much closer (architecturally and API's and such)
 to 2.8 than trunk so the flow of fixes is easier to go that way.


Ah okay.
I guess this can make sense as we are most likely to backport fixes to
2.7 which has recently been fixed.
And the case I needed to backport is actually old (I think from May
2011), so that is like 4 months.



 Next, it says all revs from
 1-1146127 are merged in - which isn't the case for sure. I've merged this
 fix manually for you... not sure the best way to fix this up...

 I noticed this when I was working on merging stuff for 2.7.3.  I think
 svnmerge.py init messed something up when trying to figure out what version
 the branch came from.   I'm also not sure how to best fix it.  :-(    We could
 figure out the revision of the 2.7.0 release, re-initialize the
 svnmerge:integrated stuff based on that, and then walk through the hundreds of
 commits to double check.    Not ideal and would take some time.


 For the most part, you can svnmerge.py rollback -M -r 1124595 to mark it as
 not integrated and then rerun the svnmerge.py merge.


I guess we can leave it as is? And chances are we are merging recent
bug fixes back to the 2.7 branch?


 Dan




 On Thu, Sep 22, 2011 at 9:29 AM, Claus Ibsen claus.ib...@gmail.com wrote:
  Hi
 
  I am in need to backport CAMEL-3962 to the Camel 2.7 branch.
 
  The commit has svn rev: 1124595
 
  But when I check the svnmerge.py avail list, then that commit number
  is not in that range.
 
 
  davsclaus:(svn)camel-2.7[camel-2.7.x:1174069]/$ svn info
  Path: .
  URL: https://svn.apache.org/repos/asf/camel/branches/camel-2.7.x
  Repository Root: https://svn.apache.org/repos/asf
 
  So when I run
  svnmerge.py merge -r 1124595
 
  It cannot merge that fix to the 2.7 branch.
 
  I know some of you guys are svnmerge.py experts, and maybe can check it
  out.
 
 
  --
  Claus Ibsen
  -
  FuseSource
  Email: cib...@fusesource.com
  Web: http://fusesource.com
  Twitter: davsclaus, fusenews
  Blog: http://davsclaus.blogspot.com/
  Author of Camel in Action: http://www.manning.com/ibsen/
 --
 Daniel Kulp
 dk...@apache.org
 http://dankulp.com/blog
 Talend - http://www.talend.com




-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Camel 2.8.2 - Reason for the many backports?

[Claus Ibsen]

Hi

I gave the DoMerges tool a try and it worked fine.

However as my svnmerge.py python script causes some UTF-8 error after
the merge is done, the DoMerges tool breaks
after one merge.

I tried downloading the latest svnerge.py file from the official
source but it fails as well.
I guess I need to find an older svnmerge.py file that dont fail at the end.

If anyone got a .py file working, then feel free to attach on a mail
and send to me, or this @dev.




On Thu, Sep 22, 2011 at 3:34 PM, Daniel Kulp dk...@apache.org wrote:
 On Thursday, September 22, 2011 7:45:28 AM Claus Ibsen wrote:
 On Wed, Sep 21, 2011 at 4:23 PM, Daniel Kulp dk...@apache.org wrote:
  I agree that I should have given a better hey, ton of stuff going to
  happen heads up Monday morning (or Friday).

 Thanks. We are not accustomed to see 70-100 backports on the 2.x
 branch overnight.
 So we were wonder what happened. If some auto tool have been enabled or
 whatnot?

 I really hate to point this out as it's a bit of an embarrassment to me, but
 since you mentioned it...

 If you look in:
 http://svn.apache.org/repos/asf/cxf/trunk/bin/

 there is a DoMerges.java file in there that you can compile and run from a
 fixes branch checkout..    It pretty much walks you through the entire process
 of backporting fixes.   It lists all the outstanding commits that haven't been
 reviewed, allows you to [M]erge commits individually,  [B]lock commits
 (reviewed and shouldn't be merged back), show the diffs, etc.   Glen added
 some good comment to the top of it a couple weeks ago.    For the most part,
 it's quite easy to walk through a bunch of commits and merge things back with
 it.   Takes very little time.   (one enhancement I plan to add is to have it
 print the URL to the viewvc for the commit and the full URL to the JIRA if
 there is one mentioned.   Little easier than the pure diffs.)     In anycase,
 while not a complete auto tool that was used, it isn't hard to go through a
 lot of commits.

 Why is it embarrassing to me?   Well, it's a silly little Java program that is
 doing the job of something SHOULD have been written in python or perl or even
 bash.    I'll readily admit that.  Best tool for the job was definitely not
 applied here.


 --
 Daniel Kulp
 dk...@apache.org
 http://dankulp.com/blog
 Talend - http://www.talend.com




-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

[DISCUSS] - Trunk as Camel 3.0

[Claus Ibsen]

Hi

I would like to propose that Camel source code currently on trunk is
to be Camel 3.0.0.
And the current code on the 2.8.x branch is to be used for the 2.x
lifetime of Camel.

The reason for this can be summarized as:
1) All the API changes on trunk, and still to be done API changes
2) Preserve Camel 2.x API stability
3) Camel 2.x continue as usual
4) Camel 2.x is already 2+ years old.
5) The community would expect work on Camel 3.0 starting soon.


By letting the trunk code be targeted for Camel 3.0.0, we open the
ability to refactor the API more freely,
and without causing trouble for our large group of 2.x Camel users,
who are not expecting API changes in the camel-core at all.

Likewise the latest merges on the 2.8.x branch is already including
new features and other improvements,
which is a good offset for Camel 2.9.0. We can of course backport the
missings from trunk such as:
new components, and other improvements, new features, which we think
is worthwhile
and that the community would like to have in the Camel 2.9 release.



-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: [DISCUSS] - Trunk as Camel 3.0

[Claus Ibsen]

On Fri, Sep 23, 2011 at 1:36 PM, Christian Schneider
ch...@die-schneider.net wrote:
 Hi Claus,

 we could do this but it would mean that all the compatibility measures I put
 in place are in vain.


Its not in vain. Because when the API in Camel 3.0 is becoming clear
to us that this is what we want.
I guess many of the changes you have done, is already clear and a good
step in the right direction.

Anyway what I say is that the pieces of the API which are going to be
like that for Camel 3.0, we can then
add @deprecated in the 2.x code. And put in code from 3.0 as
replacement for the old @deprecated code.
We should of course do this with care, so the 2.x codebase can be run
fine as is, or fine if some end users start using the replaced API.

That means the 2.x codebase is fully API backwards compatible and
people can safely use their existing 3rd party Camel components,
interceptors,
any other other SPI adapters and whatnot they may have developed.

There are also commercial vendors (not FuseSource) who does byte code
instrumentation on the current API,
which is now broken on trunk (one example would be the DefaultChannel
class is moved).
And you cannot blame them as the API in camel-core is open and
available in the JAR file.


 As far as I understand it we want to remove all @Deprecated stuff in camel
 3.0. That means that people will have a quite incompatible update if we do
 not prepare well for it.


Well we want for sure to remove the @deprecated stuff that has been
marked as @deprecated in the current 2.8.0 release.

In terms of removing additional @deprecated stuff, I think we should
do what makes the best for the community.
I am sure many pieces can be removed asap, others may take 6 months
etc. Its really whats best for the community.

Or maybe it would be possible for Camel 3.0.0 to create a camel-legacy
(find a better name for the JAR) which is an adapter
to make using Camel 2.x components/interceptors/SPI stuff and whatnot
possible to run with the new Camel 3.0 API.


 So my strategy is to create these compatibility stubs of old classes that
 allow people a smooth transition. Of course this only works if a release is
 made that
 contains the old and the new classes so people can slowly migrate. If we do
 not release a 2.9.0 with the current trunk contents we will make it much
 more difficult for people.

 Of course we could also do a 3.0 release with the @Deprecated in place and
 remove them in 3.1 but then 3.1 would be the real major release ... so I am
 not sure this would be a good idea.


Another goal for Camel 3.0.0 with the API changes would be that we can
formalize the API officially.

We can then split up the core into smaller pieces, and have a
camel-api JAR (or whatever a good name could be )
which has the end user API. Then from Camel 3.0.0 onwards we have a
much better platform to keep a good and stable API for the
large and growing Camel community.




 Christian


 Am 23.09.2011 13:13, schrieb Claus Ibsen:

 Hi

 I would like to propose that Camel source code currently on trunk is
 to be Camel 3.0.0.
 And the current code on the 2.8.x branch is to be used for the 2.x
 lifetime of Camel.

 The reason for this can be summarized as:
 1) All the API changes on trunk, and still to be done API changes
 2) Preserve Camel 2.x API stability
 3) Camel 2.x continue as usual
 4) Camel 2.x is already 2+ years old.
 5) The community would expect work on Camel 3.0 starting soon.


 By letting the trunk code be targeted for Camel 3.0.0, we open the
 ability to refactor the API more freely,
 and without causing trouble for our large group of 2.x Camel users,
 who are not expecting API changes in the camel-core at all.

 Likewise the latest merges on the 2.8.x branch is already including
 new features and other improvements,
 which is a good offset for Camel 2.9.0. We can of course backport the
 missings from trunk such as:
 new components, and other improvements, new features, which we think
 is worthwhile
 and that the community would like to have in the Camel 2.9 release.




 --
 Christian Schneider
 http://www.liquid-reality.de

 Open Source Architect
 http://www.talend.com





-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Camel 2.8.2 - Reason for the many backports?

[Claus Ibsen]

Hi

I managed to find an old copy of the svnmerge.py that works.
However its about 20kb smaller than the latest from the trunk. And the
file from Dan Kulp.
69987 Sep 23 14:16 svnmerge.py
90590 Sep 23 14:12 svnmerge.py.dkulp

I have attached the file that works on my mac laptop.

I also set my LANG to UTF-8 as follows
export LANG=en_US.UTF-8
export LC_ALL=en_US.UTF-8

That didn't work with the latest svnmerge.py files.
So the old file attached may work without these LANG changes.

Dan pointed to me from this link
http://groups.google.com/group/spyderlib/browse_thread/thread/299e11c6e677b277





On Thu, Sep 22, 2011 at 7:02 PM, Daniel Kulp dk...@apache.org wrote:
 On Thursday, September 22, 2011 6:44:42 PM Claus Ibsen wrote:
 Hi

 I gave the DoMerges tool a try and it worked fine.

 However as my svnmerge.py python script causes some UTF-8 error after
 the merge is done, the DoMerges tool breaks
 after one merge.

 I tried downloading the latest svnerge.py file from the official
 source but it fails as well.
 I guess I need to find an older svnmerge.py file that dont fail at the end.

 If anyone got a .py file working, then feel free to attach on a mail
 and send to me, or this @dev.


 I've attached mine.   What kind of error were you getting?     Does it fail
 outside the tool as well?

 What is your LANG env variable set to?


 Dan






 On Thu, Sep 22, 2011 at 3:34 PM, Daniel Kulp dk...@apache.org wrote:
  On Thursday, September 22, 2011 7:45:28 AM Claus Ibsen wrote:
  On Wed, Sep 21, 2011 at 4:23 PM, Daniel Kulp dk...@apache.org wrote:
   I agree that I should have given a better hey, ton of stuff going
   to
   happen heads up Monday morning (or Friday).
 
  Thanks. We are not accustomed to see 70-100 backports on the 2.x
  branch overnight.
  So we were wonder what happened. If some auto tool have been enabled
  or
  whatnot?
 
  I really hate to point this out as it's a bit of an embarrassment to me,
  but since you mentioned it...
 
  If you look in:
  http://svn.apache.org/repos/asf/cxf/trunk/bin/
 
  there is a DoMerges.java file in there that you can compile and run from
  a fixes branch checkout..    It pretty much walks you through the
  entire process of backporting fixes.   It lists all the outstanding
  commits that haven't been reviewed, allows you to [M]erge commits
  individually,  [B]lock commits (reviewed and shouldn't be merged back),
  show the diffs, etc.   Glen added some good comment to the top of
  it a couple weeks ago.    For the most part, it's quite easy to walk
  through a bunch of commits and merge things back with it.   Takes very
  little time.   (one enhancement I plan to add is to have it print the
  URL to the viewvc for the commit and the full URL to the JIRA if there
  is one mentioned.   Little easier than the pure diffs.)     In anycase,
  while not a complete auto tool that was used, it isn't hard to go
  through a lot of commits.
 
  Why is it embarrassing to me?   Well, it's a silly little Java program
  that is doing the job of something SHOULD have been written in python
  or perl or even bash.    I'll readily admit that.  Best tool for the
  job was definitely not applied here.
 
 
  --
  Daniel Kulp
  dk...@apache.org
  http://dankulp.com/blog
  Talend - http://www.talend.com
 --
 Daniel Kulp
 dk...@apache.org
 http://dankulp.com/blog
 Talend - http://www.talend.com



-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Camel 2.8.2 - Reason for the many backports?

[Claus Ibsen]

On Fri, Sep 23, 2011 at 1:26 AM, Christian Müller
christian.muel...@gmail.com wrote:
 See my notes inline

 Christian
 Am 22.09.2011 13:43 schrieb Christian Müller christian.muel...@gmail.com
:

 Now it's a bit more clearer, but not totally.

 IMO, we only backported bugs and dependency changes which are bugfix
 versions in the past. With Camel 2.8.2, we backported much more - mostly
 all. I've expected a [DISCUSS] about this - not only a [HEADS UP]. I'm sure
 Dan has good reasons for this, but it shoud be discussed first.

 We backported mostly all changes (which doesn't break users existing code)
 into the 2.8 branch, but only a few changes into the 2.7 branch. Why? As
 Hadrian mentioned in the board report, the 2.7 branch is still in
 maintenance.

 When I'm back, I will add a WIKI page which describes our development
 process/policy for backporting changes.

 Also how to do it with the mentioned Java/Python scripts, as we have it done
 with our release step-by-step guide. I didn't know these scripts and nobody
 told me about their existence. I was not able to find a WIKI page about it
 (with my mobile phone ;-) ). I could imagine, I'm not the only one...


Yeah now that I got the tooling on my laptop working I would like to
add some notes in our wiki
how to do this.

Its going to be added somewhere here, as a sub page:
http://camel.apache.org/developers.html

There should also be a .exe of the svnmerge so its easy for windows
users to run it.



 Thanks in advance for clarification,
 Christian

 Sent from a mobile device

 Am 22.09.2011 10:12 schrieb Guillaume Nodet gno...@gmail.com:

  Fwiw, git-svn could be handy too ... as merges are really easy with git.
 
  On Thu, Sep 22, 2011 at 19:02, Daniel Kulp dk...@apache.org wrote:
 
  On Thursday, September 22, 2011 6:44:42 PM Claus Ibsen wrote:
   Hi
  
   I gave the DoMerges tool a try and it worked fine.
  
   However as my svnmerge.py python script causes some UTF-8 error after
   the merge is done, the DoMerges tool breaks
   after one merge.
  
   I tried downloading the latest svnerge.py file from the official
   source but it fails as well.
   I guess I need to find an older svnmerge.py file that dont fail at
 the
  end.
  
   If anyone got a .py file working, then feel free to attach on a mail
   and send to me, or this @dev.
 
 
  I've attached mine. What kind of error were you getting? Does it fail
  outside the tool as well?
 
  What is your LANG env variable set to?
 
 
  Dan
 
 
 
 
 
  
   On Thu, Sep 22, 2011 at 3:34 PM, Daniel Kulp dk...@apache.org
 wrote:
On Thursday, September 22, 2011 7:45:28 AM Claus Ibsen wrote:
On Wed, Sep 21, 2011 at 4:23 PM, Daniel Kulp dk...@apache.org
  wrote:
 I agree that I should have given a better hey, ton of stuff
 going
 to
 happen heads up Monday morning (or Friday).
   
Thanks. We are not accustomed to see 70-100 backports on the 2.x
branch overnight.
So we were wonder what happened. If some auto tool have been
 enabled
or
whatnot?
   
I really hate to point this out as it's a bit of an embarrassment
 to
  me,
but since you mentioned it...
   
If you look in:
http://svn.apache.org/repos/asf/cxf/trunk/bin/
   
there is a DoMerges.java file in there that you can compile and run
  from
a fixes branch checkout.. It pretty much walks you through the
entire process of backporting fixes. It lists all the outstanding
commits that haven't been reviewed, allows you to [M]erge commits
individually, [B]lock commits (reviewed and shouldn't be merged
 back),
show the diffs, etc. Glen added some good comment to the top of
it a couple weeks ago. For the most part, it's quite easy to walk
through a bunch of commits and merge things back with it. Takes
 very
little time. (one enhancement I plan to add is to have it print the
URL to the viewvc for the commit and the full URL to the JIRA if
 there
is one mentioned. Little easier than the pure diffs.) In anycase,
while not a complete auto tool that was used, it isn't hard to go
through a lot of commits.
   
Why is it embarrassing to me? Well, it's a silly little Java
 program
that is doing the job of something SHOULD have been written in
 python
or perl or even bash. I'll readily admit that. Best tool for the
job was definitely not applied here.
   
   
--
Daniel Kulp
dk...@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
  --
  Daniel Kulp
  dk...@apache.org
  http://dankulp.com/blog
  Talend - http://www.talend.com
 
 
 
 
  --
  
  Guillaume Nodet
  
  Blog: http://gnodet.blogspot.com/
  
  Open Source SOA
  http://fusesource.com




-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http

Re: Camel 2.8.2 - Reason for the many backports?

[Claus Ibsen]

 Also how to do it with the mentioned Java/Python scripts, as we have it done
 with our release step-by-step guide. I didn't know these scripts and nobody
 told me about their existence. I was not able to find a WIKI page about it
 (with my mobile phone ;-) ). I could imagine, I'm not the only one...


 Yeah now that I got the tooling on my laptop working I would like to
 add some notes in our wiki
 how to do this.

 Its going to be added somewhere here, as a sub page:
 http://camel.apache.org/developers.html

 There should also be a .exe of the svnmerge so its easy for windows
 users to run it.

We already had a wiki page, so I have improved it. And added notes
about the DoMerges tool
https://cwiki.apache.org/confluence/display/CAMEL/Merging+commits+from+trunk+to+fixes+branch

Re: Camel 2.8.2 - Reason for the many backports?

[Claus Ibsen]

On Sat, Sep 24, 2011 at 7:34 PM, Christian Müller
christian.muel...@gmail.com wrote:
 Hello Claus!

 Thank you for your work updating the WIKI page. I didn't know them...


Yeah there is some good to know wiki pages for Camel team members here
http://camel.apache.org/developers.html


 But I have to stress this topic a bit more, because I still have open
 questions:
 1) Is it a problem when different committers use different merge tools (the
 Java program, the Python script, simply Git, ...)?

Dan already explained. For windows users you may use cygwin or some
unix emulator to be able to run the python script.
Or maybe adjust the source code in DoMerges.java and have it invoked
the windows .exe port of the svnmerge.py.

 2) What is our policy about backporting issues (only bugs, dependency
 upgrades for bug fix versions, improvements, new features, dependency
 upgrades which are not bug fix versions, ...)?

It ought to be bug fixes only, with zero dependency upgrades. However
there could be just cause to upgrade
a dependency due to a security fix, or very important bug fixes in a dependency.
For example Apache CXF has many bugs in recent releases which gets fixed.
(eg CXF 2.4.2 have 59 bug fixes -
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+CXF+AND+fixVersion+%3D+%222.4.2%22+ORDER+BY+issuetype+ASC%2C+key+DESC)

At Apache Camel we did that for Camel 2.8.1 release.
However the current state of 2.8.2 is unfortunately not following that practice.

There seems to be backported *too* many commits.
For example the state of 2.8.2, even include commits which was
*deliberately* omitted for the 2.8.1. Granted the svnmerge.py should
possible have some of those tickets set as blocked. But the commits
was done without any prior heads-up. The offset ought to have started
from 2.8.1 release and then the changes since. But the offset was
started from the Camel 2.8.0 release, and thus includes commits which
we * deliberately* omitted in Camel 2.8.1.

The Karaf team seems to have a better practice, by discussing on the
@dev which tickets to backport (especially if non-bug tickets).
We the Camel team ought to follow their example IMHO, and also discuss
which tickets to backport.
Especially for non-bug tickets.

Likewise I don't believe there is one uber-person (that would include
me as that uber-person, in case you wonder)
who should sit and backport a batch of commits. Its the duty of all of
us to backport tickets.
In fact I think its primary the persons who actually worked on the
tickets, at the given time, is the
best person to judge if the ticket is safe to backport. But having a
weekly/semi-weekly procedure of discussing
and backport any left overs is a good idea. Then we ensure that the
maintenance branches is not becoming doormat
and we have a repeatable procedure in place, that the community can
rely upon. And they over time get familiar with.
If they keep an eye on the commit logs / JIRA - they see the progress
and that tickets get backport in timely manner.
There are possible a rare number of people who may even try out
SNAPSHOT versions of maintenance branches.
So it would help if tickets is back ported on a regularly basis.

We may also consider adding some note/field in JIRA if a ticket is
not safe to backport. Sometimes you work on a bug/improvement
that is just too complicated/or too big/risk of introducing side
effects/or rely upon other improvements/new features etc. that its not
feasible to backport. For example if we have a known work-around it
could be better to notice the workaround in the release notes for that
given release.



 3) Still not clear why we backport many issues to 2.8.2 and not to 2.7.4.

 I stess this to make it clear for everybody, document it and to provide a
 better mentoring for new committers.

 Christian

 Sent from a mobile device




-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Camel 2.8.2 - Reason for the many backports?

[Claus Ibsen]

On Sat, Sep 24, 2011 at 8:32 PM, Hadrian Zbarcea hzbar...@gmail.com wrote:
 Excellent points Christian. My take on this inline.

 Hadrian

 On 09/24/2011 01:34 PM, Christian Müller wrote:

 Hello Claus!

 Thank you for your work updating the WIKI page. I didn't know them...

 But I have to stress this topic a bit more, because I still have open
 questions:
 1) Is it a problem when different committers use different merge tools
 (the
 Java program, the Python script, simply Git, ...)?

 Probably not. The result it what matters. As long as the tool does the job
 everybody should use what he's comfortable with, unless there is a very good
 reason not to (don't see one in this case).

 2) What is our policy about backporting issues (only bugs, dependency
 upgrades for bug fix versions, improvements, new features, dependency
 upgrades which are not bug fix versions, ...)?

 I think we should backport as much as possible and give our users the best
 experience possible on any supported branch as long as:

We have to agree if its a *patch* release or if its not a patch release.
A patch release is supposed to be a 100% drop-in replacement to fix
some major bugs / security vulnerabilities.
A very low-risk upgrade, with just enough changes, and nothing more.
Better to be conservative and omit a commit, than to include it, if
you are in doubt.


 * we have 100% backward compatibility on patch versions (3rd digit).

We do not have that for 2.8.2. There is API changes. There is new
features backported, which risk introducing new bugs.
There is problem keeping documentation up to date, when backporting
new features, as you would have to remember
to update the documentation as well. Which wasn't the case for 2.8.2.
This will of course get better if the documentation was part
of the SVN.



 Dependencies versions may be upgraded to include fixed bugs, but probably
 not to a major release

 * almost 100% compatibility on minor releases. Simple, straightforward
 migration steps if at all.


And this is *certainly* not the case for Camel 2.9. But we are already
debating this in another thread.


 3) Still not clear why we backport many issues to 2.8.2 and not to 2.7.4.

 We should backport as much as we can to 2.7.x while it is maintained. I
 think it's just a matter of finding the time to do it.


 I stess this to make it clear for everybody, document it and to provide a
 better mentoring for new committers.

 Yes, by all means we should document that. It'll be helpful to both
 committers and users at large who would know what to expect.



 Christian

 Sent from a mobile device





-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Camel 2.8.2 - Reason for the many backports?

[Claus Ibsen]

On Fri, Sep 23, 2011 at 3:09 PM, Willem Jiang willem.ji...@gmail.com wrote:
 Hi Claus,

 I just found your svnmerge.py doesn't has the detail log message like this,
 it may be cause by your old copy of svnmerge.py.

 Author: davsclaus
 Date: Fri Sep 23 07:51:41 2011
 New Revision: 1174573

 URL: http://svn.apache.org/viewvc?rev=1174573view=rev
 Log:
 Merged revisions 1174571 via svnmerge from
 https://svn.apache.org/repos/asf/camel/branches/camel-2.8.x

 * we should get some commit message here *


Thanks Willem.

I think that old svmerge.py file may have an issue. I have switched to
use the copy from Dan.
I had trouble today backporting a fix to the 2.7 branch.
Could anyone try to backport CAMEL-4487? The rev number in the 2.8
branch is: 1175323

CAMEL-4487 is a low-risk, minor bug fix, that would be safe to
backport to the 2.7 branch.




-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/