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
>> >> >> >>>>>>>
>> >> >> >>>>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>
>> >> >> >
>> >> >
>> >> >
>> >>
>> >
>
>

Reply via email to