2 Replies Latest reply on Oct 24, 2018 8:15 AM by Carlos Oliva

    JDK11 Wildfly 14 and EJB Schedule,Singleton

    Carlos Oliva Novice

      Should the example in "Scheduling in JavaEE", work in Wildfly 14 and JDK11?  I took the example described in the url, https://www.baeldung.com/scheduling-in-java-enterprise-edition and tested it in Wildfly 10.1, running in JDK8.x, and Wildfly 14, running in JDK11. I complied the classes of the example with JDK8.x and with JDK11, respectively.  I packaged the classes in two jar files, crontime08.jar and crontimer11.jar, respectively. Afterwards, I deployed the crontime08.jar and crontime11.jar in Wildfy 10.1 and Wildfly 14, respectively. The example works fine in Wildfly 10.1 with JDK 8.x; it fails in Wildfly 14 with JDK 11. It looks like the classes deploy in both cases. Nevertheless, in Wildlfy 1 withJDK11, Wildfly spews Weld errors like the following:
      2018-10-22 16:31:02,040 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."crontimer11.jar".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."crontimer11.jar".WeldStartService: Failed to start service

      I am attaching the relevant log that Wildfly 14 produced.

        • 1. Re: JDK11 Wildfly 14 and EJB Schedule,Singleton
          Philippe Marschall Expert

          The interesting part in the stack trace is

           

          Caused by: org.jboss.weld.exceptions.WeldException: WELD-001524: Unable to load proxy class for bean Session bean [class WorkerBean with qualifiers [@Any @Default]; local interfaces are [WorkerBean] with class class WorkerBean using classloader ModuleClassLoader for Module "deployment.crontimer11.jar" from Service Module Loader

            at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:370)

            at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.module.ejb.SessionBeanProxyInstantiator.<init>(SessionBeanProxyInstantiator.java:48)

            at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.module.ejb.SessionBeanImpl.initializeAfterBeanDiscovery(SessionBeanImpl.java:283)

            at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:111)

            at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:102)

            at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62)

            at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55)

            at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)

            at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)

            at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)

            at java.base/java.lang.Thread.run(Thread.java:834)

            at org.jboss.threads@2.3.2.Final//org.jboss.threads.JBossThread.run(JBossThread.java:485)

          Caused by: java.lang.RuntimeException: java.lang.ClassFormatError: Illegal class name "/WorkerBean$Proxy$_$$_Weld$EnterpriseProxy$" in class file /WorkerBean$Proxy$_$$_Weld$EnterpriseProxy$

            at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:113)

            at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:469)

            at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:362)

            ... 11 more

          Caused by: java.lang.ClassFormatError: Illegal class name "/WorkerBean$Proxy$_$$_Weld$EnterpriseProxy$" in class file /WorkerBean$Proxy$_$$_Weld$EnterpriseProxy$

            at java.base/java.lang.ClassLoader.defineClass1(Native Method)

            at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016)

            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

            at java.base/java.lang.reflect.Method.invoke(Method.java:566)

            at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:120)

            at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:109)

            ... 13 more

          • 2. Re: JDK11 Wildfly 14 and EJB Schedule,Singleton
            Carlos Oliva Novice

            I found a Jira case about WELD messages in this link: [WELD-2244] Unable to create proxy for large class - JBoss Issue Tracker.  It looks like some versions of WELD used to fail "When a proxy is created while decorating a bean with many methods".

            The code of the WorkerBean has two annotations (Is that too much "decoration"?) as follows:

            import javax.ejb.Singleton;
            import javax.ejb.Lock;
            import javax.ejb.LockType;
            import java.util.concurrent.atomic.AtomicBoolean;

            @Singleton
            public class WorkerBean {

                private AtomicBoolean busy = new AtomicBoolean(false);

                @Lock(LockType.READ)
                public void doTimerWork() throws InterruptedException {
                    if (!busy.compareAndSet(false, true)) {
            System.out.println("WorkerBean not busy compareAndSet ....");
                        return;
                    }
                    try {
            System.out.println("WorkerBean execute ....");
                        //Thread.sleep(20000L);
                    } finally {
                        busy.set(false);
                    }
                }
            }