Using Pax Logging as logging infrastructure
Alin Dreghiciu
Very good initiative. I was thinking myself to fire up such a project
but now that you did it I guess is better to help out over here.
So, first thing is about logging infrastructure. As I can see you
opted for going the SLF4J way.
My suggestion is to switch to Pax Logging http://wiki.ops4j.org/confluence/x/F
as this project was created to fill in this need in OSGi world. Beside
supporting the API you mention also supports some other ones, that
people may be using. Beside that Pax Logging is also an OSGi specs
implementation of logging service.
Another plus of Pax Logging is that being made for OSGi supports
configuration via Configuration Admin.
Alin Dreghiciu
Hendy Irawan
> Hi guys,
>
> Very good initiative. I was thinking myself to fire up such a project
> but now that you did it I guess is better to help out over here.
Looking at the ModuleFusion structure, I can see some similarity (or
overlap) compared to:
1. Pax Construct
2. Apache ServiceMix (Kernel)
3. Spring-DM Target Platform
I may be wrong, but developing with ModuleFusion seems to means "cut
what you don't want, then add the ones you want /manually/"
ModuleFusion seems to be somewhere between a quickstart and a
enterprise infrastructure. However for "enterprise" I don't think it's
current approach works well. There has to be dependency management and
a way of adding/removing necessary libraries in a more robust manner
(e.g. Maven) instead of drag and dropping things to 'load' dir...
Although, 'load' dir is a very good thing since that's what we all use
in deployment scenario (ServiceMix and SpringSource dm server take
this approach). However for development scenario it needs a better of
generating the artifacts that will get deployed.
Actually right now my thinking is forking for this topic alone.......
I'm suggesting that:
1. Pax Construct should be a base (for creating a ModuleFusion
project), with an archetype approach, rather than "extracting a zip".
Because a 'zip' can be created using the results of an archetype +
required parts of local repo, the reverse is not true. This makes it
easy to fiddle with the libraries that can be included in the
resulting project. Like AppFuse. Current approach is "somewhat
monolithic"
2. Pax Construct comes with Pax Runner as a bonus, therefore Felix/
Equinox/Knopflerfish is supported out of the box without further
messing around. If need be, a 'mega dist' can be created which
includes all these implementations (selectable at runtime) and zipped.
Users downloading the modulefusion zip won't need to download anything
anymore.
3. Apache ServiceMix becomes a base for deployment (Pax Construct is
base for development). ServiceMix has lots of nice functionalities,
like superb admin console and "auto-wrapping" of non-OSGi JARs
(similar to SpringSource dm Server).. however this feature should be
disable-able if strict OSGi mode is needed. ServiceMix closely
collaborates with Felix, but it can work with Equinox as well. IMHO
ServiceMix has a very aligned goal with ModuleFusion, both enable
"component based development". Just drop the thing and away you go.
ServiceMix Kernel is very small (5.3 MB at the moment), it's smaller
than ModuleFusion dist actually and has overlapping bundles.
4. ServiceMix uses Pax-Logging... :-) I am biased, but Pax-Logging is
better than them all. :) Please let go of SLF4J and say welcome to Pax
Logging. Pax Logging supports all these logging APIs anyway so in my
estimates Alin's suggestion should be a trivial change. Pax Logging
also has excellent free support, most bugs are solved within less than
24 hours (thanks Alin :-)