Cast Exceptions within a WAR

Question

We have a couple of servlets running on WLS 5.1 where the behavior when
          sharing context seems to be broken on WebLogic within a WAR?
          In the init method of one we initialize a single-ton class. It is then
          placed in the ServletContext. Later a 2nd servlet is invoked and also within
          the init method we first check for the existence of that class. The class is
          found, but the moment we tried to cast it to its original form we get a Cast
          exception.
          We tried using both the servletContext returned by the
          config.getServletContext as well as the
          config.getServletContext().getContext("/someURI"). Both returned the same
          object and in both cases the moment the cast is attempted the exception is
          raised.
          Note that a similar exercise when using an Object of type String it works
          fine. This originally led me to believe that maybe is a classpath issue, but
          I pointed the weblogic.classpath to the WEB-INF/lib directory where the jar
          files are, but no luck.
          Any ideas?
          

Answer 1

Cheers (and if Im wong PLEASE LET ME KNOW too!)                    Nope, you are spot on!
          Cameron Purdy, LiveWater
          "Robert Masters" <[email protected]> wrote in message
          news:[email protected]...
          > It gets even more fun when you start integrating WAR packaged Servlets and
          > EAR packaged enterprise beans. Basically weblogic deals with no less that
          4
          > classloaders:
          >
          > the standard classloader for the VM (loads everything from the classpath)
          > the WLAS server classloader (loads classes from the weblogic.class.path)
          > the Servlet classloader(war files etc)
          > the EJB classloader (for ejbs!)
          >
          >
          > My findings so far have show that you must ensure that ANY objects that an
          > EJB shares (via the public interfaces) are ONLY stored in one of the jars
          (i
          > put then in the ejb jar). You see what happens is this:
          >
          > the EAR jar directory sort of "exports" the ejb home , remote interface
          and
          > ANY classes found in the ejb method signatures to the WeblogicClassloader.
          > These classes are then sortof "passed" onto the Servlet classloader.
          > However, if the classes are ALREADY in the WAR they take precedence over
          the
          > classes in the EAR which will ultimately cause a ClassCastException.
          >
          > The simple rule is to ensure that you keep all EJB and related classes in
          > the EAR and any serblet/jsp stuff in the WAR. If you have common classes
          > that are used internally by BOTH Serlet and/or EJB's that are NOT part of
          > the EJB signaures you can put these into the weblogic Classpath
          >
          >
          > Pheewww. It took me a couple of hours to figure all this out but now my
          > Servlet, JSP's and EJBs are all working nicely :)
          >
          >
          > Cheers (and if Im wong PLEASE LET ME KNOW too!)
          >
          > Regards
          >
          > Rob
          > "Cameron Purdy" <[email protected]> wrote in message
          > news:[email protected]...
          > > It is probable that if you execute a .jsp directly immediately after you
          > > launch WL5.1 that this error will not happen. There is a terrible
          > > architectural problem with class loaders in WL and the behavior is
          > extremely
          > > weird (although at least predictable). If the first request to the WL
          > > server goes to a Servlet pkgd in a WAR, then JSPs will be loaded in a
          > > completely different class loader context, including classes from your
          WAR
          > > that the JSP uses! So if you (for example) put something in the
          > > HttpServletRequest attribute table from your Servlet and try to get it
          out
          > > from your JSP, you will get a ClassCastException! (You'd think they
          would
          > > have tried that at least once :-(
          > >
          > > Now here is the weirdness: If, after starting the server, you put in a
          > URL
          > > for a .jsp (and make sure you refresh just in case it was cached), then
          > > subsequent requests to Servlets will work when they forward to JSPs ...
          > > that's right the class loader is somehow set up differently depending on
          > > where the very first HTTP request gets routed to!
          > >
          > > We found this by accident ... we thought we were going to have to scrap
          WL
          > > because of the ClassCastException, but a developer "accidently"
          refreshed
          > a
          > > JSP first and then everything worked!
          > >
          > > Cameron Purdy, LiveWater
          > >
          > > "Julio Castillo" <[email protected]> wrote in message
          > > news:[email protected]...
          > > > We have a couple of servlets running on WLS 5.1 where the behavior
          when
          > > > sharing context seems to be broken on WebLogic within a WAR?
          > > >
          > > > In the init method of one we initialize a single-ton class. It is then
          > > > placed in the ServletContext. Later a 2nd servlet is invoked and also
          > > within
          > > > the init method we first check for the existence of that class. The
          > class
          > > is
          > > > found, but the moment we tried to cast it to its original form we get
          a
          > > Cast
          > > > exception.
          > > >
          > > > We tried using both the servletContext returned by the
          > > > config.getServletContext as well as the
          > > > config.getServletContext().getContext("/someURI"). Both returned the
          > same
          > > > object and in both cases the moment the cast is attempted the
          exception
          > is
          > > > raised.
          > > >
          > > > Note that a similar exercise when using an Object of type String it
          > works
          > > > fine. This originally led me to believe that maybe is a classpath
          issue,
          > > but
          > > > I pointed the weblogic.classpath to the WEB-INF/lib directory where
          the
          > > jar
          > > > files are, but no luck.
          > > >
          > > > Any ideas?
          > > >
          > > >
          > >
          > >
          >
          >