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 <[email protected]>wrote:
> Hi Ray,
>
> Am 16.11.2012 um 23:04 schrieb Raymond Auge:
>
> > On Fri, Nov 16, 2012 at 4:49 PM, Felix Meschberger <[email protected]
> >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 <
> [email protected]
> >>> 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>
