BundleBeanDeploymentArchiveFactory.scanRoot fails for classes not located in bundle root

[gkvas]

In a typical Eclipse plug-in, classes are located in the "bin" folder when in the workspace. This causes scanRoot to report wrong class names, because Bundle.findEntries reports the path up to the bundle root including the bin folder.

Subsequently, the ServicePublisher fails:

java.lang.NoClassDefFoundError: bin/at/kvas/tutorial/weld/app/FooImpl (wrong name: at/kvas/tutorial/weld/app/FooImpl)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:787)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:188)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClassHoldingLock(ClasspathManager.java:632)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:607)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:568)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:492)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:465)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216)
at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:395)
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:464)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
at org.eclipse.osgi.internal.loader.BundleLoader.loadClass(BundleLoader.java:340)
at org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:229)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractBundle.java:1212)
at org.jboss.weld.environment.osgi.impl.integration.ServicePublisher.(ServicePublisher.java:80)
at org.jboss.weld.environment.osgi.impl.integration.IntegrationActivator.startManagement(IntegrationActivator.java:229)
at org.jboss.weld.environment.osgi.impl.integration.IntegrationActivator.bundleChanged(IntegrationActivator.java:150)

[mathieuancelin]

Ok,

I'm not sure I understand what happens.
In a standard JAR classes aren't supposed to be in a bin folder, why is it the case in Eclispe plug-in ?

How can I reproduce the use case ?

[gkvas]

Hi,

I wanted to see whether I can use weld-osgi from within an Eclipse RCP application. For this I did the following:

1.) Define a target-platform in Eclipse that also includes the 5 weld-osgi plugins.
2.) Adjust the start-levels of these plug-ins to one below my application bundle
3.) Create a simple plug-in with a Main class that implements IApplication
4.) Create a class FooImpl + with interface Foo in this plug-in and make the class implement this interface
5.) At @publish the to the FooImpl application.
6.) Run the application

I could get further if within scanRoot, I change

                        replace("/", ".").
                        replace(".class", "");

to

                        replace("bin/", ".").
                        replace("/", ".").
                        replace(".class", "");

on lines 181/182.

In general, I'd be interested how bootstrapping weld-OSGi in an RCP environment is done best.

[gkvas]

Sorry, that additional replace should be: replace("bin/", "").