6 Replies Latest reply on Mar 21, 2006 12:07 PM by tromanowski

    JNDI Lookup Failure, ClassCastException, 4.0.4RC1

    tromanowski

      Problem: I'm getting a java.lang.ClassCastException in my server log when I try when I try to perform a JNDI lookup.

      The error is much like the one here found by khooke here: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=79130

      Actually, I am encountering what may be a few problems, but am going to try and go from the top. I've searched forums for days and I have the feeling that my problem is a common one, but so far all the standard solutions aren't working. I've read the ejb 3.0 simplified and persistence specs (pfd), wiki's and forums, but I am new to EJB 3.0 and fear I am overlooking the obvious.

      I'm running jboss 4.0.4RC1 and installed the ejb 3.0 libs via the installer.

      I'm running Myfaces 1.1.1 with Beehive pageflows, and oracle 10g as my database. I've tested my war file separately to verify that is not causing me problems. My problem is only encountered when I try to access an entity bean (well, when I try to perform a JNDI lookup).

      Regarding the other posting above, my persistence.xml file looks like:

      <?xml version="1.0" encoding="UTF-8"?>
      <persistence>
       <persistence-unit name="requirements">
       <jta-data-source>java:/OracleDS</jta-data-source>
       <properties>
       <property name="hibernate.hbm2ddl.auto" value="update"/>
       <property name="hibernate.dialect" value="org.hibernate.dialect.OracleDialect"/>
       </properties>
       </persistence-unit>
      </persistence>


      My EJBs are reside in their own jar file, and are built into an ear. My persistence.xml file is placed within the META-INF directory of the EJB jarfile.

       InitialContext ic = new InitialContext();
      
       rm = (RequirementsManagerBean)ic.lookup( "alpha/RequirementsManagerBean/local" );




      From the RC3 to RC4 upgrade guide (this still applies, no?), "If you deploy EJBs within an EAR, then the default JNDI name is the same, except the base name is prepended to the default JNDI name. For example, if it is foo.ear then the default names would be foo/EJBNAME/remote and foo/EJBNAME/local". My ear name is "alpha".

      My datasource appears to be configured correctly because i see it connected via the jmx-console, and a "MyTableEntity" test entity EJB I created causes a "mytable" table to be created in my oracle database.

      In my Global JNDI namespace, the following is listed:
      java: Namespace
      
       +- XAConnectionFactory (class: org.jboss.mq.SpyXAConnectionFactory)
       +- DefaultDS (class: org.jboss.resource.adapter.jdbc.WrapperDataSource)
       +- SecurityProxyFactory (class: org.jboss.security.SubjectSecurityProxyFactory)
       +- OracleDS (class: org.jboss.resource.adapter.jdbc.WrapperDataSource)
       +- DefaultJMSProvider (class: org.jboss.jms.jndi.JNDIProviderAdapter)
       +- comp (class: javax.naming.Context)
       +- JmsXA (class: org.jboss.resource.adapter.jms.JmsConnectionFactoryImpl)
       +- ConnectionFactory (class: org.jboss.mq.SpyConnectionFactory)
       +- jaas (class: javax.naming.Context)
       | +- JmsXARealm (class: org.jboss.security.plugins.SecurityDomainContext)
       | +- jbossmq (class: org.jboss.security.plugins.SecurityDomainContext)
       | +- HsqlDbRealm (class: org.jboss.security.plugins.SecurityDomainContext)
       +- timedCacheFactory (class: javax.naming.Context)
      Failed to lookup: timedCacheFactory, errmsg=org.jboss.util.TimedCachePolicy
       +- TransactionPropagationContextExporter (class: org.jboss.tm.TransactionPropagationContextFactory)
       +- StdJMSPool (class: org.jboss.jms.asf.StdServerSessionPoolFactory)
       +- comp.ejb3 (class: javax.naming.Context)
       | NonContext: null
       +- TransactionPropagationContextImporter (class: org.jboss.tm.TransactionPropagationContextImporter)
       +- TransactionManager (class: org.jboss.tm.TxManager)
      
      
      Global JNDI Namespace
      
       +- XAConnectionFactory (class: org.jboss.mq.SpyXAConnectionFactory)
       +- TopicConnectionFactory (class: org.jboss.naming.LinkRefPair)
       +- UIL2ConnectionFactory[link -> ConnectionFactory] (class: javax.naming.LinkRef)
       +- UserTransactionSessionFactory (proxy: $Proxy27 implements interface org.jboss.tm.usertx.interfaces.UserTransactionSessionFactory)
       +- alpha (class: org.jnp.interfaces.NamingContext)
       | +- RequirementsManagerBean (class: org.jnp.interfaces.NamingContext)
       | | +- local (proxy: $Proxy71 implements No ClassLoaders found for: com.test.gems.requirements.RequirementsManagerInterface (no security manager: RMI class loader disabled))
       | +- MyTableManager (class: org.jnp.interfaces.NamingContext)
       | | +- local (proxy: $Proxy69 implements No ClassLoaders found for: com.test.gems.requirements.MyTableInterface (no security manager: RMI class loader disabled))


      So it looks like JNDI binding is my problem, but here is what I _really_ don't get: I only have a problem when my Local Stateless bean calls
      return this.em.find(RequirementsEntity.class, 1);

      (I have a test record in the table with a primary key of 1.)

      If I don't attempt to call this method, and call another one which returns a string from the same Local Stateless bean, my jsp page renders correctly and displays the value returned by the bean's method. I _do_, however, still get the ClassCastException on my JNDI lookup (makes sense, considering the Global JNDI listing shows the bean as not bound).

      Entity bean:

      @Entity
      @Table(name="requirements")
      public class RequirementsEntity implements java.io.Serializable
      {
       public RequirementsEntity(){}
      
       public RequirementsEntity( String name, String description )
       {
       this.name = name;
       this.description = description;
       }
      
       @Id
       // at GeneratedValue(strategy=GenerationType.AUTO)
       public int getEr_Id() {
       return er_Id;
       }
      
       public void setEr_Id(int er_Id){
       this.er_Id = er_Id;
      
       ...
      
       et. al.
      
       ...
       }



      Snippet of the Stateless bean:
      @Stateless
      @Local(RequirementsManagerInterface.class)
      public class RequirementsManagerBean implements RequirementsManagerInterface {
      
       private String name = "A test jsp can access this attribute just fine via a method after the bean is looked up";
       /**
       * Create an EntityManager to use with our Entity Beans
       */
       @PersistenceContext(unitName = "requirements")
       protected EntityManager em;



      Just for kicks, I also attempted a context lookup using "alpha/requirements/RequirementsManagerBean/local" and that produced the same errors.
      Related Questions:
      Is my injection incorrect?

      Do I need to explicitly list the beans I am accessing via the property in persistence.xml? From the RC5 tutorials and the spec, it looks like that is not necessary, but I am not clear on when such usage is necessary (to avoid name collisions?).

      Does jboss 4.0.4RC1 include the EJB3.0 RC5-PDF libs? The date on the 4.0.4RC1 jars is newer than the EJB3.0 RC5-PDF libs, and I see other postings suggesting that 4.0.4RC1 includes these, but it is not clear.

      When I have a pre-exising table in my database and then deploy my ear, hibernate attempts to alter the pre-existing table, failing each time (even though I've set my "hibernate.hbm2ddl.auto" property to "update." This may be normal hibernate behavior, and is more of a hibernate question, but i'll throw it out there if anyone would like to answer.

      Is there something inherently wrong with my find call?


      Sorry for the long post, just wanted to provide as much info on the prolbem as possible. I'm also putting together notes for a tutorial on things I found to be unclear from the current docs, so I welcome any tertiary info.

        • 1. Re: JNDI Lookup Failure, ClassCastException, 4.0.4RC1
          tromanowski

          Trying to get to the root of the JNDI lookup problem, I'm finding that the gray area is in EAR deployment. While trying to determine if there is a conflict with the standard documented managed bean configuration (as configured faces-config.xml) for myfaces, I did not come across any cut-and-dry info on building and deploying an EJB 3.0 ear in jboss, where you have a war file and any number of entity jar files. Ok, actually there are a few forum postings on this, but for previous releases of JBoss in which the implementation may have been different do to the changing EJB 3.0 spec. The "ear" example of the RC5 tutorials has a build.xml file that builds a tutorial.jar, which is obviously very different from an ear.

          The latest JBoss documentation (including forum postings & wiki) suggest that an ear containing a war file and ejb 3.0 entities in a separate jar file should work, as long as the ejb3.0 jar file has a proper persistence.xml file in its MAN-INF directory. Is this still the case? That's what I've been using, but my beans are still not being registered.

          Is anyone that is using the current Jboss EJB 3.0 release building and deploying an ear? Would you please post the structure of your ear?

          I've found a potential solution here:
          http://weblogs.java.net/blog/ss141213/archive/2005/12/using_java_pers.html

          There, glassfish is used, but it looks like the ear structure (with a lib directory, no application.xml file, separate war and ejb jar files) is generic and should be portable to any compliant platform. Is there a reason this configuration won't work with JBoss 4.0.4RC1 or later?

          I'll be trying the configuration recommended in the blog above after some rest, but would appreciate any useful input anyone may have.

          • 2. Re: JNDI Lookup Failure, ClassCastException, 4.0.4RC1
            elkner

             

            "tromanowski" wrote:

            Is anyone that is using the current Jboss EJB 3.0 release building and deploying an ear? Would you please post the structure of your ear?


            foobar.ear
            foobar.ear!lib
            foobar.ear!lib/bar-if.jar
            foobar.ear!lib/bar-if.jar!META-INF
            foobar.ear!lib/bar-if.jar!META-INF/MANIFEST.MF
            foobar.ear!lib/bar-if.jar!META-INF/INDEX.LIST
            foobar.ear!lib/bar-if.jar!foo
            foobar.ear!lib/bar-if.jar!foo/bar
            foobar.ear!lib/bar-if.jar!foo/bar/dao
            foobar.ear!lib/bar-if.jar!foo/bar/dao/CatTestDao.class
            foobar.ear!lib/bar-pu.jar
            foobar.ear!lib/bar-pu.jar!META-INF
            foobar.ear!lib/bar-pu.jar!META-INF/MANIFEST.MF
            foobar.ear!lib/bar-pu.jar!META-INF/persistence.xml
            foobar.ear!lib/bar-pu.jar!META-INF/INDEX.LIST
            foobar.ear!lib/bar-pu.jar!foo
            foobar.ear!lib/bar-pu.jar!foo/bar
            foobar.ear!lib/bar-pu.jar!foo/bar/entities
            foobar.ear!lib/bar-pu.jar!foo/bar/entities/CatTest.class
            foobar.ear!META-INF
            foobar.ear!META-INF/application.xml
            foobar.ear!bar-ejb.jar
            foobar.ear!bar-ejb.jar!META-INF
            foobar.ear!bar-ejb.jar!META-INF/MANIFEST.MF
            foobar.ear!bar-ejb.jar!META-INF/jboss.xml
            foobar.ear!bar-ejb.jar!META-INF/INDEX.LIST
            foobar.ear!bar-ejb.jar!foo
            foobar.ear!bar-ejb.jar!foo/bar
            foobar.ear!bar-ejb.jar!foo/bar/common
            foobar.ear!bar-ejb.jar!foo/bar/common/Util.class
            foobar.ear!bar-ejb.jar!foo/bar/server
            foobar.ear!bar-ejb.jar!foo/bar/server/CatTestBean.class
            foobar.ear!bar-ejb.jar!foo/bar/server/TraceInterceptor.class
            foobar.ear!bar-ejb.jar!log4j.properties


            with foobar.ear!META-INF/application.xml
            <?xml version="1.0" encoding="UTF-8"?>
            <!DOCTYPE application PUBLIC
             "-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN"
             "http://java.sun.com/dtd/application_1_3.dtd">
            
            <application>
             <display-name>@product.name@</display-name>
             <module>
             <ejb>lib/@ant.project.name@-pu-@product.version@.jar</ejb>
             </module>
             <module>
             <ejb>lib/@ant.project.name@-if-@product.version@.jar</ejb>
             </module>
             <module>
             <ejb>@ant.project.name@-ejb-@product.version@.jar</ejb>
             </module>
             <!--
             <module>
             <ejb>commons-server-@product.version@.jar</ejb>
             </module>
             -->
            </application>


            • 3. Re: JNDI Lookup Failure, ClassCastException, 4.0.4RC1
              asack

               

              "tromanowski" wrote:

              The latest JBoss documentation (including forum postings & wiki) suggest that an ear containing a war file and ejb 3.0 entities in a separate jar file should work, as long as the ejb3.0 jar file has a proper persistence.xml file in its MAN-INF directory. Is this still the case? That's what I've been using, but my beans are still not being registered.

              Is anyone that is using the current Jboss EJB 3.0 release building and deploying an ear? Would you please post the structure of your ear?

              I've found a potential solution here:
              http://weblogs.java.net/blog/ss141213/archive/2005/12/using_java_pers.html

              There, glassfish is used, but it looks like the ear structure (with a lib directory, no application.xml file, separate war and ejb jar files) is generic and should be portable to any compliant platform. Is there a reason this configuration won't work with JBoss 4.0.4RC1 or later?

              I'll be trying the configuration recommended in the blog above after some rest, but would appreciate any useful input anyone may have.


              EAR deployments IMO are tricky, i.e. its not like a WAR where the servlet spec spells out where to but libraries and how the app server is suppose to use them (lib gets the first crack before any parent classloaders).

              Since I believe JBoss currently doesn't support J2EE 5 spec regarding EARs, there is no EAR/lib file to stick jars.

              As already suggested, you can stick your entities into one jar file and list it as a module in your application.xml. That's probably the best way to share them across the various modules within your EAR file.

              Finally, you (everyone) should get warm and fuzzy with these Wiki pages:

              http://wiki.jboss.org/wiki/Wiki.jsp?page=ClassLoadingOverview

              Especially regarding EAR isoloation and classloading namespaces.

              • 4. Re: JNDI Lookup Failure, ClassCastException, 4.0.4RC1
                tromanowski

                Thanks for posting guys (gals?), the additional insight helps a great deal.

                asack, I can assure you I've practically memorized that portion of the wiki! Admittedly, reading and understanding are two different things. What you stated, about packaging the war and a jar of all ejbs together inside an ear, is what I've been using per the wiki. Unfortunately, it's still not working. From my original post, I've placed my persistence.xml file in the META-INF directory of my ejbs.jar file in that setup. Here's my application.xml file:

                <?xml version="1.0" encoding="UTF-8"?>
                <!DOCTYPE application PUBLIC
                 "-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN"
                 "http://java.sun.com/dtd/application_1_3.dtd">
                <application>
                 <display-name>Alpha (Voltaire) Enterprise Application</display-name>
                 <module>
                 <web>
                 <web-uri>Voltaire.war</web-uri>
                 <context-root>/Voltaire</context-root>
                 </web>
                 </module>
                 <module>
                 <ejb>ejbs.jar</ejb>
                 </module>
                </application>
                


                And here is the faces-config.xml file (is there a reason the use of managed beans would be a problem, as long as I do the proper context lookup from a jsf file?):
                <?xml version="1.0" encoding="UTF-8"?>
                
                <!DOCTYPE faces-config PUBLIC
                 "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.1//EN"
                 "http://java.sun.com/dtd/web-facesconfig_1_1.dtd">
                
                
                <faces-config>
                 <application>
                 <locale-config>
                 <default-locale>en</default-locale>
                 </locale-config>
                 </application>
                
                 <factory> <application-factory>org.apache.beehive.netui.pageflow.faces.PageFlowApplicationFactory</application-factory>
                 </factory>
                
                 <managed-bean>
                 <managed-bean-name>rmBean</managed-bean-name>
                <managed-bean-class>com.test.gems.requirements.RequirementsManagerBean</managed-bean-class>
                 <managed-bean-scope>session</managed-bean-scope>
                 </managed-bean>
                </faces-config>


                Now, if I were to use an ear configuration like elkner, would the following work?
                application.xml:
                <?xml version="1.0" encoding="UTF-8"?>
                <!DOCTYPE application PUBLIC
                 "-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN"
                 "http://java.sun.com/dtd/application_1_3.dtd">
                <application>
                 <display-name>Alpha (Voltaire) Enterprise Application</display-name>
                 <module>
                 <web>
                 <web-uri>Voltaire.war</web-uri>
                 <context-root>/Voltaire</context-root>
                 </web>
                 </module>
                 <module>
                 <ejb>entities.jar</ejb>
                 </module>
                 <module>
                 <ejb>ejb-interfaces.jar</ejb>
                 </module>
                 <module>
                 <ejb>ejbs.jar</ejb>
                 </module>
                </application>


                I would assume the managed bean file would remain the same.


                From this posting:
                http://www.jboss.com/index.html?module=bb&op=viewtopic&t=76538&view=next
                I'm wondering if the ordering of deployment is a problem. Should I alphabetize my application.xml file so that the war is loaded before the ejbs? Ejbs before war?

                This wiki listing: http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/entityconfig.html#ear
                states that, at least as of RC4, the Java EE 5 format is not supported. Also, the section on referencing the global jndi shows a persistence unit "manager1" that scopes a particular entity manager...is this different than the "requirements" persistence unit I listed in my first posting? In other words, do I need to include both those particular properties is whatever data source I'm registering? None of the RC5 examples/tutorials show these being used, and I presumed these were newer than the documentation. Instead, they all include the "hibernate.hbm2ddl.auto" and "hibernate.dialect" properties. Do I need a separate hibernate and jndi factory PUs?


                elkner:
                Thanks for your reply--that implies that JBoss is in fact compliant with the J2EE spec regarding ears, contrary (depending on the version) to what asack has mentioned. Which version are you using? I know I asked if anyone had this working with the latest version, but I should have specified an RC rather than something like a nightly build of 5.0 alpha. Also, you don't have a war packaged in your ear...would the addition of the war be the part that would cause a problem?

                I'd be very interested in seeing the application.xml (if used) of someone using a war to successfully access ejbs (either using the /lib/.jar configuration or just stuffing everything into /<all-ejbs>.jar).

                • 5. Re: JNDI Lookup Failure, ClassCastException, 4.0.4RC1
                  asack

                   

                  "tromanowski" wrote:

                  elkner:
                  Thanks for your reply--that implies that JBoss is in fact compliant with the J2EE spec regarding ears, contrary (depending on the version) to what asack has mentioned. Which version are you using? I know I asked if anyone had this working with the latest version, but I should have specified an RC rather than something like a nightly build of 5.0 alpha. Also, you don't have a war packaged in your ear...would the addition of the war be the part that would cause a problem?

                  I'd be very interested in seeing the application.xml (if used) of someone using a war to successfully access ejbs (either using the <ear>/lib/<pu>.jar configuration or just stuffing everything into <ear>/<all-ejbs>.jar).


                  Either I or you are uber confused. elkner application.xml file SPECIFIES his jars as modules so each JAR library has scope within his EAR (which is fine). Wiht J2EE 5 EAR deployments there is now a EAR/lib which automagically gets picked up by the app server and libraries are added to the classpath. If you wanted your JAR files to be referenced by two different EARs or WARS you could actually drop the JAR file in the deploy directory and have both applications now reference it without getting the dreaded ClassNotFound exception.

                  Before you go any further make sure you verify that there is one classloader for your requirement class. You can even check this by looking at the JMX console under name=Default,service=LoaderRepository and zonk in your class and see what class loaders are available.

                  • 6. Re: JNDI Lookup Failure, ClassCastException, 4.0.4RC1
                    tromanowski

                    Ok, we're on the same page with application.xml, but after spending so much time on this I was starting to question the basics.

                    I resolved my JNDI problem, which was do to collision between the myfaces classes in my WEB-INF/lib directory and the default jboss myfaces classes. I had removed the ../deploy/jsf/libs directory to fix this a while ago, but it turns out that I needed to add back in a single commons jar.

                    The bottomline is that I still have problem accessing the beans, but should be getting closer.

                    Per your suggestion, I looked up the classloaders for RequirementsManagerBean:

                    [org.jboss.mx.loading.UnifiedClassLoader3@79717e{ url=file:/C:/Program Files/jboss-4.0.4RC1/server/all/conf/ ,addedOrder=1}, org.jboss.mx.loading.UnifiedClassLoader3@914f6a{ url=file:/C:/Program Files/jboss-4.0.4RC1/server/all/tmp/deploy/tmp33566jboss-service.xml ,addedOrder=2}, org.jboss.mx.loading.UnifiedClassLoader3@1cd107f{ url=file:/C:/Program Files/jboss-4.0.4RC1/server/all/deploy/ejb3.deployer/ ,addedOrder=3}, org.jboss.mx.loading.UnifiedClassLoader3@1724a9d{ url=file:/C:/Program Files/jboss-4.0.4RC1/server/all/deploy/jboss-aop-jdk50.deployer/ ,addedOrder=4}, org.jboss.mx.loading.UnifiedClassLoader3@1b03c1a{ url=file:/C:/Program Files/jboss-4.0.4RC1/server/all/deploy/jbossweb-tomcat55.sar/ ,addedOrder=8}, org.jboss.mx.loading.UnifiedClassLoader3@1c187c8{ url=file:/C:/Program Files/jboss-4.0.4RC1/server/all/tmp/deploy/tmp33621jboss-local-jdbc.rar ,addedOrder=26}, org.jboss.mx.loading.UnifiedClassLoader3@1a2f5b1{ url=file:/C:/Program Files/jboss-4.0.4RC1/server/all/tmp/deploy/tmp33622jms-ra.rar ,addedOrder=27}]
                    


                    I'm not sure how to read this...is this showing me an array of multiple classloaders? Am I looking for duplicates?


                    At any rate, the good news is that my bean is registered ok:
                    java: Namespace
                    
                     +- XAConnectionFactory (class: org.jboss.mq.SpyXAConnectionFactory)
                     +- DefaultDS (class: org.jboss.resource.adapter.jdbc.WrapperDataSource)
                     +- SecurityProxyFactory (class: org.jboss.security.SubjectSecurityProxyFactory)
                     +- OracleDS (class: org.jboss.resource.adapter.jdbc.WrapperDataSource)
                     +- DefaultJMSProvider (class: org.jboss.jms.jndi.JNDIProviderAdapter)
                     +- comp (class: javax.naming.Context)
                     +- JmsXA (class: org.jboss.resource.adapter.jms.JmsConnectionFactoryImpl)
                     +- ConnectionFactory (class: org.jboss.mq.SpyConnectionFactory)
                     +- jaas (class: javax.naming.Context)
                     | +- other (class: org.jboss.security.plugins.SecurityDomainContext)
                     | +- JmsXARealm (class: org.jboss.security.plugins.SecurityDomainContext)
                     | +- jbossmq (class: org.jboss.security.plugins.SecurityDomainContext)
                     | +- HsqlDbRealm (class: org.jboss.security.plugins.SecurityDomainContext)
                     +- timedCacheFactory (class: javax.naming.Context)
                    Failed to lookup: timedCacheFactory, errmsg=org.jboss.util.TimedCachePolicy
                     +- TransactionPropagationContextExporter (class: org.jboss.tm.TransactionPropagationContextFactory)
                     +- StdJMSPool (class: org.jboss.jms.asf.StdServerSessionPoolFactory)
                     +- comp.ejb3 (class: javax.naming.Context)
                     | NonContext: null
                     +- TransactionPropagationContextImporter (class: org.jboss.tm.TransactionPropagationContextImporter)
                     +- TransactionManager (class: org.jboss.tm.TxManager)
                    
                    
                    Global JNDI Namespace
                    
                     +- XAConnectionFactory (class: org.jboss.mq.SpyXAConnectionFactory)
                     +- TopicConnectionFactory (class: org.jboss.naming.LinkRefPair)
                     +- UIL2ConnectionFactory[link -> ConnectionFactory] (class: javax.naming.LinkRef)
                     +- UserTransactionSessionFactory (proxy: $Proxy27 implements interface org.jboss.tm.usertx.interfaces.UserTransactionSessionFactory)
                     +- alpha (class: org.jnp.interfaces.NamingContext)
                     | +- RequirementsManagerBean (class: org.jnp.interfaces.NamingContext)
                     | | +- localStatefulProxyFactory (class: org.jboss.ejb3.stateful.StatefulLocalProxyFactory)
                     | | +- local (class: java.lang.Object)
                     | +- MyTableManager (class: org.jnp.interfaces.NamingContext)
                     | | +- local (proxy: $Proxy56 implements No ClassLoaders found for: com.test.gems.requirements.MyTableInterface (no security manager: RMI class loader disabled))
                     +- UIL2XAConnectionFactory[link -> XAConnectionFactory] (class: javax.naming.LinkRef)
                     +- QueueConnectionFactory (class: org.jboss.naming.LinkRefPair)
                     +- topic (class: org.jnp.interfaces.NamingContext)
                     | +- testDurableTopic (class: org.jboss.mq.SpyTopic)
                     | +- testTopic (class: org.jboss.mq.SpyTopic)
                     | +- securedTopic (class: org.jboss.mq.SpyTopic)
                     +- queue (class: org.jnp.interfaces.NamingContext)
                     | +- A (class: org.jboss.mq.SpyQueue)
                     | +- testQueue (class: org.jboss.mq.SpyQueue)
                     | +- ex (class: org.jboss.mq.SpyQueue)
                     | +- DLQ (class: org.jboss.mq.SpyQueue)
                     | +- D (class: org.jboss.mq.SpyQueue)
                     | +- C (class: org.jboss.mq.SpyQueue)
                     | +- B (class: org.jboss.mq.SpyQueue)
                     +- ConnectionFactory (class: org.jboss.mq.SpyConnectionFactory)
                     +- UserTransaction (class: org.jboss.tm.usertx.client.ClientUserTransaction)
                     +- jmx (class: org.jnp.interfaces.NamingContext)
                     | +- invoker (class: org.jnp.interfaces.NamingContext)
                     | | +- RMIAdaptor (proxy: $Proxy26 implements interface org.jboss.jmx.adaptor.rmi.RMIAdaptor,interface org.jboss.jmx.adaptor.rmi.RMIAdaptorExt)
                     | +- rmi (class: org.jnp.interfaces.NamingContext)
                     | | +- RMIAdaptor[link -> jmx/invoker/RMIAdaptor] (class: javax.naming.LinkRef)
                     +- UILXAConnectionFactory[link -> XAConnectionFactory] (class: javax.naming.LinkRef)
                     +- UILConnectionFactory[link -> ConnectionFactory] (class: javax.naming.LinkRef)
                    


                    Nevermind "MyTableManager"...that is from an earlier test I tried.


                    Now what I don't get is why I can't access any beans, be they normal FacesBacking beans or EJB 3.0 entity beans. I've posted my faces-config.xml file above. When I run something like:
                    <f:view>
                     <h:outputText value="#{rmBean.name}"/>
                    </f:view>


                    I get a "javax.faces.el.EvaluationException: Cannot get value for expression '#{rmBean.name}'" when the above call is made. Now many users have posted this type of problem and it's a persistence.xml or JNDI lookup problem, but I've posted my code in my earlier posting and it complies with the latest JBoss implementation of EJB 3.0 (i.e., following the migration guide and wiki postings). The stack trace of the EvaluationException above ends with "java.lang.NulPointerException"


                    2006-03-21 08:59:02,203 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
                    2006-03-21 08:59:02,203 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@12088db, cl=org.jboss.mx.loading.UnifiedClassLoader3@7227a8{ url=null ,addedOrder=0}
                    2006-03-21 08:59:02,203 INFO [STDOUT] XXXXXXXXXX In method getName. XXXXXXXXXX
                    2006-03-21 08:59:02,203 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
                    2006-03-21 08:59:02,218 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@12088db, cl=org.jboss.mx.loading.UnifiedClassLoader3@1abcd5e{ url=null ,addedOrder=0}
                    2006-03-21 08:59:02,218 INFO [org.apache.beehive.netui.pageflow.internal.DefaultExceptionsHandler] Handling Throwable javax.faces.el.EvaluationException
                    2006-03-21 08:59:02,218 ERROR [org.apache.beehive.netui.pageflow.internal.DefaultExceptionsHandler] Throwable javax.faces.el.EvaluationException unhandled by the current page flow (and any shared flow)
                    
                    Throwable: javax.faces.el.EvaluationException: Cannot get value for expression '#{rmBean.name}'
                    Stack Trace:
                    javax.faces.el.EvaluationException: Cannot get value for expression '#{rmBean.name}'
                     at org.apache.myfaces.el.ValueBindingImpl.getValue(ValueBindingImpl.java:397)
                     at javax.faces.component.UIOutput.getValue(UIOutput.java:75)
                     at org.apache.myfaces.renderkit.RendererUtils.getStringValue(RendererUtils.java:225)
                     at org.apache.myfaces.renderkit.html.HtmlTextRendererBase.renderOutput(HtmlTextRendererBase.java:65)
                    
                    ***
                     snipped stack trace to save space
                    
                    ***
                    
                    Caused by: javax.faces.el.EvaluationException: com.lmco.gems.requirements.RequirementsManagerBean
                     at org.apache.myfaces.el.PropertyResolverImpl.getValue(PropertyResolverImpl.java:78)
                     at org.apache.myfaces.el.ELParserHelper$MyPropertySuffix.evaluate(ELParserHelper.java:532)
                     at org.apache.commons.el.ComplexValue.evaluate(ComplexValue.java:145)
                     at org.apache.myfaces.el.ValueBindingImpl.getValue(ValueBindingImpl.java:378)
                     ... 71 more
                    Caused by: javax.faces.el.EvaluationException: Bean: com.lmco.gems.requirements.RequirementsManagerBean, property: name
                     at org.apache.myfaces.el.PropertyResolverImpl.getProperty(PropertyResolverImpl.java:404)
                     at org.apache.myfaces.el.PropertyResolverImpl.getValue(PropertyResolverImpl.java:71)
                     ... 74 more
                    Caused by: java.lang.reflect.InvocationTargetException
                     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
                     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
                     at java.lang.reflect.Method.invoke(Method.java:585)
                     at org.apache.myfaces.el.PropertyResolverImpl.getProperty(PropertyResolverImpl.java:400)
                     ... 75 more
                    Caused by: java.lang.NullPointerException
                     at com.lmco.gems.requirements.RequirementsManagerBean.getRequirement(RequirementsManagerBean.java:71)
                     at com.lmco.gems.requirements.RequirementsManagerBean.getName(RequirementsManagerBean.java:89)
                     ... 80 more
                    


                    The method I'm attempting to access is in fact getting called because I am printing a STDOUT from it. Is it finding a copy of the bean class in my WAR file (I'll have to triple check that they're not there), and then failing to access the beans in the ear's jar file?

                    What is interesting (or not) is this exception that happens a bit earlier in the server log:

                    , cl=org.jboss.mx.loading.HeirarchicalLoaderRepository3$CacheClassLoader@b09321{ url=null ,addedOrder=0}
                    2006-03-21 08:59:02,062 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
                    2006-03-21 08:59:02,062 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@12088db, cl=org.jboss.mx.loading.UnifiedClassLoader3@8b83e3{ url=null ,addedOrder=0}
                    2006-03-21 08:59:02,062 ERROR [STDERR] java.lang.ClassCastException: $Proxy58
                    2006-03-21 08:59:02,078 ERROR [STDERR] at org.apache.jsp.tasking.page2_jsp.jspInit(org.apache.jsp.tasking.page2_jsp:35)
                    
                    ***
                     more trace
                    ***
                    
                    2006-03-21 08:59:02,078 ERROR [STDERR] at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
                    2006-03-21 08:59:02,078 ERROR [STDERR] at java.lang.Thread.run(Thread.java:595)
                    2006-03-21 08:59:02,093 INFO [STDOUT] caught exception in second catch block.
                    2006-03-21 08:59:02,109 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
                    2006-03-21 08:59:02,109 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@12088db, cl=org.jboss.mx.loading.UnifiedClassLoader3@1630eb6{ url=null ,addedOrder=0}
                    


                    Notice the bolded section...that is a result of attempting to peform a JNDI lookup.

                    FacesContext fc = FacesContext.getCurrentInstance();
                    rm = (RequirementsManagerBean)fc.getApplication().createValueBinding("#{rmBean}").getValue(fc);
                    



                    I've also tried:

                    InitialContext ic = new InitialContext();
                    rm = (RequirementsManagerBean)ic.lookup("alpha/RequirementsManagerBean/local");
                    


                    The above, however, I wouldn't expect to be valid since this is a jsf page and I'm trying to access RequirmentsManagerBean as a managed bean.

                    I really think this is a problem between JSF managed beans and the JNDI access, but I don't know where to go from here. The following forum postings have similar problems, but the most relevent ones don't have any responses. Googling for info on other sites has really created more questions than answers. Is the war/jar file separation within my ear the culprit? Are there better questions I should be asking?

                    "Inject EntityManager in JSF managed bean always NULL"
                    http://www.jboss.com/index.html?module=bb&op=viewtopic&t=78257

                    "ClassCastException on EntityBean returned from Stateless Se"
                    http://www.jboss.com/index.html?module=bb&op=viewtopic&t=72007

                    "JSF Problems on JBoss AS 4.0.4RC1
                    http://www.jboss.com/index.html?module=bb&op=viewtopic&t=78982


                    Asack, or anyone else...any suggestions?