Community
Participate
Working Groups
well it is marked as optional but if core.net.proxy is not installed, file transfer (in particular in p2) fails. I suspect the problem is in ProxySetupHelper.selectProxyFromProxies. Taht method returns an IProxyData. This type is not available if core.net.proxy is not there. As a result, the ProxySetupHelper class will not verify and the referencing code (e.g., in AbstractRetrieveFileTransfer.setupProxies) will fail with a CNF or some such.
Adding Henrich to cc as this is likely regression because of recently added fix for bug 295030.
I only looked briefly at this. The changes made for 295030 if no proxy is defined should have been a refactoring. I am doubtful this is a regression in particular since this code would definitely be called during a transfer and cause a CNF exception at that time as well.
(In reply to comment #2) > I only looked briefly at this. > The changes made for 295030 if no proxy is defined should have been a > refactoring. > I am doubtful this is a regression in particular since this code would > definitely be called during a transfer and cause a CNF exception at that time > as well. I think the refactoring may have moved a reference to some proxy API class (e.g. IProxyData) outside of the try/catch block...which was in place around the existing code so that if the core api wasn't present (no proxy support), that the filetransfer could continue.
Jeff...do you have a copy of the stack trace/NoClassDefinedFound exception that was generated? I want to identify the execution path through the code that resulted in this.
(In reply to comment #3) > I think the refactoring may have moved a reference to some proxy API class > (e.g. IProxyData) outside of the try/catch block...which was in place around > the existing code so that if the core api wasn't present (no proxy support), > that the filetransfer could continue. That is possible. I take another look. Unfortunately our tests are dependent on core.net.proxy also...
(In reply to comment #5) > (In reply to comment #3) > > I think the refactoring may have moved a reference to some proxy API class > > (e.g. IProxyData) outside of the try/catch block...which was in place around > > the existing code so that if the core api wasn't present (no proxy support), > > that the filetransfer could continue. > > That is possible. I take another look. Unfortunately our tests are dependent on > core.net.proxy also... Hi Henrich. I'm fixing this issue right now...and I'll also fix our tests so they can be run either with or w/o proxy api.
Fixes released to HEAD. Ran tests both with and without proxy api, for both httpclient and urlconnection-based providers. This fix will be in 6/7/2010 integration build and forward. Details Added try/catch for NoClassDefFoundError for any use of ProxySetupHelper class, which was added for dealing with bug 295030. Added try/catch for filetransfer tests to allow for testing without proxy api. Added test launch configs for running w/o proxy api and for httpclient or urlconnection provider.
(In reply to comment #7) > Fixes released to HEAD. Thanks Scott!
Thanks for getting on this. I did not get a stack trace as p2 was eating them. I entered a bug there for that.
