Here's a different patch: http://codereview.appspot.com/4346041

I put in a stripped down tika-config.xml file to avoid the Tika
problem mentioned below.

However, it does seem to stall on the
org.apache.sling.launchpad.webapp.integrationtest.servlets.post.PostServletOutputContentTypeTest
test. Not sure why.

Justin

On Thu, Mar 31, 2011 at 9: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