metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ottobackwards <>
Subject [GitHub] metron pull request #739: METRON-1165 [FEATURE-BRANCH] Add ability for Bundl...
Date Fri, 08 Sep 2017 15:03:07 GMT
GitHub user ottobackwards opened a pull request:

    METRON-1165 [FEATURE-BRANCH] Add ability for BundleSystem to add bundles after initialization

    As part of supporting parser extensions and the bundle system hosted in other applications
than storm, and specifically for hosting in the rest service, we need the ability to add new
bundles to the system, preferably without requiring an application restart or reloading the
entire system.
    The use case:
    1. Install a parser extension assembly from the extension ui
    2. switch to the sensor ui
    3. create new instance (+) and be able to use the parser(s) from the assembly you just
    This PR lays down the ground work for that capability, and will be integrated with the
extension ui branch if or when taken to the Feature Branch.
    In this PR I further refactor the original NIFI Nar concept of Initial Context, which
is used in the BundleClassLoaders and the ExtensionManager.  I have moved the context to full
classes, and moved their creation to those classes in a Builder implementation.
    This allows the creation of multiple 'contexts' with different parameters and scopes.
    I have also added the ability to merge one context into another.
    Thus the idea is that:
    - these classes have their initial context from the full scan of the bundle system library
    - adding a new bundle means on demand creation of a new context, for just that bundle
    - we merge the bundles to make the new content available
    The addXXXX capability is limited availability ( it is ```java protected ``` ).
    It's only public facing exposure is through the BundleSystem class.
    BundleSystem is the 'easy button', simplified interface to the bundles, and should be
in most cases the only interface required.  Exposing it this way allows us to be sure that
the ADD calls are only called in a context where we can do the type of locking we want to
    ## Testing
    This is a preparation PR.  The add functionality is not utilized outside the tests.
    So this is a code review, no regressions check.
    - Build and Tests should run
    - Full Dev should start and have data in kibana ( no regression )
    - [x] Is there a JIRA ticket associated with this PR? If not one needs to be created at
[Metron Jira](

    - [x] Does your PR title start with METRON-XXXX where XXXX is the JIRA number you are
trying to resolve? Pay particular attention to the hyphen "-" character.
    - [x] Has your PR been rebased against the latest commit within the target branch (typically
    - [na] Have you included steps to reproduce the behavior or problem that is being changed
or addressed?
    - [na] Have you included steps or a guide to how the change may be verified and tested
    - [x] Have you ensured that the full suite of tests and checks have been executed in the
root metron 
    - [x] Have you written or updated unit tests and or integration tests to verify your changes?
    - [na] If adding new dependencies to the code, are these dependencies licensed in a way
that is compatible for inclusion under [ASF 2.0](

    - [x] Have you verified the basic functionality of the build by building and running locally
with Vagrant full-dev environment or the equivalent?

You can merge this pull request into a Git repository by running:

    $ git pull ext-bundle-add

Alternatively you can review and apply these changes as the patch at:

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #739
commit 4d294b9b5ea646e38f2ae6072e6f7f83277d65aa
Author: Otto Fowler <>
Date:   2017-09-08T05:35:05Z

    implement ability to add new bundles to system



View raw message