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>
