I added an updated patch set @ http://codereview.appspot.com/4345041/
It seems to work locally. Do you see anything wrong with that or see anything that I missed? <http://codereview.appspot.com/4345041/>Regards, Eric On Fri, Apr 1, 2011 at 12:54 PM, Eric Norman <[email protected]>wrote: > Right. That's the main reason why I was suggesting to expand the itemId > back to a path before passing it on to the AccessManagerPlugin > implementation. The item path is something the AccessManagerPlugin should > know what to with. > > Regards, > Eric > > > On Fri, Apr 1, 2011 at 8:36 AM, Justin Edelson > <[email protected]>wrote: > >> What I mean is that ItemId is an opaque object. The only thing you can >> do with it *by itself* is to figure out whether or not the Id denotes >> a Node. IIUC, to do anything useful, you need to use classes from >> org.apache.jackrabbit.core. >> >> However, I don't think this should block trunk from being updated to >> 2.2.5. It is, however, something we should resolve before the next >> release. >> >> Justin >> >> On Fri, Apr 1, 2011 at 9:57 AM, Eric Norman <[email protected]> >> wrote: >> > It's hard to predict what an implementor would do. The more I think >> about >> > it, maybe it would make more sense for us to just lookup the path for >> the >> > ItemId and not bother passing along the second argument. Then we >> wouldn't >> > need the AccessManagerPlugin2 interface at all. >> > Eric >> > On Fri, Apr 1, 2011 at 6:17 AM, Justin Edelson < >> [email protected]> >> > wrote: >> >> >> >> On Fri, Apr 1, 2011 at 12:42 AM, Eric Norman <[email protected]> >> >> wrote: >> >> > Thanks for the review. >> >> > >> >> > Maybe it is ok to just pass the ItemId to the >> >> > AccessManagerPlugin2#canRead >> >> > method as a string? >> >> >> >> That'd solve the export problem, but the question remains - what would >> >> an implementor of AccessManagerPlugin2 actually *do* with this value? >> >> >> >> > >> >> > >> >> > On Thu, Mar 31, 2011 at 6:37 PM, Justin Edelson >> >> > <[email protected]>wrote: >> >> > >> >> >> I made a few comments. Mostly API version bumps which aren't AFAIK >> >> >> necessary. >> >> >> >> >> >> The bigger issue, to me, is the AccessManagerPlugin2 interface's use >> >> >> of org.apache.jackrabbit.core.id.ItemId. This is *not* a Jackrabbit >> >> >> API class and I have my doubts that we should be exporting it (as I >> >> >> did in my patch). >> >> >> >> >> >> Is it actually possible to implement AccessManagerPlugin2 and do >> >> >> anything of import with the ItemID parameter? >> >> >> >> >> >> I'll take a look at the Tika issue. Did you try 0.9? >> >> >> >> >> >> Justin >> >> >> >> >> >> On Thu, Mar 31, 2011 at 8:45 PM, Eric Norman < >> [email protected]> >> >> >> wrote: >> >> >> > Moving further discussion to the dev list... >> >> >> > Thanks Justin, >> >> >> > I almost got it working using your patch + some other changes. >> >> >> > See the diffs @ http://codereview.appspot.com/4345041/ >> >> >> > Now I hit an issue loading the tika parsers that was described @ >> >> >> > http://jackrabbit.markmail.org/thread/k5fhbkbs774buv4w >> >> >> > Any suggestions on how to workaround that? >> >> >> > If I use version 0.6 of the tika bundle the repository will start >> but >> >> >> throws >> >> >> > NPE when extracting text for the search index: >> >> >> > 31.03.2011 17:38:35.968 *WARN* [jackrabbit-pool-1] >> >> >> > org.apache.jackrabbit.core.query.lucene.LazyTextExtractorField >> Failed >> >> >> > to >> >> >> > extract text from a binary >> >> >> > property java.lang.NullPointerException >> >> >> > at >> >> >> > >> >> >> > >> org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:92) >> >> >> > at >> >> >> > >> >> >> >> >> >> >> org.apache.jackrabbit.core.query.lucene.JackrabbitParser.parse(JackrabbitParser.java:192) >> >> >> > at >> >> >> > >> >> >> >> >> >> >> org.apache.jackrabbit.core.query.lucene.LazyTextExtractorField$ParsingTask.run(LazyTextExtractorField.java:174) >> >> >> > >> >> >> > If I use version 0.8 of the tika bundle it throws a >> RuntimeException >> >> >> > that >> >> >> > makes the repository not start properly: >> >> >> > 31.03.2011 17:43:13.171 *INFO* [Repository Pinger] >> >> >> > org.apache.jackrabbit.core.RepositoryImpl Repository has been >> >> >> > shutdown >> >> >> > 31.03.2011 17:43:13.171 *ERROR* [Repository Pinger] >> >> >> > org.apache.sling.jcr.jackrabbit.server startRepository: Uncaught >> >> >> Throwable >> >> >> > trying to access Reposi >> >> >> > tory, calling stopRepository() (java.lang.RuntimeException: Unable >> to >> >> >> load >> >> >> > embedded Tika configuration) java.lang.RuntimeException: Unable to >> >> >> > load >> >> >> emb >> >> >> > edded Tika configuration >> >> >> > at >> >> >> > >> >> >> >> >> >> >> org.apache.jackrabbit.core.query.lucene.JackrabbitParser.<init>(JackrabbitParser.java:91) >> >> >> > at >> >> >> > >> >> >> >> >> >> >> org.apache.jackrabbit.core.query.lucene.SearchIndex.<init>(SearchIndex.java:211) >> >> >> > at >> >> >> > sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >> >> >> > Method) >> >> >> > at >> >> >> > sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown >> >> >> > Source) >> >> >> > at >> >> >> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown >> >> >> > Source) >> >> >> > at java.lang.reflect.Constructor.newInstance(Unknown >> Source) >> >> >> > at java.lang.Class.newInstance0(Unknown Source) >> >> >> > at java.lang.Class.newInstance(Unknown Source) >> >> >> > at >> >> >> > >> >> >> >> >> >> >> org.apache.jackrabbit.core.config.BeanConfig.newInstance(BeanConfig.java:189) >> >> >> > at >> >> >> > >> >> >> >> >> >> >> org.apache.jackrabbit.core.config.RepositoryConfigurationParser$1.getQueryHandler(RepositoryConfigurationParser.java:631) >> >> >> > at >> >> >> > >> >> >> >> >> >> >> org.apache.jackrabbit.core.config.RepositoryConfig.getQueryHandler(RepositoryConfig.java:1032) >> >> >> > at >> >> >> > >> >> >> > >> org.apache.jackrabbit.core.SearchManager.<init>(SearchManager.java:174) >> >> >> > at >> >> >> > >> >> >> >> >> >> >> org.apache.jackrabbit.core.RepositoryImpl.getSystemSearchManager(RepositoryImpl.java:630) >> >> >> > at >> >> >> > >> >> >> >> >> >> >> org.apache.jackrabbit.core.RepositoryImpl.access$100(RepositoryImpl.java:124) >> >> >> > at >> >> >> > >> >> >> >> >> >> >> org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.getSearchManager(RepositoryImpl.java:1860) >> >> >> > at >> >> >> > >> >> >> >> >> >> >> org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.doPostInitialize(RepositoryImpl.java:2095) >> >> >> > at >> >> >> > >> >> >> >> >> >> >> org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.initialize(RepositoryImpl.java:2000) >> >> >> > at >> >> >> > >> >> >> >> >> >> >> org.apache.jackrabbit.core.RepositoryImpl.initStartupWorkspaces(RepositoryImpl.java:533) >> >> >> > at >> >> >> > >> >> >> > >> org.apache.jackrabbit.core.RepositoryImpl.<init>(RepositoryImpl.java:342) >> >> >> > at >> >> >> > >> >> >> > >> org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:605) >> >> >> > at >> >> >> > >> >> >> >> >> >> >> org.apache.sling.jcr.jackrabbit.server.impl.SlingServerRepository.acquireRepository(SlingServerRepository.java:160) >> >> >> > at >> >> >> > >> >> >> >> >> >> >> org.apache.sling.jcr.base.AbstractSlingRepository.startRepository(AbstractSlingRepository.java:787) >> >> >> > at >> >> >> > >> >> >> >> >> >> >> org.apache.sling.jcr.base.AbstractSlingRepository.run(AbstractSlingRepository.java:917) >> >> >> > at java.lang.Thread.run(Unknown Source) >> >> >> > Caused by: org.apache.tika.exception.TikaException: Configured >> parser >> >> >> class >> >> >> > not found: org.apache.jackrabbit.core.query.pdf.PDFParser >> >> >> > at >> >> >> > org.apache.tika.config.TikaConfig.<init>(TikaConfig.java:151) >> >> >> > at >> >> >> > org.apache.tika.config.TikaConfig.<init>(TikaConfig.java:98) >> >> >> > at >> >> >> > org.apache.tika.config.TikaConfig.<init>(TikaConfig.java:85) >> >> >> > at >> >> >> > >> >> >> >> >> >> >> org.apache.jackrabbit.core.query.lucene.JackrabbitParser.<init>(JackrabbitParser.java:82) >> >> >> > ... 23 more >> >> >> > Caused by: java.lang.ClassNotFoundException: >> >> >> > org.apache.jackrabbit.core.query.pdf.PDFParser >> >> >> > at >> >> >> > >> >> >> >> >> >> >> org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:814) >> >> >> > at >> >> >> > >> org.apache.felix.framework.ModuleImpl.access$100(ModuleImpl.java:61) >> >> >> > at >> >> >> > >> >> >> >> >> >> >> org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1733) >> >> >> > at java.lang.ClassLoader.loadClass(Unknown Source) >> >> >> > at java.lang.Class.forName0(Native Method) >> >> >> > at java.lang.Class.forName(Unknown Source) >> >> >> > at >> >> >> > org.apache.tika.config.TikaConfig.<init>(TikaConfig.java:125) >> >> >> > ... 26 more >> >> >> > >> >> >> > >> >> >> > Regards, >> >> >> > Eric >> >> >> > On Thu, Mar 31, 2011 at 3:20 PM, Justin Edelson < >> >> >> [email protected]> >> >> >> > wrote: >> >> >> >> >> >> >> >> >> >> >> >> On Mar 31, 2011, at 5:43 PM, Craig Ganoe <[email protected]> wrote: >> >> >> >> >> >> >> >> > As I said in one of my longer emails, the only Sling code >> change I >> >> >> >> > noticed is that Sling's PluggableDefaultAccessManager makes a >> call >> >> >> >> > to >> >> >> >> > canRead(itemPath) on its superclass in Jackrabbit - >> >> >> DefaultAccessManager. >> >> >> >> > For some reason unclear to me they changed it in from just >> taking >> >> >> >> > a >> >> >> path as >> >> >> >> > a parameter in 2.1 to taking both a path and an item ID in 2.2, >> >> >> >> > but >> >> >> then the >> >> >> >> > JavaDocs say either one of the parameters can be null. >> >> >> >> >> >> >> >> This was discussed both on sling-dev and jackrabbit-dev. IIRC, it >> >> >> >> was >> >> >> >> actually done in 2.1.3. I posted a potential patch on sling-dev >> when >> >> >> this >> >> >> >> initially came up. >> >> >> >> >> >> >> >> Justin >> >> >> >> >> >> >> >> > >> >> >> >> > I made a little progress today, but unfortunately, due to the >> >> >> >> > absurdities of today's build tools, I'm stuck with a bunch of >> >> >> >> > vague >> >> >> messages >> >> >> >> > that have nothing to do with actually building the software. >> That >> >> >> today you >> >> >> >> > can't replace a few libraries and a few lines of code and still >> >> >> >> > build >> >> >> >> > software without causing miles of vague errors that have >> nothing >> >> >> >> > to do >> >> >> with >> >> >> >> > the compilability of the actual code is ridiculous. >> >> >> >> > >> >> >> >> > [INFO] Scanning for projects... >> >> >> >> > [WARNING] >> >> >> >> > [WARNING] Some problems were encountered while building the >> >> >> >> > effective >> >> >> >> > model for >> >> >> >> > >> >> >> >> >> >> >> org.apache.sling:org.apache.sling.testing.samples.integrationtests:jar:0.1.1-SNAPSHOT >> >> >> >> > [WARNING] >> >> >> 'dependencies.dependency.(groupId:artifactId:type:classifier)' >> >> >> >> > must be unique: >> org.apache.sling:org.apache.sling.junit.remote:jar >> >> >> >> > -> >> >> >> >> > duplicate declaration of version 0.1.1-SNAPSHOT @ line 272, >> column >> >> >> >> > 21 >> >> >> >> > [WARNING] >> >> >> 'dependencies.dependency.(groupId:artifactId:type:classifier)' >> >> >> >> > must be unique: >> >> >> >> > org.apache.sling:org.apache.sling.testing.tools:jar -> >> >> >> >> > duplicate declaration of version 0.1.1-SNAPSHOT @ line 277, >> column >> >> >> >> > 21 >> >> >> >> > [WARNING] >> >> >> >> > [WARNING] It is highly recommended to fix these problems >> because >> >> >> >> > they >> >> >> >> > threaten the stability of your build. >> >> >> >> > [WARNING] >> >> >> >> > [WARNING] For this reason, future Maven versions might no >> longer >> >> >> support >> >> >> >> > building such malformed projects. >> >> >> >> > [WARNING] >> >> >> >> > >> >> >> >> > On Mar 31, 2011, at 2:24 PM, Eric Norman wrote: >> >> >> >> >> Hi All, >> >> >> >> >> >> >> >> >> >> I found a use case where I could also use an upgrade to >> >> >> >> >> jackrabbit >> >> >> >> >> 2.2.5 to >> >> >> >> >> utilize some changes in user/group management. I filed JIRA >> >> >> >> >> issue SLING-2044 for tracking and will attempt the upgrade >> today. >> >> >> >> >> >> >> >> >> >> Regards, >> >> >> >> >> Eric >> >> >> >> >> >> >> >> >> >> On Fri, Mar 25, 2011 at 8:23 AM, Justin Edelson >> >> >> >> >> <[email protected]>wrote: >> >> >> >> >> >> >> >> >> >>> On Fri, Mar 25, 2011 at 9:03 AM, Ian Boston <[email protected]> >> >> >> >> >>> wrote: >> >> >> >> >>>> >> >> >> >> >>>> On 25 Mar 2011, at 12:54, Justin Edelson wrote: >> >> >> >> >>>> >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> On Mar 24, 2011, at 5:06 PM, Ian Boston <[email protected]> >> wrote: >> >> >> >> >>>>> >> >> >> >> >>>>>> >> >> >> >> >>>>>> On 24 Mar 2011, at 20:44, Craig Ganoe wrote: >> >> >> >> >>>>>> >> >> >> >> >>>>>>> >> >> >> >> >>>>>>> Is there any documentation for upgrading the jackrabbit >> >> >> >> >>>>>>> version >> >> >> in >> >> >> >> >>>>>>> the >> >> >> >> >>> Sling build? >> >> >> >> >>>>>> >> >> >> >> >>>>>> AFAIK, there is not. >> >> >> >> >>>>>> Ian >> >> >> >> >>>>> >> >> >> >> >>>>> There is, in a sense. Look at JIRA and Subversion and >> you'll >> >> >> >> >>>>> see >> >> >> the >> >> >> >> >>> exact set of changes made for prior upgrades. >> >> >> >> >>>> >> >> >> >> >>>> good point, >> >> >> >> >>>> >> >> >> >> >>>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >> >> >> https://issues.apache.org/jira/browse/SLING-1660?page=com.atlassian.jira.plugin.ext.subversion%3Asubversion-commits-tabpanel#issue-tabs >> >> >> >> >>>> >> >> >> >> >>>> http://svn.apache.org/viewvc?view=revision&revision=987559 >> >> >> >> >>>> >> >> >> >> >>>> was that the right issue ? >> >> >> >> >>> >> >> >> >> >>> SLING-1531 too... >> >> >> >> >>> >> >> >> >> >>>> >> >> >> >> >>>> Ian >> >> >> >> >>>> >> >> >> >> >>>> >> >> >> >> >>>>> >> >> >> >> >>>>> Justin >> >> >> >> >>>>>> >> >> >> >> >>>>>>> >> >> >> >> >>>>>>> Thanks. >> >> >> >> >>>>>>> >> >> >> >> >>>>>>> Craig >> >> >> >> >>>>>>> >> >> >> >> >>>>>> >> >> >> >> >>>> >> >> >> >> >>>> >> >> >> >> >>> >> >> >> >> > >> >> >> > >> >> >> > >> >> >> >> >> > >> > >> > >> > >
