23 Oct, 2014

12 commits


22 Oct, 2014

2 commits


21 Oct, 2014

8 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
     
  • git-svn-id: https://svn.forgerock.org/openig/trunk@638 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

4 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
     
  • git-svn-id: https://svn.forgerock.org/openig/trunk@620 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    mark
     

10 Oct, 2014

1 commit


09 Oct, 2014

1 commit


08 Oct, 2014

1 commit


06 Oct, 2014

1 commit


01 Oct, 2014

1 commit


25 Sep, 2014

4 commits


24 Sep, 2014

4 commits


23 Sep, 2014

1 commit