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.<init>(JITCompiler.java:66)
at org.jruby.Ruby.<init>(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.<init>(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
on 13.08.2008 13:28
on 13.08.2008 18:40
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 Doss <joshua.doss@gmail.com> 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
on 14.08.2008 00:05
Thanks for the reply, Rich. I have your page on wiki.oracle.com regarding restful_authentication and SSO bookmarked for inspiration. :) 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 Manalang 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
on 14.08.2008 00:21
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
on 14.08.2008 00:44
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 Doss 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 Manalang wrote:
>> <joshua.doss@gmail.com> 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