Hello developers, I attempted to implement the move of the uniqueID to the server side. Naively, I attempted to set the generated results id as a header in the response to the initial CALL_TEST service. Here is my code:
(from AbstractWebTestCaller.java) private void addResultsIdHeaderToResponse(String theResultsId) { HttpServletResponse response = this.webImplicitObjects.getHttpServletResponse(); response.addHeader(HttpServiceDefinition.TEST_ID_PARAM, theResultsId); } Unfortunately, when I try to read this value on the client, it comes up as null. It seems that the connection does not register any headers as being set. (From DefaultHttpClient:) HttpURLConnection connection = callRunTest(theRequest); String resultsId = getResultsIdFromHeader(connection); GetResultsFromHeader expands to: private String getResultsIdFromHeader(HttpURLConnection theConnection) { String resultsId = theConnection.getHeaderField(HttpServiceDefinition.TEST_ID_PARAM); if (resultsId == null) { throw new IllegalStateException();//I always get this } return resultsId; } I haven't worked much with headers, is either of these two code fragments fundamentally flawed? Cheers, Nick On 7/9/03 2:11 AM, "Christopher Lenz" <[EMAIL PROTECTED]> wrote: > Lesiecki Nicholas wrote: >> Hi, >> >> --- Christopher Lenz <[EMAIL PROTECTED]> wrote: >> >>> On a related note, we are now pretty much in a feature freeze until we >>> branch out a CACTUS_15_BRANCH for maintenance. That will be done as soon >>> as we release a beta of 1.5. Until then, we should not add the Test-ID >>> functionality to CVS. We'll keep the already present UniqueGenerator, >>> but I'd like to remove the code that adds it to the request etc. We can >>> add it back later, but it'll probably look completely different anyway >>> if we implement it as a cookie generated on the server side. >> >> Ok, I can rip this all out if you like. It *will* look completely different >> once we move to the server. Again, I'd love for us to branch soon so I can >> continue the work. > > Yes, we're a couple of days away from a beta and the branch now. If you > don't have time to remove the unique ID references, I can probably do it > today or tomorrow. > >> Regarding testing the functionality: >> >>> I don't think we can do very much to really test this. We need to look >>> good and hard at the algorithm :-) There is currently only one potential >>> situation where generated IDs might clash: when they are generated on >>> the same machine (as identified by the IP-address) but on different JVMs >>> at the same time (System.currentTimeMillis() yields the same value). >>> This is pretty unlikely, and I think that by putting the identity hash >>> code of the test case instance into the mix, the resulting IDs should >>> never clash. As I noted a week or so ago, RMI uses >>> new Object().hashCode() >>> to get a host/JVM unique ID. If that works, our algorithm should be >>> pretty damn safe :-) >> >> I think all these problems will disappear once we hit the server. All I >> think we'll have to do is synchronize on the application context: >> >> synchronized(application){ >> count++; >> } >> >> (where count is a static variable in some generator class.) >> >> That way each incoming test is guaranteed to have a different id with >> respect to that application context. Since the server distributes the IDs, >> there would be no need to id the clients specifically. We could start count >> at System.currentTimeMillis() just to be on the safe side. > > Sounds good :-) > >> Of course, there may be problems with synching on the application context. > > I have no idea about that... --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]