Petals Distribution

Commited, now we just need to add configurability through the handler's configuration.

Ok, actually this is wrong, we go back to the first idea: having one pool for the logger handler and keeping petals-log in the system classloader: it's too much complex to change this constraint (it would mean entering in the complexity of the LogManager).

This could change in the future when switching to something like slf4j (see PETALSDISTRIB-135).

EDIT: ALL OF THIS IS ABANDONED, SEE NEXT COMMENT

So, that's not good enough: we should move petals-log to the kernel classloader and remove it from the system classloader where only petals-commons-log would stay (amongst other things).

This means providing our own subclass of LogManager responsible of:

• Doing what org.ow2.petals.microkernel.server.PetalsServerImpl.initializeLogging() and org.ow2.petals.launcher.PetalsLauncher.setLogingSystemConfigurationFile(Configuration) are currently doing.
• Loading the handlers from within the kernel classloader and not the system classloader as currently done by LogManager.

But also we should support adding extra handlers, such as petals-log-mongodb, with an easy procedure:

• Adding the jar to the lib or extension or whatever directory
• Configuring the logging.properties file with the handler

Resolved for real: the kernel, just before setting up the logging system, will inject in PetalsPayloadDumperFileHandler (the handler that needed to access the Transformers pool before) a helper that delegate to the kernels classloader's SourceHelper and thus Transformers pool.

No more code duplication for SourceHandler and a shared Transformer pool with the kernel, which makes sense since the logging system is kind of part of the kernel.
The only reason we have to do that is that LogManager, the thing that instantiate the Handler, needs them to be instantiated in the system classloader, for security reasons mostly.

It's better to use a pool of transformers in petals-log