3 Replies Latest reply on May 12, 2004 11:07 AM by jae

    ClassCastException at runtime

    Frederic Burlet Newbie

      Hi,

      I encounter some problems when running my app. I got a ClassCastException at runtime.

      I made 2 ear: one is the client of the other. I put the interfaces in the both ears. I defined for the both a loader repository (through jboss-app.xml).

       <loader-repository>
       kiala:entities=LoaderRepository
       <loader-repository-config>
       java2ParentDelegation=false
       </loader-repository-config>
       </loader-repository>
      


      I'm allowed to cold/hot (re)deploy the application but at runtime, I got a ClassCastException.

      I would like to be able to cold/hot (re)deploy my modules independent from each other and run the application as well. (And even later, to deploy these modules on separate machines).

      Any help would be appreciate,

      Fred.



        • 1. Re: ClassCastException at runtime
          jae Master

          i posted this message back when the mailing lists were being used directly (as opposed to now where we primarily use the forums and just see the messages via the list).

          maybe i should turn this into the base for a wiki faq page since this topic seems to be coming up a lot as of late.

          -----

          if you want to have two scoped ears in the same VM communicate w/ each other, then you need to extract the common interfaces out of both of the scoped ears and either deploy them as standalone jars, or package them up into an *unscoped* ear.

          ie:

          A.ear is scoped and exposes it's interface via a class called Foo.

          B.ear is scoped and needs to use interface Foo to access A.ear

          remove class Foo from both A.ear and B.ear and either deploy it in a standalone jar and you'll be good to go. the "whiteboard" picture would look something like this:


          Foo.jar

          A.ear (scoped) B.ear (scoped)


          so when A.ear asks for interface Foo, it sees that it is not available via it's classloader and then asks for it from the top level class loader. the same thing occurs w/ B.ear - it can't find the class, and asks the top level loader, leaving both ears to get the same class loader definition.
          this also now allows you to hot deploy A.ear and/or B.ear w/o having to restart jboss.

          this mechanism also works if for hot deploying unscoped ears as well.

          keep in mind that if your interfaces return an object of type Baz, that class will also have to be packaged inside the same jar that contains the ejb interfaces.

          a slight con to this approach is that if any of the classes change inside the standalone jar file and you redeploy it, you will either have to restart the server or "touch" all the other deployment archives that rely upon that jar. the reason for this is that the ear's class loader will have a stale reference to classes in the jar.

          • 2. Re: ClassCastException at runtime
            Frederic Burlet Newbie


            Ok, thank you for your help.

            Yes, it might be a good idea to post your explanation on the wiki.

            Fred.