Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
branch: jmx
Commits on Oct 7, 2012
  1. @jdillon
Commits on Oct 6, 2012
  1. @jdillon
Commits on Oct 5, 2012
  1. @jdillon

    Merge pull request #558 from sonatype/NXCM-4737-include-custom-query-…

    jdillon authored
    …strings-via-builder
    
    [NXCM-4737] hack in query-string customizations via QueryStringBuilder s...
  2. @cstamas

    Merge pull request #560 from sonatype/httpclient4x-bump

    cstamas authored
    HttpClient 4x being slow with HTTPS connections.
Commits on Oct 4, 2012
  1. @cstamas

    HttpClient 4x being slow with HTTPS connections.

    cstamas authored
    * 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
  2. @adreghiciu

    Merge pull request #557 from sonatype/log-remote-access-time

    adreghiciu authored
    Log timing of http remote requests made by Nexus
  3. @adreghiciu

    Merge pull request #559 from sonatype/nxcm-4721-validate-same-member-…

    adreghiciu authored
    …multiple
    
    [NXCM-4721] Validate that for a group, member repositories list is unique
  4. @adreghiciu

    [NXCM-4721] Validate that for a group, ember repositories list is uni…

    adreghiciu authored
    …que (no same member repository multiple times)
    
    Signed-off-by: Alin Dreghiciu <adreghiciu@gmail.com>
Commits on Oct 3, 2012
  1. @jdillon

    Update headers

    jdillon authored
  2. @jdillon

    [NXCM-4737] hack in query-string customizations via QueryStringBuilde…

    jdillon authored
    …r so that remote browsing secure.central gets the proper request paramemters.
  3. @nabcos

    Unset public key path in legacy ITs nexus.properties

    nabcos authored
    ITs started failing because they could not read the encrypted problem
    report bundles' content.
  4. @cstamas
  5. @peterlynch

    Merge pull request #556 from sonatype/nexus-5288

    peterlynch authored
    NEXUS-5288: Appender class changed.
  6. @adreghiciu @cstamas

    Log timing of http remote requests made by Nexus

    adreghiciu authored cstamas committed
    Signed-off-by: Alin Dreghiciu <adreghiciu@gmail.com>
  7. @peterlynch

    Merge pull request #538 from sonatype/nexus-5197-avoid-npe

    peterlynch authored
    [NEXUS-5197] Avoid NPE in member change detection
  8. @peterlynch

    fix license headers

    peterlynch authored
  9. @peterlynch

    allow running (JUnit) tests named Abstract* that are not 'abstract'

    peterlynch authored
    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
  10. @cstamas

    NEXUS-5288: Appender class changed.

    cstamas authored
    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.
Commits on Oct 2, 2012
  1. @nabcos

    Move public key path for problem reporting to nexus-webapp

    nabcos authored
    nexus.properties is only contained in the nexus bundles, while the
    webapp's plexus.properties are already set when running the Nexus WAR.
  2. @nabcos
  3. @nabcos
  4. @cstamas

    Updated readme

    cstamas authored
  5. @cstamas

    NEXUS-5286: updated README

    cstamas authored
  6. @cstamas

    Merge pull request #554 from sonatype/nexus-5280

    cstamas authored
    NEXUS-5280: ContextMemberProvider should always return same list of members
  7. @cstamas
  8. @nabcos
Commits on Oct 1, 2012
  1. @cstamas
  2. @cstamas

    NEXUS-5280: Fixing "look ahead" problem.

    cstamas authored
    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.
  3. @cstamas

    NEXUS-5280: ContextMemberProvider should always return same list of m…

    cstamas authored
    …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.
Commits on Sep 28, 2012
  1. @ifedorenko

    disable unit and integration tests during release by default

    ifedorenko authored
    Signed-off-by: Igor Fedorenko <igor@ifedorenko.com>
  2. [maven-release-plugin] prepare for next development iteration

    Sonatype Release Machine authored
  3. [maven-release-plugin] prepare release nexus-2.2

    Sonatype Release Machine authored
  4. @cstamas

    Merge pull request #553 from sonatype/nexus-5280

    cstamas authored
    NEXUS-5280: ContextMemberProvider should always return same list
  5. @cstamas

    NEXUS-5280: ContextMemberProvider should always return same list of m…

    cstamas authored
    …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.
Commits on Sep 27, 2012
  1. @adreghiciu

    Merge pull request #552 from sonatype/nexus-it-support

    adreghiciu authored
    Simple change to make ITs work
Something went wrong with that request. Please try again.