Jetty and the IdP have to be in sync on logging versions
Basics
Logistics
Basics
Logistics
Description
Not sure I know the right answer but we currently have sort of floating assumption that the deployer must be matching the versions of slf4j and logback between the shipped IdP and the Jetty layer if using the idp-logging module example or the underlying Jetty modules that use those jars.
This isn't really clean because upgrading either IdP or Jetty can break or become a source of conflict if they don't match. This is a general Jetty upgrade issue anyway I guess, so maybe the answer is "be careful, document" while dealing with it in the obvious way in our Jetty packaging for Windows.
We can force Jetty to use the versions we package by setting variables in the ini file (e.g. logback.version=1.2.3). That seems to get Jetty to start up properly on the older logback in 9.4.44. Maybe that's the right answer.
That might be the extent of the work I guess, modulo maybe adding to the Jetty example docs and the jetty-base example repo such that it matches what we're shipping.
Ultimately I guess this is just a thing we have to be conscious of.
Environment
None
Activity
Scott Cantor
November 2, 2021 at 10:22 PM
I updated the parent POM for 4.2 with the latest libraries, but I think we’ve satisfied ourselves that they don’t actually need to be tied together.
Scott Cantor
October 6, 2021 at 11:53 AM
At least based on Jetty’s docs, they are supposed to favor the WEB-INF/lib jars for locating webapp classes over its parent classloader, so that in theory should mean Jetty’s logging through 1.2.6 while the IdP continues to use 1.2.3.
Scott Cantor
October 6, 2021 at 11:46 AM
As a follow up, I am seeing possibly unrelated breakage to the root webapp context. I tried updating to the newer logback jars, and that still starts the IdP but does not fix the webapp issue, so I guess it’s something else.
I don’t know which actual logback jar(s) the IdP ended up using of course with two different sets in the mix.
Not sure I know the right answer but we currently have sort of floating assumption that the deployer must be matching the versions of slf4j and logback between the shipped IdP and the Jetty layer if using the idp-logging module example or the underlying Jetty modules that use those jars.
This isn't really clean because upgrading either IdP or Jetty can break or become a source of conflict if they don't match. This is a general Jetty upgrade issue anyway I guess, so maybe the answer is "be careful, document" while dealing with it in the obvious way in our Jetty packaging for Windows.
We can force Jetty to use the versions we package by setting variables in the ini file (e.g. logback.version=1.2.3). That seems to get Jetty to start up properly on the older logback in 9.4.44. Maybe that's the right answer.
That might be the extent of the work I guess, modulo maybe adding to the Jetty example docs and the jetty-base example repo such that it matches what we're shipping.
Ultimately I guess this is just a thing we have to be conscious of.