Claus, 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 option. 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 reasons: 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. at org.apache.camel.component.file.remote.FtpOperations.connect(FtpOperations.java:107)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT] at org.apache.camel.component.file.remote.FtpsOperations.connect(FtpsOperations.java:40)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT] at org.apache.camel.component.file.remote.RemoteFileProducer.connectIfNecessary(RemoteFileProducer.java:170)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT] at org.apache.camel.component.file.remote.RemoteFileProducer.preWriteCheck(RemoteFileProducer.java:123)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT] at org.apache.camel.component.file.GenericFileProducer.processExchange(GenericFileProducer.java:75)[65:org.apache.camel.camel-core:2.4.0.SNAPSHOT] at org.apache.camel.component.file.remote.RemoteFileProducer.process(RemoteFileProducer.java:49)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT] Best regards, /Bengt 2010/6/14 Bengt Rodehav <be...@rodehav.com> > 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 <willem.ji...@gmail.com> > > 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 <willem.ji...@gmail.com> >>> >>> 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] >>>> >>>> http://old.nabble.com/-DISCUSS--OSGi-improvements-and-type-converters-ts28776216.html#a28776216 >>>> >>>> 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(OsgiFactoryFinder.java:71) >>>>> at >>>>> >>>>> >>>>> org.apache.camel.component.file.GenericFileEndpoint.createGenericFileStrategy(GenericFileEndpoint.java:134) >>>>> 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) >>>>> >>>>> 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 >>>>> >>>>> >>>>> >>> >> >
