7 Replies Latest reply on May 1, 2009 9:52 PM by dan.j.allen

    UnsatisfiedDependencyException when using @Logger

      I get an UnsatisfiedDependencyException when using @Logger. 



      @Logger private Log log;




      I have webbeans-logger-1.0.0.CR1.jar and webbeans-logging-1.0.0.PREVIEW1.jar on the classpath.


      When I start up my app and set the log level to debug, nothing is logged that mentions the producer method in org.jboss.webbeans.log.LoggerProducer.


      Is there anything else I need to do other than make sure the additional logging jars are on the classpath to get this to work.

        • 1. Re: UnsatisfiedDependencyException when using @Logger
          dan.j.allen

          I believe the problem is that the logger package is not bundling a beans.xml, which is what activates the beans in that artifact. You can either crack it open and put one in there yourself (/META-INF/beans.xml). You may be able to declare it in XML too, but clearly the beans.xml is the easiest approach.

          • 2. Re: UnsatisfiedDependencyException when using @Logger

            It looks like it just looks for beans.xml not META-INF/beans.xml


            Is webbeans supposed to run in Java 5?  The LoggerProducer class has Java 6 specific code in it.  String didn't get an isEmpty() method until Java 6.

            • 3. Re: UnsatisfiedDependencyException when using @Logger
              dan.j.allen

              It looks like it just looks for beans.xml not META-INF/beans.xml

              I'm pretty sure it's META-INF/beans.xml. Chapter 11 of the spec begins:


              Bean classes must be deployed in an EAR, WAR, EJB-JAR or JAR archive or directory in the application classpath that
              has a file named beans.xml in the metadata directory (META-INF, or WEB-INF in the case of a WAR). If a bean is deployed
              to a location that is not in the application classpath, or does not contain a file named beans.xml in the metadata directory,
              it will not be discovered by the container.



              Is webbeans supposed to run in Java 5?  The LoggerProducer class has Java 6 specific code in it.  String didn't get an isEmpty() method until Java 6.


              Oops! That's a mistake. I'm pretty sure the target platform for the Web Beans RI is JDK 5 and above.

              • 4. Re: UnsatisfiedDependencyException when using @Logger

                Dan Allen wrote on May 01, 2009 04:02:



                It looks like it just looks for beans.xml not META-INF/beans.xml

                I'm pretty sure it's META-INF/beans.xml. Chapter 11 of the spec begins:

                Bean classes must be deployed in an EAR, WAR, EJB-JAR or JAR archive or directory in the application classpath that
                has a file named beans.xml in the metadata directory (META-INF, or WEB-INF in the case of a WAR). If a bean is deployed
                to a location that is not in the application classpath, or does not contain a file named beans.xml in the metadata directory,
                it will not be discovered by the container.



                Is webbeans supposed to run in Java 5?  The LoggerProducer class has Java 6 specific code in it.  String didn't get an isEmpty() method until Java 6.



                ServletWebBeanDiscovery.scan() hard codes beans.xml so /META-INF/beans.xml is not picked.  This should probably be fixed to match the spec.

                • 5. Re: UnsatisfiedDependencyException when using @Logger
                  dan.j.allen

                  Wow, you are just on a roll today with bug reports ;) I filed an issue and corrected it: WBX-38

                  • 6. Re: UnsatisfiedDependencyException when using @Logger

                    Here's another one.  The same problem exists in the SE module too.  The is a beans.xml file but it is in the root of the jar.  The code in SEWebBeanDiscovery looks for beans.xml not META-INF/beans.xml.

                    • 7. Re: UnsatisfiedDependencyException when using @Logger
                      dan.j.allen

                      Fixed that one too. Clearly a bad pattern got repeated.