Hi Andreas, all With http://svn.apache.org/r1533055 the Attributes are loaded in a doPrivileged() block. Can you check if this finally solves the issue for you.
best Rupert On Thu, Oct 17, 2013 at 1:09 PM, Rupert Westenthaler <rupert.westentha...@gmail.com> wrote: > 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 -- | Rupert Westenthaler rupert.westentha...@gmail.com | Bodenlehenstraße 11 ++43-699-11108907 | A-5500 Bischofshofen
