Extras

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Extras

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 ?

Rémy
Reply | Threaded
Open this post in threaded view
|

Re: Extras

markt
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Extras

Rémy Maucherat
On Thu, Jan 10, 2019 at 1:09 PM Mark Thomas <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Extras

Rainer Jung-3
Am 10.01.2019 um 13:16 schrieb Rémy Maucherat:

> On Thu, Jan 10, 2019 at 1:09 PM Mark Thomas <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Extras

Rémy Maucherat
On Thu, Jan 10, 2019 at 2:53 PM Rainer Jung <[hidden email]> wrote:

> Am 10.01.2019 um 13:16 schrieb Rémy Maucherat:
> > On Thu, Jan 10, 2019 at 1:09 PM Mark Thomas <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Extras

Rainer Jung-3
Am 10.01.2019 um 15:01 schrieb Rémy Maucherat:

> On Thu, Jan 10, 2019 at 2:53 PM Rainer Jung <[hidden email]> wrote:
>
>> Am 10.01.2019 um 13:16 schrieb Rémy Maucherat:
>>> On Thu, Jan 10, 2019 at 1:09 PM Mark Thomas <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Extras

Konstantin Kolinko
In reply to this post by Rémy Maucherat
ср, 9 янв. 2019 г. в 20:10, Rémy Maucherat <[hidden email]>:

>
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Extras

Rémy Maucherat
On Mon, Jan 14, 2019 at 12:27 PM Konstantin Kolinko <[hidden email]>
wrote:

> ср, 9 янв. 2019 г. в 20:10, Rémy Maucherat <[hidden email]>:
> >
> > 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>