Bugzilla – Full Text Bug Listing
| Summary: | Proxy support is not optional | ||
|---|---|---|---|
| Product: | [RT] ECF | Reporter: | Jeff McAffer <jeffmcaffer> |
| Component: | ecf.filetransfer | Assignee: | Scott Lewis <slewis> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | henrich.kraemer, slewis |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | |||
|
Description
Jeff McAffer
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. |