You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cactus-dev@jakarta.apache.org by Lesiecki Nicholas <nd...@yahoo.com> on 2003/07/07 17:54:52 UTC
Moving UniqueId to the server side
Hi,
--- Christopher Lenz <cm...@gmx.de> 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.
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.
Of course, there may be problems with synching on the application context.
What do you guys think?
Cheers,
Nick
--- Christopher Lenz <cm...@gmx.de> wrote:
> Hi Nick,
>
> 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 :-)
>
> Of course that's just theory, and I have no good idea how to test
> this... there are just so many factors (JVM memory model, OS scheduling
> latency, ...).
>
> 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.
>
> Nicholas Lesiecki wrote:
> > Hi all,
> >
> > Does anyone have any ideas about how to integration test the unique id
> > functionality? Essentially it will be known to work when two test
> results
> > are never confused in a multi-threaded/multi-JVM environment. This
> happened
> > to me all the time when running FilterTestCases at eBlox. I am,
> however, not
> > sure why, or under what exact circumstances the behavior could be
> > reproduced. Does anyone have any suggestions as to what I should write?
> >
> > Cheers,
> > nick
>
> --
> Christopher Lenz
> /=/ cmlenz at gmx.de
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: Mavenizing!
Posted by Julien Dubois <ju...@julien-dubois.com>.
Hello everybody,
3 things concerning Maven :
1. CVS access
I can't do a "cvs add" as I've got no write access. At least that's the error
message I got.
So I put my new files here : http://www.julien-dubois.com/jakarta-cactus/
So I just did this (attached) mostly worthless patch.
I'm using Cervisia (it's the default CVS GUI embedded into Konqueror) to
create the patch. Tell me if it's working ok.
2. Building the documentation
I can't generate the documentation with the current navigation.xml files.
Using the Maven/xdocs format, they should be like this :
http://picocontainer.cvs.codehaus.org/viewcvs.cgi/*checkout*/pico/xdocs/
navigation.xml?content-type=text%2Fplain&rev=1.26&root=picocontainer
IMHO, we should copy the current navigation.xml files to some
navigation-cactus.xml files, and do a search'n replace in the current Ant
code.
Then we'll be able to have normal navigation.xml files.
I'll do them, no problem, I did many of those last week at work.
3. Testing & mock objects
With my current Maven files, some of the tests will not run. I know it, I've
got to learn how to use Mock objects first. Because for the moment I've got
no idea how this is supposed to work. I'll learn that this week.
Julien.
Re: Mavenizing!
Posted by Christopher Lenz <cm...@gmx.de>.
Julien Dubois wrote:
> Hi guys,
>
> I was following your Clover discussion : we'll also need a license for the
> maven-clover-plugin.
>
> Vincent : can you create empty files (project.xml, project.properties,
> maven.xml) in all the samples/ and integration/ subprojects?
> I'll then be able to send you some patches.
Please not that you can inlude new files in your patch. You just need to
"cvs add" them, and then run "cvs diff -N -u" (where the -N option means
"include new files").
The only scenario where this does not work is if you need new
directories, which need to be present in CVS and thus require you to
have write access to the repo. But IIUC there is no need for new
directories here, so the normal patch-creation procedure should be enough.
--
Christopher Lenz
/=/ cmlenz at gmx.d
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: Mavenizing!
Posted by Christopher Lenz <cm...@gmx.de>.
Julien Dubois wrote:
> Hi guys,
>
> I was following your Clover discussion : we'll also need a license for the
> maven-clover-plugin.
>
> Vincent : can you create empty files (project.xml, project.properties,
> maven.xml) in all the samples/ and integration/ subprojects?
> I'll then be able to send you some patches.
Please not that you can inlude new files in your patch. You just need to
"cvs add" them, and then run "cvs diff -N -u" (where the -N option means
"include new files").
The only scenario where this does not work is if you need new
directories, which need to be present in CVS and thus require you to
have write access to the repo. But IIUC there is no need for new
directories here, so the normal patch-creation procedure should be enough.
--
Christopher Lenz
/=/ cmlenz at gmx.d
RE: Mavenizing!
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: Julien Dubois [mailto:julien@julien-dubois.com]
> Sent: 27 September 2003 12:56
> To: Cactus Developers List
> Subject: Mavenizing!
>
> Hi guys,
>
> I was following your Clover discussion : we'll also need a license for
the
> maven-clover-plugin.
We have one already... I'm sending the jar to you by private email. Just
drop it in your ANTHOME/lib directory. That said you don't need to use
it to build cactus unless you use the top level "ant release" target or
you turn clovering on.
>
> Vincent : can you create empty files (project.xml, project.properties,
> maven.xml) in all the samples/ and integration/ subprojects?
> I'll then be able to send you some patches.
Julien, can you send us the full files by email to the cactus dev
mailing lists. We'll then commit them and you will then be able to send
patches against them.
Thanks
-Vincent
>
> Julien.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: Mavenizing!
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: Julien Dubois [mailto:julien@julien-dubois.com]
> Sent: 27 September 2003 12:56
> To: Cactus Developers List
> Subject: Mavenizing!
>
> Hi guys,
>
> I was following your Clover discussion : we'll also need a license for
the
> maven-clover-plugin.
We have one already... I'm sending the jar to you by private email. Just
drop it in your ANTHOME/lib directory. That said you don't need to use
it to build cactus unless you use the top level "ant release" target or
you turn clovering on.
>
> Vincent : can you create empty files (project.xml, project.properties,
> maven.xml) in all the samples/ and integration/ subprojects?
> I'll then be able to send you some patches.
Julien, can you send us the full files by email to the cactus dev
mailing lists. We'll then commit them and you will then be able to send
patches against them.
Thanks
-Vincent
>
> Julien.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Mavenizing!
Posted by Julien Dubois <ju...@julien-dubois.com>.
Hi guys,
I was following your Clover discussion : we'll also need a license for the
maven-clover-plugin.
Vincent : can you create empty files (project.xml, project.properties,
maven.xml) in all the samples/ and integration/ subprojects?
I'll then be able to send you some patches.
Julien.
Mavenizing!
Posted by Julien Dubois <ju...@julien-dubois.com>.
Hi guys,
I was following your Clover discussion : we'll also need a license for the
maven-clover-plugin.
Vincent : can you create empty files (project.xml, project.properties,
maven.xml) in all the samples/ and integration/ subprojects?
I'll then be able to send you some patches.
Julien.
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: Clover?
Posted by Christopher Lenz <cm...@gmx.de>.
Vincent Massol wrote:
> Hi Nick,
>
> You don't see the value because we're still missing the important bit
> which is to automatically fail the build when the coverage percentage is
> below a threshold. We'll get there one day :-
>
> OTOH, I use Clover from time to time to tell me where tests should be
> written. I don't look often but I like to have it when I need it.
I also use the clover reports from time to time... but they should be
optional in the build process. I actually believe they are *optional*, and
we have a flag (clover.enable) to enable it. Doesn't that flag work?
> I do agree we could possibly do without the web reports. However, that
> only costs some space on the web server. I'd be okay to remove the
> clover reports from the zip distribution though because they're taking
> so much space.
+1. We could actually hardwire the link in the docs to the online version,
to avoid a broken link in the local docs.
> WRT the license we have a license for Cactus and I can send you the
> clover jar for Cactus if you wish.
Yeah. When I started working on Cactus, I simply dropped the Clover guys a
mail [1], and told them I was committer on the project (with something like
a link to the contributors page as proof). I got back a link for downloading
a team licenced version in (almost) no time. I guess we could just forward
that link to you privately.
-chris
[1] I see they now have a form for the process:
http://www.thecortex.net/clover/freelicense.jsp
> Thanks
> -Vincent
>
>>-----Original Message-----
>>From: Nicholas Lesiecki [mailto:ndlesiecki@yahoo.com]
>>Sent: 25 September 2003 08:30
>>To: Cactus Developers List
>>Subject: Clover?
>>
>>As you all know, I am a big proponent of advanced testing techniques.
>>(Heh,
>>I guess anyone following this list probably is.) So, on the whole, I
>
> like
>
>>the idea of Clover. However, I'd like to raise the question of whether
>
> we
>
>>think it's providing enough benefit to the development effort to
>
> justify
>
>>its
>>continued existence in our build process. (Much in the spirit of Chris
>>questioning AspectJ's contribution to the project.)
>>
>>Do we look at the clover reports often? Do our users use them? Do they
>>help
>>us increase our code coverage? Or are we ignoring them? I ask because
>
> I
>
>>don't have a clear idea of the benefits, only of the cost, which is
>
> the
>
>>frustration of trying to turn the dratted thing off in the build
>
> script.
>
>>(Why am I trying to turn it off?--Because I don't have a
>
> license...another
>
>>problem though you all may have a good solution to it.) Clover also
>
> adds
>
>>to
>>the build's general complexity.
>>
>>So what do the developers think? Is it pulling its weight?
>>
>>
>>Cheers,
>>Nick
>>
>>P.S. I won't argue with the conclusions, I just want to raise the
>>question.
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: Clover?
Posted by Christopher Lenz <cm...@gmx.de>.
Vincent Massol wrote:
> Hi Nick,
>
> You don't see the value because we're still missing the important bit
> which is to automatically fail the build when the coverage percentage is
> below a threshold. We'll get there one day :-
>
> OTOH, I use Clover from time to time to tell me where tests should be
> written. I don't look often but I like to have it when I need it.
I also use the clover reports from time to time... but they should be
optional in the build process. I actually believe they are *optional*, and
we have a flag (clover.enable) to enable it. Doesn't that flag work?
> I do agree we could possibly do without the web reports. However, that
> only costs some space on the web server. I'd be okay to remove the
> clover reports from the zip distribution though because they're taking
> so much space.
+1. We could actually hardwire the link in the docs to the online version,
to avoid a broken link in the local docs.
> WRT the license we have a license for Cactus and I can send you the
> clover jar for Cactus if you wish.
Yeah. When I started working on Cactus, I simply dropped the Clover guys a
mail [1], and told them I was committer on the project (with something like
a link to the contributors page as proof). I got back a link for downloading
a team licenced version in (almost) no time. I guess we could just forward
that link to you privately.
-chris
[1] I see they now have a form for the process:
http://www.thecortex.net/clover/freelicense.jsp
> Thanks
> -Vincent
>
>>-----Original Message-----
>>From: Nicholas Lesiecki [mailto:ndlesiecki@yahoo.com]
>>Sent: 25 September 2003 08:30
>>To: Cactus Developers List
>>Subject: Clover?
>>
>>As you all know, I am a big proponent of advanced testing techniques.
>>(Heh,
>>I guess anyone following this list probably is.) So, on the whole, I
>
> like
>
>>the idea of Clover. However, I'd like to raise the question of whether
>
> we
>
>>think it's providing enough benefit to the development effort to
>
> justify
>
>>its
>>continued existence in our build process. (Much in the spirit of Chris
>>questioning AspectJ's contribution to the project.)
>>
>>Do we look at the clover reports often? Do our users use them? Do they
>>help
>>us increase our code coverage? Or are we ignoring them? I ask because
>
> I
>
>>don't have a clear idea of the benefits, only of the cost, which is
>
> the
>
>>frustration of trying to turn the dratted thing off in the build
>
> script.
>
>>(Why am I trying to turn it off?--Because I don't have a
>
> license...another
>
>>problem though you all may have a good solution to it.) Clover also
>
> adds
>
>>to
>>the build's general complexity.
>>
>>So what do the developers think? Is it pulling its weight?
>>
>>
>>Cheers,
>>Nick
>>
>>P.S. I won't argue with the conclusions, I just want to raise the
>>question.
RE: Clover?
Posted by Vincent Massol <vm...@pivolis.com>.
Hi Nick,
You don't see the value because we're still missing the important bit
which is to automatically fail the build when the coverage percentage is
below a threshold. We'll get there one day :-
OTOH, I use Clover from time to time to tell me where tests should be
written. I don't look often but I like to have it when I need it.
I do agree we could possibly do without the web reports. However, that
only costs some space on the web server. I'd be okay to remove the
clover reports from the zip distribution though because they're taking
so much space.
WRT the license we have a license for Cactus and I can send you the
clover jar for Cactus if you wish.
Thanks
-Vincent
> -----Original Message-----
> From: Nicholas Lesiecki [mailto:ndlesiecki@yahoo.com]
> Sent: 25 September 2003 08:30
> To: Cactus Developers List
> Subject: Clover?
>
> As you all know, I am a big proponent of advanced testing techniques.
> (Heh,
> I guess anyone following this list probably is.) So, on the whole, I
like
> the idea of Clover. However, I'd like to raise the question of whether
we
> think it's providing enough benefit to the development effort to
justify
> its
> continued existence in our build process. (Much in the spirit of Chris
> questioning AspectJ's contribution to the project.)
>
> Do we look at the clover reports often? Do our users use them? Do they
> help
> us increase our code coverage? Or are we ignoring them? I ask because
I
> don't have a clear idea of the benefits, only of the cost, which is
the
> frustration of trying to turn the dratted thing off in the build
script.
> (Why am I trying to turn it off?--Because I don't have a
license...another
> problem though you all may have a good solution to it.) Clover also
adds
> to
> the build's general complexity.
>
> So what do the developers think? Is it pulling its weight?
>
>
> Cheers,
> Nick
>
> P.S. I won't argue with the conclusions, I just want to raise the
> question.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: Clover?
Posted by Vincent Massol <vm...@pivolis.com>.
Hi Nick,
You don't see the value because we're still missing the important bit
which is to automatically fail the build when the coverage percentage is
below a threshold. We'll get there one day :-
OTOH, I use Clover from time to time to tell me where tests should be
written. I don't look often but I like to have it when I need it.
I do agree we could possibly do without the web reports. However, that
only costs some space on the web server. I'd be okay to remove the
clover reports from the zip distribution though because they're taking
so much space.
WRT the license we have a license for Cactus and I can send you the
clover jar for Cactus if you wish.
Thanks
-Vincent
> -----Original Message-----
> From: Nicholas Lesiecki [mailto:ndlesiecki@yahoo.com]
> Sent: 25 September 2003 08:30
> To: Cactus Developers List
> Subject: Clover?
>
> As you all know, I am a big proponent of advanced testing techniques.
> (Heh,
> I guess anyone following this list probably is.) So, on the whole, I
like
> the idea of Clover. However, I'd like to raise the question of whether
we
> think it's providing enough benefit to the development effort to
justify
> its
> continued existence in our build process. (Much in the spirit of Chris
> questioning AspectJ's contribution to the project.)
>
> Do we look at the clover reports often? Do our users use them? Do they
> help
> us increase our code coverage? Or are we ignoring them? I ask because
I
> don't have a clear idea of the benefits, only of the cost, which is
the
> frustration of trying to turn the dratted thing off in the build
script.
> (Why am I trying to turn it off?--Because I don't have a
license...another
> problem though you all may have a good solution to it.) Clover also
adds
> to
> the build's general complexity.
>
> So what do the developers think? Is it pulling its weight?
>
>
> Cheers,
> Nick
>
> P.S. I won't argue with the conclusions, I just want to raise the
> question.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Clover?
Posted by Nicholas Lesiecki <nd...@yahoo.com>.
As you all know, I am a big proponent of advanced testing techniques. (Heh,
I guess anyone following this list probably is.) So, on the whole, I like
the idea of Clover. However, I'd like to raise the question of whether we
think it's providing enough benefit to the development effort to justify its
continued existence in our build process. (Much in the spirit of Chris
questioning AspectJ's contribution to the project.)
Do we look at the clover reports often? Do our users use them? Do they help
us increase our code coverage? Or are we ignoring them? I ask because I
don't have a clear idea of the benefits, only of the cost, which is the
frustration of trying to turn the dratted thing off in the build script.
(Why am I trying to turn it off?--Because I don't have a license...another
problem though you all may have a good solution to it.) Clover also adds to
the build's general complexity.
So what do the developers think? Is it pulling its weight?
Cheers,
Nick
P.S. I won't argue with the conclusions, I just want to raise the question.
Clover?
Posted by Nicholas Lesiecki <nd...@yahoo.com>.
As you all know, I am a big proponent of advanced testing techniques. (Heh,
I guess anyone following this list probably is.) So, on the whole, I like
the idea of Clover. However, I'd like to raise the question of whether we
think it's providing enough benefit to the development effort to justify its
continued existence in our build process. (Much in the spirit of Chris
questioning AspectJ's contribution to the project.)
Do we look at the clover reports often? Do our users use them? Do they help
us increase our code coverage? Or are we ignoring them? I ask because I
don't have a clear idea of the benefits, only of the cost, which is the
frustration of trying to turn the dratted thing off in the build script.
(Why am I trying to turn it off?--Because I don't have a license...another
problem though you all may have a good solution to it.) Clover also adds to
the build's general complexity.
So what do the developers think? Is it pulling its weight?
Cheers,
Nick
P.S. I won't argue with the conclusions, I just want to raise the question.
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: Moving UniqueId to the server side
Posted by Vincent Massol <vm...@pivolis.com>.
No worry. Take your time. This is open source. Everyone participates at
his own rhythm! :-)
Have fun,
-Vincent
> -----Original Message-----
> From: Lesiecki Nicholas [mailto:ndlesiecki@yahoo.com]
> Sent: 07 August 2003 17:19
> To: Cactus Developers List
> Subject: RE: Moving UniqueId to the server side
>
> Thanks Vincent! I hadn't thought of that. I don't know when I will get
a
> chance to work on this again. This weekend I'm visiting family, and
next
> weekend someone's visiting me... So I guess all my lobbying for being
able
> to release soon after 1.5 was a moot point. Sorry everyone :( But I'm
not
> going to give up or forget.
>
> Cheers,
> Nick
>
> --- Vincent Massol <vm...@pivolis.com> wrote:
> > Hmm... Not sure where the problem is. What I can suggest is to
verify
> > the header is correctly set. You can do that by opening a telnet
session
> > to your server and typing the GET command. You will then be able to
see
> > the headers.
> >
> > Alternatively you can probably use wget to peform the same thing.
> >
> > -Vincent
> >
> > > -----Original Message-----
> > > From: Nicholas Lesiecki [mailto:ndlesiecki@yahoo.com]
> > > Sent: 28 July 2003 09:18
> > > To: Cactus Developers List
> > > Subject: Re: Moving UniqueId to the server side
> > >
> > > 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" <cm...@gmx.de> wrote:
> > >
> > > > Lesiecki Nicholas wrote:
> > > >> Hi,
> > > >>
> > > >> --- Christopher Lenz <cm...@gmx.de> 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: cactus-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
cactus-dev-help@jakarta.apache.org
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: Moving UniqueId to the server side
Posted by Vincent Massol <vm...@pivolis.com>.
No worry. Take your time. This is open source. Everyone participates at
his own rhythm! :-)
Have fun,
-Vincent
> -----Original Message-----
> From: Lesiecki Nicholas [mailto:ndlesiecki@yahoo.com]
> Sent: 07 August 2003 17:19
> To: Cactus Developers List
> Subject: RE: Moving UniqueId to the server side
>
> Thanks Vincent! I hadn't thought of that. I don't know when I will get
a
> chance to work on this again. This weekend I'm visiting family, and
next
> weekend someone's visiting me... So I guess all my lobbying for being
able
> to release soon after 1.5 was a moot point. Sorry everyone :( But I'm
not
> going to give up or forget.
>
> Cheers,
> Nick
>
> --- Vincent Massol <vm...@pivolis.com> wrote:
> > Hmm... Not sure where the problem is. What I can suggest is to
verify
> > the header is correctly set. You can do that by opening a telnet
session
> > to your server and typing the GET command. You will then be able to
see
> > the headers.
> >
> > Alternatively you can probably use wget to peform the same thing.
> >
> > -Vincent
> >
> > > -----Original Message-----
> > > From: Nicholas Lesiecki [mailto:ndlesiecki@yahoo.com]
> > > Sent: 28 July 2003 09:18
> > > To: Cactus Developers List
> > > Subject: Re: Moving UniqueId to the server side
> > >
> > > 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" <cm...@gmx.de> wrote:
> > >
> > > > Lesiecki Nicholas wrote:
> > > >> Hi,
> > > >>
> > > >> --- Christopher Lenz <cm...@gmx.de> 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: cactus-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
cactus-dev-help@jakarta.apache.org
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: Moving UniqueId to the server side
Posted by Lesiecki Nicholas <nd...@yahoo.com>.
Thanks Vincent! I hadn't thought of that. I don't know when I will get a
chance to work on this again. This weekend I'm visiting family, and next
weekend someone's visiting me... So I guess all my lobbying for being able
to release soon after 1.5 was a moot point. Sorry everyone :( But I'm not
going to give up or forget.
Cheers,
Nick
--- Vincent Massol <vm...@pivolis.com> wrote:
> Hmm... Not sure where the problem is. What I can suggest is to verify
> the header is correctly set. You can do that by opening a telnet session
> to your server and typing the GET command. You will then be able to see
> the headers.
>
> Alternatively you can probably use wget to peform the same thing.
>
> -Vincent
>
> > -----Original Message-----
> > From: Nicholas Lesiecki [mailto:ndlesiecki@yahoo.com]
> > Sent: 28 July 2003 09:18
> > To: Cactus Developers List
> > Subject: Re: Moving UniqueId to the server side
> >
> > 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" <cm...@gmx.de> wrote:
> >
> > > Lesiecki Nicholas wrote:
> > >> Hi,
> > >>
> > >> --- Christopher Lenz <cm...@gmx.de> 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: cactus-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
>
RE: Moving UniqueId to the server side
Posted by Lesiecki Nicholas <nd...@yahoo.com>.
Thanks Vincent! I hadn't thought of that. I don't know when I will get a
chance to work on this again. This weekend I'm visiting family, and next
weekend someone's visiting me... So I guess all my lobbying for being able
to release soon after 1.5 was a moot point. Sorry everyone :( But I'm not
going to give up or forget.
Cheers,
Nick
--- Vincent Massol <vm...@pivolis.com> wrote:
> Hmm... Not sure where the problem is. What I can suggest is to verify
> the header is correctly set. You can do that by opening a telnet session
> to your server and typing the GET command. You will then be able to see
> the headers.
>
> Alternatively you can probably use wget to peform the same thing.
>
> -Vincent
>
> > -----Original Message-----
> > From: Nicholas Lesiecki [mailto:ndlesiecki@yahoo.com]
> > Sent: 28 July 2003 09:18
> > To: Cactus Developers List
> > Subject: Re: Moving UniqueId to the server side
> >
> > 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" <cm...@gmx.de> wrote:
> >
> > > Lesiecki Nicholas wrote:
> > >> Hi,
> > >>
> > >> --- Christopher Lenz <cm...@gmx.de> 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: cactus-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: Moving UniqueId to the server side
Posted by Vincent Massol <vm...@pivolis.com>.
Hmm... Not sure where the problem is. What I can suggest is to verify
the header is correctly set. You can do that by opening a telnet session
to your server and typing the GET command. You will then be able to see
the headers.
Alternatively you can probably use wget to peform the same thing.
-Vincent
> -----Original Message-----
> From: Nicholas Lesiecki [mailto:ndlesiecki@yahoo.com]
> Sent: 28 July 2003 09:18
> To: Cactus Developers List
> Subject: Re: Moving UniqueId to the server side
>
> 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" <cm...@gmx.de> wrote:
>
> > Lesiecki Nicholas wrote:
> >> Hi,
> >>
> >> --- Christopher Lenz <cm...@gmx.de> 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: cactus-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: Moving UniqueId to the server side
Posted by Vincent Massol <vm...@pivolis.com>.
Hmm... Not sure where the problem is. What I can suggest is to verify
the header is correctly set. You can do that by opening a telnet session
to your server and typing the GET command. You will then be able to see
the headers.
Alternatively you can probably use wget to peform the same thing.
-Vincent
> -----Original Message-----
> From: Nicholas Lesiecki [mailto:ndlesiecki@yahoo.com]
> Sent: 28 July 2003 09:18
> To: Cactus Developers List
> Subject: Re: Moving UniqueId to the server side
>
> 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" <cm...@gmx.de> wrote:
>
> > Lesiecki Nicholas wrote:
> >> Hi,
> >>
> >> --- Christopher Lenz <cm...@gmx.de> 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: cactus-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: Moving UniqueId to the server side
Posted by Nicholas Lesiecki <nd...@yahoo.com>.
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" <cm...@gmx.de> wrote:
> Lesiecki Nicholas wrote:
>> Hi,
>>
>> --- Christopher Lenz <cm...@gmx.de> 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: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: Moving UniqueId to the server side
Posted by Lesiecki Nicholas <nd...@yahoo.com>.
> 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.
>
My home internet connection has been wonky of late. Therfore, I can make no
gaurantees as to when I'll have a chance. Feel free to rip it out, or I
will attempt it Saturday morning.
>
> Sounds good :-)
>
> > Of course, there may be problems with synching on the application
> context.
>
> I have no idea about that...
I'll proceed with this plan then, unless I hear otherwise.
Cheers,
nick
--- Christopher Lenz <cm...@gmx.de> wrote:
> Lesiecki Nicholas wrote:
> > Hi,
> >
> > --- Christopher Lenz <cm...@gmx.de> 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...
>
> --
> Christopher Lenz
> /=/ cmlenz at gmx.de
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: Moving UniqueId to the server side
Posted by Christopher Lenz <cm...@gmx.de>.
Lesiecki Nicholas wrote:
> Hi,
>
> --- Christopher Lenz <cm...@gmx.de> 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...
--
Christopher Lenz
/=/ cmlenz at gmx.de
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org