Attempting to test sample, test works on Resin, I get this for Tomcat:
test:
[cactus]
-----------------------------------------------------------------
[cactus] Running tests against Tomcat 4.1.24-LE-jdk14
[cactus]
-----------------------------------------------------------------
[cactus] Deleting 4 files from /tmp/cactus/tomcat4x
[cactus] Deleted 2 directories from /tmp/cactus/tomcat4x
[cactus] Couldn't find tools.jar (needed for JSP compilation)
You must either set location or path on <pathelement>
at org.apache.tools.ant.types.Path.list(Path.java:309)
at org.apache.tools.ant.types.Path.list(Path.java:320)
...
Any thoughts?
Cheers,
nick
On 6/20/03 3:54 AM, "Christopher Lenz" <[EMAIL PROTECTED]> wrote:
> Nicholas Lesiecki wrote:
>>
>>> As you said, I don't think a simpleAspectJ integration app fits too well
>>> the current Cactus landscape. I see several potential subjects related
>>> to AOP that you could work with in Cactus:
>>
>> I assume you mean any AOP sample app, not just AspectJ...
>>
>>> - decide whether it is possible to use AOP for replacing redirectors (at
>>> least in some cases)
>>
>> I'm intrigued, but puzzled by this one. How do you envision AOP doing away
>> with the need for redirectors? Where would the AOP step in?
>
> I also don't see how this could be achieved technically.
>
>>> Then of course, if you're happy to work on something that's not AOP
>>> related, there's plenty of interesting stuff on the todo page:
>>> http://jakarta.apache.org/cactus/participating/todo.html
>>
>> Yep, I'm happy to do so. (Presuming that's where the help is most needed.) I
>> think that I'd most like to tackle the concurrent tests issue and/or
>
> I'm also interested in this issue. Not to say that I want to do it myself,
> though :-)
>
> I had a prototype of this a month or two ago. Basically, what I had done was
> to add a "Token" parameter to the CALL_TEST request on the client side, with
> a pseudo-unique 32-bit ID composed from:
> - a simple (non-secure) Random
> - the client machines IP address
> - the current time
> - identity hash code of the test case object
>
> Obviously, the test results object would then be stored in the servlet
> context under that ID, and a GET_RESULTS request would need to specify the
> ID as "Token" parameter again.
>
> After a bit of work I realized that it would be better to refactor some
> parts of the redirectors and the HTTP client before adding the feature, and
> dumped the whole thing because we were (and still are :-P ) approaching a
> release.
>
> On a related note, I have added a related TODO item to the page a couple of
> days ago that hasn't been published to the web site yet (the auto-publishing
> doesn't seem to work that great yet):
>
> "Explore ways to improve the performance and design of the HTTP
> transport. Currently, each test invocation involves a new connection
> to the server. The HTTP/1.1 Keepalive feature could be used to reuse a
> single connection for all test invocations. Responses to the
> GET_RESULTS request do not need to include a body if there was no
> exception on the server-side. Possibly use custom HTTP headers to
> communicate the Cactus service parameters such as the name of the test
> class and method, instead of using query string parameters."
>
> While this is not directly related to the concurrency issue, it might have
> some impact on the design of currency support.
>
>> documentation/completion of the custom tag testing framework. (Presuming the
>
> I'd be interested to hear what you are referring to here. A search on the
> TODO page for "tag" reveals nothing :-)
>
>> replacement of redirectors with AOP is a reasonably large endeavor that
>> won't be fully tackled any time soon.)
>
> -chris
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
