org.forgerock / org.forgerock.openig

07 Nov, 2014

5 commits

  • 70a47970   OPENIG-338 ... Browse Dir » 
    Wrong charset used in Entity class
- Added static UTF_8 Charset.
- Replaced newDecodedContentReader(null)
by newDecodedContentReader(UTF_8) in entity#getJson.

git-svn-id: https://svn.forgerock.org/openig/trunk@695 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    violette
     
  • 61cbf492   OPENIG-264 Supports zero-length Durations ... Browse Dir » 
    That will be useful to support deactivation marker values when configuring cache timeouts.

This fix support both `zero` and `disabled` as zero-length Duration markers.
When the parsed String value also represents a zero-length duration (like `0 days and 0 ms`),
the special ZERO marker duration is returned.

Updated documentation as well.

git-svn-id: https://svn.forgerock.org/openig/trunk@692 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    guillaume.sauthier
     
  • 2fd96997   OPENIG-371 (CR-5157) Expose the source Name to the Logger API ... Browse Dir » 
    In order to facilitate OPENIG-370 (log simplification), we now expose the Name
of the log source to the Logger. This has a number of implications:
 * `LogEntry.source` has been splited into the `source` and `type` attributes.
source being the original Name and type being the type of the entry (like
`log`, `started`, `elapsed`, ...). Log messages have the `log` type and
exception's messages have the `throwable` type.
 * Logger is no more a LogSink implementation
 * LogEntry has been adapted to directly use Logger instead of LogSink (this way
it can benefit of the Logger.source attribute's value automatically)
 * Logger do not "rebase" the source name anymore: can't do that since source
is not a String anymore.
 * That solves the source duplication issue of OPENIG-370

LogSink interface has been adapted to have a source Name instead of a source
String when trying to determine if something is legible.

LogSink implementations (ConsoleLogSink and FileLogSink) have been changed to
keep an output as close as possible as what we have previously (don't want to
work on OPEN-370 yet).

git-svn-id: https://svn.forgerock.org/openig/trunk@689 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    guillaume.sauthier
     
  • 46839327   OPENIG-371 (CR-5157) Support hierarchical names to uniquely identify heap objects ... Browse Dir » 
    A Name is a recursive object based on a leaf name and a parent Name.

Each Heap as a unique Name used to scope names of the managed heap objects.
Each heap object has a unique Name whose parent is the container Heap.

The Heaplet interface has been updated to give the Name instead of just a String.

The name of each created heap is based on the resource name.

git-svn-id: https://svn.forgerock.org/openig/trunk@688 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    guillaume.sauthier
     
  • 397990d0   OPENIG-320 CR-5181 Rename KeyStore 'file' option to 'url' ... Browse Dir » 
    git-svn-id: https://svn.forgerock.org/openig/trunk@687 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    matthew
     

06 Nov, 2014

1 commit

05 Nov, 2014

1 commit

04 Nov, 2014

1 commit

03 Nov, 2014

2 commits

31 Oct, 2014

2 commits

30 Oct, 2014

4 commits

29 Oct, 2014

1 commit

  • 6f011d88   OPENIG-358 (CR-5060) Improve generated names for inline object declarations ... Browse Dir » 
    Although the JSON pointer is sufficient to guarantee unicity of a name
within the scope of a heap, it makes it hard for reader to link that name
to the configuration object they provided.

This patch supports both improvements:
* if a `name` attribute is provided in the declaration, use it as-is
* if not, prepend the `type` attribute value to the pointer String to help identification

This patch also updates the logs samples provided in the documentation.

git-svn-id: https://svn.forgerock.org/openig/trunk@666 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    guillaume.sauthier
     

24 Oct, 2014

5 commits

23 Oct, 2014

10 commits

22 Oct, 2014

1 commit

21 Oct, 2014

7 commits

  • a9828d1f   Oops, wrong alias ... Browse Dir » 
    Thanks @Matt for noticing

git-svn-id: https://svn.forgerock.org/openig/trunk@641 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    guillaume.sauthier
     
  • fe489077   OPENIG-347 CaptureFilter is now deprecated in favor of "capture" decoration ... Browse Dir » 
    git-svn-id: https://svn.forgerock.org/openig/trunk@640 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    guillaume.sauthier
     
  • b68d4ec6   OPENIG-299 Provide a default 'capture' decorator instance ... Browse Dir » 
    git-svn-id: https://svn.forgerock.org/openig/trunk@639 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    guillaume.sauthier
     
  • 3c08dd4c   OPENIG-299 (CR-4904) Add capture decoration for Filter/Handler ... Browse Dir » 
    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
     
  • dfbe06f1   Introduce Json.ofEnum(Class<T> enumType) to transform JsonValue list to list of Enums ... Browse Dir » 
    git-svn-id: https://svn.forgerock.org/openig/trunk@636 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    guillaume.sauthier
     
  • ae05730f   OPENIG-340 (CR-4904) Introduce heap object decorators. ... Browse Dir » 
    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
     
  • c4e17004   Supports multiple declaration resolution. ... Browse Dir » 
    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