camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bengt Rodehav <>
Subject Re: camel-ftp problems with ftps implicit mode
Date Mon, 14 Jun 2010 12:02:52 GMT

Not sure if you're still reading this conversation since it hasn't been
about ftps for a while - I'll give it a try though.

I've now tested your ftps enhancement against Filezilla and Serv-U. It
works. However, I noticed the following:

If option "execPbsz" is not set then the PBSZ command is not sent at all.
The documentation says that default value is "0" which indicates that PBSZ
is always sent. I think the behaviour is correct but the documentation
should change and specify that "null" is the default value for "execPbsz".

About the configuration, I still think that the configuration is a bit
illogical. First of all, PBSZ and PROT commands are valid even though a
secure data channel is not used. It might even be valid for purt ftp (not
ftps) as well - I'm not sure. Therefore, the execProt and execPbsz options
should take effect regardless of the value of the useSecureDataChannel

Furthermore, I think the normal case should be default and require very
little configuration. I therefore suggest the following:

a) useSecureDataChannel should be true by default. This is due to two
  1. If ftp severs have requirements in this area, they tend to be
restrictive. Serv-U, for example require PROT P (secure data channel). Clear
text is allowed if one explicitly sends PROT C but not if no PROT command is
sent at all.
  2. I think that if the default is clear text then many developers will
send unencrypted content by mistake. I think that if you choose to use ftps,
most developers assume that the data is encrypted. That's what I did anyway.

b) If useSecureDataChannel is true, then this implies execPbsz=0 and
execProt=P without having to configure it explicitly.

c) execPbsz and execProt options shall always take effect and shall override
the values implied by setting useSecureDataChannel to true. Normally one
would not have to configure these options at all.

One can argue that if we make PBSZ 0 and PROT P the default, then we could
skip the useSecureDataChannel and only have the execProt and execPbsz
options. This would actually be OK since overriding the PBSZ 0 / PROT P
options is an active decision by a developer who presumably knows what s/he
is doing. This is OK with me but then it should also be possible to disable
sending of the PBSZ and PROT commands by explicitly setting those options to
the empty string.

Maybe I'm writing too much in this thread now but I also found another
problem: If something goes wrong, e g file already exists (Filezilla doesn't
permit overwrite) then I get the following exception on subsequent attempts.
I have to  restart the route to get it to work.


Best regards,


2010/6/14 Bengt Rodehav <>

> Willem,
> Just rebuilt Camel with the latest changes. It now works.
> Thanks a lot - I really appreciate your help,
> /Bengt
> 2010/6/14 Willem Jiang <>
> Bengt Rodehav wrote:
>>> Helllo Willem,
>>> Really interesting URL about the OSGi improvements in Camel. Will these
>>> things be part of Camel 2.4? When? In what state is the new OSGi support?
>>> Guillaume mentions that he is creating services that one can depend on
>>> (which is what I have discussed with hime on another thread). If this
>>> works
>>> now, then I can probably drop my OSGi extender that I use for that
>>> purpose.
>>> It would be interesting to know the new pattern/best practice for using
>>> Camel in OSGi.
>> There are some JIRA number (CAMEL-2693, 2793) about the refactoring,
>> Guillaume already finished them, please try it.
>>> Anyway, I tried adding the import you mentioned. I'm not sure I
>>> understood
>>> you correctly. I first tried adding it as a dynamic import. This didn't
>>> work
>>> since neither the dash nor forward slash characters are accepted by the
>>> maven-bundle-plugin in a DynamicImport-Package instruction. I then
>>> added META-INF/services/org/apache/camel/component/ in an Import-Package.
>>> The maven-bundle-plugin accepted this. However my bundle then no longer
>>> resolves since that import is not found in runtime. I then marked it as
>>> optional. My bundle then resolves but when the camel context is started I
>>> get the same exception as before.
>>> When I look at camel-core and camel-ftp they don't seem to export
>>> the META-INF/services/org/apache/camel/component/ package. How then could
>>> I
>>> hope to being able to import it?
>>>  It's my fault, I didn't write a test to verify my thought.
>> As camel-core doesn't export the package of
>> "META-INF/services/org/apache/camel/component/" your bundle will not start
>> rightly.
>> So I revert the change of OsgiFactoryFinder(CAMEL-2809), now it can find
>> the factory without importing the package of
>> "META-INF/services/org/apache/camel/component/" in your bundle.
>>  I'm probably missing something here. The error message indicates that
>>> Camel
>>> is looking for "strategy.factory.file"
>>> in META-INF/services/org/apache/camel/component/. I'm not sure what that
>>> means. I can see that in camel-core there is a file called "file" in
>>> the META-INF/services/org/apache/camel/component/ folder. That file
>>> contains
>>> a property called "strategy.factory.class". I assume the value of that
>>> property is what we are looking for. Still can't figure out how my bundle
>>> can access the directory if it's not exported.
>> The issue is caused by application bundle has the right to access the
>> properties file, I workaround it by reverting the change of
>> OsgiFactoryFinder.
>> Willem
>>> /Bengt
>>> 2010/6/13 Willem Jiang <>
>>>  Hi Bengt,
>>>> You need also add the package import of
>>>> "META-INF/services/org/apache/camel/component/"
>>>> As the OsgiFactoryFinder is changed to use camel application bundle to
>>>> load
>>>> the resource, you need to make sure your application bundle has the
>>>> right to
>>>> access the file.
>>>> BTW, there are some discusses about the refactoring that you can take a
>>>> look[1]
>>>> [1]
>>>> Willem
>>>> Bengt Rodehav wrote:
>>>>  Willem,
>>>>> There might still be some OSGi related problems. When testing different
>>>>> failing scenarios I got the following exception:
>>>>> 21:44:59,398 | DEBUG | guration Updater | FileEndpoint
>>>>> |
>>>>> mponent.file.GenericFileEndpoint  138 | No strategy factory defined in
>>>>> 'META-INF/services/org/apache/camel/component/'
>>>>> org.apache.camel.NoFactoryAvailableException: Could not find factory
>>>>> class
>>>>> for resource: strategy.factory.file
>>>>> at
>>>>> org.apache.camel.core.osgi.OsgiFactoryFinder.findClass(
>>>>> at
>>>>> org.apache.camel.component.file.GenericFileEndpoint.createGenericFileStrategy(
>>>>> at
>>>>> org.apache.camel.component.file.GenericFileEndpoint.getGenericFileProcessStrategy(
>>>>> at
>>>>> org.apache.camel.component.file.GenericFileConsumer.doStart(
>>>>> at org.apache.camel.impl.ServiceSupport.start(
>>>>> at
>>>>> org.apache.camel.util.ServiceHelper.startService(
>>>>> at
>>>>> org.apache.camel.impl.DefaultCamelContext.start(
>>>>> Seems like Camel cannot find any factory class for
>>>>> "strategy.factory.file".
>>>>> Sounds fishy to me and seems related to the class loading issues I had
>>>>> before. Can you check that the OSGi refactoring that has been made in
>>>>> Camel
>>>>> 2.4 takes this into account? I'll try to reproduce the error.
>>>>> /Bengt

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