23 Oct, 2014

11 commits


22 Oct, 2014

1 commit


21 Oct, 2014

7 commits

  • Thanks @Matt for noticing
    
    git-svn-id: https://svn.forgerock.org/openig/trunk@641 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    guillaume.sauthier
     
  • git-svn-id: https://svn.forgerock.org/openig/trunk@640 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    guillaume.sauthier
     
  • git-svn-id: https://svn.forgerock.org/openig/trunk@639 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    guillaume.sauthier
     
  • This decorator can be applied on any Filters or Handlers whose
    input/outputs needs to be observed.
    
    This decorator prints the message's values in the observed
    component's logSink or in its own configurable logSink (if one
    was specified).
    
    Multiple observation points can be specified depending on what you're
    interested in.
    
    Observation points for Filter:
                                ---
              -- (request) ->  |   | -- (filtered-request) ->
                               | F |
     <- (filtered-response) -- |   | <- (response) --
                                ---
    
    Observation points for Handler:
                       ---
     -- (request) ->  |   |
                      | H |
     <- (response) -- |   |
                       ---
    
    git-svn-id: https://svn.forgerock.org/openig/trunk@637 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    guillaume.sauthier
     
  • git-svn-id: https://svn.forgerock.org/openig/trunk@636 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    guillaume.sauthier
     
  • Decorators have the unique capability of transforming heap objects: they
    can encapsulate the original object into another compatible one (they
    still have to share the same interface), they can post-configure
    instances, ...
    
    Two levels of decorations are supported: per-instance and global.
    
    Global decoration allows to share widely a decoration for all objects
    managed inside of a Heap. This is very useful to avoid writing the same
    decoration over and over for each heap object.
    
    Per-instance decoration permits to selectively apply decoration on some
    instances. That can be very useful if you want to focus on a given heap
    object, without impacting others.
    
    Here is an example of decoration configuration for an instance:
    
        {
          "name": "Handler",
          "type": "ClientHandler",
          "capture": "request" <-- the decoration
        }
    
    An arbitrary number of decorations can be applied on any instance.
    
    The attribute name has to match a heap object name of the wanted decorator.
    The attribute value is the configuration that will be passed to the
    decorator when asked to decorate the heap object instance.
    
    Decorators have to be declared in the /heap/objects list, just like
    any other heap objects. The name of a decorator is the key that will be
    used to lookup the right decorator in the heap when decorations are
    processed.
    
    Global decorations are Heap-scoped decorations: all heap objects
    provided/managed by a given Heap will be decorated with that special
    decorator. They are inherited between heaps.
    
    Global decorations are enabled when a /heap/decorations object in the
    JSON configuration (system config or route config) is found. Each
    attributes of that object are representing a decoration configuration
    to be applied on heap objects.
    
    Example of global decoration configuration:
    
        {
          "heap": {
            "objects": [ ... ],
            "decorations": {
              "decorator-name": a JSON node representing the decoration config
              ...
            }
          }
        }
    
    Notice that, in order to prevent infinite recursions, decorators cannot
    be decorated themselves.
    
    git-svn-id: https://svn.forgerock.org/openig/trunk@635 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    guillaume.sauthier
     
  • This case can happen when a component tries to resolve twice the same
    object declaration.
    
    This is unlikely to happen without any decorator support because all the
    heap interactions are going on in one place and it's easy to refactor the
    code to only resolve a declaration once.
    
    But when decorators comes into play, it's no more easy to share resolved
    objects references around.
    
    git-svn-id: https://svn.forgerock.org/openig/trunk@634 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    guillaume.sauthier
     

15 Oct, 2014

3 commits

  • - Reorganized imports.
    - Removed extra spaces.
    - Closed previously 'omitted' inputstreamreader in RouteBuilder.
    (OPENIG-312)
    
    git-svn-id: https://svn.forgerock.org/openig/trunk@623 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    violette
     
  • Consider using Jackson for parsing the JSON configuration
    - Renamed JsonValueUtil to Json.
    - Renamed JsonValueUtilTest to JsonTest.
    
    git-svn-id: https://svn.forgerock.org/openig/trunk@622 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    violette
     
  • configuration
    
    - Remove json simple from openig pom file configuration. (added com.fasterxml.jackson.core / databind)
    - Jackson throws now IOExceptions instead of json exceptions.
    - Added unit tests.
    - Fixed javadoc.
    
    git-svn-id: https://svn.forgerock.org/openig/trunk@621 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    violette
     

01 Oct, 2014

1 commit


24 Sep, 2014

2 commits


17 Sep, 2014

1 commit


16 Sep, 2014

1 commit


15 Sep, 2014

4 commits

  • matthew
     
  • It was misplaced in the openig-core module where it was used in openig-war module.
    
    git-svn-id: https://svn.forgerock.org/openig/trunk@573 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    guillaume.sauthier
     
  • Heap.get(String):Object gains type safety
    
        Heap.get(String, Class<T>):T
    
    Heap.getRequiredObject(JsonValue, Class<T>) has a shorter name
    
        Heap.resolve(JsonValue, Class<T>):T
    
    Heap.getObject(JsonValue, Class<T>) is replaced by a resolve
    variant that supports optional dependencies:
    
        Heap.resolve(JsonValue, Class<T>, boolean):T
    
    git-svn-id: https://svn.forgerock.org/openig/trunk@572 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    guillaume.sauthier
     
  • Inline object declarations are a mean to ease understanding of
    Exchange processing.
    They permit to describe anonymously, inner objects when a reference to
    another heap object is required. That introduce, in the configuration
    files, some hierarchical support, easing the user to mentally
    represents his processing chain.
    
    This is done in a fully backward compatible way, without requiring any
    changes to existing object declarations (the one that requires other
    objects through references or names).
    
    The idea is to automatically extract inline declaration when the Heaplet
    is calling the get***Object() methods: if the provided JsonValue is a
    String, traditional object lookup is performed, but when the JsonValue
    represents a JSONObject (a Map), we try to turn this into a normal
    object declaration (just like what is done during heap initialisation).
    If the given JsonValue does not describe a valid declaration, a
    JsonValueException is thrown (again, just like the heap init process
    is doing).
    
    Notice that inline declarations do not require a 'name' attribute to
    be specified (like anonymous Java classes), so we generate a unique name
    based on the JsonPointer (represents the location of the node in
    the JSON structure).
    
    Notice that OPENIG-316 is partly resolved in this commit: HeapUtil methods
    have only been moved into the Heap interface: no additional type safety,
    no renaming.
    
    git-svn-id: https://svn.forgerock.org/openig/trunk@571 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    guillaume.sauthier
     

10 Sep, 2014

1 commit

  • OpenIG used to provide a default Session implementation based on the
    underlying Servlet container's HttpSession. This changeset intends to
    gives to the user the ability to change the session persistence
    strategy (in other words: changing the Session implementation).
    
    This can be done at the global level (in the config.json, declaring a
    SessionFactory object named 'Session') or on a per-route basis (with the
    new 'session' attribute).
    When an Exchanges comes into a route that declares a new session type, a new
    session is build (no existing session items are propagated) and replace
    the old session. When the exchange exits the route, the new session is closed
    (notify the session that it's time to persist its content) and is replaced
    by the old one. Really like a push/pop stack mechanism.
    
    Notice that the 2 sessions are completely separated (cannot access the old
    content from the new and vis-versa). First, that would defeat the purpose of
    different session persistence modes (if items are propagated, where should
    I persist them ?). Secondly, Session is not intended to share data between
    handlers/filters: the Exchange is basically a request-scoped Map that is
    designed for that purpose.
    
    The JWT based session is a session implementation whose persistence is done
    using an HTTP Cookie, the session's content being serialized as JSON (usable
    types are constrained, see list below) and used as the payload of an
    encrypted JSON Web Token (JWT).
    
    The use of the JWT session has a few constraints:
     * HTTP Cookies are size-limited to 4K -> Small objects can be stored
     * Only JSON compatible types are supported:
        * null
        * Java primitive types + their boxed equivalent
        * Strings (and any CharSequence)
        * List and Map (of the supported types, recursively)
     * Same client performing concurrent HTTP invocations (so within the
       same HTTP session) that will modify their own session content will
       see inconsistencies in the session. This is due to the fact that the JWT
       session is not shared, each concurrent Thread has its own instance and
       can modify it at will. At the end of the processing, each Thread will
       serialize its own session's content regardless of other Threads.
    
    git-svn-id: https://svn.forgerock.org/openig/trunk@565 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    guillaume.sauthier
     

08 Sep, 2014

3 commits


05 Sep, 2014

5 commits

  • To keep backward compatibility, 'keystone' and 'truststore' are left
    unchanged but have been deprecated.
    We've added 2 new attributes to specify reference(s) to TrustManager(s)
    and KeyManager(s) declared as heap objects.
    
    Issues: OPENIG-305
    
    git-svn-id: https://svn.forgerock.org/openig/trunk@560 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    guillaume.sauthier
     
  • This change eases references resolution when they are provided as a JSON
    String array (like ["RefOne", "RefTwo"]).
    
    git-svn-id: https://svn.forgerock.org/openig/trunk@559 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    guillaume.sauthier
     
  • The two referenced service implementations do not exist (anymore ?).
    And the service file name was incorrect (no HeapletService interface
    exist).
    
    git-svn-id: https://svn.forgerock.org/openig/trunk@558 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    guillaume.sauthier
     
  • KeyStore and related security objects are being more and more central
    to OpenIG:
     * Used by HttpClient
     * Needed for encryption / decryption
    
    This patch is a first step to provide a way to configure theses as
    usual heap objects (through JSON).
    
    KeyStore heap object is an abstraction around the keystore file (either JKS,
    PKCS12 or other depending on the platform capabilities).
    Specifying a password or not depends on he usage:
     * If KeyStore will be used to read private credentials (through a
       KeyManager for example), a password is required
     * If not (for a TrustManager), no password is required
    
    KeyManager and TrustManager are using a KeyStore heap object and
    are used within SSL mechanism (SSLContext) to provide a view on the KeyStore:
     * KeyManager when private credentials access is required.
     * TrustManager when only public information access is required
    
    Issues: OPENIG-295
    Reviews: CR-4441
    
    git-svn-id: https://svn.forgerock.org/openig/trunk@557 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    guillaume.sauthier
     
  • The previously introduced evaluate() method was a step in the right
    direction, allowing resolution of static (no references to ${exchange})
    string JsonValue, returning a simple resolved String.
    While it works great, it's a shame that we don't benefit anymore of the
    JsonValue API, in particular the conversion methods (asURL(), ...).
    
    This fix uses a JsonTransformer to actually resolve any String wrapped
    JsonValue and creates a deep copy of the given JsonValue.
    
    git-svn-id: https://svn.forgerock.org/openig/trunk@556 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    guillaume.sauthier