You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by David Jordan <Da...@sas.com> on 2011/09/23 19:54:28 UTC
JMX issue with TDB-0.8.11-SNAPSHOT
I am getting the following exception for one of my programs, but not others, curiously.
WARN [main] (Log.java:146) - Failed to initialize JMX
java.security.AccessControlException: access denied (javax.management.MBeanTrustPermission register)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:568)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.checkMBeanTrustPermission(DefaultMBeanServerInterceptor.java:1824)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:310)
at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:482)
at com.hp.hpl.jena.sparql.mgt.ARQMgt.register(ARQMgt.java:88)
at com.hp.hpl.jena.sparql.mgt.ARQMgt.init(ARQMgt.java:54)
at com.hp.hpl.jena.query.ARQ.init(ARQ.java:400)
at com.hp.hpl.jena.query.ARQ.<clinit>(ARQ.java:419)
at com.hp.hpl.jena.tdb.TDB.<clinit>(TDB.java:76)
at com.sas.hls.hoa.ontology.Database.<clinit>(Database.java:17)
at com.sas.hls.hoa.ontology.CreateOntologySingletons.main(CreateOntologySingletons.java:20)
David Jordan
Software Developer
SAS Institute Inc.
Health & Life Sciences, Research & Development
Bldg R ▪ Office 4467
600 Research Drive ▪ Cary, NC 27513
Tel: 919 531 1233 ▪ david.jordan@sas.com<ma...@sas.com>
www.sas.com<http://www.sas.com>
SAS® … THE POWER TO KNOW®
Re: JMX issue with TDB-0.8.11-SNAPSHOT
Posted by Brian McBride <br...@epimorphics.com>.
Thanks David - I'll try that as a workaround.
brian
On 17/10/2011 16:47, David Jordan wrote:
> I included the following on the command line
> -Djava.security.policy=java.policy
>
> And had a file named java.policy containing the following:
> grant {
> permission javax.management.MBeanTrustPermission "register";
> }
>
> This took care of the issue. I also moved back to 0.8.10. I was just running a simple Java application that was not running in any app server environment.
>
>
> -----Original Message-----
> From: Brian McBride [mailto:brian@epimorphics.com]
> Sent: Monday, October 17, 2011 11:34 AM
> To: jena-users@incubator.apache.org
> Subject: Re: JMX issue with TDB-0.8.11-SNAPSHOT
>
> I am seeing the same problem, but with 0.8.10. Log trace below.
>
> I running a maven build which is invoking an ant build.xml file which uses tdbloader to load an ntriples file into a fresh tdb store.
>
> It is tdbloader that is barfing.
>
> Brian
>
>
>
>
> ================
> WARN [main] (Log.java:73) - Failed to initialize JMX
> java.security.AccessControlException: access denied (javax.management.MBeanTrustPermission register)
> at
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:393)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:585)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.checkMBeanTrustPermission(DefaultMBeanServerInterceptor.java:1868)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:328)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:516)
> at com.hp.hpl.jena.sparql.mgt.ARQMgt.register(ARQMgt.java:88)
> at com.hp.hpl.jena.sparql.mgt.ARQMgt.init(ARQMgt.java:54)
> at com.hp.hpl.jena.query.ARQ.init(ARQ.java:368)
> at com.hp.hpl.jena.query.ARQ.<clinit>(ARQ.java:385)
> at com.hp.hpl.jena.tdb.TDB.<clinit>(TDB.java:76)
> at tdb.tdbloader.main(tdbloader.java:39)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at org.apache.tools.ant.taskdefs.ExecuteJava.run(ExecuteJava.java:217)
> at
> org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:152)
> at org.apache.tools.ant.taskdefs.Java.run(Java.java:771)
> at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:221)
> at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:135)
> at org.apache.tools.ant.taskdefs.Java.execute(Java.java:108)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:390)
> at org.apache.tools.ant.Target.performTasks(Target.java:411)
> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1397)
> at
> org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
> at org.apache.tools.ant.Project.executeTargets(Project.java:1249)
> at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:390)
> at org.apache.tools.ant.Target.performTasks(Target.java:411)
> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1397)
> at org.apache.tools.ant.Project.executeTarget(Project.java:1366)
> at
> org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:270)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:534)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
>
> On 25/09/2011 19:11, David Jordan wrote:
>> No, it is just one of my plain simple Java applications, no app server at all. I have a number of small applications, all make the same call to a class of mine called Database, which has the following static initializer.
>>
>> static {
>> TDB.setOptimizerWarningFlag(false);
>> }
>>
>> Only one of the programs causes this exception. I had run this program before Friday, never got this problem. And Friday, it was only happening with this one program, consistently. It was weird. I set up a JMX policy file to grant the register permission, so the problem is no longer holding me up. But it is very weird that this was happening for just one of the programs, and that it had worked fine before.
>>
>>
>> -----Original Message-----
>> From: Andy Seaborne [mailto:andy.seaborne.apache@gmail.com] On Behalf
>> Of Andy Seaborne
>> Sent: Saturday, September 24, 2011 3:54 PM
>> To: jena-users@incubator.apache.org
>> Subject: Re: JMX issue with TDB-0.8.11-SNAPSHOT
>>
>> On 23/09/11 18:54, David Jordan wrote:
>>> I am getting the following exception for one of my programs, but not others, curiously.
>>>
>>> WARN [main] (Log.java:146) - Failed to initialize JMX
>>> java.security.AccessControlException: access denied (javax.management.MBeanTrustPermission register)
>>> at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
>>> at java.lang.SecurityManager.checkPermission(SecurityManager.java:568)
>>> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.checkMBeanTrustPermission(DefaultMBeanServerInterceptor.java:1824)
>>> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:310)
>>> at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:482)
>>> at com.hp.hpl.jena.sparql.mgt.ARQMgt.register(ARQMgt.java:88)
>>> at com.hp.hpl.jena.sparql.mgt.ARQMgt.init(ARQMgt.java:54)
>>> at com.hp.hpl.jena.query.ARQ.init(ARQ.java:400)
>>> at com.hp.hpl.jena.query.ARQ.<clinit>(ARQ.java:419)
>>> at com.hp.hpl.jena.tdb.TDB.<clinit>(TDB.java:76)
>>> at com.sas.hls.hoa.ontology.Database.<clinit>(Database.java:17)
>>> at
>>> com.sas.hls.hoa.ontology.CreateOntologySingletons.main(CreateOntology
>>> S
>>> ingletons.java:20)
>>>
>> In what environment is this running? I've not seen it and the "access denied" implies the app isn't being allowed to register mbeans. is this some webapp container and might it have some sort of security on?
>>
>> Andy
>>
>>> David Jordan
>>> Software Developer
>>> SAS Institute Inc.
>>> Health& Life Sciences, Research& Development Bldg R ▪ Office 4467
>>> 600 Research Drive ▪ Cary, NC 27513
>>> Tel: 919 531 1233 ▪ david.jordan@sas.com<ma...@sas.com>
>>> www.sas.com<http://www.sas.com>
>>> SAS® … THE POWER TO KNOW®
>>>
>>>
>>>
RE: JMX issue with TDB-0.8.11-SNAPSHOT
Posted by David Jordan <Da...@sas.com>.
I included the following on the command line
-Djava.security.policy=java.policy
And had a file named java.policy containing the following:
grant {
permission javax.management.MBeanTrustPermission "register";
}
This took care of the issue. I also moved back to 0.8.10. I was just running a simple Java application that was not running in any app server environment.
-----Original Message-----
From: Brian McBride [mailto:brian@epimorphics.com]
Sent: Monday, October 17, 2011 11:34 AM
To: jena-users@incubator.apache.org
Subject: Re: JMX issue with TDB-0.8.11-SNAPSHOT
I am seeing the same problem, but with 0.8.10. Log trace below.
I running a maven build which is invoking an ant build.xml file which uses tdbloader to load an ntriples file into a fresh tdb store.
It is tdbloader that is barfing.
Brian
================
WARN [main] (Log.java:73) - Failed to initialize JMX
java.security.AccessControlException: access denied (javax.management.MBeanTrustPermission register)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:393)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:585)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.checkMBeanTrustPermission(DefaultMBeanServerInterceptor.java:1868)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:328)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:516)
at com.hp.hpl.jena.sparql.mgt.ARQMgt.register(ARQMgt.java:88)
at com.hp.hpl.jena.sparql.mgt.ARQMgt.init(ARQMgt.java:54)
at com.hp.hpl.jena.query.ARQ.init(ARQ.java:368)
at com.hp.hpl.jena.query.ARQ.<clinit>(ARQ.java:385)
at com.hp.hpl.jena.tdb.TDB.<clinit>(TDB.java:76)
at tdb.tdbloader.main(tdbloader.java:39)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.apache.tools.ant.taskdefs.ExecuteJava.run(ExecuteJava.java:217)
at
org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:152)
at org.apache.tools.ant.taskdefs.Java.run(Java.java:771)
at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:221)
at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:135)
at org.apache.tools.ant.taskdefs.Java.execute(Java.java:108)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:390)
at org.apache.tools.ant.Target.performTasks(Target.java:411)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1397)
at
org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
at org.apache.tools.ant.Project.executeTargets(Project.java:1249)
at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:390)
at org.apache.tools.ant.Target.performTasks(Target.java:411)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1397)
at org.apache.tools.ant.Project.executeTarget(Project.java:1366)
at
org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:270)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:534)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
On 25/09/2011 19:11, David Jordan wrote:
> No, it is just one of my plain simple Java applications, no app server at all. I have a number of small applications, all make the same call to a class of mine called Database, which has the following static initializer.
>
> static {
> TDB.setOptimizerWarningFlag(false);
> }
>
> Only one of the programs causes this exception. I had run this program before Friday, never got this problem. And Friday, it was only happening with this one program, consistently. It was weird. I set up a JMX policy file to grant the register permission, so the problem is no longer holding me up. But it is very weird that this was happening for just one of the programs, and that it had worked fine before.
>
>
> -----Original Message-----
> From: Andy Seaborne [mailto:andy.seaborne.apache@gmail.com] On Behalf
> Of Andy Seaborne
> Sent: Saturday, September 24, 2011 3:54 PM
> To: jena-users@incubator.apache.org
> Subject: Re: JMX issue with TDB-0.8.11-SNAPSHOT
>
> On 23/09/11 18:54, David Jordan wrote:
>> I am getting the following exception for one of my programs, but not others, curiously.
>>
>> WARN [main] (Log.java:146) - Failed to initialize JMX
>> java.security.AccessControlException: access denied (javax.management.MBeanTrustPermission register)
>> at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
>> at java.lang.SecurityManager.checkPermission(SecurityManager.java:568)
>> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.checkMBeanTrustPermission(DefaultMBeanServerInterceptor.java:1824)
>> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:310)
>> at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:482)
>> at com.hp.hpl.jena.sparql.mgt.ARQMgt.register(ARQMgt.java:88)
>> at com.hp.hpl.jena.sparql.mgt.ARQMgt.init(ARQMgt.java:54)
>> at com.hp.hpl.jena.query.ARQ.init(ARQ.java:400)
>> at com.hp.hpl.jena.query.ARQ.<clinit>(ARQ.java:419)
>> at com.hp.hpl.jena.tdb.TDB.<clinit>(TDB.java:76)
>> at com.sas.hls.hoa.ontology.Database.<clinit>(Database.java:17)
>> at
>> com.sas.hls.hoa.ontology.CreateOntologySingletons.main(CreateOntology
>> S
>> ingletons.java:20)
>>
> In what environment is this running? I've not seen it and the "access denied" implies the app isn't being allowed to register mbeans. is this some webapp container and might it have some sort of security on?
>
> Andy
>
>> David Jordan
>> Software Developer
>> SAS Institute Inc.
>> Health& Life Sciences, Research& Development Bldg R ▪ Office 4467
>> 600 Research Drive ▪ Cary, NC 27513
>> Tel: 919 531 1233 ▪ david.jordan@sas.com<ma...@sas.com>
>> www.sas.com<http://www.sas.com>
>> SAS® … THE POWER TO KNOW®
>>
>>
>>
>
Re: JMX issue with TDB-0.8.11-SNAPSHOT
Posted by Brian McBride <br...@epimorphics.com>.
Hi Ian,
That's how I was using it till today - well exec:java actually.
I switched to using ant because I want to a conditional build (i.e. only
build the data if the source files have changed). Couldn't find a way
to do that in maven. Suggestions welcome.
Brian
On 17/10/2011 16:46, Ian Dickinson wrote:
> Hi Brian,
>
> On 17/10/11 16:34, Brian McBride wrote:
>> I running a maven build which is invoking an ant build.xml file which
>> uses tdbloader to load an ntriples file into a fresh tdb store.
> Not saying that it's part of the problem, but if you use exec:exec you
> can invoke tdbloader without needing to go via Ant.
>
> http://mojo.codehaus.org/exec-maven-plugin/exec-mojo.html
>
> Ian
>
>
Re: JMX issue with TDB-0.8.11-SNAPSHOT
Posted by Ian Dickinson <ia...@epimorphics.com>.
Hi Brian,
On 17/10/11 16:34, Brian McBride wrote:
> I running a maven build which is invoking an ant build.xml file which
> uses tdbloader to load an ntriples file into a fresh tdb store.
Not saying that it's part of the problem, but if you use exec:exec you
can invoke tdbloader without needing to go via Ant.
http://mojo.codehaus.org/exec-maven-plugin/exec-mojo.html
Ian
--
____________________________________________________________
Ian Dickinson Epimorphics Ltd, Bristol, UK
mailto:ian@epimorphics.com http://www.epimorphics.com
cell: +44-7786-850536 landline: +44-1275-399069
------------------------------------------------------------
Epimorphics Ltd. is a limited company registered in England
(no. 7016688). Registered address: Court Lodge, 105 High St,
Portishead, Bristol BS20 6PT, UK
Re: JMX issue with TDB-0.8.11-SNAPSHOT
Posted by Brian McBride <br...@epimorphics.com>.
I am seeing the same problem, but with 0.8.10. Log trace below.
I running a maven build which is invoking an ant build.xml file which
uses tdbloader to load an ntriples file into a fresh tdb store.
It is tdbloader that is barfing.
Brian
================
WARN [main] (Log.java:73) - Failed to initialize JMX
java.security.AccessControlException: access denied
(javax.management.MBeanTrustPermission register)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:393)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:585)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.checkMBeanTrustPermission(DefaultMBeanServerInterceptor.java:1868)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:328)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:516)
at com.hp.hpl.jena.sparql.mgt.ARQMgt.register(ARQMgt.java:88)
at com.hp.hpl.jena.sparql.mgt.ARQMgt.init(ARQMgt.java:54)
at com.hp.hpl.jena.query.ARQ.init(ARQ.java:368)
at com.hp.hpl.jena.query.ARQ.<clinit>(ARQ.java:385)
at com.hp.hpl.jena.tdb.TDB.<clinit>(TDB.java:76)
at tdb.tdbloader.main(tdbloader.java:39)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.apache.tools.ant.taskdefs.ExecuteJava.run(ExecuteJava.java:217)
at
org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:152)
at org.apache.tools.ant.taskdefs.Java.run(Java.java:771)
at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:221)
at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:135)
at org.apache.tools.ant.taskdefs.Java.execute(Java.java:108)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:390)
at org.apache.tools.ant.Target.performTasks(Target.java:411)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1397)
at
org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
at org.apache.tools.ant.Project.executeTargets(Project.java:1249)
at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:390)
at org.apache.tools.ant.Target.performTasks(Target.java:411)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1397)
at org.apache.tools.ant.Project.executeTarget(Project.java:1366)
at
org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:270)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:534)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
On 25/09/2011 19:11, David Jordan wrote:
> No, it is just one of my plain simple Java applications, no app server at all. I have a number of small applications, all make the same call to a class of mine called Database, which has the following static initializer.
>
> static {
> TDB.setOptimizerWarningFlag(false);
> }
>
> Only one of the programs causes this exception. I had run this program before Friday, never got this problem. And Friday, it was only happening with this one program, consistently. It was weird. I set up a JMX policy file to grant the register permission, so the problem is no longer holding me up. But it is very weird that this was happening for just one of the programs, and that it had worked fine before.
>
>
> -----Original Message-----
> From: Andy Seaborne [mailto:andy.seaborne.apache@gmail.com] On Behalf Of Andy Seaborne
> Sent: Saturday, September 24, 2011 3:54 PM
> To: jena-users@incubator.apache.org
> Subject: Re: JMX issue with TDB-0.8.11-SNAPSHOT
>
> On 23/09/11 18:54, David Jordan wrote:
>> I am getting the following exception for one of my programs, but not others, curiously.
>>
>> WARN [main] (Log.java:146) - Failed to initialize JMX
>> java.security.AccessControlException: access denied (javax.management.MBeanTrustPermission register)
>> at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
>> at java.lang.SecurityManager.checkPermission(SecurityManager.java:568)
>> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.checkMBeanTrustPermission(DefaultMBeanServerInterceptor.java:1824)
>> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:310)
>> at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:482)
>> at com.hp.hpl.jena.sparql.mgt.ARQMgt.register(ARQMgt.java:88)
>> at com.hp.hpl.jena.sparql.mgt.ARQMgt.init(ARQMgt.java:54)
>> at com.hp.hpl.jena.query.ARQ.init(ARQ.java:400)
>> at com.hp.hpl.jena.query.ARQ.<clinit>(ARQ.java:419)
>> at com.hp.hpl.jena.tdb.TDB.<clinit>(TDB.java:76)
>> at com.sas.hls.hoa.ontology.Database.<clinit>(Database.java:17)
>> at
>> com.sas.hls.hoa.ontology.CreateOntologySingletons.main(CreateOntologyS
>> ingletons.java:20)
>>
> In what environment is this running? I've not seen it and the "access denied" implies the app isn't being allowed to register mbeans. is this some webapp container and might it have some sort of security on?
>
> Andy
>
>> David Jordan
>> Software Developer
>> SAS Institute Inc.
>> Health& Life Sciences, Research& Development Bldg R ▪ Office 4467
>> 600 Research Drive ▪ Cary, NC 27513
>> Tel: 919 531 1233 ▪ david.jordan@sas.com<ma...@sas.com>
>> www.sas.com<http://www.sas.com>
>> SAS® … THE POWER TO KNOW®
>>
>>
>>
>
RE: JMX issue with TDB-0.8.11-SNAPSHOT
Posted by David Jordan <Da...@sas.com>.
No, it is just one of my plain simple Java applications, no app server at all. I have a number of small applications, all make the same call to a class of mine called Database, which has the following static initializer.
static {
TDB.setOptimizerWarningFlag(false);
}
Only one of the programs causes this exception. I had run this program before Friday, never got this problem. And Friday, it was only happening with this one program, consistently. It was weird. I set up a JMX policy file to grant the register permission, so the problem is no longer holding me up. But it is very weird that this was happening for just one of the programs, and that it had worked fine before.
-----Original Message-----
From: Andy Seaborne [mailto:andy.seaborne.apache@gmail.com] On Behalf Of Andy Seaborne
Sent: Saturday, September 24, 2011 3:54 PM
To: jena-users@incubator.apache.org
Subject: Re: JMX issue with TDB-0.8.11-SNAPSHOT
On 23/09/11 18:54, David Jordan wrote:
> I am getting the following exception for one of my programs, but not others, curiously.
>
> WARN [main] (Log.java:146) - Failed to initialize JMX
> java.security.AccessControlException: access denied (javax.management.MBeanTrustPermission register)
> at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:568)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.checkMBeanTrustPermission(DefaultMBeanServerInterceptor.java:1824)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:310)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:482)
> at com.hp.hpl.jena.sparql.mgt.ARQMgt.register(ARQMgt.java:88)
> at com.hp.hpl.jena.sparql.mgt.ARQMgt.init(ARQMgt.java:54)
> at com.hp.hpl.jena.query.ARQ.init(ARQ.java:400)
> at com.hp.hpl.jena.query.ARQ.<clinit>(ARQ.java:419)
> at com.hp.hpl.jena.tdb.TDB.<clinit>(TDB.java:76)
> at com.sas.hls.hoa.ontology.Database.<clinit>(Database.java:17)
> at
> com.sas.hls.hoa.ontology.CreateOntologySingletons.main(CreateOntologyS
> ingletons.java:20)
>
In what environment is this running? I've not seen it and the "access denied" implies the app isn't being allowed to register mbeans. is this some webapp container and might it have some sort of security on?
Andy
>
> David Jordan
> Software Developer
> SAS Institute Inc.
> Health& Life Sciences, Research& Development Bldg R ▪ Office 4467
> 600 Research Drive ▪ Cary, NC 27513
> Tel: 919 531 1233 ▪ david.jordan@sas.com<ma...@sas.com>
> www.sas.com<http://www.sas.com>
> SAS® … THE POWER TO KNOW®
>
>
>
Re: JMX issue with TDB-0.8.11-SNAPSHOT
Posted by Andy Seaborne <an...@apache.org>.
On 23/09/11 18:54, David Jordan wrote:
> I am getting the following exception for one of my programs, but not others, curiously.
>
> WARN [main] (Log.java:146) - Failed to initialize JMX
> java.security.AccessControlException: access denied (javax.management.MBeanTrustPermission register)
> at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:568)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.checkMBeanTrustPermission(DefaultMBeanServerInterceptor.java:1824)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:310)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:482)
> at com.hp.hpl.jena.sparql.mgt.ARQMgt.register(ARQMgt.java:88)
> at com.hp.hpl.jena.sparql.mgt.ARQMgt.init(ARQMgt.java:54)
> at com.hp.hpl.jena.query.ARQ.init(ARQ.java:400)
> at com.hp.hpl.jena.query.ARQ.<clinit>(ARQ.java:419)
> at com.hp.hpl.jena.tdb.TDB.<clinit>(TDB.java:76)
> at com.sas.hls.hoa.ontology.Database.<clinit>(Database.java:17)
> at com.sas.hls.hoa.ontology.CreateOntologySingletons.main(CreateOntologySingletons.java:20)
>
In what environment is this running? I've not seen it and the "access
denied" implies the app isn't being allowed to register mbeans. is this
some webapp container and might it have some sort of security on?
Andy
>
> David Jordan
> Software Developer
> SAS Institute Inc.
> Health& Life Sciences, Research& Development
> Bldg R ▪ Office 4467
> 600 Research Drive ▪ Cary, NC 27513
> Tel: 919 531 1233 ▪ david.jordan@sas.com<ma...@sas.com>
> www.sas.com<http://www.sas.com>
> SAS® … THE POWER TO KNOW®
>
>
>