Oracle Application Server java.lang.SecurityException

Ruby JRuby
1

All-

I’m seeing this strange error (included below) on deployment that I’m
not familiar with which occurs on application deployment (which is
successful inasmuch as it can be) or on any subsequent pagefetch. I’m
at a total loss on it. Google has two hits on the error and Oracle’s
Metalink has no results for it.

I started by deploying a new Rails 2.1 application using JRuby 1.1.3
w/ warbler 0.9.10, which resulted in this error. I then downgraded to
warbler 0.9.9 (and using jruby-complete-1.1.2.jar), which I’m
currently successfully using in production with a Rails 2.1 app,
resulting in the same error. I then removed jruby-complete-1.1.2.jar
in favor of jruby-complete-1.1.1.jar with the same results.

I’ve since dropped the required Rails libraries down to 2.0.2 and
basically tried every permutation of versioning of JRuby, Rails and
warbler with the same results. Making certain that I’m removing the
contents of tmp/war each time. Now here’s where it gets… odd.

I have a production and test environment which have the same
configuration and a backup copy of a war with the perfectly
functioning Rails 2.1 app I mentioned above. In the test environment,
I undeployed the webapp (running fine at the time) and immediately
redeployed the same WAR… and now I get the same error as with
everything else.

So it seems to be a problem with Oracle Application Server… I’ve
reset the java policy file for the container to be as permissive as
possible and still see the error. I’m wondering if anyone on the list
has seen anything like this and would be able to point me in the right
direction about it.

Error:

java.lang.SecurityException: Unauthorised domain name: java.lang for
jmx write type operation
at
oracle
.oc4j
.admin
.jmx.shared.UserMBeanServer.checkWriteAccess(UserMBeanServer.java:601)
at
oracle
.oc4j
.admin.jmx.shared.UserMBeanServer.registerMBean(UserMBeanServer.java:
315)
at sun.management.ManagementFactory$1.run(ManagementFactory.java:
278)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.management.ManagementFactory.addMBean(ManagementFactory.java:273)
at
sun.management.ManagementFactory.addMXBean(ManagementFactory.java:253)
at
sun
.management
.ManagementFactory.createPlatformMBeanServer(ManagementFactory.java:304)
at
java
.lang
.management
.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:504)
at org.jruby.management.BeanManager.register(BeanManager.java:45)
at org.jruby.management.BeanManager.register(BeanManager.java:28)
at org.jruby.compiler.JITCompiler.(JITCompiler.java:66)
at org.jruby.Ruby.(Ruby.java:204)
at org.jruby.Ruby.newInstance(Ruby.java:157)
at
org.jruby.javasupport.JavaEmbedUtils.initialize(JavaEmbedUtils.java:84)
at
org
.jruby
.rack
.DefaultRackApplicationFactory
.newRuntime(DefaultRackApplicationFactory.java:79)
at
org
.jruby
.rack
.DefaultRackApplicationFactory
.createApplication(DefaultRackApplicationFactory.java:146)
at
org
.jruby
.rack
.DefaultRackApplicationFactory
.newErrorApplication(DefaultRackApplicationFactory.java:99)
at
org
.jruby
.rack
.DefaultRackApplicationFactory.init(DefaultRackApplicationFactory.java:
39)
at
org
.jruby
.rack
.PoolingRackApplicationFactory.init(PoolingRackApplicationFactory.java:
53)
at
org
.jruby
.rack
.RackServletContextListener
.contextInitialized(RackServletContextListener.java:38)
at
com
.evermind.server.http.HttpApplication.initDynamic(HttpApplication.java:
1009)
at
com.evermind.server.http.HttpApplication.(HttpApplication.java:
549)
at
com.evermind.server.Application.getHttpApplication(Application.java:890)
at
com.evermind.server.http.HttpServer.getHttpApplication(HttpServer.java:
707)
at
com.evermind.server.http.HttpSite.initApplications(HttpSite.java:625)
at com.evermind.server.http.HttpSite.setConfig(HttpSite.java:278)
at com.evermind.server.http.HttpServer.setSites(HttpServer.java:
278)
at com.evermind.server.http.HttpServer.setConfig(HttpServer.java:
179)
at
com
.evermind
.server.ApplicationServer.initializeHttp(ApplicationServer.java:2394)
at
com.evermind.server.ApplicationServer.setConfig(ApplicationServer.java:
1551)
at
com
.evermind
.server.ApplicationServerLauncher.run(ApplicationServerLauncher.java:92)

Setup:

  • Windows Server 2K3
  • Java 5 EE / JDK 6 (1.6.0_05-b13 / HotSpot Client 10.0-b19, mixed mode)
  • Oracle Collaboration v10.1.1.0.2
    • Oracle Portal v10.1.4
    • Oracle Application Server v10.1
  • Warbler 0.9.10 (with the default jruby-complete/rack)
  • Rails 2.1

Thanks.

-J.

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
2

Hi. We’re running a similar environment on mix.oracle.com (OAS
10.1.3/JDK 1.5/Rails 2.1 on Linux). We use Warbler 0.9.5 (we have
dependencies on Goldspike that JRuby-Rack doesn’t provide). Anyway,
your problem maybe related to running OAS on JDK 1.6. As far as I
know, Oracle doesn’t support that running on JDK 1.6.

Rich

On Wed, Aug 13, 2008 at 4:28 AM, Joshua D. [email protected]
wrote:

0.9.9 (and using jruby-complete-1.1.2.jar), which I’m currently successfully
and a backup copy of a war with the perfectly functioning Rails 2.1 app I

at
at
org.jruby.rack.RackServletContextListener.contextInitialized(RackServletContextListener.java:38)
at com.evermind.server.http.HttpServer.setSites(HttpServer.java:278)

-J.

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
3

Thanks for the reply, Rich. I have your page on wiki.oracle.com
regarding restful_authentication and SSO bookmarked for
inspiration. :slight_smile: Although I was never able to replicate it because I
don’t think $java_servlet_response was a valid object in my setup. Is
that a reason why Goldspike is being used on mix.oracle.com?

I figured that configuring the container to use JDK 1.6 was likely an
aggravating factor in the problem… and there’s a few nits I’ve found
with form processing and file uploading (tempfiles seem to be based on
the remote filename alone) that may be a result of that pairing.

However, I stumbled onto the root cause of the problem… when I
upgraded my local copy of JRuby to v1.1.3, I installed from scratch
all the gems and gem versions that I’m actively using (vs. the litany
of old, unused, or “testing” gems I had in my local prior version).

After seeing JRuby 1.1.3 and warbler 0.9.10 break down along the way,
I simply installed warbler v0.9.9 via gem repo and grabbed a copy of
jruby-complete-1.1.2.jar from
http://repository.codehaus.org/org/jruby/jruby-complete/
… as it turns out, the version of that jar at that location does
not match the version of the jar that I had been running without
problems until that point. And md5sum comparison of the two files
(done from cygwin on XP) outputs the following:

e1cee975c94b98654a336ef9780e7cc4 *jruby-complete-1.1.2.jar
5b40eafb8a001ad1c669df641cb196c0 *jruby-complete-1.1.2.jar.dont_use

(*.dont_use is the version pulled from the above URL)

I don’t know from where I would have pulled the previous jar, but it
would have been sometime in May, so likely from a wiki page on Rack/
Warbler or possibly from some series of links starting from a blog
post regarding Warbler … I would say that, all things considered, my
“working version” of the complete jar is older than the current and
unofficial. The error, I would bet at this point, stems in large part
from an old version of the java.policy file for 1.4 being used for
1.6. … this assumes, also, that my previous tests regarding jruby-
complete-1.1.1.jar were invalid…

-J.

On Aug 13, 2008, at 12:40 PM, Rich M. wrote:

All-
I started by deploying a new Rails 2.1 application using JRuby

and a backup copy of a war with the perfectly functioning Rails 2.1
and still
oracle
278)
304)
at
.jruby
org
at
com
com.evermind.server.http.HttpSite.initApplications(HttpSite.java:625)
com

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
4

Tested a new java policy whose contents are:

grant {
permission java.security.AllPermission;
};

Assuming that the above is a correct policy, the attempt was
unsuccessful… same error as before.

-J.

On Aug 13, 2008, at 6:05 PM, Joshua D. wrote:

pairing.
… as it turns out, the version of that jar at that location does
would have been sometime in May, so likely from a wiki page on Rack/
On Aug 13, 2008, at 12:40 PM, Rich M. wrote:

[email protected] wrote:

results for it.
complete-1.1.1.jar
I have a production and test environment which have the same
reset the
write type operation
.jmx.shared.UserMBeanServer.registerMBean(UserMBeanServer.java:315)
sun
at org.jruby.management.BeanManager.register(BeanManager.java:28)
.DefaultRackApplicationFactory
.rack
.jruby
com
at
179)
com

  • Oracle Collaboration v10.1.1.0.2

http://xircles.codehaus.org/manage_email

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
5

Yep, our dependency on Goldspike is strictly because of the
$java_servlet
object being available to our app. We don’t use it for anything other
than
SSO. Sometime I’ll sit down and port the Oracle SSO module to Ruby so
we
don’t need to rely on Goldspike any more.

As far as the jars go, I find it’s best to build your own jars.
Besides,
you’ll want to build on the proper JDK that your appserv will be running
on.

Rich