network proxy is always used when defined

I have the same issue, but I found a workaround.
In my case I have some real external repositories which are behind an http proxy and some local repositories using file:// protocol.
If I order proxy connectors with external repositories first, my local repositories aren't read and I have an error from my http proxy. If I put my local repositories first, everything is fine.

I've not been able to reproduce this with 1.0.2-SNAPSHOT following the instructions in both comments. Arnaud, are you able to try the snapshot and check whether we've fixed this with some other changes?

I don't know, but it's fixed in current SNAPSHOT

it has been reported on list that this is still a problem. It may be an issue with the system properties. a potential workaround for this is to use the -Dhttp.nonProxyHosts in the startup script (or wrapper.conf). IF that doesn't work, try replacing wagon-http-lightweight with wagon-http.

I have fought against the same problem last week and finally found a solution.

We have the same setup as described above in our company: we have a local maven2 repository that is used as server for our own artifacts. This repository needs to be reached directly. In addition, we are using a couple of remote repositories in the internet. To reach these repositories, a network proxy has to be used.

We are using archiva 1.0.2 as mirror in the maven configuration to proxy all these repositories. Everything works fine, as long as we are using either the local repository without a proxy only or the remote repositories behind the network proxy. Using both kinds of repositories results in strange error messages.

After hours of testing, researching and even code reviews I found the problem: as soon as a network proxy is defined on the archiva configuration page, saving a proxy connector the used direct connection via the archiva configuration changes the archiva.xml configuration file. Instead of the usual empty <proxyId/> tag, the configuration file contains <proxyId>(direct connection)</proxyId>. And this does not work.

After I have removed the the '(direct connection)' manually from the configuration file the mixed setup is working!

the configuration file isn't the issue here.

There are two problems:
1) the wagons were not being re-initialised, meaning the first used remote proxy stuck forever
2) the lightweight-http-wagon being used did not reset the system properties after use

The first is fixed. The second has been worked around.

Note that the second is highly likely to be a problem if you have concurrent requests accessing both, however I'm reluctant to add synchronisation just for that purpose. It would be better for us to invest in switching to commons-httpclient again in 1.2 so this becomes a non-issue.

Brett, if there is a known issue with lightweight-http-wagon, why is this issue closed? I'm still experiencing it in 1.1.1. This issue should be open with the workarounds clearly listed for those of us running into it, please.

What I understood is that the workaround is in archiva's code. That's why Brett closed it.

Thanks Arnaud, maybe that's my confusion in understanding the comments on this issue. But like I said, I'm still experiencing it with 1.1.1 so its not fixed if its a workaround in the code base. I didn't have the -Dhttp.nonProxyHosts set so I'm trying that and hopefully that's the workaround Brett was referring to. I'll also try the http wagon if it doesn't work. I know I tried that under Archiva 1.0.1 and it hosed my instance so I'm hesitant to try it.

we were using the http wagon for a while but encountered some deadlocking in the version of httpclient. I believe there's an open issue for switching to something else (we're now looking at the jetty http client), which is why I closed this one. The obvious bug was fixed, with limitations.

Are you experiencing it in all cases, or only on concurrent access to both proxied and non-proxied repos?

I experience it after Archiva has been up for some time. For 1.0.2 it was only about 5 minutes, for 1.1.1 it was good for about 3 days. After that point it will switch to always using the proxy server even for remote repos configured to use direct connect. The concurrency of the access is not an issue since after this issue happens it will happen consistently until a restart even with no other users accessing the server.

Perhaps it is triggered by an exception that doesn't reset the properties. Would you mind creating a new issue for us to investigate this specifically?

Brett, I created MRM-909.