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  |
 Eric Rizzo
Messages: 3070
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  |
Eric Rizzo
Messages: 3070
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 |
Eric Rizzo
Messages: 3070
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
|
|
|
Goto Forum:
Current Time: Fri Apr 26 05:12:22 GMT 2024
Powered by FUDForum. Page generated in 0.03307 seconds |
] 
Search
Help
Register
Login
Home
