Телеграмм чат группы jvmchat страница 17687

2020 September 21

E

ну тип серъёзно? у всех проблемы на проекте это именно на скольки элементах выбрать линейный поиск заюзать либо бинарный?

источник

11:03пожаловаться #1

AS

Aleksey Shipilev in pro.jvm

Aleksandr

Вот более подробный трейс ошибки https://pastebin.pl/view/c659c6c0

Но к слову, я видел похожие тикеты, как пример - https://access.redhat.com/solutions/5355911

Судя по стектрейсу, вопросы к com.microsoft.sqlserver.jdbc. Ошибка по сути означает, что поля sun/security/ssl/SSLSessionImpl.nullSession больше нет. Но все внутренние использования снесены в 8u252 вместе с полем. Я так понимаю, что такая ошибка возможна, если кто-то в класспас притащил старый sun.security.ssl, ну и приехали...

источник

11:23пожаловаться #2

AS

Aleksey Shipilev in pro.jvm

А, ну и в RH Solution то же самое написано: "alpn-boot jars are on the classpath, providing a customized sun.security.ssl.ClientHandshaker class that still tries to reference the SSLSessionImpl.nullSession field. This field was removed in u252, so the alpn-boot jar triggers this error if used on u252."

источник

11:27пожаловаться #3

AG

Alexey Genus in pro.jvm

Это не баг, это фича!

источник

11:30пожаловаться #4

AS

Aleksey Shipilev in pro.jvm

Вообще прискорбно, что такое ломается. Если бы это был не ALPN, то можно было бы откатить, конешн...

A

А, ну и в RH Solution то же самое написано: "alpn-boot jars are on the classpath, providing a customized sun.security.ssl.ClientHandshaker class that still tries to reference the SSLSessionImpl.nullSession field. This field was removed in u252, so the alpn-boot jar triggers this error if used on u252."

А где вы нашли ответ, не совсем понял?

источник

11:33пожаловаться #6

AS

Aleksey Shipilev in pro.jvm

Aleksandr

А где вы нашли ответ, не совсем понял?

https://access.redhat.com/solutions/5355911, "Root Cause"

источник

11:34пожаловаться #7

A

Aleksandr in pro.jvm

А, надо залогиниться...

источник

11:34пожаловаться #8

AS

Aleksey Shipilev in pro.jvm

Оттуда же ссылка есть на https://www.eclipse.org/jetty/documentation/current/alpn-chapter.html#alpn-versions -- надо найти и выкосить "левые" alpn джарники, судя по всему.

источник

11:35пожаловаться #9

A

Aleksandr in pro.jvm

Да, похоже проблема действительно с ним, очень похоже на правду

источник

11:36пожаловаться #10

A

Aleksandr in pro.jvm

Но ведь версию последнюю в таком случае лигитивно ли использовать? 😅

источник

11:36пожаловаться #11

A

Aleksandr in pro.jvm

Я про jdk

источник

11:36пожаловаться #12

AS

Aleksey Shipilev in pro.jvm

Легитимно, почему нет? Но проблема при деплойменте, да. Нужно, блин, решить -- использовать старые джарники со своим ALPN на 8u242-, или новые джарники с JDK-овым ALPN на 8u252+.

источник

11:37пожаловаться #13

A

Aleksandr in pro.jvm

А мне на будущее, буду сразу подробнее расписывать проблему, просто боюсь иногда что отпугну деталями людей, а так вопросы называют мета-вопросами

источник

11:39пожаловаться #14

AS

Aleksey Shipilev in pro.jvm

А, короче, чуваки из Jetty ALPN вообще говорят "Be certain to get the ALPN boot artifact version that matches the version of your JRE." Удачного деплоя, короч :) То есть при переходе между минорными апдейтами JDK может потребоваться бамп версии, чтобы их внутренние копипасты из JDK всё ещё работали

источник

11:41пожаловаться #15

A

Aleksandr in pro.jvm

Aleksey Shipilev

Оттуда же ссылка есть на https://www.eclipse.org/jetty/documentation/current/alpn-chapter.html#alpn-versions -- надо найти и выкосить "левые" alpn джарники, судя по всему.

Зарегался я на редхатовском форуме, почему-то не могу всё равно увидеть ответ, какой там джарник говорите левый?

источник

11:42пожаловаться #16

AK

Alexander Komarov in pro.jvm

потому что у Алексея премиум аккаунт на редхате))

источник

11:42пожаловаться #17

A

Aleksandr in pro.jvm

Ну понятно…

источник