• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Problem using Tomcat's crossContext

 
perico palotes
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
    Pie
    Posts: 18098
    50
    Android Eclipse IDE Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.
     
    perico palotes
    Greenhorn
    Posts: 2
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Pie
    Posts: 18098
    50
    Android Eclipse IDE Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic