Question

I am new to my position, and am in the process of learning Java because 2 of the applications I am responsible for are written in Java. Unfortunately for me though, when our networking folks did an apache upgrade on the Linux machine, it caused outages to our website and GlassFish. They have since restored Apache to the version we were running prior to the upgrade, and along with this they had to obtain a new key for the SSL.

My environment:
Physical Linux Suse Enterprise server, with Apache 2.2.10 and GlassFish Enterprise Server v.2.1.1 which is running one web application & one enterprise application.

The steps I have taken so far:

1. imported the new SSL into keystore.
2. updated domain.xml to reflect the changes in alias & keystore file
3. restarted Derby database (a.k.a. JavaDB):
   asadmin start-database –dbhost 0.0.0.0 –dbport 1527
4. restarted the GlassFish domain:
   asadmin start-domain domain1

Applications were not running because of a couple severe errors, one being something to do with JDBC connection to MySQL. So I logged into admin console and ping’d all the connection pools. MySQL wasn’t connecting so I discovered two things under ‘additional properties’: the IP address for serverName had an extra digit, so I removed it. and the url was missing an IP address jdbc:mysql://3306/dbname so I changed it to jdbc:mysql://127.0.0.1:3306/dbname. I ping’d again and this fixed the connection issue.

So I stopped and started the domain again, but still nothing. At least I’m down to just 2 severe errors though. I’ve copied the main error message from the server log below. The other message is simply stating the applications couldn’t start because of previous errors. Since I’ve been in this position, no changes have been made to either of the applications running on the GlassFish server and no changes were done in the admin console prior to this outage.

Fixing the issues up to this point has been no easy task for me. I’ve done lots of Googleing and found a lot of help so far but I’m not having much luck with the below issue. Seems like I shouldn’t need to change anything on the actual application(s) since they were working prior to this. Any ideas? Thanks for you time!

[#|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

I was able to find the solution to the Severe error I was receiving. The key for me was the line in the message: Caused by: java.security.AccessControlException: access denied (java.lang.reflect.ReflectPermission suppressAccessChecks).

I Googled these words and stumbled upon a Java.net blog post written by Felipe Gaucho, http://weblogs.java.net/blog/felipegaucho/archive/2010/01/02/glassfish-securitymanagercheckpermission:

After configuring Hudson to run in a Glassfish with security manager
enabled I started to have problems in other applications, specially
web applications using reflection to access private fields in Java
classes. 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";
};