On 02/07/2010 08:31, Andr=C3=A9 Warnier wrote:
> Christopher Schultz wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Nikita,
>>
>> On 7/1/2010 6:37 PM, Nikita Tovstoles wrote:
>>> I borrowed "sub-domain" from Google Analytics terminology. I have one=
>>> server, running one tomcat instance with one virtual host. That host =
is
>>> running one app - a JS/html widget that is embedded on multiple sites=
=2E
>>>
>>> We need to track usage per-deployment (per site embedding the wiget).=
>>> For
>>> (google) analytics purposes, the easiest way to do so is to have a
>>> different
>>> (sub)domain per deployment. So the same tomcat instance is responding=
to
>>> requests for site1.widget.com, site2.widget.com, etc.
>>>
>>> a user may interact with 2 widget deployed on 2 different sites (and
>>> thus
>>> served from different (sub)domains) within 30 minutes. It is for this=
>>> case
>>> that we want user to share the same HttpSession:
>>>
>>> - go to some site A where our widget is deployed at site1.widget.com
>>> - go to some other site B where our widget is deployed at
>>> site2.widget.com
>>> - reuse the same JSESSIONID because its' domain is set to ".widget.co=
m"
>>
>> This sounds like a job for a non-JSESSIONID cookie that is created fro=
m
>> your own code.
>>
> +1
>=20
> But I am still lost as to what you are calling "sites" and "subdomains"=
> and "deployed at site1.widget.com".
> If I follow the explanation above, you have something like this :
> <Host name=3D"localhost" appBase=3D"webapps">
> <Alias>site1.widget.com</Alias>
> <Alias>site2.widget.com</Alias>
> <Alias>site3.widget.com</Alias>
> <Alias>site4.widget.com</Alias>
> ...
> </Host>
You can omit the aliases and just rely on the defaultHost setting in
Engine to route all requests to a specific Host.
p
> Is that it ?
> And if so, where is the widget-webapp deployed (on disk), and how many
> times really ?
>=20
> I am not trying to be a pedant, just to make sure I understand the
> layout, so that we might maybe come up with a suggestion to solve your
> problem (even if it is not by changing the JSESSIONID cookie domain)
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>=20
|