Pax Logging Service log4j packages

[Raúl Kripalani]

Hey guys,

The pax-logging-service bundle embeds log4j inside of it, but doesn't export anything. Is this by design? Can we export the log4j classes?

Basically this means that we have all of log4j present in the environment, but other bundles are unable to access its classes if, for example, they want to use classes from packages:

* org.apache.log4j.varia, e.g. to use or extend LevelMatchFilter, or LevelRangeFilter, etc.

* org.apache.log4j.pattern, e.g. to create new pattern converters, etc.

I am OSGifying an applications where one of the modules configures log4j programmatically, and it requires all these items. It ultimately calls Logger.getRootLogger() or Logger.getLogger(...) to get a hold of the actual Logger, so in theory this would wire it to Pax Logging, but it then configures the appenders, patterns, filters, etc. programmatically.

Thanks for your help,

Raúl.

[Niclas Hedhman]

This is on purpose. The reason is that log4j is hopeless in defining a "private" and a "public" part, or API if you like. I had that discussion with Ceki already in 2003/2004, and at the time he had no clue what I (representing Apache Avalon at the time) was talking about. But something must have sunk in, since he later created SLF4j and Logback, the proper separation of concerns.

Now, for Pax Logging, the "defined" API of log4j was initially from examining a dozen or more projects on what was used. The Log4j API in Pax Logging is also not the unmodified code of Log4j, as it needs to support the OSGi environment AND allow for different backends (such as Logback or java.util.logging).

So, we add more API parts on use-case basis. Present what you would like to use, and then we should be able to make that available in Pax Logging's Log4j's API.

Hope that helps

Niclas

--
--
------------------
OPS4J - http://www.ops4j.org - op...@googlegroups.com

---
You received this message because you are subscribed to the Google Groups "OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ops4j+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

[Raúl Kripalani]

Hey Niclas,

Thanks for your quick reply. I'm also a committer @ OPS4j and I understand the separation of concerns basis, but of course it comes with a trade-off.

In this case it blocks the ability to interact with log4j programmatically, at least for advanced use cases like using the varia package. It doesn't appear to hinder the implementation of new Filters, Appenders, etc. because the basic APIs are exported.

The question is: what are the actual benefits of imposing this limitation? I think here the 80/20 Pareto Law applies: 80% of the framework is not used by most people, but hiding it poses an obstacle for the remaining 20%.

So at this point of maturity of Pax Logging, I think we may want to open up the framework to more advanced use cases, without jeopardising the separation of concerns if possible. What I'm thinking of is a Fragment Bundle that attaches to pax-logging-service and exports all of log4j's packages. Users requiring advanced use cases can just install this fragment. (I recall that a fragment can inject export headers to the host, right?).

The "ignitor" (pun intended) of this question is that I'm working on making Apache Ignite [1] deployable on OSGi, and we have a module called ignite-log4j which basically establishes some custom loggers and appenders programmatically.

[1] http://ignite.apache.org

Regards,

Raúl.

[Achim Nierbeck]

Hi Raul, 

good to see you again :)

unless something changed in the osgi-framework a fragment bundle still can "manipulate" the host export and import packages. Therefore your approach of opening some of the internal packages to your needs sounds as a reasonable idea. 

In your special case I'd start with such a fragment bundle with the apache-ignite project. 

If you see a broader use-case where a lot more people could participate from let's think of it to move it to ops4j. 

just my 2 cents to get you going fast :-)

regards, Achim 

Apache Member

Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead
blog <http://notizblog.nierbeck.de/>

Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master 

[Niclas Hedhman]

Sorry for not being so quick this time...

The reason for the limitation is to have a clear picture of what should be supported from one release to the next, having the confidence knowing what can be modified in the Log4j classes without impacting users.

Over the years, many things have been added, and it is not out of the question to do additional ones.

I never learned Fragments very much, but if Achim is correct, then that would be an option.

Since you have use-cases, and the target is well-known and understood, then I suggest that you bring them forth one by one, and we make a decision if it is reasonable request. Blanket opening of "everything" is something I strongly dislike. Note that Log4j is forked, and not using the original sources.

You mention custom Loggers and custom Appenders. The latter is indirectly supported via org.ops4j.pax.logging.spi.PaxAppender, but "native" Log4j appenders are not. Again, this was done so that when one changes the backend (now there is 3 in the works), the appender doesn't have to be re-written.
Guillaume knows a lot more about this, as he fixed up what I once started.

If you are willing to explain what you would like to do with respect to customer Loggers, I think that is a point of discussion. As I have no idea what you are using it for, I can't really comment on a Pax Logging-friendly approach to add the feature you crave.

Cheers

Niclas

[Niclas Hedhman]

By the way, congrats to the graduation out of the Incubator of Ignite. I think Hazelcast is, and rightly so, a bit worried about this outcome. ;-)

Also, you guys haven't done the DOAP file, so you don't show up on http://projects.apache.org. The info about it is at https://projects-old.apache.org/doap.html (see left side bar for instructions and more). In essence, a doap.xml file in subversion site directory and an entry in some global file pointing to it.

Niclas