* bumped version to httpclient 4.2.1 + httpcore 4.2.2 + httpmime 4.2.1 (latest GA) * applied recommended changes to connManager, parameters handling * catching IllegalStateException thrown by httpClient connmgr in case when JVM lacks support for TLS (was swallowed without this) * removing explicit connection close, to make use of pooling
…que (no same member repository multiple times) Signed-off-by: Alin Dreghiciu <email@example.com>
…r so that remote browsing secure.central gets the proper request paramemters.
ITs started failing because they could not read the encrypted problem report bundles' content.
We have in codebase test classes named 'Abstract*' but are not really 'abstract' and ones that are really abstract ( meant to be extended only ) surefire will do the right thing by allowing it to try to run any class that ends in Test and starts with Abstract. This will allow us to have test for real classes that are named Abstract* and keep the naming convention that IDEs expect for tests. 'abstract' test classes are still not run. If developer intends otherwise to execute a test class named 'Abstract*' then add one or more test methods and do not make it abstract. I noticed several tests that were being missed besides the ones covered in nexus-5197 because once upon a time we excluded Abstract named classes. ( probably my suggestion ). I've left failsafe config to ignore Abstract* named test classes because I am unclear on TestNG semantics and also those should be integration tests, which do not normally follow the convention of unit tests where tests are named one to one to the unit under test + 'Test' suffix
The appender did change between 2.1 and 2.2. Problem with "upgrade step" is that log manager is started from a servlet context listener, way before nexus is, hence, nexus upgrade step would be able to do anything way after logback configuration is loaded (and errors would be emitted about Appender). After chatting with Alin, this looked the simplest: introduce a marker interface, that would be implemented by those implementations of LogConfigurationParticipant, that does NOT want to let users tamper with their configuration. Event system config participant is such LogConfigurationParticipant (see it's config file, states "DO NOT EDIT"). When LogbackLogManager detects that a participant implements this marker interface, it will not check for config file existence (as it happened before this change) and write it out when not present, but it will "blindly", always write it out, potentially replacing the changed file. Now, the LogbackNexusEventSystemLogConfigurationParticipant implements the NonEditable marker interface and this resolves the problem, as on upgrade (from X to 2.2), 2.2 will simply overwrite the logback-event.xml.
nexus.properties is only contained in the nexus bundles, while the webapp's plexus.properties are already set when running the Nexus WAR.
With NEXUS-5280 implemented in a way it was done originally, Nexus lost the ability to load up configuration where a group G1 referenced G2 as member, while G2 was not YET loaded (is a valid scenario). This is fixed by not Note: as it is obvious, doing GroupRepository#getMemberRepositories() during boot (since this code is invoked during boot, but also during "normal" runtime reconfigurations) results in NoSuchRepoEx that made many "group of groups" ITs to fail. Reason is that method above goes to RepositoryRegistry to "resolve" member IDs to Repository instances, but G2 is not yet in registry. Solution is to make lookup "lazy": similarly as before, now the list of member IDs are "remembered", and the list of contexts is lazily constructed. In cases like member changes or disabling indexing on a repository, IndexerManager will recreate LazyContextMemberProvider just it did before.
…embers. But, we forgot to handle a special case: there is one case, when instead of the group member change, a member configuration change might cause that group context list MUST change, the groups ContextMemberProvider pre-built list must change: that when Repository#setIndexable() is changed (if change from true to false, context is removed from NexusIndexer, if changed from false to true, context is being created). This case was not handled, and groups (who's member was made non-indexable) was still containing and handing over a "stale", already shut down context to indexer components. In other words, with original change, the list remain unchanged, even if the context was shut down and removed from NexusIndexer, but group continued to use it, that caused NPE (IndexSearcher is closed and nullified on shut down contexts), but also some cleanup problem exists in MI and NPE caused IllegalMonitorState (NPE happened during locking, so not all context were actually locked, but against all were unlock tried). Now, repository updates are propagated to groups where it is contained. Added UT that tests exactly this case: making a repo from indexable to non-indexable and back to indexable, while verifying that it's group is not running into those sort of problems.
Signed-off-by: Igor Fedorenko <firstname.lastname@example.org>
…embers. At least during search processing is running. As it is now, it is directly hooked onto group, that if group changed during search, causes to have different repositories locked or unlocked. In case of member addition, an IllegalMonitorStateEx would happen (a non-locked context would be unlocked) and in case of member removal, the context of removed member would remain locked. There was an UT testing exactly this case, but for some reason it was commented out. Test returned, code updated and added more checks and explanations in comment. Method setRepositoryIndexContextSearchable() was called when it was actually not needed.