weld-project / weld

High-performance runtime for data analytics applications

Home Page:https://www.weld.rs

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

BeanArchives can't be resolved in URL form

santospm opened this issue · comments

I'm running Weld in a jarinjar setup, and I've been getting

java.lang.IllegalStateException: Singleton not set for STATIC_INSTANCE => []
	at org.jboss.weld.bootstrap.api.helpers.RegistrySingletonProvider$RegistrySingleton.get(RegistrySingletonProvider.java:28)
	at org.jboss.weld.Container.instance(Container.java:57)
	at org.jboss.weld.SimpleCDI.<init>(SimpleCDI.java:77)
	at org.jboss.weld.environment.servlet.WeldProvider$EnvironmentCDI.<init>(WeldProvider.java:45)
	at org.jboss.weld.environment.servlet.WeldProvider.getCDI(WeldProvider.java:61)
	at javax.enterprise.inject.spi.CDI.lambda$getCDIProvider$0(CDI.java:87)
	at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:174)

Going through the logs I found this:

07:11:11.250 [main] WARN org.jboss.weld.Bootstrap - WELD-ENV-000028: Weld initialization skipped - no bean archive found

After some analysis, I found that no bean archives were found because the BeanArchiveHandlers assume the archive 'ref' is either gonna be war:, file:, or jar:. In my case, since I'm running in a jarinjar runtime, it returns rsrc:; I can see the logs hwere Weld is having trouble with it:

07:11:11.245 [main] DEBUG org.jboss.weld.Bootstrap - WELD-ENV-000032: Processing bean archive reference: rsrc:META-INF/beans.xml
07:11:11.246 [main] WARN org.jboss.weld.Bootstrap - WELD-ENV-000031: The bean archive reference rsrc:META-INF/beans.xml cannot be handled by any BeanArchiveHandler: [org.jboss.weld.environment.deployment.discovery.FileSystemBeanArchiveHandler@13c8ac77, org.jboss.weld.environment.servlet.deployment.ServletContextBeanArchiveHandler@4bdf]

Finally, in the code, I pinpointed the issue on FileSystemBeanArchiveHandler, but this holds true for all implementations of BeanArchiveHandler:

public BeanArchiveBuilder handle(String path) {
        boolean nested = false;
        File file;

        if (path.contains(JAR_URL_SEPARATOR)) {
            // Most probably a nested archive, e.g. "/home/duke/duke.jar!/lib/foo.jar"
            file = new File(path.substring(0, path.indexOf(JAR_URL_SEPARATOR)));
            nested = true;
        } else {
            file = new File(path);   <--- steps in here
        }
        if(!file.canRead()) {
            return null;     <--- returns here
        }

Instead of checking for a specific scheme, like jar, war, or file, it should be expanded to other URL schemes, as it is possible to do so, as long as there is an URLStreamHandler; which there is.