Bad asset resource resolving

[Bart Wulteputte <ba...@gmail.com>]

Hi all,

It seems that the way assets are resolved has changed a little. When an
asset contains an additional . (dot) it can't be resolved anymore to the
actual asset resource. e.g. /content/my.asset.pdf resolves to
/content/my.pdf rather than the expected path.

As a simple test you can copy the sling-logo.png to
/content/sling.logo.png. When now using the Sling Resolver Test - we see
that resolving /content/sling.logo.png results in a non-existing resource
with path /content/sling.png instead of the expected asset url. The section
after the first dot is now interpreted as a selector which didn't used to
be the case for assets in the past.

Was this intentionally changed or is this an actual bug?

Best regards

Bart

Re: Bad asset resource resolving

[Bart Wulteputte <ba...@gmail.com>]

Hi Stefan

I've explained myself rather poorly. I've dug into this and prepared a
example package - which I've logged under SLING-6476 to better illustrate
the issue I'm having.

2017-01-16 22:01 GMT+01:00 Stefan Seifert <ss...@pro-vision.de>:

> no, the basics of resource resolution have not change recently - a
> resource with multiple dots in it's resource name (like
> /content/sling.logo.png) should always be resolvable by this name. and it
> works as expected when i reproduce the steps you describe (copy to
> /content/sling.logo.png).
>
> i tested it with the current sling launchpad from trunk.
>
> stefan
>
>
> >-----Original Message-----
> >From: Bart Wulteputte [mailto:bart.wulteputte@gmail.com]
> >Sent: Monday, January 16, 2017 1:44 PM
> >To: users@sling.apache.org
> >Subject: Bad asset resource resolving
> >
> >Hi all,
> >
> >It seems that the way assets are resolved has changed a little. When an
> >asset contains an additional . (dot) it can't be resolved anymore to the
> >actual asset resource. e.g. /content/my.asset.pdf resolves to
> >/content/my.pdf rather than the expected path.
> >
> >As a simple test you can copy the sling-logo.png to
> >/content/sling.logo.png. When now using the Sling Resolver Test - we see
> >that resolving /content/sling.logo.png results in a non-existing resource
> >with path /content/sling.png instead of the expected asset url. The
> section
> >after the first dot is now interpreted as a selector which didn't used to
> >be the case for assets in the past.
> >
> >Was this intentionally changed or is this an actual bug?
> >
> >Best regards
> >
> >Bart
>

RE: Bad asset resource resolving

[Stefan Seifert <ss...@pro-vision.de>]

no, the basics of resource resolution have not change recently - a resource with multiple dots in it's resource name (like /content/sling.logo.png) should always be resolvable by this name. and it works as expected when i reproduce the steps you describe (copy to /content/sling.logo.png).

i tested it with the current sling launchpad from trunk.

stefan


>-----Original Message-----
>From: Bart Wulteputte [mailto:bart.wulteputte@gmail.com]
>Sent: Monday, January 16, 2017 1:44 PM
>To: users@sling.apache.org
>Subject: Bad asset resource resolving
>
>Hi all,
>
>It seems that the way assets are resolved has changed a little. When an
>asset contains an additional . (dot) it can't be resolved anymore to the
>actual asset resource. e.g. /content/my.asset.pdf resolves to
>/content/my.pdf rather than the expected path.
>
>As a simple test you can copy the sling-logo.png to
>/content/sling.logo.png. When now using the Sling Resolver Test - we see
>that resolving /content/sling.logo.png results in a non-existing resource
>with path /content/sling.png instead of the expected asset url. The section
>after the first dot is now interpreted as a selector which didn't used to
>be the case for assets in the past.
>
>Was this intentionally changed or is this an actual bug?
>
>Best regards
>
>Bart