Перезапуск GlassFish - теперь получение исключения, отправляющего событие, инициализированное контекстом, в экземпляр класса слушателя.

Question

Я новичок в этой должности и изучаю Java, потому что 2 приложения, за которые я отвечаю, написаны на Java. К сожалению для меня, хотя, когда наши сетевые специалисты выполнили обновление Apache на машине с Linux, это вызвало перебои в работе нашего сайта и GlassFish. С тех пор они восстановили Apache до версии, которую мы использовали до обновления, и вместе с этим им пришлось получить новый ключ для SSL.

Моя среда: Физический сервер Linux Suse Enterprise, с Apache 2.2.10 и GlassFish Enterprise Server v.2.1.1, на котором выполняется одно веб-приложение и одно корпоративное приложение.

Шаги, которые я предпринял до сих пор:

1. импортировал новый SSL в хранилище ключей.
2. обновлен домен.xml, чтобы отразить изменения в файле псевдонима и хранилища ключей
3. перезапущенная база данных Derby (также известная как JavaDB): asadmin start-database --dbhost 0.0.0.0 --dbport 1527
4. перезапустил домен GlassFish: домен начального домена asadmin1

Приложения не работали из-за пары серьезных ошибок, одна из которых была связана с подключением JDBC к MySQL. Поэтому я вошел в консоль администратора и ping'd все пулы соединений. MySQL не подключался, поэтому я обнаружил две вещи в разделе "дополнительные свойства": в IP-адресе для serverName была добавлена ​​дополнительная цифра, поэтому я удалил ее. и в URL отсутствовал IP-адрес jdbc:mysql://3306/dbname, поэтому я изменил его на jdbc:mysql://127.0.0.1:3306/dbname. Я снова ping'd, и это решило проблему с подключением.

Поэтому я остановился и снова запустил домен, но все равно ничего. По крайней мере, я до 2 серьезных ошибок, хотя. Я скопировал основное сообщение об ошибке из журнала сервера ниже. В другом сообщении просто говорится, что приложения не могут быть запущены из-за предыдущих ошибок. Поскольку я занимал эту должность, в приложение, работающее на сервере GlassFish, не было внесено никаких изменений, и в консоли администратора до этого не было никаких изменений.

Исправление проблем до этого момента было нелегкой задачей для меня. Я много занимался Google и нашел много помощи, но мне не очень повезло с проблемой ниже. Похоже, мне не нужно ничего менять в реальных приложениях, так как они работали до этого. Есть идеи? Спасибо за ваше время!

[#|2012-03-02T10:36:22.209-0600|SEVERE|sun-appserver2.1|javax.enterprise.system.container.web|_ThreadID=12;_ThreadName=pool-1-thread-3;_RequestID=317b1d80-3858-4841-bc6a-8e18e9331da8;|WebModule[/Applications]PWC1275: Exception sending context initialized event to listener instance of class org.jboss.seam.servlet.SeamListener
java.lang.RuntimeException: Could not create Component: org.jboss.seam.core.init
    at org.jboss.seam.init.Initialization.addComponent(Initialization.java:989)
    at org.jboss.seam.init.Initialization.init(Initialization.java:576)
    at org.jboss.seam.servlet.SeamListener.contextInitialized(SeamListener.java:34)
    at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4655)
    at org.apache.catalina.core.StandardContext.start(StandardContext.java:5364)
    at com.sun.enterprise.web.WebModule.start(WebModule.java:345)
    at com.sun.enterprise.web.LifecycleStarter.doRun(LifecycleStarter.java:58)
    at com.sun.appserv.management.util.misc.RunnableBase.runSync(RunnableBase.java:304)
    at com.sun.appserv.management.util.misc.RunnableBase._submit(RunnableBase.java:176)
    at com.sun.appserv.management.util.misc.RunnableBase.submit(RunnableBase.java:192)
    at com.sun.enterprise.web.VirtualServer.startChildren(VirtualServer.java:1762)
    at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1244)
    at org.apache.catalina.core.StandardHost.start(StandardHost.java:971)
    at com.sun.enterprise.web.LifecycleStarter.doRun(LifecycleStarter.java:58)
    at com.sun.appserv.management.util.misc.RunnableBase.runSync(RunnableBase.java:304)
    at com.sun.appserv.management.util.misc.RunnableBase.run(RunnableBase.java:341)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
    at java.util.concurrent.FutureTask.run(FutureTask.java:138)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:619)
Caused by: java.security.AccessControlException: access denied (java.lang.reflect.ReflectPermission suppressAccessChecks)
    at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
    at java.security.AccessController.checkPermission(AccessController.java:546)
    at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
    at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:107)
    at org.jboss.seam.Component.scanMethod(Component.java:788)
    at org.jboss.seam.Component.initMembers(Component.java:532)
    at org.jboss.seam.Component.<init>(Component.java:254)
    at org.jboss.seam.Component.<init>(Component.java:217)
    at org.jboss.seam.init.Initialization.addComponent(Initialization.java:974)
    ... 21 more
|#]

Answer 1

Мне удалось найти решение той серьезной ошибки, которую я получал. Ключом для меня была строка в сообщении: Caused by: java.security.AccessControlException: access denied (java.lang.reflect.ReflectPermission suppressAccessChecks),

Я погуглил эти слова и наткнулся на сообщение в блоге Java.net, написанное Фелипе Гаучо, http://weblogs.java.net/blog/felipegaucho/archive/2010/01/02/glassfish-securitymanagercheckpermission:

После настройки Hudson для работы на Glassfish с включенным менеджером безопасности у меня начались проблемы в других приложениях, особенно в веб-приложениях, использующих отражение для доступа к закрытым полям в классах Java. Over the web I noticed a lot of people struggling with the same issue (Seam, GWT, Vaadin, etc). The problem is caused because most of the modern frameworks tries to access Java private fields directly - perhaps motivated by the popularity of type-unsafe languages or just designed for better performance. The frameworks designer expect to have this freedom but the Security Manager imposes strict rules against that. Applications based on these frameworks running on a secure Glassfish will eventually throw an exception.

He goes on to suggest two different workarounds, and #2 worked for me. Suppressing the access checks in the security policy of GlassFish by adding the following code to the security policy file:

usr/local/glassfish/domains/domain1/config/server.policy

grant codeBase "file:${com.sun.aas.installRoot}/domains/domain1/applications/your_app_name/-" {
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};