Re: Extras
On Mon, Jan 14, 2019 at 12:27 PM Konstantin Kolinko wrote: > ср, 9 янв. 2019 г. в 20:10, Rémy Maucherat : > > > > Hi, > > > > So I'm looking at random small items as possible cleanups and ... The > > extras came up. > > > > At some point (15 years ago) the idea was to have a smaller JAR and avoid > > bloat, but right now I don't see the point of keeping them out of the > > regular catalina.jar (and thus reduce the complexity of the build a bit): > > - a listener to configure JMX remote (possibly not as useless as it > sounds > > for cloud stuff even though they like their Jolokia since it's json) > > - some webservices naming factory (ok, so I guess it's not very useful, > but > > only +15kB or so) > > > > Did I miss something ? > > > > 1. I think there was a discussion to move CGI and SSI servlet/filter > into extras (or to delete them). > > Nothing pressing here. I do not mind those servlets being present in > catalina.jar. > Personally, I'd like to keep kludges likes extras out from now on, because the stuff there is forgotten. Separate JARs should be used for separate components, and if useless they should be removed. > > 2. I am OK with the changes that you did (moving the classes into > catalina.jar). > > Dropping maven artifacts: > some Maven users may be surprised by this, but I think that they can > adapt easily. > I am OK with this. > Yes, it's very easy to change for users. > > The documentation needs update as well. > E.g. documentation for JmxRemoteLifecycleListener [1] (nightly docs > build for 9.0) still mentions catalina-jmx-remote.jar. > > [1] > https://ci.apache.org/projects/tomcat/tomcat9/docs/config/listeners.html#JMX_Remote_Lifecycle_Listener_-_org.apache.catalina.mbeans.JmxRemoteLifecycleListener Thanks, I fixed the issue, it's a good idea to not keep the doc outdated. Rémy > > > Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Extras
ср, 9 янв. 2019 г. в 20:10, Rémy Maucherat : > > Hi, > > So I'm looking at random small items as possible cleanups and ... The > extras came up. > > At some point (15 years ago) the idea was to have a smaller JAR and avoid > bloat, but right now I don't see the point of keeping them out of the > regular catalina.jar (and thus reduce the complexity of the build a bit): > - a listener to configure JMX remote (possibly not as useless as it sounds > for cloud stuff even though they like their Jolokia since it's json) > - some webservices naming factory (ok, so I guess it's not very useful, but > only +15kB or so) > > Did I miss something ? > 1. I think there was a discussion to move CGI and SSI servlet/filter into extras (or to delete them). Nothing pressing here. I do not mind those servlets being present in catalina.jar. 2. I am OK with the changes that you did (moving the classes into catalina.jar). Dropping maven artifacts: some Maven users may be surprised by this, but I think that they can adapt easily. I am OK with this. The documentation needs update as well. E.g. documentation for JmxRemoteLifecycleListener [1] (nightly docs build for 9.0) still mentions catalina-jmx-remote.jar. [1] https://ci.apache.org/projects/tomcat/tomcat9/docs/config/listeners.html#JMX_Remote_Lifecycle_Listener_-_org.apache.catalina.mbeans.JmxRemoteLifecycleListener Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Extras
Am 10.01.2019 um 15:01 schrieb Rémy Maucherat: On Thu, Jan 10, 2019 at 2:53 PM Rainer Jung wrote: Am 10.01.2019 um 13:16 schrieb Rémy Maucherat: On Thu, Jan 10, 2019 at 1:09 PM Mark Thomas wrote: There is the possibility that an alternative logging JAR could return. https://markmail.org/message/gdmffcyporhcmqge Whether that needs an optional / alternative JAR or whether it could be handled via configuration is TBD. Ok, so I'm not doing anything immediately but I'll put my patch in a BZ instead. It does remove a chunk of build.xml, which is good. In the meantime Log4J2 (I think starting with 2.10.0) added the artefact log4j-appserver.jar and support for an additional config file log4j2-tomcat.xml: https://logging.apache.org/log4j/2.x/log4j-appserver/index.html That allows for clean integration, so I currently do no longer see a need for an alternative JULI jar. Ok. I find the proposed setup rather lame looking however. log4j2/[lib|conf] + modify classpath ? It should be in bin and conf respectively to blend in, but adding to the classpath manually is still needed (bad). You are totally right, I lik that aspect neither, but even with my propsed minimal alternative juli jar it would have been necessary to include the log4j2 core and api jar in the classpath. I must confess I don't remember whether it would be feasible to combine java.util.logging with log4j2 without putting log4j2 into the classpath. At least I'm pretty sure log4j2 doesn't provide such a deploment out of the box. I would also find it much cleaner than the default approach, no doubt. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Extras
On Thu, Jan 10, 2019 at 2:53 PM Rainer Jung wrote: > Am 10.01.2019 um 13:16 schrieb Rémy Maucherat: > > On Thu, Jan 10, 2019 at 1:09 PM Mark Thomas wrote: > > > >> There is the possibility that an alternative logging JAR could return. > >> https://markmail.org/message/gdmffcyporhcmqge > >> > >> Whether that needs an optional / alternative JAR or whether it could be > >> handled via configuration is TBD. > >> > > > > Ok, so I'm not doing anything immediately but I'll put my patch in a BZ > > instead. It does remove a chunk of build.xml, which is good. > > In the meantime Log4J2 (I think starting with 2.10.0) added the artefact > log4j-appserver.jar and support for an additional config file > log4j2-tomcat.xml: > > https://logging.apache.org/log4j/2.x/log4j-appserver/index.html > > That allows for clean integration, so I currently do no longer see a > need for an alternative JULI jar. > Ok. I find the proposed setup rather lame looking however. log4j2/[lib|conf] + modify classpath ? It should be in bin and conf respectively to blend in, but adding to the classpath manually is still needed (bad). Rémy
Re: Extras
Am 10.01.2019 um 13:16 schrieb Rémy Maucherat: On Thu, Jan 10, 2019 at 1:09 PM Mark Thomas wrote: There is the possibility that an alternative logging JAR could return. https://markmail.org/message/gdmffcyporhcmqge Whether that needs an optional / alternative JAR or whether it could be handled via configuration is TBD. Ok, so I'm not doing anything immediately but I'll put my patch in a BZ instead. It does remove a chunk of build.xml, which is good. In the meantime Log4J2 (I think starting with 2.10.0) added the artefact log4j-appserver.jar and support for an additional config file log4j2-tomcat.xml: https://logging.apache.org/log4j/2.x/log4j-appserver/index.html That allows for clean integration, so I currently do no longer see a need for an alternative JULI jar. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Extras
On Thu, Jan 10, 2019 at 1:09 PM Mark Thomas wrote: > There is the possibility that an alternative logging JAR could return. > https://markmail.org/message/gdmffcyporhcmqge > > Whether that needs an optional / alternative JAR or whether it could be > handled via configuration is TBD. > Ok, so I'm not doing anything immediately but I'll put my patch in a BZ instead. It does remove a chunk of build.xml, which is good. Rémy
Re: Extras
On 09/01/2019 17:10, Rémy Maucherat wrote: > Hi, > > So I'm looking at random small items as possible cleanups and ... The > extras came up. > > At some point (15 years ago) the idea was to have a smaller JAR and avoid > bloat, but right now I don't see the point of keeping them out of the > regular catalina.jar (and thus reduce the complexity of the build a bit): > - a listener to configure JMX remote (possibly not as useless as it sounds > for cloud stuff even though they like their Jolokia since it's json) > - some webservices naming factory (ok, so I guess it's not very useful, but > only +15kB or so) > > Did I miss something ? There is the possibility that an alternative logging JAR could return. https://markmail.org/message/gdmffcyporhcmqge Whether that needs an optional / alternative JAR or whether it could be handled via configuration is TBD. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
