Eclipse Community Forums: Plugin Development Environment (PDE) » Why can't a plug-in see a fragment's additions?

Help

Home

Home » Eclipse Projects » Plugin Development Environment (PDE) » Why can't a plug-in see a fragment's additions?

Show: Today's Messages :: Show Polls :: Message Navigator

Why can't a plug-in see a fragment's additions? [message #20361]

Tue, 09 September 2008 18:47

Eclipse User

Originally posted by: wbeckwith.gmail.com

Background Info.

I'm in the process of porting a swing app to the eclipse platform and I
have hit a situation where deadlock happens between a set of plug-ins.
Basically there is a plug-in foo that depends on a plugin bar. However
plugin bar has buddy classloading enables because it needs to
dynamically load classes from plugin foo at runtime (i.e. log4j needing
to load a custom appender). The deadlock happens when 1 thread loads a
class A from the foo plug-in (thus locking the foo's bundle classloader)
and in the process also needs to load class B from the bar plug-in (thus
trying to lock it's classloader). However, in another thread, class R
is being loaded from the bar plug-in (thus locking the bar's bundle
classloader) and in the process also needs to load class R from the foo
plug-in (thus trying to lock it's classloader). Classic deadlock.

Ideally there should be no cycles in the classpath, but buddy
classloading is required to make the classes available for the log4j
case. So I see only 2 ways that this can be resolved, 1.) one is to
collapse the entire project down into a single plug-in, so that there is
only 1 bundle classloader, or 2.) I thought I could turn the bar plug-in
into a fragment and then there would again be only 1 classloader.

However, after doing this the foo plug-in does not see the classes
contributed by the bar fragment leading to compile errors in the IDE and
pde build. Only if I create a new zoo plug-in as a dependency for the
foo plug-in and change the bar's fragment's host plug-in to be the zoo
plug-in can the foo plug-in see the classes exported by the bar
fragment. But this introduces another classloader, which is the very
thing I'm trying to remove.

So in essence why doesn't a plug-in see the merged classes/resources
from it's contributing fragments?

Wb

Report message to a moderator

Re: Why can't a plug-in see a fragment's additions? [message #20418 is a reply to message #20361]

Tue, 09 September 2008 19:54

Andrew Niefer

Messages: 990
Registered: July 2009

Senior Member

The host should be able to see things in the fragment. Though there are
some things to note:
1) Classes in the fragment will need to be on the Bundle-Classpath. The
default value is '.', so if the fragment is a normal jar then you should
be fine. But if the class files are in a nested jar or a subfolder,
make sure it appears on the classpath.

2) There is the manifest header "Eclipse-ExtensibleAPI: true" which goes
in the host. I'm not completely clear on the affects of this, but it
allows fragments to contribute packages to the host. I think maybe that
without this, the fragment can only contribute classes to packages that
already exist in the host.

-Andrew

Wendell Beckwith wrote:
> Background Info.
>
> I'm in the process of porting a swing app to the eclipse platform and I
> have hit a situation where deadlock happens between a set of plug-ins.
> Basically there is a plug-in foo that depends on a plugin bar. However
> plugin bar has buddy classloading enables because it needs to
> dynamically load classes from plugin foo at runtime (i.e. log4j needing
> to load a custom appender). The deadlock happens when 1 thread loads a
> class A from the foo plug-in (thus locking the foo's bundle classloader)
> and in the process also needs to load class B from the bar plug-in (thus
> trying to lock it's classloader). However, in another thread, class R
> is being loaded from the bar plug-in (thus locking the bar's bundle
> classloader) and in the process also needs to load class R from the foo
> plug-in (thus trying to lock it's classloader). Classic deadlock.
>
> Ideally there should be no cycles in the classpath, but buddy
> classloading is required to make the classes available for the log4j
> case. So I see only 2 ways that this can be resolved, 1.) one is to
> collapse the entire project down into a single plug-in, so that there is
> only 1 bundle classloader, or 2.) I thought I could turn the bar plug-in
> into a fragment and then there would again be only 1 classloader.
>
> However, after doing this the foo plug-in does not see the classes
> contributed by the bar fragment leading to compile errors in the IDE and
> pde build. Only if I create a new zoo plug-in as a dependency for the
> foo plug-in and change the bar's fragment's host plug-in to be the zoo
> plug-in can the foo plug-in see the classes exported by the bar
> fragment. But this introduces another classloader, which is the very
> thing I'm trying to remove.
>
> So in essence why doesn't a plug-in see the merged classes/resources
> from it's contributing fragments?
>
> Wb

Report message to a moderator

Re: Why can't a plug-in see a fragment's additions? [message #21000 is a reply to message #20418]

Wed, 10 September 2008 18:11

Eclipse User

Originally posted by: felix.mayer.erdas.com

I have the same problem in Eclipse 3.4.0, even with 2 simple test projects
(Bundle-ClassPath and Eclipse-ExtensibleAPI are addressed). I have 2
projects called 'host' and 'fragment' that were created with the Plugin-In
and Fragment wizards, repectively. Everything looks fine to me, but the PDE
cannot resolve the 'import fragment.Fragment' in class Host. What could be
wrong?

Project 'host' has one class host.Host and a manifest:

package host;
import fragment.Fragment;
public class Host {
}

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Host
Bundle-SymbolicName: host
Bundle-Version: 1.0.0
Require-Bundle: org.eclipse.ui,
org.eclipse.core.runtime
Bundle-ActivationPolicy: lazy
Bundle-ClassPath: .,bin
Bundle-RequiredExecutionEnvironment: J2SE-1.5
Eclipse-ExtensibleAPI: true

Project 'fragment' is just as simple:

package fragment;
public class Fragment {
}

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Fragment
Bundle-SymbolicName: fragment
Bundle-Version: 1.0.0
Fragment-Host: host;bundle-version="1.0.0"
Bundle-ClassPath: .,bin
Bundle-RequiredExecutionEnvironment: J2SE-1.5
Export-Package: fragment

Report message to a moderator