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]> 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.
