Hi Andor, Thank you for the summary!
> also drop the jar from release artifacts No jar is dropped but the test dependency entry in pom.xml. That is there will be no `logback-classic` in pom.xml in the published jar. So, external dependants are free to do whatever they want to do. We could keep slf4j at 1.x in 3.9 and 3.8 for backward compatibility and to reduce the chance of "no provider" and "no logs". > bump logback / slf4j version to secure ones: 1.3.x, 2.0.x This is only needed for zookeeper-assembly to assemble published tarbal. Nothing more. The possible consequence of this approach is "no provider" warning from slf4j and "no logs" in execution which is noticeable. The reaction from dependants is also simple: add or bump log dependency. In contrast, replacing logback with slf4j-simple could function normally but differently which is less noticeable. Besides, administrators probably will have to configure log dependencies to gain the same log behaviors in upgrading. Best, Kezhu Wang On Thu, Aug 14, 2025 at 10:44 AM Andor Molnar <an...@apache.org> wrote: > > Thanks Kezhu, I can support this approach too, but Christopher might have > some concerns. Let’s see if I understand it well. > > TL;DR > > - change logback-classic to test scope, > - use “flatten-maven-plugin” to drop it from published pom (also drop the jar > from release artifacts) > - bump logback / slf4j version to secure ones: 1.3.x, 2.0.x > - do the above on all branches: master, 3.9, 3.8 > - create new releases > > Did I miss anything? > > Andor > > > > > On Aug 13, 2025, at 20:29, Kezhu Wang <kez...@gmail.com> wrote: > > > > Hi all, > > > > ZooKeeper delivers two shapes of artifacts to clients: > > 1. Java library mainly for client usage. > > 2. Deployable java server application. > > > > I think we could take different actions based on usage. > > 1. For library usage, ZooKeeper depends only on `slf4j-api` and should > > not ship any log framework dependencies. I saw ZOOKEEPER-4820[1], > > there are discussions to mark `logback-classic` as optional runtime > > dependency[2]. I would suggest we change it to test scope and use > > maven plugin "flatten-maven-plugin" to drop test dependencies from > > published pom.xml to express the fact that zookeeper library does not > > depend on nor prefer concrete log frameworks. This way, the library > > usage would not be affected by any CVEs of logback. > > 2. For application usage, ZooKeeper ships both slf4j and logback. I > > think we can bump both in zookeeper-assembly and add release notes to > > highlight the consequence of this change. > > > > After the above actions, there is only one possible breaking change > > for application usage: administrators have to check possible > > customized log dependencies in zookeeper deployment to meet slf4j > > requirements, otherwise there will be "no provider" warning from slf4j > > and hence no logs. I think the risk is pretty low, it affects only > > deployments with customized log dependencies which should be taken > > care of by administrators themselves. > > > > Regarding replacing logback with slf4j-simple, I think it is ok for > > tests. But will it cause much bigger breaking change than bumping > > slf4j and logback for application artifacts ? > > > > Best, > > Kezhu Wang > > > > [1]: https://issues.apache.org/jira/browse/ZOOKEEPER-4820 > > [2]: https://github.com/apache/zookeeper/pull/2155#discussion_r1559857699 > > > > > > On Thu, Aug 14, 2025 at 2:22 AM Enrico Olivelli <eolive...@gmail.com> wrote: > >> > >> Il Mer 13 Ago 2025, 19:56 Andor Molnar <an...@apache.org> ha scritto: > >> > >>> I’ve created a PR to attempt to replace logback with slf4j-simple. We do > >>> have some test code relying on logback’s appenders, but we might be able > >>> to > >>> replace it with a basic output stream. > >>> > >>> https://github.com/apache/zookeeper/pull/2293 > >>> > >>> > >>> ptal. > >>> > >> > >> Overall I agree with the approach. I left a couple of questions about the > >> impact on client users and server system admins > >> > >> I am +1 to release 3.10 and send 3.8 to EOL > >> > >> > >> > >> Thanks > >> Enrico > >> > >> > >>> > >>> Andor > >>> > >>> > >>> > >>>> On Aug 12, 2025, at 15:58, Christopher <ctubb...@apache.org> wrote: > >>>> > >>>> I would NOT ship with reload4j in new releases. That exists only as a > >>>> temporary workaround for the lack of patch support for log4j 1.2, > >>>> until one is able to update to log4j2 or something else. ZK is already > >>>> using something else (logback). Neither log4j 1.2 nor reload4j are > >>>> appropriate for use with slf4j2. If a log4j implementation is desired, > >>>> a log4j 2.x version should be used. Using reload4j would be a step in > >>>> the wrong direction. > >>>> > >>>> However, since ZK uses slf4j-api in code, I would ship *only* with > >>>> slf4j-simple as the trivial reference implementation, and let users > >>>> determine their own runtime logging dependency and configuration, > >>>> which can be trivially swapped in place of slf4j-simple. This is > >>>> basically what I argued when logback was being considered to replace > >>>> log4j/reload4j a few years ago, but others preferred logback. > >>>> > >>>> One thing to consider is that, if I remember correctly, logback is > >>>> used as a test dependency for some build tests. It is easier to run > >>>> those tests with logback than it is to do it with another runtime > >>>> dependency. It is possible to have the tests run using logback, but > >>>> still ship with slf4j-simple instead of logback, but it may take some > >>>> careful attention to the Maven pom.xml files to ensure the desired > >>>> result (let's call this the "split dependency" option). It is > >>>> certainly easier to stay with logback ("single dependency option"), > >>>> but just update it to a newer version, than to modify the Maven build > >>>> to ship something different than what is used in testing, but both > >>>> options are technically possible. > >>>> > >>>> > >>>> On Fri, Aug 8, 2025 at 5:19 PM Andor Molnar <an...@apache.org> wrote: > >>>>> > >>>>> Yeah, I totally agree. > >>>>> > >>>>> The plan to go forward after getting 3.9.4 out of the door is to either > >>> remove logback from branch-3.8 and replace it with something simpler like > >>> slf4j-simple or reload4j since we ship the logback dependency as an > >>> example. Though I’m not sure if slf4j-simple is an option for us, I have > >>> to > >>> try it out in action. > >>>>> > >>>>> The other option is to announce EoL on branch-3.8 and encourage users > >>> to upgrade to 3.9.4. At the same time we have to create a 3.10.0 release > >>> off the main branch or maybe 4.0.0. I don't have a strong opinion here > >>> either, but I’m pretty confident that we should drop Java 8 support in the > >>> next “current” release. > >>>>> > >>>>> Andor > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> On Aug 8, 2025, at 15:05, Christopher <ctubb...@apache.org> wrote: > >>>>>> > >>>>>> I don't think the upgrade to slf4j 2 is purely a semantic one. I think > >>>>>> there are genuine incompatibilities, but probably not too many. For > >>>>>> example, slf4j2 drops support for Java 7 (probably not a problem for > >>>>>> ZK, since I think Java 8 is already a requirement), and it switches > >>>>>> the binding mechanisms, so that if somebody was using a different > >>>>>> sfl4j runtime other than logback, then it probably won't work anymore > >>>>>> without additional changes on the user's part. > >>>>>> > >>>>>> I think the switch on 3.9 is probably okay, but users should be warned > >>>>>> that their logging will probably break if they had used a different > >>>>>> runtime binding for slf4j other than the logback version that ships > >>>>>> with ZK. > >>>>>> > >>>>>> As for the differences between logback 1.2 and 1.3, I have no idea... > >>>>>> it's probably fine, since ZK is mainly just using it via slf4j-api > >>>>>> anyway, rather than using it directly, but I'd start getting concerned > >>>>>> that 1.3 is also no longer being developed. ZK should probably get > >>>>>> ahead of that on the master branch by requiring Java 11, and using > >>>>>> logback 1.5 there, if it hasn't been done already. Or else this > >>>>>> question of switching from logback 1.2 to 1.3 is going to come up > >>>>>> again soon when there's a CVE found against 1.3 and you have to switch > >>>>>> to 1.5 and Java 11.... certainly don't want to do that in a bugfix > >>>>>> release from the ZK 3.9 branch. > >>>>>> > >>>>>> On Thu, Aug 7, 2025 at 9:41 AM Andor Molnar <an...@apache.org> wrote: > >>>>>>> > >>>>>>> Considering all of this I’ll upgrade logback + slf4j to 1.3/2.0 on > >>> the 3.9 branch today and proceed with the release. 3.9 is the current > >>> release line and I think this step is still acceptable at this stage. I > >>> won’t do the same on the stable (3.8) branch and we should talk about > >>> EoL’ing soon in a separate thread. > >>>>>>> > >>>>>>> Andor > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> On Aug 6, 2025, at 19:56, Andor Molnar <an...@apache.org> wrote: > >>>>>>>> > >>>>>>>> "The 1.2.x series for logback-core and logback-classic has been > >>> deprecated for several years and is no longer maintained. As such, use of > >>> the 1.2.x series is discouraged.” > >>>>>>>> > >>>>>>>> "Logback version 1.3.15 is the latest in the 1.3.x series. It > >>> requires SLF4J version 2.0.x and JDK 8. Please note that the 1.3.x series > >>> is no loger actively developed.” > >>>>>>>> > >>>>>>>> "The current actively developed version of logback-core and > >>> logback-classic is 1.5.18. It requires JDK 11 and SLF4J version 2.0.1 at > >>> runtime.” > >>>>>>>> > >>>>>>>> Looks like our only option is 1.3.x, but once we drop JDK 8 support > >>> (3.10.x maybe?), we’ll be able to upgrade to 1.5. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> On Aug 6, 2025, at 19:52, Andor Molnar <an...@apache.org> wrote: > >>>>>>>>> > >>>>>>>>> I cannot upgrade logback without upgrading slf4j as well. Build > >>> fails. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> On Aug 6, 2025, at 17:07, Patrick Hunt <ph...@apache.org> wrote: > >>>>>>>>>> > >>>>>>>>>> Is slf4j really needed for security? > >>>>>>>>>> > >>>>>>>>>> Only cve I see here is from 2018... > >>>>>>>>>> https://www.slf4j.org/news.html > >>>>>>>>>> > >>>>>>>>>> Should we revert the slf4j change in its entirety/all branches > >>> until it can > >>>>>>>>>> be made in a b/w compatible way? > >>>>>>>>>> > >>>>>>>>>> Patrick > >>>>>>>>>> > >>>>>>>>>> On Wed, Aug 6, 2025 at 2:59 PM Andor Molnar <an...@apache.org> > >>> wrote: > >>>>>>>>>> > >>>>>>>>>>> Maybe the slf4j upgrade (1.7.30 -> 2.0.13) has higher impact, > >>> because it’s > >>>>>>>>>>> a major upgrade. Logback is just an example of how to do logging > >>> with > >>>>>>>>>>> ZooKeeper real life setups probably replace it with something > >>> else like > >>>>>>>>>>> log4j2. The logging facade (slf4j) could have bw incompatible > >>> changes that > >>>>>>>>>>> will force users to make changes related to logging on their > >>> classpath. > >>>>>>>>>>> > >>>>>>>>>>> I’m speculating and haven’t checked slf4j for details. > >>>>>>>>>>> > >>>>>>>>>>> Andor > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> On Aug 6, 2025, at 16:46, Patrick Hunt <ph...@apache.org> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> Is the only problem the minor "semantic" upgrade of logback in a > >>> fix > >>>>>>>>>>>> release of zk? That should be stable (contract wise) on the > >>> dependency, > >>>>>>>>>>>> right? Or is there some real impact, eg b/w incompat change > >>> visible to ZK > >>>>>>>>>>>> users? If the former that seems fine, if the latter then we have > >>> a harder > >>>>>>>>>>>> problem to address. (security issue breaking b/w compat) > >>>>>>>>>>>> > >>>>>>>>>>>> Patrick > >>>>>>>>>>>> > >>>>>>>>>>>> On Wed, Aug 6, 2025 at 2:36 PM Andor Molnar <an...@apache.org> > >>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> Sorry for the confusion, I picked 3.8 as an example, but > >>> logback/slf4j > >>>>>>>>>>>>> upgrades haven’t been backported to 3.9 either. Therefore I > >>> created the > >>>>>>>>>>>>> following backport PR: > >>>>>>>>>>>>> > >>>>>>>>>>>>> https://github.com/apache/zookeeper/pull/2290 > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> "Why would they be applied to master and not to any active > >>> (release) > >>>>>>>>>>>>> line? > >>>>>>>>>>>>> > >>>>>>>>>>>>> Since we’ve already released 3.9.3 with logback 1.2.13 and > >>> don’t want > >>>>>>>>>>>>> users to realize 1.2->1.3 logback upgrade in a 3.9.3->3.9.4 > >>> ZooKeeper > >>>>>>>>>>>>> upgrade process, although this upgrade is necessary anyways to > >>> address > >>>>>>>>>>> the > >>>>>>>>>>>>> CVE in question. > >>>>>>>>>>>>> > >>>>>>>>>>>>> (in my understanding) > >>>>>>>>>>>>> > >>>>>>>>>>>>> Andor > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> On Aug 6, 2025, at 15:34, Patrick Hunt <ph...@apache.org> > >>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I'm confused - this thread started with "OWASP reports CVEs on > >>> the 3.8 > >>>>>>>>>>>>>> branch and noticed in the PRs that we should only upgrade > >>> logback on > >>>>>>>>>>> the > >>>>>>>>>>>>>> master branch" - I read that as "some fixes on 3.9 are not > >>> backported > >>>>>>>>>>> to > >>>>>>>>>>>>>> 3.8". But you are saying that this is not fixed (still owasp > >>> warnings) > >>>>>>>>>>> on > >>>>>>>>>>>>>> 3.9 which is separate from master? Why would they be applied > >>> to master > >>>>>>>>>>>>> and > >>>>>>>>>>>>>> not to any active (release) line? What is the impact of the > >>> changes on > >>>>>>>>>>>>>> master and 3.9? iiuc there are backward incompatible changes > >>> if applied > >>>>>>>>>>>>> to > >>>>>>>>>>>>>> 3.8? There should not be b/w incompatible changes applied to > >>> any 3.x > >>>>>>>>>>>>> (incl > >>>>>>>>>>>>>> master, a future 3.x...) release. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Patrick > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On Wed, Aug 6, 2025 at 1:16 PM Andor Molnar <an...@apache.org> > >>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Yeah, that would remove the burden of maintaining the 3.8 > >>> version > >>>>>>>>>>> line, > >>>>>>>>>>>>>>> but 3.9.x versions still don’t have logback and slf4j > >>> upgraded, still > >>>>>>>>>>>>>>> flagged by the Owasp build and users will probably still > >>> complain > >>>>>>>>>>> about > >>>>>>>>>>>>>>> CVEs. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> My question is what should we do on branches other than the > >>> master? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> 1. Backport logback and slf4j upgrades from master, or > >>>>>>>>>>>>>>> 2. Add Owasp suppression rule to skip checking these libraries > >>>>>>>>>>>>> completely. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I need to answer this question before going forward with the > >>> 3.9.4 > >>>>>>>>>>>>> release. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Regards, > >>>>>>>>>>>>>>> Andor > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On Aug 6, 2025, at 13:39, Christopher <ctubb...@apache.org> > >>> wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> +1 to that idea. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> The releases page[1] says "Apache ZooKeeper 3.9.3 is our > >>> current > >>>>>>>>>>>>>>>> release, and 3.8.4 our latest stable release". Is 3.9 > >>> sufficiently > >>>>>>>>>>>>>>>> stable to replace 3.8 as the current "stable"? If the answer > >>> is yes, > >>>>>>>>>>>>>>>> then I think it makes sense to EOL 3.8. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> [1]: https://zookeeper.apache.org/releases.html#download > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On Mon, Aug 4, 2025 at 2:52 PM Patrick Hunt < > >>> ph...@apache.org> > >>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Should we sunset that minor release due to the "unfixable" > >>> security > >>>>>>>>>>>>>>> issue > >>>>>>>>>>>>>>>>> and EOL of dependenc(ies)? > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Patrick > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> On Mon, Aug 4, 2025 at 10:03 AM Andor Molnar < > >>> an...@apache.org> > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Yeah, I agree with that, but we can’t leave things here > >>> just like > >>>>>>>>>>>>> that. > >>>>>>>>>>>>>>>>>> Either we should keep updating the logging libraries on > >>> all active > >>>>>>>>>>>>>>> branches > >>>>>>>>>>>>>>>>>> or add the necessary suppression to Owasp. Otherwise the > >>> report > >>>>>>>>>>>>> result > >>>>>>>>>>>>>>> will > >>>>>>>>>>>>>>>>>> be completely meaningless. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Andor > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> On Aug 4, 2025, at 08:21, Christopher < > >>> ctubb...@apache.org> > >>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Yes, that is basically my concern. I commented at > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>> https://github.com/apache/zookeeper/pull/2290#issuecomment-3145955665 > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> On Fri, Aug 1, 2025, 18:43 Andor Molnar <an...@apache.org> > >>> wrote: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Christopher raised concern about it in > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> > >>> https://github.com/apache/zookeeper/pull/2162#pullrequestreview-2037135095 > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> I suspect because SLF4j has to be major upgraded with > >>> logback 1.x > >>>>>>>>>>>>> -> > >>>>>>>>>>>>>>> 2.x > >>>>>>>>>>>>>>>>>>>> which should not be done in bugfix releases. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> I’m not sure. Maybe we should just add another Owasp > >>> suppression, > >>>>>>>>>>>>> but > >>>>>>>>>>>>>>>>>> that > >>>>>>>>>>>>>>>>>>>> wouldn’t be appropriate either. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Andor > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> On Jul 30, 2025, at 18:39, Andor Molnar < > >>> an...@apache.org> > >>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> That’s my understanding too, but looks like folks > >>> skipped even > >>>>>>>>>>> the > >>>>>>>>>>>>>>> 3.9 > >>>>>>>>>>>>>>>>>>>> backport in the case of logback. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Andor > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> On Jul 30, 2025, at 16:36, Patrick Hunt < > >>> ph...@apache.org> > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> My understanding, I thought the rule was to backport > >>> any patch > >>>>>>>>>>> to > >>>>>>>>>>>>>>> all > >>>>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>>>> the active releases unless it's a new feature. Perhaps > >>> ask the > >>>>>>>>>>>>>>> folks > >>>>>>>>>>>>>>>>>> who > >>>>>>>>>>>>>>>>>>>>>> committed? > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Patrick > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> On Wed, Jul 30, 2025 at 2:06 PM Andor Molnar < > >>> an...@apache.org > >>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Hi folks, > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Currently I’m working on some backports, because > >>> OWASP reports > >>>>>>>>>>>>>>> CVEs > >>>>>>>>>>>>>>>>>> on > >>>>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>> 3.8 branch and noticed in the PRs that we should only > >>> upgrade > >>>>>>>>>>>>>>> logback > >>>>>>>>>>>>>>>>>>>> on > >>>>>>>>>>>>>>>>>>>>>>> the master branch. Why is that? > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> logback-core-1.2.13.jar > >>>>>>>>>>>>>>> (pkg:maven/ch.qos.logback/logback-core@1.2.13 > >>>>>>>>>>>>>>>>>> , > >>>>>>>>>>>>>>>>>>>>>>> cpe:2.3:a:qos:logback:1.2.13:*:*:*:*:*:*:*) : > >>> CVE-2024-12798, > >>>>>>>>>>>>>>>>>>>> CVE-2024-12801 > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Regards, > >>>>>>>>>>>>>>>>>>>>>>> Andor > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>> > >>> > >>> >
