I have figured out how to get around this problem .... I thought I
understood why this makes my problem go away ... .but I don't think I fully
do.
This problem was annoying me so I stepped through the code and found that
commenting out the following lines makes my problem go away and I can run a
very simple test ..,
>From AbstractHttpClient's constructor I commented out the logger line:
private static Log logger = LogService.getInstance
().getLog(AbstractHttpClient.class.getName())
which then meant the logger entries in the doTest(ServletTestRequest)
method of the AbstractHttpClient class had to be commented out also
logger.entry("doTest(" + theRequest + ")"); AND logger.exit("doTest");
Ok I don't understand exactly why this makes it work, but here is what I
have discovered in my investigation ... please feel free to shed some
light:
1. The declaration of logger, requires a call to LogService.init() before
you can call the getLog() method.
2. Addidng Log4J to the class path does not help in anyway.
3. If you are wondering why AbstractHttpClient's constructor gets called,
the short story is:
TestSuite's Class argument constructor that is called from the suite()
method of the your custom test class, traverses the inheritance hierarchy
to find all the "declared methods", basically trying to get all the ones
that start with "test". (This is how JUnit works)
So in my case... the hierarchy is:
ShoppingCartServletTest (my own test class)
---> ServletTestCase (cactus parent)
--------> AbstractTestCase (cactus parent)
runGeneric(AbstractHttpClient) is a "declared method" in AbstractTestCase.
I've probably confused rather than helped the issue. I hope at least one
person understands what I'm talking about and can shed more light on the
issue.
The bottom line is, commenting out those 3 lines has solved my problem, but
I don't quite understand why because there are other logger entries in
other classes (e.g. AutoReadHttpURLConnection and HttpClientHelper) with
the same logger declaration and they don't create a problem.
I hope this helps.
Regards
Aklil
Nick Chalko
<[EMAIL PROTECTED]> To: "'[EMAIL PROTECTED]'"
<[EMAIL PROTECTED]>
18/10/2001 06:39 AM cc:
Please respond to Subject: RE: VAJ 3.5.3 Class loader
problem
cactus-user
I check "all projects" for the class path of the client, and I still get
the
Failed to invoke suite():java.lang.NoClassDefFoundError
So I still stuck running cactus from the command line against Weblogic,
instead inside VAJ.
-----Original Message-----
From: Idler, Todd [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 15, 2001 8:46 AM
To: '[EMAIL PROTECTED]'
Subject: RE: VAJ 3.5.3 Class loader problem
Hi David and Aklil,
I was having a similar problem and finally remembered what I did to correct
it. I don't currently have VisualAge installed and I'm going from memory
on
this one. You might also look in the archived postings because I believe
that there was another thread on this topic.
The problem may be that the Servlet API project can't be found by the
client-side of the cactus test. The Servlet project is automatically
included in the classpath for WTE, but you need to explicitly add it to the
classpath of the project that contains the test class. You can either add
the Servlet project globally for use in all projects or you can add it
specifically to the classpath for the project that you are testing. As an
explanation for those who don't use VisualAge, you can add VisualAge
projects to the classpath in addition to directories.
I think that the offending class was ServletException. One of my test
methods was declared as throwing this exception. Since the exception class
couldn't be found, the suite wasn't successfully created. Even though
testXxxx() is executed on the server side, the exceptions it throws must be
locatable on the client side.
Todd
This message is for the designated recipient only and may contain
privileged or confidential information. If you have received it in error,
please notify the sender immediately and delete the original. Any other
use of the email by you is prohibited.
