Gopal Ramasammy-Cook worte:
> > Thanks for the response. However, I do have Turbine as a set of classes (which I
>myself compiled) in my webapps/Web-INF/classes directory. I do not think it is a
>Turbine class path issue, for it was, the Turbine class itself would not found. The
>reason I have used the Turbine classes as opposed to the Turbine jar, is so that I
>can debug easier (and understand Turbine better as well).
You need the *sources* to understand Turbine better ;-). As long as you don't plan on
changing Turbine classes, recompiling
and having the servlet container reload them at runtime (which is not always a good
idea), having Turbine classes unjarred
does not benefit you. Of course compiling your own Turbine jar from CVS sources is a
good idea.
> > As I mentioned previously, I have actually placed a System.out.println() debug
>statement in my TurbineServices class, and this print statement actually does appear
>in my Tomcat console, which means that the Turbine classes are being found by the JVM.
> >
> > The problem appears to be specifically around the Global Cache Service. When I
>remove the code that actually calls the cache service, my code runs correctly.
I can't really guess what can be wrong there, from what you have written...
> > By the way, I am using the snapshot of 28 Aug 2000.
You should consider updating your Turbine sources from CVS often. Many things get
fixed (or broken ;-)) on
daily basis.
[EMAIL PROTECTED] wrote:
> I believe the problem is in BaseInitableBroker.java:223 wher
> it goes
>
> try
> {
> initable = (Initable)Class.forName(className).newInstance();
> }
>
> The Class.forName is failing as it checks context
> classloader and is not finding appropriate classes.
So? What's wrong with context loader? it has classes/ and all jars in lib/ in
it's classpath...
> This is prolly because your classes are in WEB-INF/lib and
> the turbine classes are in WEB-INF/classes or vice versa. It
> always leaves me pulling out hair when that sort of thing
> happens. Easieest solution is to unjar everything into
> WEB-INF/classes - thou you may want to package it up
> propperly when you release it as putting heaps in
> WEB-INF/classes can cause odd behaviour.
I do have my classes (including custom services) in webapp/WEB-INF/classes and all
the jars form the distribution including turbine-2.0.jar in webapp/WEB-INF/lib and
everything is working just fine. I don't know how uncompressing jar influences
debugging (haven't done that yet) but I thaught that as far as the debuger can find
the *source* files, it doesn't matter where the classes are loaded from.
Rafal.
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
