BTW: The last Jenkins build showed up the same problem [1]. As I assume that the configuration of Jenkins was not changed from Java 6 to Java 7 I have no Idea why ...
https://builds.apache.org/job/stanbol-trunk-1.6/org.apache.stanbol$org.apache.stanbol.integration-tests/1480/testReport/junit/org.apache.stanbol.enhancer.it/FstLinkingTest/testFstLinkingEnhancement/ best Rupert On Thu, Oct 17, 2013 at 12:59 PM, Rupert Westenthaler <rupert.westentha...@gmail.com> wrote: > HI Reto, > > Thanks for the information. If the 'getClassLoader' permission is not > included in the default I will change the engine to load the Solr > Attribute in a doPrivileged(..) block. The class name is anyway > statically in the code (and not parsed via a configuration). So there > is no danger that a user can load remote code. > > best > Rupert > > > On Thu, Oct 17, 2013 at 11:37 AM, Reto Bachmann-Gmür <r...@apache.org> wrote: >> Hi Rupert, Andreas, all >> >> It seems that indeed ("java.lang.RuntimePermission" "getClassLoader") is not >> part of the basePermissionRole in the 0.X branch but is part of this role in >> the 1.0 branch. The reason is that the ng branch is using >> org.apache.clerezza.platform.config:0.4.0.SNAPSHOT. >> >> The more fundamental issue is that the default system graph is just provided >> by one bundle which sets the system graph if this isn't there yet. Bundles >> could of course modify the system graph in ntheir activators but there >> should be a mechanism that ensures a bundle makes its modifications only >> once and doesn't overwrite subsequent user made changes. >> >> Cheers, >> Reto >> >> >> >> >> >> >> On Thu, Oct 17, 2013 at 6:31 AM, Rupert Westenthaler >> <rupert.westentha...@gmail.com> wrote: >>> >>> Hi Andreas, Reto, all >>> >>> at least we are making progress ... >>> ... loading the FST corpus does now work. >>> >>> But now the engine is running into an other security related problem >>> >>> java.security.AccessControlException: access denied >>> ("java.lang.RuntimePermission" "getClassLoader") >>> at >>> java.security.AccessControlContext.checkPermission(AccessControlContext.java:372) >>> at >>> java.security.AccessController.checkPermission(AccessController.java:559) >>> at >>> java.lang.SecurityManager.checkPermission(SecurityManager.java:549) >>> at >>> java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1549) >>> at java.lang.Class.getClassLoader(Class.java:614) >>> at >>> org.apache.lucene.util.AttributeSource$AttributeFactory$DefaultAttributeFactory.getClassForInterface(AttributeSource.java:79) >>> at >>> org.apache.lucene.util.AttributeSource$AttributeFactory$DefaultAttributeFactory.createAttributeInstance(AttributeSource.java:65) >>> at >>> org.apache.lucene.util.AttributeSource.addAttribute(AttributeSource.java:271) >>> at >>> org.apache.stanbol.enhancer.engines.lucenefstlinking.LinkableTokenFilter.<init>(LinkableTokenFilter.java:148) >>> at >>> org.apache.stanbol.enhancer.engines.lucenefstlinking.FstLinkingEngine.tag(FstLinkingEngine.java:358) >>> at >>> org.apache.stanbol.enhancer.engines.lucenefstlinking.FstLinkingEngine.computeEnhancements(FstLinkingEngine.java:175) >>> >>> indicating that the SecurityManager denies Solr access to the Classloader. >>> >>> LinkableTokenFilter.java:148 registers an Solr Analyzer Attribute to >>> the TokenFilter. The Attribute in question is provided by a JAR that >>> is embedded in the same bundle. Solr uses "Class.forName(..)" in >>> AttributeSource.java:79. >>> >>> @Reto: it it expected that the SecurityManager denies access to the >>> Classloader used by Class.forName(..). Should I move the >>> initialization of the Attributes in a doPrivileged(..) block, or is >>> something really wrong with the SecurityManager configuration of >>> Andreas JVM? >>> >>> best >>> Rupert >>> >>> On Wed, Oct 16, 2013 at 3:31 PM, Andreas Kuckartz <a.kucka...@ping.de> >>> wrote: >>> > Hi Rupert, >>> > >>> > thanks again, but unfortunately the integration tests still fail. Log >>> > file is appended. >>> > >>> > Cheers, >>> > Andreas >>> > --- >>> > >>> > Rupert Westenthaler: >>> >> Hi Andreas >>> >> >>> >> Based on the new error log the problem was accessing the last >>> >> modification date of the FST corpus file outside the doPrivileged() >>> >> block. >>> >> I have fixed this with http://svn.apache.org/r1532742. >>> >> >>> >> Would be nice if you could check again >>> >> >>> >> best >>> >> Rupert >>> > >>> >>> >>> >>> -- >>> | Rupert Westenthaler rupert.westentha...@gmail.com >>> | Bodenlehenstraße 11 ++43-699-11108907 >>> | A-5500 Bischofshofen >> >> > > > > -- > | Rupert Westenthaler rupert.westentha...@gmail.com > | Bodenlehenstraße 11 ++43-699-11108907 > | A-5500 Bischofshofen -- | Rupert Westenthaler rupert.westentha...@gmail.com | Bodenlehenstraße 11 ++43-699-11108907 | A-5500 Bischofshofen
