File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Tomcat and the fly likes Problem using Tomcat's crossContext Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Products » Tomcat
Bookmark "Problem using Tomcat Watch "Problem using Tomcat New topic
Author

Problem using Tomcat's crossContext

perico palotes
Greenhorn

Joined: Jan 24, 2011
Posts: 2
Hello everyone!!

I'm trying to learn about Tomcat's crossContext feature. I've been coding a sample app composed of there projects (netbeans 6.9).

The first project is intended to be a common jar with the classes of the objects to be shared. Only one in this case: a class named SharedObject that is a wrapper of a String with a get/set and toString methods. The second (with crossContext enabled) is a ServletContextListener that creates a SharedObject instance and stores it in the context

with its context.xml:

The third project is a servlet that looks for the sender's context, gets the SharedObject and prints some data

The output from both parts are:
  • listener sender
    __________________________________ininininin___________________________________
    __________________________ServletContext hashcode = 16825026____________________
  • servlet receiver
    Servlet SharedAppDemo at /SharedApp_demo
    ServletContext hashcode = 16825026
    shared name: from listener
    SharedApp.lib.SharedObject cannot be cast to SharedApp.lib.SharedObject


  • As you can see, the object is the same (same hashcode) but I cannot cast it. Both sender and receiver have their own copy of the shared jar, may that be the error? What am I doing wrong??

    Thanks you all in advance!
    Tim Holloway
    Saloon Keeper

    Joined: Jun 25, 2001
    Posts: 16305
        
      21

    Welcome to the JavaRanch, Perico!

    I'm afraid the hashcode value doesn't help. Just aside from everything else, hashcodes are not guaranteed to be unique by definition.

    But the real issue is that each and every webapp has its own classpath, and if one app constructs an object using one classpath and another app constructs - or attempts to access - an object from another classpath, not only the objects, but their defining classes are not considered to be the same.

    In other words, each class has an invisible qualification on it that indicates what classloader managed it, and therefore the same class from different classloaders isn't really the "same" class.


    Customer surveys are for companies who didn't pay proper attention to begin with.
    perico palotes
    Greenhorn

    Joined: Jan 24, 2011
    Posts: 2
    Tim Holloway wrote:Welcome to the JavaRanch, Perico!

    I'm afraid the hashcode value doesn't help. Just aside from everything else, hashcodes are not guaranteed to be unique by definition.

    But the real issue is that each and every webapp has its own classpath, and if one app constructs an object using one classpath and another app constructs - or attempts to access - an object from another classpath, not only the objects, but their defining classes are not considered to be the same.

    In other words, each class has an invisible qualification on it that indicates what classloader managed it, and therefore the same class from different classloaders isn't really the "same" class.

    Thanks for your answer Tim. I suspected the behaviour you mention (confirming it is a useful lesson though). However, how am I supposed to share an object if the fact that having different classloaders prevents it? Am I obliged to share also the classloader (and how)? or is it that crossContext only allows to share primitive types?

    Regards!
    Tim Holloway
    Saloon Keeper

    Joined: Jun 25, 2001
    Posts: 16305
        
      21

    You'd either have to have a common classloader, which is usually somewhere between inconvenient and impossible or you'd have to serialize the object. Serialization isn't real convenient either, since the binary internal stuff has to be marshalled, transmitted and unmarshalled - AND the serializations have to be compatible, but the framework should be helping on that.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Problem using Tomcat's crossContext