Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cocoon.apache.org
From: "Carsten Ziegeler" <cziegeler@s-und-n.de>
To: <users@cocoon.apache.org>
Subject: RE: SendMailTransformer session issue
Date: Tue, 3 Aug 2004 20:42:24 +0200
Organization: S&N AG
MIME-Version: 1.0
In-Reply-To: <1091557761.2557.21.camel@localhost.localdomain>
Thread-Index: AcR5hrc8rifMz+//SyOh12DZ80rRiwAAekIw
Message-ID: <OFBE5C3F35.35E235CE-ONC1256EE5.00660760@sundn.de>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset="iso-8859-1"

=20
Rui Alberto L. Gon=E7alves wrote:
>=20
> I all,
>=20
> I need to use SendMailTransformer to send the user the=20
> current page that he/she is viewing.
> To do this, I'm doing:
>=20
> <email:sendmail>
>  ...
> <email:attachment name=3D"Your page"
>                   mime-type=3D"text/html"
>                   src=3D"cocoon:/display_user_page"/> ...
> </email:sendmail>
>=20
> I'm using cookies to identify the user session, and the=20
> target cocoon:/display_user_page uses user session values.
>=20
> It looks like SendMailTransformer ignores this and just=20
> performs an http request as another new different client!=20
> (JSESSION id cookie is not sent)
>=20
> Does anyone would like to suggest an approach to this problem?
> Thanks for any help.
> Rui
>=20
I have currently no solution for this, but I can try to=20
explain what is happening:

Usually, the cocoon protocol is resolved internally which means
if you use it, the request is handled internally and no new
http request is send. Of course, an internal request runs in
the same session as the original one.

Unfortunately, the cocoon protocol delivers by design XML, to
be more precise the XML send by the last transformer before
it is feed into the serializer.
Therefore if you want to create a PDF attachment, using the
cocoon protocol would simply fail. You wouldn't get PDF
but XSL:FO which is not what you want :(

Therefore the sendmail transformer "rewrites" the internal
cocoon protocol to an external one in order to run the correct
serializer at the end.

I think it is possible to append the session id or to add=20
a cookie to the request, but it is not the same client! It is
the server that acts now as the client. If your servlet engine
verifies this, it won't work even if you would append=20
the information.

Now, a possible solution would be to either extend or create
a new protocol that works the same way as the cocoon protocol
but doesn't always deliver XML. It would use the correct
serializer at the end and offer a byte stream instead of sax
events.

Carsten


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org