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 <[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>
