0 Replies Latest reply on Sep 29, 2004 10:01 PM by Craig Berry

    MBean in sar dynamically loading ear-level jar classes in 4.

    Craig Berry Newbie

      My project builds and deploys as an ear properly in 3.2.4, but fails with a classloader problem in 4.0.0. I would greatly appreciate help solving this problem.

      The ear contains (among other things) a jar containing all our app code, including the code specifying and used by a few mbeans. The mbeans are deployed as a sar file inside the ear. The sar file contains nothing but a jboss-service.xml and a manifest file; the latter has only header info (it's autogenerated by the xdoclet jar task).

      The jboss-service.xml looks like this:

      <?xml version="1.0" encoding="UTF-8"?>
      
      <service>
       <mbean code="com.portblue.mgmt.ConfigurationManager"
       name="com.portblue.mgmt:service=ConfigurationManager">
       </mbean>
      
       <mbean code="com.portblue.mgmt.SweeperManager"
       name="com.portblue.mgmt:service=SweeperManager">
      <depends>com.portblue.mgmt:service=ConfigurationManager</depends>
      <depends>jboss.j2ee:jndiName=com.portblue.model.admin.user.SweeperFacadeRemoteHome,service=EJB</depends>
      <depends>user:name=QuartzService,service=QuartzService</depends>
       </mbean>
      </service>
      


      When this mbean initializes, things start out fine; the outermost classes are found and execute properly. However, during ConfigurationManager initialization, a commons Digester object (which is parsing a config file) tries to load a class by name at runtime. The class is in the jar from which the mbean code itself came, and this worked fine in 3.2.4, but in 4.0.0 the classloader cannot find the class.

      I'm completely stuck by this problem, and unless I solve it we cannot migrate from 3.2.4 to 4.0.0. Anybody out there have a clue, please?