felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@adobe.com>
Subject Re: Webconsole/plugins and context path
Date Fri, 16 Nov 2012 21:49:06 GMT
Hi,

Am 16.11.2012 um 22:36 schrieb Raymond Auge:

> Ok, thank you Felix.
> 
> Few things:
> 1) I found a bug in our request dispatcher which was causing part of the
> issue. Fixed!
> 2) Equinox explictely returns null on any attempt to get a resource from
> the system bundle, which causes the LicenseServlet to return a 404. Top
> that off by a slightly annoying way in which our portal handles 404's and
> you get a rather confusing behavior.
> 3) One of the webconsole plugins is certainly not respecting the context
> path:
> 
> org.apache.felix.servicediagnostics.plugin-0.1.1.jar
> 
> doesn't even append the webconsole servlet to some of the javascript
> libraries it's trying to load, path let alone the context path.

That surely is a bug. Would you mind creating an issue against it ? Thank you very much.

> 
> For 2) I'm not really sure what to do with that. Any suggestions?

Hmm, good question. Looking at the code, I would say that 404 for a non-existing resource
is the correct reaction. But then, the resource is generally requested by the client because
the same LicenseServlet has offered that resource to the it in the first place.

Maybe we should send back some narrative (and set some caching headers to prevent caching
that) ?

Regards
Felix

> 
> Thanks,
> - Ray
> 
> 
> On Fri, Nov 16, 2012 at 11:18 AM, Felix Meschberger <fmeschbe@adobe.com>wrote:
> 
>> Hi,
>> 
>> Am 16.11.2012 um 16:06 schrieb Raymond Auge:
>> 
>>> Since Felix has recently braught up the topic of webconsole and it's
>>> plugins, I'd like to highlight that there is a general disrespect in
>> these
>>> of the context path assigned by the host application.
>> 
>> I do not completely understand the problem. The Web Console generally is
>> registered at /system/console inside the context serving the Http Service.
>> If this context happens to be a non-root context, the Web Console is
>> registered such.
>> 
>> For example: If the Http Service is backed by the servlet context at
>> /sample/context, the Web Console is accessible at
>> /sample/context/system/console.
>> 
>> In addition the Web Console root path is configurable with /system/console
>> being the default.
>> 
>> One problem is for plugins redirecting to know the correct path. For this,
>> there exist two properties on the server side (request attribute) and the
>> client side (global JavaScript variable) indicating the root path
>> (including the servlet context path) of the Web Console and the path to the
>> plugin being called (also including the servlet context path).
>> 
>> As long as plugins use those "variables", everything is fine.
>> 
>> Does that help ?
>> 
>> Regards
>> Felix
>> 
>>> 
>>> While it's the common assumption that these are running at the root
>> context
>>> path, this limits the usability of webconsole and it's plugins in other
>>> HttpService implementations which may not place the webconsole at the
>> root.
>>> 
>>> I just wanted to bring this up in advance, as if I start opening tickets
>>> for each individiual case it's going to get noisy.
>>> 
>>> Sincerely and thank you,
>>> - Ray
>> 
>> 
> 
> 
> -- 
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> <http://twitter.com/#!/rotty3000> | Senior Software Architect | *Liferay,
> Inc.* <http://www.liferay.com>  <https://twitter.com/#!/liferay>
> 
> ---
> 
> 24-25 October 2012 |* Liferay **Spain Symposium* |
> liferay.com/spain2012<http://www.liferay.com/spain2012>
> 
> 16 November 2012 |* Liferay **Italy Symposium* |
> liferay.com/italy2012<http://www.liferay.com/italy2012>


Mime
View raw message