Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Platform - User Assistance (UA) » Problem with Help indexing when Compass is involved
Problem with Help indexing when Compass is involved [message #473825] Fri, 30 May 2008 14:50 Go to next message
Eric Rizzo is currently offline Eric Rizzo
Messages: 2313
Registered: July 2009
Senior Member
A while back I posted a problem we are seeing when help indexing kicks
in (at the time, I thought it had to do with opening the help sidebar,
but it turns out that was just the manifestation of an indexing problem,
because the sidebar includes the Dynamic Help). Here's the original
thread:
http://dev.eclipse.org/newslists/news.eclipse.platform.ua/ms g00198.html

As I've discovered, the problem is due to Lucene's reliance on System
properties to dictate implementation classes. See these Lucene bugs:
http://issues.apache.org/jira/browse/LUCENE-670
http://issues.apache.org/jira/browse/LUCENE-636

The problem boils down to this:
Because Lucene uses a system property (global to the JVM) to allow
customization of the SegmentReader class, any plugin that specifies a
value for that property runs the risk of breaking Eclipse help indexing.
In our case (probably the only one that is very likely), our plugin
depends on Compass; Compass overrides the SegmentReader with its own
implementation, specified by setting the system, property. However,
because Compass is not visible to the help plugin's classloader, Lucene
blows up with a ClassNotFoundException when it tries to initialize itself.
If Eclipse help invokes Lucene first, this problem is avoided (because
Lucene's dependence on that system property is in a static initializer,
only run once per classloader); but if our plugin triggers Compass to
load first, Lucene blows up.

So, I'm looking for a work-around. I'm trying, in my plugin Activator's
start() method, to somehow force Lucene to initialize. But no luck so far.
Any ideas on how to work around this problem?

Also, it seems that this would be a somewhat common problem - I mean,
any plugin that uses Compass (version < 2.0) is going to run into this.
I'm surprised it has not been reported before.

Eric
Re: Problem with Help indexing when Compass is involved [message #473834 is a reply to message #473825] Tue, 03 June 2008 21:39 Go to previous message
Eric Rizzo is currently offline Eric Rizzo
Messages: 2313
Registered: July 2009
Senior Member
Eric Rizzo wrote:
> A while back I posted a problem we are seeing when help indexing kicks
> in (at the time, I thought it had to do with opening the help sidebar,
> but it turns out that was just the manifestation of an indexing problem,
> because the sidebar includes the Dynamic Help). Here's the original
> thread:
> http://dev.eclipse.org/newslists/news.eclipse.platform.ua/ms g00198.html
>
> As I've discovered, the problem is due to Lucene's reliance on System
> properties to dictate implementation classes. See these Lucene bugs:
> http://issues.apache.org/jira/browse/LUCENE-670
> http://issues.apache.org/jira/browse/LUCENE-636
>
> The problem boils down to this:
> Because Lucene uses a system property (global to the JVM) to allow
> customization of the SegmentReader class, any plugin that specifies a
> value for that property runs the risk of breaking Eclipse help indexing.
> In our case (probably the only one that is very likely), our plugin
> depends on Compass; Compass overrides the SegmentReader with its own
> implementation, specified by setting the system, property. However,
> because Compass is not visible to the help plugin's classloader, Lucene
> blows up with a ClassNotFoundException when it tries to initialize itself.
> If Eclipse help invokes Lucene first, this problem is avoided (because
> Lucene's dependence on that system property is in a static initializer,
> only run once per classloader); but if our plugin triggers Compass to
> load first, Lucene blows up.
>
> So, I'm looking for a work-around. I'm trying, in my plugin Activator's
> start() method, to somehow force Lucene to initialize. But no luck so far.
> Any ideas on how to work around this problem?
>
> Also, it seems that this would be a somewhat common problem - I mean,
> any plugin that uses Compass (version < 2.0) is going to run into this.
> I'm surprised it has not been reported before.

Upgrading to Compass 2.0 solved the problem; the new version no longer
sets the system property and thus does not interfere with the help
plugin's instance of Lucene.

I'm still surprised no one else has run into this before - my impression
was that Compass was a fairly popular library and the 2.0 version is
brand new.

Eric
Re: Problem with Help indexing when Compass is involved [message #614400 is a reply to message #473825] Tue, 03 June 2008 21:39 Go to previous message
Eric Rizzo is currently offline Eric Rizzo
Messages: 2313
Registered: July 2009
Senior Member
Eric Rizzo wrote:
> A while back I posted a problem we are seeing when help indexing kicks
> in (at the time, I thought it had to do with opening the help sidebar,
> but it turns out that was just the manifestation of an indexing problem,
> because the sidebar includes the Dynamic Help). Here's the original
> thread:
> http://dev.eclipse.org/newslists/news.eclipse.platform.ua/ms g00198.html
>
> As I've discovered, the problem is due to Lucene's reliance on System
> properties to dictate implementation classes. See these Lucene bugs:
> http://issues.apache.org/jira/browse/LUCENE-670
> http://issues.apache.org/jira/browse/LUCENE-636
>
> The problem boils down to this:
> Because Lucene uses a system property (global to the JVM) to allow
> customization of the SegmentReader class, any plugin that specifies a
> value for that property runs the risk of breaking Eclipse help indexing.
> In our case (probably the only one that is very likely), our plugin
> depends on Compass; Compass overrides the SegmentReader with its own
> implementation, specified by setting the system, property. However,
> because Compass is not visible to the help plugin's classloader, Lucene
> blows up with a ClassNotFoundException when it tries to initialize itself.
> If Eclipse help invokes Lucene first, this problem is avoided (because
> Lucene's dependence on that system property is in a static initializer,
> only run once per classloader); but if our plugin triggers Compass to
> load first, Lucene blows up.
>
> So, I'm looking for a work-around. I'm trying, in my plugin Activator's
> start() method, to somehow force Lucene to initialize. But no luck so far.
> Any ideas on how to work around this problem?
>
> Also, it seems that this would be a somewhat common problem - I mean,
> any plugin that uses Compass (version < 2.0) is going to run into this.
> I'm surprised it has not been reported before.

Upgrading to Compass 2.0 solved the problem; the new version no longer
sets the system property and thus does not interfere with the help
plugin's instance of Lucene.

I'm still surprised no one else has run into this before - my impression
was that Compass was a fairly popular library and the 2.0 version is
brand new.

Eric
Previous Topic:Mac client support for eclipse 3.3
Next Topic:simple cheatsheet editor doesn't support command results property?
Goto Forum:
  


Current Time: Sat Oct 25 16:22:16 GMT 2014

Powered by FUDForum. Page generated in 0.01964 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software