Thank you for detailed explanation. If it is interesting I can say what names I would choose. I would call pax-logging-api as pax-logging-core and pax-logging-service as pax-logging-extension. Why - because core can function without extension and has core functionality. And extension can't function without core and adds some new functionality. Please, note, that I don't say that the names you choose are wrong. I just say how I would do that. I can add the following information. I in my app had only pax-logging-api. And I couldn't understand what logged the information to console. I've checked all other libraries I use to see if they include some logging functionality. And that was one of the reason I started this thread.
Consider my notes as small feedback from user. Thanks for good library. On Sunday, 28 August 2016 04:34:34 UTC+3, Niclas Hedhman wrote: > > > The assumption is that Pax Logging API bundle was stable enough to not > undergo fixes in the "6 month" horizon that we were working with, and that > the bug fixes we needed were effectively all in the Service. > > A nice sideeffect is also that you should be able to swap from Log4j to > Logback to fully custom without stopping anything. But that was not a > primary driver for us at that time. > > But generally speaking, I like the principle that "nothing stops" when > upgrading bundles, other than the bundle being upgraded. > > Cheers > Niclas > > On Sat, Aug 27, 2016 at 10:51 PM, iJava <[email protected] > <javascript:>> wrote: > >> Thank you for your explanation. Do I understand you right - you assume >> that no one will update logging-api bundle? >> >> On Saturday, 27 August 2016 13:28:29 UTC+3, Niclas Hedhman wrote: >>> >>> >>> When OSGi refreshes a bundle, all dependent bundles are stopped. And a >>> when this developed originally, one of the requirements in a critical >>> project. And since the logging is a dependency of almost every other >>> bundle, I needed to make the service depend on API and all other bundles >>> only depend on API bundle. >>> >>> That way, we were able to upgrade the Service bundle without stopping >>> the application (no other bundle stopping) at all, and that was the >>> objective. >>> >>> Cheers >>> Niclas >>> >>> On Sat, Aug 27, 2016 at 4:15 PM, iJava <[email protected]> wrote: >>> >>>> Then could you explain the reason for separating to two bundles - api >>>> and service. if api can do something then is not api. Maybe it is better >>>> to >>>> put them in one bundle >>>> and avoid such difficulty? >>>> >>>> On Saturday, 27 August 2016 05:12:34 UTC+3, Niclas Hedhman wrote: >>>>> >>>>> IIRC, there is also an subtle detail in the API vs Service >>>>> interaction, in that the API will continue to "function" with a missing >>>>> service (to allow for refreshing the service bundle without stopping >>>>> everything). I don't remember the final solution I put in, but there were >>>>> at least 3 options being evaluated (buffer, wait and toStdOut). >>>>> >>>>> Should check what is actually being done by default. >>>>> >>>>> Niclas >>>>> >>>>> On Thu, Aug 25, 2016 at 7:26 PM, Marc Schlegel <[email protected]> >>>>> wrote: >>>>> >>>>>> You should start pax-logging as early as possible. The bundles which >>>>>> are logging (e.g. pax-web) do not care if a log-service is available, >>>>>> they >>>>>> will just print to the console until pax-logging is ready. >>>>>> >>>>>> When using BndTools you can arrange the startorder in the >>>>>> runbundles-list. Beware though that the order is changed when resolving >>>>>> the >>>>>> bundles. This has been fixed for the upcoming release 3.3) >>>>>> >>>>>> >>>>>> Am Donnerstag, 25. August 2016 13:14:30 UTC+2 schrieb iJava: >>>>>>> >>>>>>> Hi Achim, >>>>>>> >>>>>>> Thank you for feedback. I think that felix.fileinstall and >>>>>>> felix.configadmin need some time. Somehow this way... >>>>>>> >>>>>>> On Thursday, 25 August 2016 13:59:50 UTC+3, Achim Nierbeck wrote: >>>>>>>> >>>>>>>> Might be, in Karaf the Pax-Logging bundles are started quite early >>>>>>>> ... >>>>>>>> >>>>>>>> regards, Achim >>>>>>>> >>>>>>>> >>>>>>>> 2016-08-25 12:19 GMT+02:00 iJava <[email protected]>: >>>>>>>> >>>>>>>>> I solved my problem. The issue was that pax-logging and log4j are >>>>>>>>> not immediately ready after pax logging api and service bundle >>>>>>>>> started. >>>>>>>>> They need some time (1-3 seconds). >>>>>>>>> >>>>>>>>> I installed and started bundles one by one, and some bundles >>>>>>>>> stated they logging before pax-logging was ready - that's why I got >>>>>>>>> DEBUG >>>>>>>>> messages when I didn't want to get them. >>>>>>>>> Now I changed the sequence of bundle management and everything >>>>>>>>> seems to be fine. >>>>>>>>> >>>>>>>>> Are my explanations of the problem right? >>>>>>>>> >>>>>>>>> On Wednesday, 24 August 2016 23:44:55 UTC+3, iJava wrote: >>>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> Could someone explain 1)what is >>>>>>>>>> org.ops4j.pax.logging.DefaultServiceLog , 2) how it is related with >>>>>>>>>> my >>>>>>>>>> configs for log4j and 3) what values >>>>>>>>>> it can have besides WARN and INFO. >>>>>>>>>> >>>>>>>>>> I ask, because when I don't set it via system parameter to WARN >>>>>>>>>> OR INFO I get about 56000 lines of DEBUG. >>>>>>>>>> Even if I set it to FATAL I anyway get 56000 lines in log of >>>>>>>>>> DEBUG. >>>>>>>>>> >>>>>>>>> -- >>>>>>>>> -- >>>>>>>>> ------------------ >>>>>>>>> OPS4J - http://www.ops4j.org - [email protected] >>>>>>>>> >>>>>>>>> --- >>>>>>>>> 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 [email protected]. >>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> 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 >>>>>>>> >>>>>>>> -- >>>>>> -- >>>>>> ------------------ >>>>>> OPS4J - http://www.ops4j.org - [email protected] >>>>>> >>>>>> --- >>>>>> 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 [email protected]. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Niclas Hedhman, Software Developer >>>>> http://zest.apache.org - New Energy for Java >>>>> >>>> -- >>>> -- >>>> ------------------ >>>> OPS4J - http://www.ops4j.org - [email protected] >>>> >>>> --- >>>> 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 [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> >>> -- >>> Niclas Hedhman, Software Developer >>> http://zest.apache.org - New Energy for Java >>> >> > > > -- > Niclas Hedhman, Software Developer > http://zest.apache.org - New Energy for Java > -- -- ------------------ OPS4J - http://www.ops4j.org - [email protected] --- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
