mathieuancelin / weld-osgi

This project aims to provide an OSGi integration for Weld. This project is no longer updated, see https://github.com/weld/core for updates
https://github.com/weld/core
12 stars 10 forks source link

BundleBeanDeploymentArchiveFactory.scanRoot fails for classes not located in bundle root #84

Open gkvas opened 11 years ago

gkvas commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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