You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Raymond Auge <ra...@liferay.com> on 2012/11/16 16:06:30 UTC
Webconsole/plugins and context path
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.
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
Re: Webconsole/plugins and context path
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am 19.11.2012 um 22:20 schrieb Raymond Auge:
> In equinox, calling:
>
> final Bundle bundle = getBundleContext().getBundle( pathInfo.bundleId );
>
> for bundleId = 0, what you get back is an instance of:
>
> org.eclipse.osgi.framework.internal.core.InternalSystemBundle
>
> which has this:
>
> /**
> * Find the specified resource in this bundle.
> * This methods returns null for the system bundle.
> */
> public URL getResource(String name) {
> return (null);
> }
>
> So, regardless of whether name represents a valid url or not, you're always
> going to get null back.
>
> Thoughts?
Hmm, this might hint at something wrong in the LicenseServlet: To find the license files the Bundle.findEntries method is used. To later access the license files, the Bundle.getResource method is used. The first method does not use the class loader while the latter does. So maybe we should really use the Bundle.getEntry method instead ?
Or even serialize and encode the full URL received from the Bundle.findEntries call and use that URL to actually access the file using the new URL(String) constructor. This may fail and a fallback may be to use new URI(String).getPath() instead and then use Bundle.getEntry:
URL url;
try {
url = new URL(pathInfo.licenseFile);
} catch (MalformedURLException e) {
String path = new URI(pathInfo.licenseFile).getPath();
url = bundle.getEntry(path);
}
WDYT ?
Regards
Felix
>
>
>
> On Mon, Nov 19, 2012 at 5:03 AM, Felix Meschberger <fm...@adobe.com>wrote:
>
>> Hi Ray,
>>
>> Am 16.11.2012 um 23:04 schrieb Raymond Auge:
>>
>>> On Fri, Nov 16, 2012 at 4:49 PM, Felix Meschberger <fmeschbe@adobe.com
>>> wrote:
>>>
>>>> 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.
>>>>
>>>
>>> I'll fill a bug.
>>
>> Thanks.
>>
>>>
>>> For reference here is a screenshot of the HTML source:
>>>
>> https://raw.github.com/rotty3000/scratchpad/master/snaps/servicegraph.png
>>>
>>>
>>>>
>>>>>
>>>>> 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) ?
>>>>
>>>
>>> I'm not really sure who is at fault since Equinox first does indeed
>> return
>>> a list of resources for:
>>>
>>> Enumeration entries = bundle.findEntries( "/", patterns[i] + "*", true );
>>>
>>> but then fails later when actually getting same:
>>>
>>> final URL resource = bundle.getResource( pathInfo.* );
>>>
>>> However, I think it's valid for the system bundle to not return
>> resources.
>>> So is it webconsole that should not be trying in the first place? Or
>>> perhaps respecting that some system bundle impls out in the wild may
>>> actually not behave the same as felix does?
>>
>> I could imagine this could be an URL interpretation issue: The
>> Bundle.findEntries method returns URLs. The LicenseServlet.findResource
>> method unly uses the path (URL.getPath()) portion of the URL to identify
>> the file. This is potentially wrong, because the URL could be anything as
>> long as it refers to the appropriate resource.
>>
>> Would you be able to validate that idea ?
>>
>> Regards
>> Felix
>>
>>>
>>> Sincerely,
>>> - Ray
>>>
>>>
>>>>
>>>> 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>
>>>>
>>>>
>>>
>>>
>>> --
>>> *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>
>>
>>
>
>
> --
> *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>
Re: Webconsole/plugins and context path
Posted by Raymond Auge <ra...@liferay.com>.
In equinox, calling:
final Bundle bundle = getBundleContext().getBundle( pathInfo.bundleId );
for bundleId = 0, what you get back is an instance of:
org.eclipse.osgi.framework.internal.core.InternalSystemBundle
which has this:
/**
* Find the specified resource in this bundle.
* This methods returns null for the system bundle.
*/
public URL getResource(String name) {
return (null);
}
So, regardless of whether name represents a valid url or not, you're always
going to get null back.
Thoughts?
On Mon, Nov 19, 2012 at 5:03 AM, Felix Meschberger <fm...@adobe.com>wrote:
> Hi Ray,
>
> Am 16.11.2012 um 23:04 schrieb Raymond Auge:
>
> > On Fri, Nov 16, 2012 at 4:49 PM, Felix Meschberger <fmeschbe@adobe.com
> >wrote:
> >
> >> 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.
> >>
> >
> > I'll fill a bug.
>
> Thanks.
>
> >
> > For reference here is a screenshot of the HTML source:
> >
> https://raw.github.com/rotty3000/scratchpad/master/snaps/servicegraph.png
> >
> >
> >>
> >>>
> >>> 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) ?
> >>
> >
> > I'm not really sure who is at fault since Equinox first does indeed
> return
> > a list of resources for:
> >
> > Enumeration entries = bundle.findEntries( "/", patterns[i] + "*", true );
> >
> > but then fails later when actually getting same:
> >
> > final URL resource = bundle.getResource( pathInfo.* );
> >
> > However, I think it's valid for the system bundle to not return
> resources.
> > So is it webconsole that should not be trying in the first place? Or
> > perhaps respecting that some system bundle impls out in the wild may
> > actually not behave the same as felix does?
>
> I could imagine this could be an URL interpretation issue: The
> Bundle.findEntries method returns URLs. The LicenseServlet.findResource
> method unly uses the path (URL.getPath()) portion of the URL to identify
> the file. This is potentially wrong, because the URL could be anything as
> long as it refers to the appropriate resource.
>
> Would you be able to validate that idea ?
>
> Regards
> Felix
>
> >
> > Sincerely,
> > - Ray
> >
> >
> >>
> >> 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>
> >>
> >>
> >
> >
> > --
> > *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>
>
>
--
*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>
Re: Webconsole/plugins and context path
Posted by Felix Meschberger <fm...@adobe.com>.
Hi Ray,
Am 16.11.2012 um 23:04 schrieb Raymond Auge:
> On Fri, Nov 16, 2012 at 4:49 PM, Felix Meschberger <fm...@adobe.com>wrote:
>
>> 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.
>>
>
> I'll fill a bug.
Thanks.
>
> For reference here is a screenshot of the HTML source:
> https://raw.github.com/rotty3000/scratchpad/master/snaps/servicegraph.png
>
>
>>
>>>
>>> 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) ?
>>
>
> I'm not really sure who is at fault since Equinox first does indeed return
> a list of resources for:
>
> Enumeration entries = bundle.findEntries( "/", patterns[i] + "*", true );
>
> but then fails later when actually getting same:
>
> final URL resource = bundle.getResource( pathInfo.* );
>
> However, I think it's valid for the system bundle to not return resources.
> So is it webconsole that should not be trying in the first place? Or
> perhaps respecting that some system bundle impls out in the wild may
> actually not behave the same as felix does?
I could imagine this could be an URL interpretation issue: The Bundle.findEntries method returns URLs. The LicenseServlet.findResource method unly uses the path (URL.getPath()) portion of the URL to identify the file. This is potentially wrong, because the URL could be anything as long as it refers to the appropriate resource.
Would you be able to validate that idea ?
Regards
Felix
>
> Sincerely,
> - Ray
>
>
>>
>> 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>
>>
>>
>
>
> --
> *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>
Re: Webconsole/plugins and context path
Posted by Raymond Auge <ra...@liferay.com>.
On Fri, Nov 16, 2012 at 4:49 PM, Felix Meschberger <fm...@adobe.com>wrote:
> 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.
>
I'll fill a bug.
For reference here is a screenshot of the HTML source:
https://raw.github.com/rotty3000/scratchpad/master/snaps/servicegraph.png
>
> >
> > 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) ?
>
I'm not really sure who is at fault since Equinox first does indeed return
a list of resources for:
Enumeration entries = bundle.findEntries( "/", patterns[i] + "*", true );
but then fails later when actually getting same:
final URL resource = bundle.getResource( pathInfo.* );
However, I think it's valid for the system bundle to not return resources.
So is it webconsole that should not be trying in the first place? Or
perhaps respecting that some system bundle impls out in the wild may
actually not behave the same as felix does?
Sincerely,
- Ray
>
> 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>
>
>
--
*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>
Re: Webconsole/plugins and context path
Posted by Felix Meschberger <fm...@adobe.com>.
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 <fm...@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>
Re: Webconsole/plugins and context path
Posted by Raymond Auge <ra...@liferay.com>.
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.
For 2) I'm not really sure what to do with that. Any suggestions?
Thanks,
- Ray
On Fri, Nov 16, 2012 at 11:18 AM, Felix Meschberger <fm...@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>
Re: Webconsole/plugins and context path
Posted by Felix Meschberger <fm...@adobe.com>.
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