> 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.
That sounds sensible, except that I would compose the ID of: - the current time - thread id (same test, different threads) - process id (in case the threads are running in different JVMs) - client machine IP - unique id for the test, this could be the hash code or some combination of test class, test method, and hash code > 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. Well, I'm not sure what work you were intending. Do you think I should abstain from this feature until the release? Is there a development branch I should use instead? Since I'm not as savvy with the HTTP layer as you might be, I think I'd be happy to hold off on fiddling with that, and simply add test_id as a request parameter like the others. (We can always refactor it later.) > I'd be interested to hear what you are referring to here. A search on the > TODO page for "tag" reveals nothing :-) Well, it seems like your JspTagLifecycle is the superior choice for testing custom tags. The way the current docs read, there is only a brief pointer to the Javadoc for JspTagLifecycle. The Javadoc seems very helpful, and complete. So I suggest some refactoring of the docs to give JspTagLifecycle the prominence it deserves on the Cactus homepage. After looking over the docs, I can't see anything it's missing, so scratch that second bit about "completing it". I hadn't remembered how complete it was. BTW, is there any private ZIP that you guys have of libraries that the dratted build needs? I'm chasing down required JARs all over creation. The link to "GUMP nightly builds" on the "building from source" page goes nowhere. Also, is there some set of targets I should use to: A) build cactus and run the unit tests B) build cactus, run the unit tests, and run the acceptance tests I suppose I could figure it out in an hour or so, but any pointers would be appreciated. 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]
