Carrot2

Workbench does not open -- class not found from OpenSearch component

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 3.0
  • Component/s: Framework Core
  • Labels:
    None

Description

Workbench fails to load the open search component because it declares JAR dependencies on Rome. This is quite strange and may be related with dynamic class creation mechanism we have. I will investigate in the afternoon today.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Dawid Weiss added a comment -

I know what the problem is – we instantiate classes using reflection from plugins that have no direct relationship with the plugin these instantiated classes come from. This causes, as one side-effect, class not found exceptions for any class that is visible only from the target plugin. If this sounds vague that's because it is.

Anyway, I do have at least two different workarounds in my head
1) extract plugin JARs to separate plugins and re-export them,
2) add very specific buddy policy between sources/ algorithms and core/attribute plugins.

Will work on these.

Show
Dawid Weiss added a comment - I know what the problem is – we instantiate classes using reflection from plugins that have no direct relationship with the plugin these instantiated classes come from. This causes, as one side-effect, class not found exceptions for any class that is visible only from the target plugin. If this sounds vague that's because it is. Anyway, I do have at least two different workarounds in my head 1) extract plugin JARs to separate plugins and re-export them, 2) add very specific buddy policy between sources/ algorithms and core/attribute plugins. Will work on these.
Hide
Permalink
Dawid Weiss added a comment -

Definitely the cause of our problems is the fact that we're using Java reflection to instantiate component instances. The extension (factory) model we previously had, in spite of the duplication it provided in addition to suite definitions, was more flexible and aligned well with the OSGi model. Extension implementations reside inside their defining plugin and since so have access to all of that plugin's resources (classes).

Let's stick to the suite definition model for now though. Consistency between the webapp, DCS and workbench is worth it.

Show
Dawid Weiss added a comment - Definitely the cause of our problems is the fact that we're using Java reflection to instantiate component instances. The extension (factory) model we previously had, in spite of the duplication it provided in addition to suite definitions, was more flexible and aligned well with the OSGi model. Extension implementations reside inside their defining plugin and since so have access to all of that plugin's resources (classes). Let's stick to the suite definition model for now though. Consistency between the webapp, DCS and workbench is worth it.
Hide
Permalink
Dawid Weiss added a comment -

Fixed in trunk.

Show
Dawid Weiss added a comment - Fixed in trunk.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Carrot2. Try JIRA - bug tracking software for your team.