camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bengt Rodehav <be...@rodehav.com>
Subject Re: camel-ftp problems with ftps implicit mode
Date Sat, 12 Jun 2010 08:08:11 GMT
Hi Willem,

That worked - thanks!

I added the following:


 <DynamicImport-Package>org.apache.camel.*</DynamicImport-Package>

which did the trick. I think it's probably hard to know what exact
classes/packages will be used "under the hood" which is why I used the
dynamic import.

I would suggest that a Wiki page regarding how to use Camel in an OSGi
environment would be documented (maybe there is one already?). I think there
are many considerations that are not straight forward for developers (at
least not for me). The following (at least) need to be described:

- What dependencies (maven wise) do I need at build time? (camel-spring I
guess)

- What imports (OSGi wise) do I need in run time? Best practice? (dynamic or
fixed? what packages?)

- What features/bundles must be installed?

- Some description of how the OSGi support is implemented. I think this is
good for the general understanding and will probably give you guys less
"support" issues (like mine). This is where you would describe how Camel
registers components/languages/strategies and so forth and how they are
resolved in run time.

- Additionally, it's important to specify how it is possible for an
application to know when all required Camel resources are available for use
in an OSGi environment. I've had a mail conversation regarding this with
Guillaume Nodet. Ideally Camel would register OSGi services for every
registered component (or bundle, or something else) that applications could
depend on. I'm not aware if any of this has been implemented in Camel yet.
Right now I've had to create an OSGi extender that waits for my required
bundles to be started (in my case camel-core, camel-spring and camel-ftp). I
then register a service that my applications can depend on. This must be
solved in a better way within the Camel project.

Thanks a lot for your help Willem - I really appreciate it. I'll now proceed
with my ftps testing :-)

/Bengt


2010/6/12 Willem Jiang <willem.jiang@gmail.com>

> Hi Bengt,
>
> I ran the test and find the OsgiClassResolver is using the bundle of you
> camel application to load the class. So you need to add the import package
> of "org.apache.camel.component.file.strategy" into your camel application
> bundle.
>
> Willem
>
>
> Bengt Rodehav wrote:
>
>> Willem,
>>
>> I've tried to modify spring-osgi to make it possible to import
>> the org.apache.camel.component.file.strategy package from camel-core but I
>> haven't succeeded. I've used explicit import as well as dynamic. When I
>> use
>> explicit import I can see (via the webconsole) that spring-osgi does
>> indeed
>> import the org.apache.camel.component.file.strategy package from
>> camel-core.
>> But it still cannot resolve
>> the
>> org.apache.camel.component.file.strategy.GenericFileProcessStrategyFactory
>> class.
>>
>> Running out of ideas....
>>
>> /Bengt
>>
>> 2010/6/11 Bengt Rodehav <bengt@rodehav.com>
>>
>>  Willem,
>>>
>>> I've done some more digging in order to understand what is happening.
>>> Apparently spring-osgi embeds the OsgiClassResolver class (it is
>>> specified
>>> as a Private-Package). The class that the resolver is trying to resolve
>>> is:
>>>
>>>
>>>
>>>  org.apache.camel.component.file.strategy.GenericFileProcessStrategyFactory
>>>
>>> The package org.apache.camel.component.file.strategy is exported from
>>> camel-core but it is not imported into spring-osgi which must be the
>>> reason
>>> why it cannot be resolved.
>>>
>>> If the resolver resides in spring-osgi (which it does) then it must
>>> import
>>> all packages that it can potentially be requested to resolve. I guess one
>>> way of doing that would be via Dynamic-Import.
>>>
>>> Will you take a look at this?
>>>
>>> /Bengt
>>>
>>>
>>>
>>> 2010/6/11 Bengt Rodehav <bengt@rodehav.com>
>>>
>>> Hello again Willem!
>>>
>>>> Maybe we should switch thread since this presently has nothing to do
>>>> with
>>>> ftps...
>>>>
>>>> Anyway, it's going to be pretty hard for me to extract a small test
>>>> case.
>>>> Not sure I will be enable to do it. Just out of curiosity, did you also
>>>> try
>>>> a "ftps:" endpoint?
>>>>
>>>> Also, I've been doing some System.out debugging. I've found out the
>>>> following:
>>>>
>>>> The resolver that is being used is an instance of
>>>> the org.apache.camel.core.osgi.OsgiClassResolver class. When I search
>>>> through the Camel source code I only find this class in one place - in
>>>> the
>>>> camel-core-osgi component. To my knowledge I don't use that component
>>>> and I
>>>> have no idea how that class can be instantiated in run-time.
>>>>
>>>> Any thoughts on this? Is this the correct resolver to use? How is
>>>> camel-core supposed to find that class? How does it work?
>>>>
>>>> /Bengt
>>>>
>>>>
>>>> 2010/6/10 Willem Jiang <willem.jiang@gmail.com>
>>>>
>>>>  Hi Bengt,
>>>>> I just tried to use some file endpoint inside our camel OSGi test
>>>>> platform, the route is started without any issue.
>>>>>
>>>>> Can you create a small test case which is based on you application and
>>>>> submit it into a JIRA ?
>>>>> In this way I can keep on digging the issue :)
>>>>>
>>>>> Willem
>>>>>
>>>>>
>>>>> Bengt Rodehav wrote:
>>>>>
>>>>>  I now get the following exception:
>>>>>>
>>>>>> java.lang.TypeNotPresentException: Type
>>>>>>
>>>>>>
>>>>>> org.apache.camel.component.file.strategy.GenericFileProcessStrategyFactory
>>>>>> class not found not present
>>>>>>       at
>>>>>>
>>>>>>
>>>>>> org.apache.camel.component.file.GenericFileEndpoint.createGenericFileStrategy(GenericFileEndpoint.java:145)
>>>>>>       at
>>>>>>
>>>>>>
>>>>>> org.apache.camel.component.file.GenericFileEndpoint.getGenericFileProcessStrategy(GenericFileEndpoint.java:118)
>>>>>>       at
>>>>>>
>>>>>>
>>>>>> org.apache.camel.component.file.GenericFileConsumer.doStart(GenericFileConsumer.java:397)
>>>>>>       at
>>>>>> org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:56)
>>>>>>       at
>>>>>>
>>>>>> org.apache.camel.util.ServiceHelper.startService(ServiceHelper.java:53)
>>>>>>       at
>>>>>>
>>>>>>
>>>>>> org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:1015)
>>>>>> ...
>>>>>>
>>>>>> This is incredibly strange to me. It seems like the caller (line 145
>>>>>> in
>>>>>> class GenericFileEndpoint) cannot find the class
>>>>>> GenericFileProcessStrategyFactory. They both reside in camel-core so
>>>>>> there
>>>>>> can be no problem in finding the class. However it is not exactly
>>>>>> trying
>>>>>> to
>>>>>> find it but to "resolve" it. The following call throws the exception:
>>>>>>
>>>>>> factory =
>>>>>>
>>>>>>
>>>>>> this.getCamelContext().getClassResolver().resolveClass(DEFAULT_STRATEGYFACTORY_CLASS);
>>>>>>
>>>>>> Any ideas?
>>>>>>
>>>>>> /Bengt
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2010/6/10 Bengt Rodehav <bengt@rodehav.com>
>>>>>>
>>>>>>  Willem,
>>>>>>
>>>>>>> I'm just now building a new trunk version of Camel and need to verify
>>>>>>> with
>>>>>>> you that I'm using Camel properly in an OSGi environment:
>>>>>>>
>>>>>>> - I only install the features "camel" (includes camel-core and
>>>>>>> camel-spring
>>>>>>> bundles) + camel-ftp (that I wish to test)
>>>>>>>  Do I need camel-spring if I'm not using Spring directly? I create
>>>>>>> all
>>>>>>> my
>>>>>>> routes in Java DSL.
>>>>>>>
>>>>>>> -  I noticed that there is a component called camel-core-osgi. Should
>>>>>>> I
>>>>>>> use
>>>>>>> it in any way? How?
>>>>>>>
>>>>>>> Just out of curiosity. What was the typo you mentioned?
>>>>>>>
>>>>>>> /Bengt
>>>>>>>
>>>>>>>
>>>>>>> 2010/6/10 Willem Jiang <willem.jiang@gmail.com>
>>>>>>>
>>>>>>>  Hi Bengt,
>>>>>>>
>>>>>>>> It's a typo, I just fixed it with an OSGi unit test.
>>>>>>>> Please check out the last camel trunk code to keep on riding with
>>>>>>>> Camel :)
>>>>>>>>
>>>>>>>>
>>>>>>>> Willem
>>>>>>>>
>>>>>>>> Bengt Rodehav wrote:
>>>>>>>>
>>>>>>>>  Thanks Willem - what a relief...
>>>>>>>>
>>>>>>>>> I eagerly await the results from your digging,
>>>>>>>>>
>>>>>>>>> /Bengt
>>>>>>>>>
>>>>>>>>> 2010/6/10 Willem Jiang <willem.jiang@gmail.com>
>>>>>>>>>
>>>>>>>>>  I can reproduce the error that you met, there must be something
>>>>>>>>> wrong
>>>>>>>>>
>>>>>>>>>  with
>>>>>>>>>> current OSGi refactoring,
>>>>>>>>>> I will keep digging to see if I can fix this issue soon.
>>>>>>>>>>
>>>>>>>>>> Willem
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Bengt Rodehav wrote:
>>>>>>>>>>
>>>>>>>>>>  Thanks for your reply Willem,
>>>>>>>>>>
>>>>>>>>>>  I've tried various combinations of camel features. Right now I
>>>>>>>>>>> use
>>>>>>>>>>> the
>>>>>>>>>>> "camel" feature (plus camel-ftp since that's what I'm trying to
>>>>>>>>>>> test).
>>>>>>>>>>> In
>>>>>>>>>>> runtime I can see the camel-core, camel-spring and the camel-ftp
>>>>>>>>>>> bundles
>>>>>>>>>>> installed and active. I manage to create an
>>>>>>>>>>> OsgiDefaultCamelContext
>>>>>>>>>>> the
>>>>>>>>>>> following way:
>>>>>>>>>>>
>>>>>>>>>>>  mCamelContextFactory = new CamelContextFactory();
>>>>>>>>>>>  mCamelContextFactory.setBundleContext(theBundleContext);
>>>>>>>>>>>  mCamelContext = mCamelContextFactory.createContext();
>>>>>>>>>>>
>>>>>>>>>>> However, when I try to start the camel context I get the
>>>>>>>>>>> exception
>>>>>>>>>>> I
>>>>>>>>>>> mentioned above:
>>>>>>>>>>>
>>>>>>>>>>> Caused by: org.apache.camel.ResolveEndpointFailedException:
>>>>>>>>>>> Failed
>>>>>>>>>>> to
>>>>>>>>>>> resolve endpoint:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> file://data/connect/test/sample/file2ftps?delay=1000&move=archive%2F%24%
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 7Bdate%3Anow%3AyyyyMMdd%7D%2F%24%7Bfile%3Aname%7D&moveFailed=failed%2F%24%7Bfile%3Aname.noext%7D-%24%7Bdate%3Anow%3AyyyyMMddHHmmssSSS%7D.%24%7Bfile%3Aext%7D
>>>>>>>>>>> due to: No language could be found for: file
>>>>>>>>>>>     at
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> org.apache.camel.impl.DefaultCamelContext.getEndpoint(DefaultCamelContext.java:377)
>>>>>>>>>>>
>>>>>>>>>>> To me it sounds like the languages has not been registered
>>>>>>>>>>> properly.
>>>>>>>>>>> Looking
>>>>>>>>>>> through the code it looks like the OSGi "registration" part of
>>>>>>>>>>> camel
>>>>>>>>>>> has
>>>>>>>>>>> moved from camel-osgi to camel-core. Which I guess means that I
>>>>>>>>>>> should
>>>>>>>>>>> not
>>>>>>>>>>> be using camel-osgi anymore (just camel-core in combination with
>>>>>>>>>>> camel-spring). This is what I'm doing, but I still get the above
>>>>>>>>>>> exception.
>>>>>>>>>>>
>>>>>>>>>>> Could it be a problem with iPojo? I use iPOJO to create my OSGi
>>>>>>>>>>> services
>>>>>>>>>>> from configurations handled by file install. I noticed that the
>>>>>>>>>>> BundleContext I'm using is really an instance
>>>>>>>>>>> of  org.apache.felix.ipojo.IPojoContext.
>>>>>>>>>>>
>>>>>>>>>>> Any clues?
>>>>>>>>>>>
>>>>>>>>>>> /Bengt
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2010/6/10 Willem Jiang <willem.jiang@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>>  Hi Bengt,
>>>>>>>>>>>
>>>>>>>>>>>  Did you use the apache camel feature of the Camel 2.4-SNAPSHOT ?
>>>>>>>>>>>
>>>>>>>>>>>> If so,  you just need to install the feature of camel, it
>>>>>>>>>>>> includes
>>>>>>>>>>>> the
>>>>>>>>>>>> camel-core feature and camel-spring feature.
>>>>>>>>>>>>
>>>>>>>>>>>> And you can still use org.apache.camel.osgi.CamelContextFactory
>>>>>>>>>>>> to
>>>>>>>>>>>> create
>>>>>>>>>>>> the camel context :)
>>>>>>>>>>>>
>>>>>>>>>>>> Willem
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Bengt Rodehav wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>  Claus,
>>>>>>>>>>>>
>>>>>>>>>>>>  I have now managed to build Camel version 2.4-SNAPSHOT.
>>>>>>>>>>>> However,
>>>>>>>>>>>>
>>>>>>>>>>>>> I
>>>>>>>>>>>>> can't
>>>>>>>>>>>>> get
>>>>>>>>>>>>> my application to work on that version. I'm using Karaf 1.6.0
>>>>>>>>>>>>> for
>>>>>>>>>>>>> deployment
>>>>>>>>>>>>> and something has definitely changed in Camel regarding OSGi. I
>>>>>>>>>>>>> haven't
>>>>>>>>>>>>> figured out how to use Camel 2.4-SNAPSHOT in Karaf yet. Maybe
>>>>>>>>>>>>> you
>>>>>>>>>>>>> (or
>>>>>>>>>>>>> someone else reading this) can help out?
>>>>>>>>>>>>>
>>>>>>>>>>>>> When using Camel 2.3, I create my camel context using
>>>>>>>>>>>>> the org.apache.camel.osgi.CamelContextFactory class. In
>>>>>>>>>>>>> runtime,
>>>>>>>>>>>>> this
>>>>>>>>>>>>> class
>>>>>>>>>>>>> is imported from the camel-spring-osgi bundle. The activator
>>>>>>>>>>>>> for
>>>>>>>>>>>>> this
>>>>>>>>>>>>> bundle
>>>>>>>>>>>>> (org.apache.camel.osgi.Activator) seems to reside in the
>>>>>>>>>>>>> camel-osgi
>>>>>>>>>>>>> bundle
>>>>>>>>>>>>> but that bundle also seems to be embedded in camel-spring-osgi.
>>>>>>>>>>>>> Have
>>>>>>>>>>>>> to
>>>>>>>>>>>>> admit that this solution is far from pretty but it seems to
>>>>>>>>>>>>> work.
>>>>>>>>>>>>> The
>>>>>>>>>>>>> activator keeps track of installed bundles and their camel
>>>>>>>>>>>>> resources
>>>>>>>>>>>>> (such
>>>>>>>>>>>>> as components and languages).
>>>>>>>>>>>>>
>>>>>>>>>>>>> When I switch to Camel 2.4-SNAPSHOT I get the following
>>>>>>>>>>>>> exception:
>>>>>>>>>>>>>
>>>>>>>>>>>>> ...
>>>>>>>>>>>>> Caused by: org.apache.camel.ResolveEndpointFailedException:
>>>>>>>>>>>>> Failed to
>>>>>>>>>>>>> resolve en
>>>>>>>>>>>>> dpoint:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> file://data/connect/sample/file2ftps?delay=1000&move=archive%2F%24%7Bdat
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> e%3Anow%3AyyyyMMdd%7D%2F%24%7Bfile%3Aname%7D&moveFailed=failed%2F%24%7Bfile%3Ana
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> me.noext%7D-%24%7Bdate%3Anow%3AyyyyMMddHHmmssSSS%7D.%24%7Bfile%3Aext%7D
>>>>>>>>>>>>> due
>>>>>>>>>>>>> to:
>>>>>>>>>>>>> No language could be found for: file
>>>>>>>>>>>>>    at
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> org.apache.camel.impl.DefaultCamelContext.getEndpoint(DefaultCamelCon
>>>>>>>>>>>>> text.java:377)
>>>>>>>>>>>>> ...
>>>>>>>>>>>>>
>>>>>>>>>>>>> It seems like Camel cannot find the "file" language (which is
>>>>>>>>>>>>> supposed
>>>>>>>>>>>>> to
>>>>>>>>>>>>> be
>>>>>>>>>>>>> mapped to the org.apache.camel.language.simple.SimpleLanguage
>>>>>>>>>>>>> class).
>>>>>>>>>>>>> I
>>>>>>>>>>>>> then
>>>>>>>>>>>>> tried to find the proper activator to find out why the language
>>>>>>>>>>>>> doesn't
>>>>>>>>>>>>> seem
>>>>>>>>>>>>> to be registered.
>>>>>>>>>>>>>
>>>>>>>>>>>>> First, the camel-spring-osgi bundle does not seem to exist in
>>>>>>>>>>>>> camel
>>>>>>>>>>>>> anymore.
>>>>>>>>>>>>> Instead, the CamelContextFactory is now imported from the
>>>>>>>>>>>>> camel-spring
>>>>>>>>>>>>> bundle. camel-spring's activator
>>>>>>>>>>>>> (org.apache.camel.osgi.Activator) is
>>>>>>>>>>>>> now
>>>>>>>>>>>>> part of the camel-spring component but when I look at it I
>>>>>>>>>>>>> can't
>>>>>>>>>>>>> see
>>>>>>>>>>>>> that
>>>>>>>>>>>>> it
>>>>>>>>>>>>> keeps track of anything but it's own BundleContext and Bundle
>>>>>>>>>>>>> instance.
>>>>>>>>>>>>> Then
>>>>>>>>>>>>> who keeps track of the registered components, type converters,
>>>>>>>>>>>>> languages
>>>>>>>>>>>>> and
>>>>>>>>>>>>> so forth?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I must be missing something here. Can someone please explain to
>>>>>>>>>>>>> me
>>>>>>>>>>>>> how
>>>>>>>>>>>>> to
>>>>>>>>>>>>> use Camel 2.4 in OSGi? I must say I've had a lot of problems
>>>>>>>>>>>>> with
>>>>>>>>>>>>> the
>>>>>>>>>>>>> combination of camel and OSGi before as well but I was hoping
>>>>>>>>>>>>> for
>>>>>>>>>>>>> Camel's
>>>>>>>>>>>>> OSGi support to get better - right now I'm a bit disillusioned
>>>>>>>>>>>>> :-(
>>>>>>>>>>>>>
>>>>>>>>>>>>> I noticed that camel-osgi still exists in Camel 2.4 but it
>>>>>>>>>>>>> doesn't
>>>>>>>>>>>>> look
>>>>>>>>>>>>> like
>>>>>>>>>>>>> a bundle anymore. Maybe there is a secret here that I haven't
>>>>>>>>>>>>> fully
>>>>>>>>>>>>> understood.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Bengt
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2010/6/7 Claus Ibsen <claus.ibsen@gmail.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>>  On Mon, Jun 7, 2010 at 4:30 PM, Bengt Rodehav <
>>>>>>>>>>>>> bengt@rodehav.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>  Claus,
>>>>>>>>>>>>>
>>>>>>>>>>>>>  I have now tested my version using both passive and active
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> (which
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  requires a
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  certificate) mode. I've tested against a free ftp server -
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Filezilla -
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  and a
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  commercial ftp server (that we often use) - Serv-u. It works
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> fine.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  I haven't tested your version yet because it requires me to
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> build
>>>>>>>>>>>>>>> my
>>>>>>>>>>>>>>> application against Camel version 2.4-SNAPSHOT instead of
>>>>>>>>>>>>>>> Camel
>>>>>>>>>>>>>>> version
>>>>>>>>>>>>>>> 2.3.0. To get this to work I need to get all the 2-4-SNAPSHOT
>>>>>>>>>>>>>>> artifacts
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  into
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  my local Maven repository. I tried to do this by building
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Camel
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  locally
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  but
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  I never seem to get it to build. Right now, I'm stuck with
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  following
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Maven error message (I'm usng Maven 2.0.11):
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  You can just cd into camel-ftp and build that jar. And then
>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>> grab
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  the camel-core jar as well.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  And if you use spring then camel-spring .jar as well. Then
>>>>>>>>>>>>>> you
>>>>>>>>>>>>>> got
>>>>>>>>>>>>>> what you need for 2.4-SNAPSHOTs.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yeah Maven can be strange. Sometimes you need to nuke you
>>>>>>>>>>>>>> local
>>>>>>>>>>>>>> m2
>>>>>>>>>>>>>> repo
>>>>>>>>>>>>>> cache.
>>>>>>>>>>>>>> And I use maven 2.0.9.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  [INFO] Writing OBR metadata
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  [INFO]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>>>>>>> [INFO] Building Camel :: Jetty
>>>>>>>>>>>>>>> [INFO]    task-segment: [clean, install]
>>>>>>>>>>>>>>> [INFO]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>>>>>>> [INFO] [clean:clean]
>>>>>>>>>>>>>>> Downloading:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://repository.apache.org/content/repositories/releases//com/su
>>>>>>>>>>>>>>> n/mail/all/1.4.3/all-1.4.3.pom
>>>>>>>>>>>>>>> [INFO] Unable to find resource 'com.sun.mail:all:pom:1.4.3'
>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>> repository
>>>>>>>>>>>>>>> apache
>>>>>>>>>>>>>>> .releases (
>>>>>>>>>>>>>>> https://repository.apache.org/content/repositories/releases/
>>>>>>>>>>>>>>> )
>>>>>>>>>>>>>>> Downloading:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://svn.apache.org/repos/asf/servicemix/m2-repo/com/sun/mail/all
>>>>>>>>>>>>>>> /1.4.3/all-1.4.3.pom
>>>>>>>>>>>>>>> [INFO] Unable to find resource 'com.sun.mail:all:pom:1.4.3'
>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>> repository
>>>>>>>>>>>>>>> servic
>>>>>>>>>>>>>>> emix (http://svn.apache.org/repos/asf/servicemix/m2-repo)
>>>>>>>>>>>>>>> Downloading:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://jansi.fusesource.org/repo/release/com/sun/mail/all/1.4.3/all
>>>>>>>>>>>>>>> -1.4.3.pom
>>>>>>>>>>>>>>> [INFO] Unable to find resource 'com.sun.mail:all:pom:1.4.3'
>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>> repository
>>>>>>>>>>>>>>> jansi.
>>>>>>>>>>>>>>> release.m2 (http://jansi.fusesource.org/repo/release)
>>>>>>>>>>>>>>> Downloading:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://repository.ops4j.org/maven2/com/sun/mail/all/1.4.3/all-1.4.3
>>>>>>>>>>>>>>> .pom
>>>>>>>>>>>>>>> [INFO] Unable to find resource 'com.sun.mail:all:pom:1.4.3'
>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>> repository
>>>>>>>>>>>>>>> ops4j
>>>>>>>>>>>>>>> (http://repository.ops4j.org/maven2)
>>>>>>>>>>>>>>> Downloading:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://repo1.maven.org/maven2/com/sun/mail/all/1.4.3/all-1.4.3.pom
>>>>>>>>>>>>>>> [INFO] Unable to find resource 'com.sun.mail:all:pom:1.4.3'
>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>> repository
>>>>>>>>>>>>>>> centra
>>>>>>>>>>>>>>> l (http://repo1.maven.org/maven2)
>>>>>>>>>>>>>>> [INFO]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>>>>>>> [ERROR] BUILD ERROR
>>>>>>>>>>>>>>> [INFO]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>>>>>>> [INFO] Error building POM (may not be this project's POM).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Project ID: javax.mail:mail:jar:null
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Reason: Cannot find parent: com.sun.mail:all for project:
>>>>>>>>>>>>>>> javax.mail:mail:jar:nu
>>>>>>>>>>>>>>> ll for project javax.mail:mail:jar:null
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [INFO]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>>>>>>> [INFO] For more information, run Maven with the -e switch
>>>>>>>>>>>>>>> [INFO]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>>>>>>> [INFO] Total time: 4 minutes 26 seconds
>>>>>>>>>>>>>>> [INFO] Finished at: Mon Jun 07 12:59:05 CEST 2010
>>>>>>>>>>>>>>> [INFO] Final Memory: 231M/483M
>>>>>>>>>>>>>>> [INFO]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /Bengt
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2010/6/5 Bengt Rodehav <bengt@rodehav.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  God you're fast. I made my own attempts and attached diff
>>>>>>>>>>>>>>> files to
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> JIRA
>>>>>>>>>>>>>>> issue you created. I also added a couple of
>>>>>>>>>>>>>>> comments/suggestions to
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  issue.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  In short I believe that it is probably easier for the
>>>>>>>>>>>>>>>> user/developer
>>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  it
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  is enough to specify whether a secure data channel should
>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> used
>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  (the default should be true). Adding more detailed options,
>>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  you
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  did, is
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  of course just a benefit as long as it is possible to also
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> configure
>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> easy way (like I described).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  I haven't tested your changes yet - will do. I have done
>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  limited
>>>>>>>>>>>>>>>> testing with my own version, but only in passive mode. If
>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  secure
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  data channel in active mode one must first create a
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> public/private
>>>>>>>>>>>>>>> key
>>>>>>>>>>>>>>> pair
>>>>>>>>>>>>>>> for the ftps client to use and I haven't gotten around to
>>>>>>>>>>>>>>> testing
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> yet.
>>>>>>>>>>>>>>> /Bengt
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  2010/6/4 Claus Ibsen <claus.ibsen@gmail.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   Hi
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  On Fri, Jun 4, 2010 at 3:42 PM, Bengt Rodehav <
>>>>>>>>>>>>>>>> bengt@rodehav.com
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  OK, will try to do that sometime this weekend.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  Will be in touch,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   I was one step ahead of you. I created the ticket and took
>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> stab
>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>  resolving it.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>  https://issues.apache.org/activemq/browse/CAMEL-2790
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Can you try with the latest source code? And maybe if there
>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>> still
>>>>>>>>>>>>>>>>> some issue then work on a patch from there.
>>>>>>>>>>>>>>>>> Would be lovely with an unit test, but the test ftp server
>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>> cannot understand the secure data transfer.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Anyway would be awesome if you could test it on your real
>>>>>>>>>>>>>>>>> systems.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  /Bengt
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  2010/6/4 Claus Ibsen <claus.ibsen@gmail.com>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>   Hi
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>  Well spotted. Do you mind creating a JIRA ticket and link
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>  this
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>  post
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>  using nabble etc.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> And you may even want to contribute a patch :)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  On Fri, Jun 4, 2010 at 11:34 AM, Bengt Rodehav <
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> bengt@rodehav.com
>>>>>>>>>>>>>>>>>>>  wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>  I'm using camel-ftp for secure ftps communication. I
>>>>>>>>>>>>>>>>>>> need
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> to be
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>  able
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>   to
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>  connect to a wide range of ftps servers in both explicit
>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> implicit
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>   mode.
>>>>>>>>>>>>>>>>>> I have encountered problems using camel-ftp for ftps
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> communication
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  in
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> implicit mode.
>>>>>>>>>>>>>>>>>> Some ftps servers require that the file transfer is
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> encrypted
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  (not
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  just
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>  commands). This is of course very natural and is the
>>>>>>>>>>>>>>>>>> reason
>>>>>>>>>>>>>>>>>> why
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>   ftps
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>  is
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> chosen in the first place. However, commons-net (which
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> camel-ftp
>>>>>>>>>>>>>>>>> uses)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>   does
>>>>>>>>>>>>>>>>>>  (for some reason) not by default setup a secure channel
>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>  file
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>  transfers.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>  It has to be requested by code similar to the
>>>>>>>>>>>>>>>>>>>> following:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>  ftpsClient.execPBSZ(0);
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>  ftpsClient.execPROT("P");
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I suggest to add an option to camel-ftp, regarding ftps,
>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>  it
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>  possible
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> to specify whether the data channel will be encrypted or
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> not.
>>>>>>>>>>>>>>>>>  Encrypted
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  should be default.
>>>>>>>>>>>>>>>>>>  When looking at the code in camel-ftp it seems like there
>>>>>>>>>>>>>>>>>> is no
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>   special
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>  handling during connect for ftps compared to ftp. Thus
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> there is
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>  no
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>  natural
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>   place to put the above code. One way is to add something
>>>>>>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>  following
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>  at the end of the method "connect" in the class
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> "FtpOperations":
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>  if(client instanceof FTPSClient) {
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>  FTPSClient ftpsClient = (FTPSClient)client;
>>>>>>>>>>>>>>>>>>>>  try {
>>>>>>>>>>>>>>>>>>>>  if (useSecureDataChannel) { // useSecureDataChannel
>>>>>>>>>>>>>>>>>>>> should
>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>> initialized from the configuration somehow
>>>>>>>>>>>>>>>>>>>>   ftpsClient.execPBSZ(0);
>>>>>>>>>>>>>>>>>>>>   ftpsClient.execPROT("P");
>>>>>>>>>>>>>>>>>>>>  }
>>>>>>>>>>>>>>>>>>>>  } catch (SSLException e) {
>>>>>>>>>>>>>>>>>>>>  throw new
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>  GenericFileOperationFailedException(client.getReplyCode(),
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>  client.getReplyString(), e.getMessage(), e);
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>  } catch (IOException e) {
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>   throw new
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>  GenericFileOperationFailedException(client.getReplyCode(),
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>  client.getReplyString(), e.getMessage(), e);
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>  }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>   }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Am I the only one having problems with this? Maybe there
>>>>>>>>>>>>>>>>>>>> is a
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>  workaround
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>  that I haven't figured out.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>  /Bengt
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>   --
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>  Claus Ibsen
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Apache Camel Committer
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>>>>>>>>>>>>>>>>> Open Source Integration: http://fusesource.com
>>>>>>>>>>>>>>>>>>> Blog: http://davsclaus.blogspot.com/
>>>>>>>>>>>>>>>>>>> Twitter: http://twitter.com/davsclaus
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>  --
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>  Claus Ibsen
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Apache Camel Committer
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>>>>>>>>>>>>>>> Open Source Integration: http://fusesource.com
>>>>>>>>>>>>>>>>> Blog: http://davsclaus.blogspot.com/
>>>>>>>>>>>>>>>>> Twitter: http://twitter.com/davsclaus
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  --
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  Claus Ibsen
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Apache Camel Committer
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>>>>>>>>>>>> Open Source Integration: http://fusesource.com
>>>>>>>>>>>>>> Blog: http://davsclaus.blogspot.com/
>>>>>>>>>>>>>> Twitter: http://twitter.com/davsclaus
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message