Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <432E6A38.3000807@apache.org>
Date: Mon, 19 Sep 2005 09:35:20 +0200
From: Carsten Ziegeler <cziegeler@apache.org>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: furious anger: portal broken
References: <20050916134435.GA7961@vision.anyware>
In-Reply-To: <20050916134435.GA7961@vision.anyware>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Jean-Baptiste,

please mind your tone - A subject like the one above does not really
help solving problems - and it's not the first time you're writing mails
in this form (including the ones you send privately and not to the
list). Usually I ignore such mails.
If you want help or are interested in discussing things it's much easier
for all of us if we try to solve a problem together rather than just
doing finger pointing.

The current svn is a development version, so it might happen that things
work one day and are broken the other day. Of course, bugs/problems
should be fixed in the final release. But as it is a development release
it's not required that things have to be fixed immediately. We have time
to solve problems until the final release is made (or the code freeze
starts). In addition things sometimes change and improve. For example it
took us some days to update from 2.1.7 to a recent 2.1.8-dev because
some things in CForms changed and broke our whole web application.

Ok, that's it on *that* subject (I hope), let's get into the technical
discussion:

Both, the JSR 168 and WSRP require the functionality to switch from http
to https and back. Switching the protocol is only possible with absolute
urls (for the switch itself). That's the reason why the LinkService now
creates absolute urls.
I tested the code on several applications and it works perfectly -
getServerName() returns the correct value (and not localhost) - even on
systems with virtual hosts. So the question is, is it just a
configuration matter on your side or is there a different way to detect
the current server name? If we are not able to detect the server name,
it breaks jsr 168 and wsrp.
So perhaps anyone has a better solution?

We could improve the LinkService by creating relative links if the
protocol is not changed - like it did before. So this would solve your
use case, but it would not solve the real underlying problem.


Carsten
-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/