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]
