javax.management.AttributeNotFoundException 8.5.35 и выше - PullRequest
0 голосов
/ 02 марта 2020

Ошибка, которую я получаю: Не удается найти атрибут XXX для org. apache .tomcat.util. net .SocketProperties

Это происходит, когда я вызываю mBeanServer.getAttribute (бла, бла)

Насколько я понимаю, это была ошибка в Tomcat 8.5.35 и исправлена ​​в 8.5.36 - хотя я обнаружил, что об этом также сообщалось в 8.5.40.

Я добавил число Tomcat устанавливается на мой Eclipse, чтобы попытаться сузить это, и вот что я нашел:

8.5.30 WORKS

8.5.34 WORKS

8.5.35 ОШИБКА

8.5.37 ОШИБКА

8.5.40 ОШИБКА

8.5.45 ОШИБКА

8.5.51 ОШИБКА

Обратите внимание, что я был невозможно найти 8.5.36 на странице загрузок tomcat.

Я не могу представить, что найденная в 8.5.35 ошибка, которая предположительно была исправлена ​​в 8.5.36, продолжает существовать вплоть до 8.5. 51 и дальше. Этот код хорошо работал ранее в течение нескольких лет в более низких версиях Tomcat, но задохнулся от 8.5.35 и выше.

Я пытаюсь определить, были ли внесены другие изменения или параметры, которые могут быть нужен сейчас как мера безопасности, которая блокирует чтение. Например, при запуске 8.5.51 я должен добавить параметр secretRequired к соединителю на сервере. xml, в противном случае он задыхается. Это не связано, но, надеюсь, вы понимаете, что я имею в виду, когда вводятся новые параметры.

При устранении неполадок я вижу имена атрибутов, имена объектов и т. Д. c. но когда я go для значения, хранящегося в атрибуте, он бомбит.

Заставляет меня задуматься, существуют ли какие-то расширенные меры, которые необходимо установить после 8.5.34. Есть идеи по этому поводу?

1 Ответ

0 голосов
/ 03 марта 2020

После долгих раскопок я наконец-то понял проблему. Обратите внимание, что сообщенная «ошибка» в 8.5.35, которая была исправлена ​​в 8.5.36, по-видимому, вообще не является ошибкой. Чистая спекуляция с моей стороны, но сообщаемая проблема существует в последующих выпусках TomCat, и 8.5.36 не найти.

При получении набора mBean для вызова mBeanServer.getAttribute () фактически существует 2 mBean. передаваемые объекты - один работает оригинал, другой имеет дополнительный ключ - "subtype = SocketProperties". Этот дополнительный ключ был тем, что вызывало ошибку в моем коде.

До 8.5.35 был только один набор mBean, который не включает ключ подтипа.

Мой код в основном создание массива ObjectInstances, которые фильтруются для «Type = ThreadPool».

Например, при установке Tomcat по умолчанию до 8.5.35 вы получаете ObjectName:

Catalina: type = ThreadPool, name = "бла-бла-бла"

Начиная с 8.5.35 вы получаете 2:

Каталина: type = ThreadPool, name = "бла-бла-бла"

Catalina: type = ThreadPool, name = "бла-бла-бла", subType = SocketProperties

Это второй, который вызывает следующую ошибку: "не удается найти атрибут maxthreads для org. apache .tomcat.util. net .socketproperties ", когда он попадает в следующую строку кода:

mBeanServer.getAttribute(objectName, "maxThreads")

Простое исключение объекта nameNames, содержащего ключ подтипа, из моего массива, проблема была решена.

filter = "*:type=ThreadPool,*";
objectName = new ObjectName(filter);
Set<ObjectInstance> setOfInstances = mBeanServer.queryMBeans(objectName, null);
for (ObjectInstance objInst : setOfInstances)
{
    if(!objInst.getObjectName().getKeyPropertyListString().contains("subType"))
        ArrayOfObjects.addElement(objInst.getObjectName());
}

Я уверен, что есть более чистый способ сделать это, и я хотел бы услышать это, но я был просто рад, наконец, выяснить причину моей проблемы и обойти ее.

Надеюсь, эта информация поможет другим, кто столкнулся с той же проблемой.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...