I don't see how this would work... It doesn't matter what stores, it matters
what creates them... Probably, Context uses some sort of Hashtable
internally to store all objects, which is a core class by itself, and it
doesn't help the problem. So, I don't get
it. May be you can give more details?
Regards,
--VG
Allen Akers wrote:
>
> I ran into the same problem and found the only good solution was to take
> a look at my custom classes and strip away what was "custom" about them
> and only save core Java objects to the context. When I need my custom
> class, I create an instance of it and pass the references to the core
> Java objects saved in the context to the class in the constructor so
> that it is pointing to the objects in the shared context. There are
> some limitations to this, but it works in all situations given a little
> thought. Let me know if you need more clarification.
>
> Allen Akers
> Programmer Analyst
> Strategic Web and Voice Development
> ________________________________
> [EMAIL PROTECTED]
>
> >>> [EMAIL PROTECTED] 03/15/01 09:46AM >>>
> Hello Vladimir,
>
> Thank you for your help with classloaders. :)
>
> I tried to put my "shared" classes in the classpath. But this approach
> failed too. I cannot understand.
>
> In this case my "shared" classes loaded by "Bootstrap class loader
> (Java system classes)" and in case any references to them should use
> above classloader. Even in case servlet reloading. Of course, I
> removed
> these classes from web-inf/classes directory.
>
> May-be I need to load this "shared" class before loading my servlet,
> that uses
> this "shared" object? May-be it is loaded by "Webapp class loader
> (contents of WEB-INF/classes)"? I don't know.
>
> This situation doesn't hurt me. I just want to know, how other Tomcat
> users deal with such problem. I think many projects use "shared"
> objects between servlets. This situation may be happen only in
> "development
> stage" and never in "production". But let me know, how do you deal
> with it?
>
> Wednesday, March 14, 2001, 7:10:01 PM, you wrote:
>
> VG> Bo Xu wrote:
> >>
> >> Andrey Myatlyuk wrote:
> >>
> >> > Hello Vladimir,
> >> >
> >> > Thank you for your help.
> >> >
> >> > And I'm still have some questions.
> >> >
> >> > Why do we need to implement "some interface"? java.io.Serializable
> I
> >> > think? But anyway I implemented this interface - it doesn't work.
> This
> >> > approach works for EJB. :)
> >> >
> >> > And my question is: Is there any way to use "some shared" object
> with
> >> > reloadable servlets without Tomcat restart?
> >> >
> >> > Thanks.
> >> >
>
> VG> After reading this message and some thinking I can say that the
> problem is
> VG> harder than I thought. There's no way to trick it, at least there's
> no interface
> VG> you can create/implement to fix it... And of course it wasn't the
> Serializable
> VG> one...
> VG> Sorry, for misleading... But... what about this:
>
> VG> Object _statesBean =
> VG>
> getServletContext().getAttribute(StatesBean.STATES_BEAN_NAME);
>
> VG> Class sBeanClazz = _statesBean.getClass();
> VG> Method m = sBeanClazz.getMethod("foo", new Class[] {/*args*/});
> VG> m.invoke(_statesBean, new Object{ /*params*/ });
>
> VG> he-he, ugly :) Not sure if it'll work...
>
> VG> Regards,
> VG> VG.
>
> >> > Wednesday, March 14, 2001, 3:16:45 PM, you wrote:
> >> >
> >> > VG> I think you're experiencing a standard Java class loader
> problem.
> >> > VG> Java treats classes loaded into different classloaders as
> different
> >> > VG> classes, even though they share the same full. qual. name.
> >> > VG> Your recompiled servlets are reloaded by a brand new class
> loader
> >> > VG> to make sure the old classes are garbage collected. What you
> get
> >> > VG> from the context is actuially an instance of a class loaded
> into
> >> > VG> a different classloader, and (StatesBean) part in your
> statement
> >> > VG> causes StatesBean to be loaded again by this new classloader
> that
> >> > VG> reloaded your servlet, so
> >> > VG> VM complains that you cannot cast objects since it thinks
> they
> >> > VG> are instances of 2 completely different classes. No matter
> where
> >> > VG> you place your files you'll have the same problem.
> >> >
> >> > VG> You can avoid this problem by writing some extra code and have
> your
> >> > VG> bean to implement some interface.... Extra work, just restart
> >> > VG> Tomcat every time...
> >> >
> >> > VG> Regards,
> >> > VG> VG.
> >> >
> >> > VG> Andrey Myatlyuk wrote:
> >> > >>
> >> > >> Hello Tomcat users,
> >> > >>
> >> > >> I'm in a trouble. I share some object(StatesBean) between
> servlets. And when I
> >> > >> recompile _servlet_, I got ClassCastException about shared
> object.
> >> > >>
> >> > >> _statesBean=
> >> > >>
> (StatesBean)getServletContext().getAttribute(StatesBean.STATES_BEAN_NAME);
> >> > >>
> >> > >>
> >> > >> Classfile for this object is placed in the same directory,
> where
> >> > >> servlets do - web-inf/classes. Where I need to place classfile
> for
> >> > >> this object to prevent Tomcat exceptions?
> >> > >>
> >> > >> Of course, if I reload Tomcat everything is OK.
> >> > >>
> >> > >> Thank you in advance!
> >> > >>
> >> > >> --
> >> > >> Best regards,
> >> > >> Andrey
> mailto:[EMAIL PROTECTED]
> >> > [...]
> >>
> >> Hi :-) I am not sure, I guess:
> >> * perhaps the problem is:
> >> - let use suppose: classloaderA -> classA -> instanceA
> >> then you "setAttribute" instanceA into ServletContext of
> >> this wepapp, so now ServletContext holds a reference to
> >> instanceA.
> >> - after a while, your Sevlet class is reloaded, with
> >> jakarta-tomcat-4.0-b1, now classloaderA is not there,
> >> so classA is not there, But instanceA is there: because
> >> at least there is One reference of instanceA is being holded
> >> by ServletContext, so it will not be GCed, and getAttribute()
> >> will not return null.
> >> - but now instanceA doesn't has "its original class" and "its
> >> original classloader", I am not sure, but I guess perhaps it
> is
> >> the reason.
> >>
> >> * IMHO, I guess: if you can find a way to load classA from a
> >> special classloader which will not be destroyed when/even if
> >> your Servlet class is reloaded, then you can solve the problem.
> >> It means that our Servlet class and some Helper classes are
> >> loaded by several classloaders in "diferent layer". if we don't
> >> want to keep a Attribute "across Servlet reloading", perhaps
> >> we don't need to it; but if we want, and we are sure that the
> >> "webapp classloader" will be destroyed and re-made, than I
> >> guess perhaps we have to use classloaders which are in
> >> "diferent layer".
> >>
> >> * the following is a good email about the classloader:
> >>
> >> //************ <good email> ************************
> >> On Sat, 10 Mar 2001, David Wall wrote:
> >>
> >> > There appears to be a serious problem with the
> classpath/classloader with
> >> > Tomcat 3.2.1.
> >> >
> >> > It may be related to the Jasper engine, which outputs a dynamic
> classpath
> >> > name that includes all of the classes and jars in the WEB-INF
> directory, as
> >> > expected. But is the same classloader used when servlets are
> loaded at
> >> > startup according to the web.xml file?
> >> >
> >>
> >> The same class loader is used to load all classes within a
> particular web
> >> application, but there is more to the story than that. See below.
> >>
> >> > Anyway, I'm not sure where the problem resides, but I have found
> that by
> >> > setting the CLASSPATH to the same thing Jasper sets up
> (specifically those
> >> > files in WEB-INF/classes and WEB-INF/lib), my beans will no longer
> complain
> >> > about unknown classes.
> >> >
> >> > But unfortunately, this "fix" doesn't really work because
> apparently they
> >> > really are loaded by different classloaders, so they are not the
> same
> >> > classes within the JVM. This causes problems for classes that
> appear to
> >> > have been initialized, but then magically are not when loaded
> through the
> >> > other classloader.
> >> >
> >>
> >> The most common cause for this is actually a developer error.
> Before
> >> explaining how this can be true, let's look a little at how class
> loading
> >> actually works in Tomcat (the details do ***not*** necessarily apply
> to
> >> any other servlet container, because standard behavior is not
> specified).
> >>
> >> There is actually a hierarchy of class loaders created when Tomcat
> is
> >> running:
> >> - Bootstrap class loader (Java system classes)
> >> - Extensions class loader (JAR files from $JAVA_HOME/jre/lib/ext)
> >> - System class loader (contents of CLASSPATH at startup time)
> >> - Webapp class loader (contents of WEB-INF/classes and WEB-INF/lib
> >> for your particular web application)
> >>
> >> Now, when your servlet class is loaded, Tomcat asks the webapp
> class
> >> loader to load it. Following the standard Java delegation model,
> the web
> >> app class loader first asks it's parent class loader to try to find
> the
> >> class -- and so on up the hierarchy. If your servlet class is
> actually in
> >> WEB-INF/classes or WEB-INF/lib, all of these attempts to delegate
> upwards
> >> will fail. Therefore, the web app class loader will load the class
> >> itself.
> >>
> >> The same thing happens for every other class that your servlet
> references
> >> -- it gets loaded by whichever class loader finds that class. If
> the load
> >> happens from a class loader *above* the calling class's class
> loader, that
> >> is fine. However, trouble occurs if you try the opposite
> direction,
> >> because there are no links *downward* in the class loader
> hierarchy.
> >>
> >> Consider what happens if you put your servlet class into
> $TOMCAT_HOME/lib
> >> (so that it gets added to the system class loader at startup time).
> When
> >> you reference the servlet, it gets loaded by the system class loader
> --
> >> not the web app class loader. So, if it tries to refer to a
> JavaBean
> >> class you have stored in WEB-INF/classes or WEB-INF/lib. What
> >> happens? You've got it: ClassNotFoundException. Because the
> servlet was
> >> loaded from the system class loader, it can only look *up* the
> hierarchy
> >> rather than *down*.
> >>
> >> > Anyway, is there anybody looking into this? I know I've seen
> several
> >> > postings complaining about classpath problems that are likely
> related to
> >> > this. Has it been fixed in 3.2.2?
> >> >
> >>
> >> The moral of the story is that you should follow the following steps
> to
> >> completely avoid class loading problems in your web apps, and
> guarantee
> >> that your apps will be portable to other servlet containers:
> >>
> >> * Do not rely on system extensions in $JAVA_HOME/jre/lib/ext. If
> you
> >> do, those classes are *not* allowed to reference any classes on
> the
> >> system class path, or inside your web application.
> >>
> >> * Do not rely on adding classes onto your CLASSPATH (or putting them
> in
> >> $TOMCAT_HOME/lib) before starting Tomcat. Such classes will have
> >> problems with downward references, as described above. Also,
> support
> >> for shared library classes is ***not*** required by the servlet
> spec,
> >> so you cannot count on this facility in a portable app.
> >>
> >> * Put all classes your application needs into WEB-INF/classes, or
> >> in JAR files unde WEB-INF/lib. In this way, they will all be
> loaded
> >> by the same class loader and not have any referencing problems.
> >>
> >> There are other specific issues with specific libraries, and there
> are
> >> some changes in how class loading works in Tomcat 4.0, but the
> above
> >> outline identifies what to do about the majority of class loading
> issues
> >> in servlet containers.
> >>
> >> > Thanks,
> >> > David
> >> >
> >>
> >> Craig McClanahan
> >>
> >> //************ </good email> ************************
> >>
> >> Bo ^_^
> >> Mar.14, 2001
>
> --
> Best regards,
> Andrey mailto:[EMAIL PROTECTED]
