[jira] [Commented] (SLING-6790) Enable aliases even if referenced format is disabled

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15983228#comment-15983228
 ] 

Carsten Ziegeler commented on SLING-6790:
-

The first version did not work, fixed in rev 1792634

> Enable aliases even if referenced format is disabled
> 
>
> Key: SLING-6790
> URL: https://issues.apache.org/jira/browse/SLING-6790
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Servlets Get 2.1.24
>
>
> When one of the default renderings is disabled and an alias exists for this, 
> the alias rendering is disabled as well. For example, it is common to have 
> the PDF rendering as an alias for XML (as the PDF rendering is based on using 
> an XML pipeline including XSLT to generate PDF). If XML is disabled, PDF 
> doesn't work either and right now, the only way to get PDF rendering work is 
> enabling XML as well. Which might not be what you want.
> So I think, if an alias exists - which is an explicit  configuration - this 
> should be enabled, regardless whether the underlying direct rendering is 
> disabled.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (SLING-6786) JCR Installer Provider doesn't rescan if exception happens during scan.

[Karl Pauls (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Pauls resolved SLING-6786.
---
Resolution: Fixed

I commited the patch in r1792627.

> JCR Installer Provider doesn't rescan if exception happens during scan.
> ---
>
> Key: SLING-6786
> URL: https://issues.apache.org/jira/browse/SLING-6786
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: JCR Installer 3.1.24
>Reporter: Karl Pauls
>Assignee: Karl Pauls
> Fix For: JCR Installer 3.1.26
>
> Attachments: SLING-6786.patch
>
>
> Currently, the JCR Installer Provider maintains a boolean flag needsScan 
> which is set to true on start and when an event occurs in the JCR for a given 
> watched folder. 
> Subsequently, when a scan is requested because of that flag being true, it 
> will set the flag to false at the beginning of the scan. In other words, the 
> folder will not be rescanned until either the provider is restarted or 
> something changes in the repository (indicated by an event), respectively.
> This is fine, however, it ignores the fact that an exception can occur during 
> the scan (e.g., connection is gone, etc.). If that happens, it will not 
> finish the scan but the needsScan will already be false - hence, until 
> something changes, the folder will not be rescanned. 
> The fix seems simple. The needsScan=false should be moved form the start of 
> the scan method to the end of it. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Versioning of o.a.s.xss [was move o.a.s.xss.JSONUtil into a separate package]

[Karl Pauls]

I would argue for #2 as well.

In regard to the JSONUtil, we should definitely either move it to a
different package or delete it completely (see other thread).

regards,

Karl

On Tue, Apr 25, 2017 at 4:03 PM, Justin Edelson
 wrote:
> Good point. To be clear, what I assumed #2 included moving that JSONUtil
> class to a separate package.
>
> On Tue, Apr 25, 2017 at 10:02 AM Konrad Windszus  wrote:
>
>> I am also in favour of #2 but I would strongly recommend to put JSONUtil
>> to a dedicated subpackage. Even in the new version this has a dependency
>> towards javax.json which may change in the future. If we have to do another
>> change in the future in that area, this would only affect the package with
>> the JSONUtil but not e.g. XSSApi.
>> > On 25. Apr 2017, at 14:21, Justin Edelson 
>> wrote:
>> >
>> > I think #2 is the best option of these and I can't see another reasonable
>> > path forward.
>> >
>> > Regards,
>> > Justin
>> >
>> > On Tue, Apr 25, 2017 at 8:09 AM Carsten Ziegeler 
>> > wrote:
>> >
>> >> I'm moving this into a separate thread to make the discussion easier.
>> >>
>> >> With the current state of the xss module, we would break every consumer
>> >> and require her to upgrade code (release their own modules depending on
>> >> XSS etc). As xss is pretty popular, this means a high burden on our
>> >> downstream users.
>> >>
>> >> I think we have these options:
>> >> 1) Pass on the pain to our users, simply release as 2.0.0 and require
>> >> everyone to upgrade
>> >>
>> >> 2) Release the new api as 2.0 under a different symbolic name allowing
>> >> our users to have new and old side by side. In that case we would need
>> >> to deprecate 1.x and users should upgrade over time.
>> >>
>> >> 3) Best effort: we release as 1.x and know that this is an incompatible
>> >> change. This will only break users of the old JSONUtil, everyone else
>> >> runs without any problems. Unfortunately if others are using the util,
>> >> this will only be detected at runtime.
>> >>
>> >> Are the other/better options?
>> >>
>> >> I think we should definitely not do 1)
>> >>
>> >> Carsten
>> >>
>> >> --
>> >> Carsten Ziegeler
>> >> Adobe Research Switzerland
>> >> cziege...@apache.org
>> >>
>>
>>



-- 
Karl Pauls
karlpa...@gmail.com

[jira] [Commented] (SLING-6791) Servlet Resolver Test does no longer find scripts being referenced through resource type

[Konrad Windszus (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15983008#comment-15983008
 ] 

Konrad Windszus commented on SLING-6791:


I don't find a user mapping for service resource resolver being used in 
https://github.com/apache/sling/blob/trunk/bundles/servlets/resolver/src/main/java/org/apache/sling/servlets/resolver/internal/SlingServletResolver.java#L1184.
 So most probably this is broken by SLING-5237. [~cziegeler] Can you have a 
look?

> Servlet Resolver Test does no longer find scripts being referenced through 
> resource type
> 
>
> Key: SLING-6791
> URL: https://issues.apache.org/jira/browse/SLING-6791
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Resolver 2.4.10
>Reporter: Konrad Windszus
>
> When using the latest launchpad (including Slingshot), going to 
> /system/console/servletresolver?url=%2Fslingshot%2Fusers%2Fslingshot1.html=GET
>  shows as candidates only
> {code}
> org.apache.sling.servlets.get.impl.DefaultGetServlet
> org.apache.sling.jcr.webdav.impl.servlets.SlingWebDavServlet
> {code}
> This is wrong, the script for rendering this is actually at 
> {{/libs/slingshot/User/html.jsp}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-3270) html-generator to support html5

[Jason E Bailey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-3270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason E Bailey updated SLING-3270:
--
Attachment: 218.patch

To fully support HTML5 you would need to do something like the referenced 
Univeristy of Warwick repo. I'm reluctant to do that without fully 
understanding all of the potential changes involved. Additionally, while 
reviewing the tagsoup codebase it does look like there's room to improve the 
overall efficiency of this library. Both cases would assume pulling in this 
parser into Sling for maintenance. I've attached what I consider the smallest 
change possible which will support the HTML5 version of the 'a' tag. This is 
generated from the github pr.

> html-generator to support html5
> ---
>
> Key: SLING-3270
> URL: https://issues.apache.org/jira/browse/SLING-3270
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Rewriter 1.0.2
>Reporter: Jason E Bailey
> Attachments: 218.patch
>
>
> Given the following fragment of HTML
> 
> This is invalid html4 and valid html5, as html5 allows anchor tags to contain 
> block elements.
> The current html-generator corrects the bad html4 and produces the following 
> output
> 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (SLING-6791) Servlet Resolver Test does no longer find scripts being referenced through resource type

[Konrad Windszus (JIRA)]

Konrad Windszus created SLING-6791:
--

 Summary: Servlet Resolver Test does no longer find scripts being 
referenced through resource type
 Key: SLING-6791
 URL: https://issues.apache.org/jira/browse/SLING-6791
 Project: Sling
  Issue Type: Bug
  Components: Servlets
Affects Versions: Servlets Resolver 2.4.10
Reporter: Konrad Windszus


When using the latest launchpad (including Slingshot), going to 
/system/console/servletresolver?url=%2Fslingshot%2Fusers%2Fslingshot1.html=GET
 shows as candidates only
{code}
org.apache.sling.servlets.get.impl.DefaultGetServlet
org.apache.sling.jcr.webdav.impl.servlets.SlingWebDavServlet
{code}

This is wrong, the script for rendering this is actually at 
{{/libs/slingshot/User/html.jsp}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] sling pull request #218: sling-3270 minimal extension of the anchor tag

[JEBailey]

GitHub user JEBailey opened a pull request:

https://github.com/apache/sling/pull/218

sling-3270 minimal extension of the anchor tag

allows the anchor tag to wrap additional content. this will address the 
most common issue being reported with using tagsoup and html5

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/JEBailey/sling sling-3270

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/218.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #218


commit a331cc91101d47fc1f50ebb9fa9e7fd76ed8e195
Author: jabail 
Date:   2017-04-25T14:02:23Z

sling-3270 minimal extension of the anchor tag

allows the anchor tag to wrap additional content.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] sling pull request #217: sling-3270 minimal extension of the anchor tag

[JEBailey]

Github user JEBailey closed the pull request at:

https://github.com/apache/sling/pull/217


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] sling pull request #217: aem-3270 minimal extension of the anchor tag

[JEBailey]

GitHub user JEBailey opened a pull request:

https://github.com/apache/sling/pull/217

aem-3270 minimal extension of the anchor tag

allows the anchor tag to wrap content. This will address the largest 
reported issue when it comes to tagsoup and HTML5 content.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/JEBailey/sling sling-3270

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/217.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #217


commit 15b58629630cf5ffd7d852f8c6da7c7452e03c0c
Author: jabail 
Date:   2017-04-25T14:02:23Z

aem-3270 minimal extension of the anchor tag

allows the anchor tag to wrap additional content.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Versioning of o.a.s.xss [was move o.a.s.xss.JSONUtil into a separate package]

[Justin Edelson]

Good point. To be clear, what I assumed #2 included moving that JSONUtil
class to a separate package.

On Tue, Apr 25, 2017 at 10:02 AM Konrad Windszus  wrote:

> I am also in favour of #2 but I would strongly recommend to put JSONUtil
> to a dedicated subpackage. Even in the new version this has a dependency
> towards javax.json which may change in the future. If we have to do another
> change in the future in that area, this would only affect the package with
> the JSONUtil but not e.g. XSSApi.
> > On 25. Apr 2017, at 14:21, Justin Edelson 
> wrote:
> >
> > I think #2 is the best option of these and I can't see another reasonable
> > path forward.
> >
> > Regards,
> > Justin
> >
> > On Tue, Apr 25, 2017 at 8:09 AM Carsten Ziegeler 
> > wrote:
> >
> >> I'm moving this into a separate thread to make the discussion easier.
> >>
> >> With the current state of the xss module, we would break every consumer
> >> and require her to upgrade code (release their own modules depending on
> >> XSS etc). As xss is pretty popular, this means a high burden on our
> >> downstream users.
> >>
> >> I think we have these options:
> >> 1) Pass on the pain to our users, simply release as 2.0.0 and require
> >> everyone to upgrade
> >>
> >> 2) Release the new api as 2.0 under a different symbolic name allowing
> >> our users to have new and old side by side. In that case we would need
> >> to deprecate 1.x and users should upgrade over time.
> >>
> >> 3) Best effort: we release as 1.x and know that this is an incompatible
> >> change. This will only break users of the old JSONUtil, everyone else
> >> runs without any problems. Unfortunately if others are using the util,
> >> this will only be detected at runtime.
> >>
> >> Are the other/better options?
> >>
> >> I think we should definitely not do 1)
> >>
> >> Carsten
> >>
> >> --
> >> Carsten Ziegeler
> >> Adobe Research Switzerland
> >> cziege...@apache.org
> >>
>
>

Re: Versioning of o.a.s.xss [was move o.a.s.xss.JSONUtil into a separate package]

[Konrad Windszus]

I am also in favour of #2 but I would strongly recommend to put JSONUtil to a 
dedicated subpackage. Even in the new version this has a dependency towards 
javax.json which may change in the future. If we have to do another change in 
the future in that area, this would only affect the package with the JSONUtil 
but not e.g. XSSApi.
> On 25. Apr 2017, at 14:21, Justin Edelson  wrote:
> 
> I think #2 is the best option of these and I can't see another reasonable
> path forward.
> 
> Regards,
> Justin
> 
> On Tue, Apr 25, 2017 at 8:09 AM Carsten Ziegeler 
> wrote:
> 
>> I'm moving this into a separate thread to make the discussion easier.
>> 
>> With the current state of the xss module, we would break every consumer
>> and require her to upgrade code (release their own modules depending on
>> XSS etc). As xss is pretty popular, this means a high burden on our
>> downstream users.
>> 
>> I think we have these options:
>> 1) Pass on the pain to our users, simply release as 2.0.0 and require
>> everyone to upgrade
>> 
>> 2) Release the new api as 2.0 under a different symbolic name allowing
>> our users to have new and old side by side. In that case we would need
>> to deprecate 1.x and users should upgrade over time.
>> 
>> 3) Best effort: we release as 1.x and know that this is an incompatible
>> change. This will only break users of the old JSONUtil, everyone else
>> runs without any problems. Unfortunately if others are using the util,
>> this will only be detected at runtime.
>> 
>> Are the other/better options?
>> 
>> I think we should definitely not do 1)
>> 
>> Carsten
>> 
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
>> 

Re: Versioning of o.a.s.xss [was move o.a.s.xss.JSONUtil into a separate package]

[Justin Edelson]

I think #2 is the best option of these and I can't see another reasonable
path forward.

Regards,
Justin

On Tue, Apr 25, 2017 at 8:09 AM Carsten Ziegeler 
wrote:

> I'm moving this into a separate thread to make the discussion easier.
>
> With the current state of the xss module, we would break every consumer
> and require her to upgrade code (release their own modules depending on
> XSS etc). As xss is pretty popular, this means a high burden on our
> downstream users.
>
> I think we have these options:
> 1) Pass on the pain to our users, simply release as 2.0.0 and require
> everyone to upgrade
>
> 2) Release the new api as 2.0 under a different symbolic name allowing
> our users to have new and old side by side. In that case we would need
> to deprecate 1.x and users should upgrade over time.
>
> 3) Best effort: we release as 1.x and know that this is an incompatible
> change. This will only break users of the old JSONUtil, everyone else
> runs without any problems. Unfortunately if others are using the util,
> this will only be detected at runtime.
>
> Are the other/better options?
>
> I think we should definitely not do 1)
>
>  Carsten
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

Versioning of o.a.s.xss [was move o.a.s.xss.JSONUtil into a separate package]

[Carsten Ziegeler]

I'm moving this into a separate thread to make the discussion easier.

With the current state of the xss module, we would break every consumer
and require her to upgrade code (release their own modules depending on
XSS etc). As xss is pretty popular, this means a high burden on our
downstream users.

I think we have these options:
1) Pass on the pain to our users, simply release as 2.0.0 and require
everyone to upgrade

2) Release the new api as 2.0 under a different symbolic name allowing
our users to have new and old side by side. In that case we would need
to deprecate 1.x and users should upgrade over time.

3) Best effort: we release as 1.x and know that this is an incompatible
change. This will only break users of the old JSONUtil, everyone else
runs without any problems. Unfortunately if others are using the util,
this will only be detected at runtime.

Are the other/better options?

I think we should definitely not do 1)

 Carsten

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

RE: move o.a.s.xss.JSONUtil into a separate package

[Stefan Seifert]

>> I was thinking about that too: why not just drop it completely.
>
>I think we should remove it - see my reply to Stefan.

+1 from my side - we can always add it later.

stefan 

Re: move o.a.s.xss.JSONUtil into a separate package

[Karl Pauls]

>>> Do we need this util class in the api at all? (I have no idea, but just
>>> asking the obvious question)
>>
>> I was thinking about that too: why not just drop it completely.
>
> I think we should remove it - see my reply to Stefan.

+1

regards,

Karl

> Regards
> Carsten

> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org



-- 
Karl Pauls
karlpa...@gmail.com

Re: move o.a.s.xss.JSONUtil into a separate package

[Carsten Ziegeler]

Karl Pauls wrote
> On Tue, Apr 25, 2017 at 1:34 PM, Carsten Ziegeler  
> wrote:
>> Karl Pauls wrote
>>> Hi,
>>>
>>> as discussed with Stefan Seifert on SLING-6685, we would like to move
>>> the JSONUtil class out of the o.a.s.xss package into a separate sub
>>> package (o.a.s.xss.json).
>>>
>>> Right now, it introduces a dependency on the javax.json package for
>>> the o.a.s.xss package. That is the reason we have to bump the version
>>> to 2.0.0 due to the commons.json removable. If we move it into its own
>>> package we wouldn't have to do that if we every switch json providers
>>> again :-).
>>>
>>> As we are bumping the major version anyways, I don't think this is a
>>> big deal - hence, I'm calling for lazy consensus (in other words, if
>>> you object, speak up now).
>>>
>> Do we need this util class in the api at all? (I have no idea, but just
>> asking the obvious question)
> 
> I was thinking about that too: why not just drop it completely.

I think we should remove it - see my reply to Stefan.

Regards
Carsten

> 
> I would actually be in favour of that but at the same time, we already
> kind of pull the rug out from under commons.json users (no deprecation
> etc.)
> so I figured it might be nicer to first move it to a separate package
> with the update to javax.json and maybe deprecate
> it there and drop the package in the future...
> 
>> If yes, moving it to a separate package and maybe naming either the
>> package or the class in a way that it is clear that this is bound to
>> javax.json and not a general purpose json util sounds like the right
>> thing to do.
> 
> I'm well known for being terrible in naming things - hence, if you
> have a good name that sounds like a good idea. Otherwise, I'll stick
> with xss.json :-)
> 
>> I understand that for semantic versioning we have to increase the major
>> version of the api. How do we deal with all the code out there currently
>> importing 1.x? Can we find a way that does not require everyone to
>> change her code?
> 
> Well, that be hard as we don't know if they actually use the JSONUtil
> class or not (thats why I want to at a minimum move the JSONUtil out
> of the xss package so that this doesn't happen again). However, if you
> have a good idea I'm all ears.
> 
> regards,
> 
> Karl
> 
>> Regards
>>
>>  Carsten
>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
> 
> 
> 


 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: move o.a.s.xss.JSONUtil into a separate package

[Carsten Ziegeler]

Stefan Seifert wrote
> 
>> Do we need this util class in the api at all? (I have no idea, but just
>> asking the obvious question)
> 
> perhaps not, but a lot of existing code outside there may use it. and 
> providing an alternative on javax.json is perhaps easier to migrate to than 
> completely removing it.
> 
Users have to migrate and they might want to migrate to a different json
library than we suggest. Given the number of choices out there having a
util class for just one is imho not worth the effort.

I think we should agree on whether we want a new json util class first,
then we can look at the versioning problem.

Regards
Carsten

> 
>> I understand that for semantic versioning we have to increase the major
>> version of the api. How do we deal with all the code out there currently
>> importing 1.x? Can we find a way that does not require everyone to
>> change her code?
> 
> if other classes except JSONUtil are used it's a drop-in replacement, just a 
> recompile against the latest package version is needed (or a relaxed import 
> statement for both major versions). but this still is of course a complex 
> tasks if a lot of bundles depend on the old major version.
> 
> we might change the symbolic name of the new xss bundle to allow parallel 
> deployment of old and new implementation.
> 
> stefan 
> 


 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: move o.a.s.xss.JSONUtil into a separate package

[Karl Pauls]

On Tue, Apr 25, 2017 at 1:53 PM, Stefan Seifert  wrote:
>
>>Do we need this util class in the api at all? (I have no idea, but just
>>asking the obvious question)
>
> perhaps not, but a lot of existing code outside there may use it. and 
> providing an alternative on javax.json is perhaps easier to migrate to than 
> completely removing it.
>
>
>>I understand that for semantic versioning we have to increase the major
>>version of the api. How do we deal with all the code out there currently
>>importing 1.x? Can we find a way that does not require everyone to
>>change her code?
>
> if other classes except JSONUtil are used it's a drop-in replacement, just a 
> recompile against the latest package version is needed (or a relaxed import 
> statement for both major versions). but this still is of course a complex 
> tasks if a lot of bundles depend on the old major version.
>
> we might change the symbolic name of the new xss bundle to allow parallel 
> deployment of old and new implementation.

Well, technically, that isn't needed from an OSGi perspective but it
might make things easier for Sling users given how things currently
work wrt. the installer etc.

regards,

Karl

> stefan
>



-- 
Karl Pauls
karlpa...@gmail.com

Re: move o.a.s.xss.JSONUtil into a separate package

[Karl Pauls]

On Tue, Apr 25, 2017 at 1:34 PM, Carsten Ziegeler  wrote:
> Karl Pauls wrote
>> Hi,
>>
>> as discussed with Stefan Seifert on SLING-6685, we would like to move
>> the JSONUtil class out of the o.a.s.xss package into a separate sub
>> package (o.a.s.xss.json).
>>
>> Right now, it introduces a dependency on the javax.json package for
>> the o.a.s.xss package. That is the reason we have to bump the version
>> to 2.0.0 due to the commons.json removable. If we move it into its own
>> package we wouldn't have to do that if we every switch json providers
>> again :-).
>>
>> As we are bumping the major version anyways, I don't think this is a
>> big deal - hence, I'm calling for lazy consensus (in other words, if
>> you object, speak up now).
>>
> Do we need this util class in the api at all? (I have no idea, but just
> asking the obvious question)

I was thinking about that too: why not just drop it completely.

I would actually be in favour of that but at the same time, we already
kind of pull the rug out from under commons.json users (no deprecation
etc.)
so I figured it might be nicer to first move it to a separate package
with the update to javax.json and maybe deprecate
it there and drop the package in the future...

> If yes, moving it to a separate package and maybe naming either the
> package or the class in a way that it is clear that this is bound to
> javax.json and not a general purpose json util sounds like the right
> thing to do.

I'm well known for being terrible in naming things - hence, if you
have a good name that sounds like a good idea. Otherwise, I'll stick
with xss.json :-)

> I understand that for semantic versioning we have to increase the major
> version of the api. How do we deal with all the code out there currently
> importing 1.x? Can we find a way that does not require everyone to
> change her code?

Well, that be hard as we don't know if they actually use the JSONUtil
class or not (thats why I want to at a minimum move the JSONUtil out
of the xss package so that this doesn't happen again). However, if you
have a good idea I'm all ears.

regards,

Karl

> Regards
>
>  Carsten
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org



-- 
Karl Pauls
karlpa...@gmail.com

RE: move o.a.s.xss.JSONUtil into a separate package

[Stefan Seifert]

>Do we need this util class in the api at all? (I have no idea, but just
>asking the obvious question)

perhaps not, but a lot of existing code outside there may use it. and providing 
an alternative on javax.json is perhaps easier to migrate to than completely 
removing it.


>I understand that for semantic versioning we have to increase the major
>version of the api. How do we deal with all the code out there currently
>importing 1.x? Can we find a way that does not require everyone to
>change her code?

if other classes except JSONUtil are used it's a drop-in replacement, just a 
recompile against the latest package version is needed (or a relaxed import 
statement for both major versions). but this still is of course a complex tasks 
if a lot of bundles depend on the old major version.

we might change the symbolic name of the new xss bundle to allow parallel 
deployment of old and new implementation.

stefan 

Re: move o.a.s.xss.JSONUtil into a separate package

[Carsten Ziegeler]

Karl Pauls wrote
> Hi,
> 
> as discussed with Stefan Seifert on SLING-6685, we would like to move
> the JSONUtil class out of the o.a.s.xss package into a separate sub
> package (o.a.s.xss.json).
> 
> Right now, it introduces a dependency on the javax.json package for
> the o.a.s.xss package. That is the reason we have to bump the version
> to 2.0.0 due to the commons.json removable. If we move it into its own
> package we wouldn't have to do that if we every switch json providers
> again :-).
> 
> As we are bumping the major version anyways, I don't think this is a
> big deal - hence, I'm calling for lazy consensus (in other words, if
> you object, speak up now).
> 
Do we need this util class in the api at all? (I have no idea, but just
asking the obvious question)
If yes, moving it to a separate package and maybe naming either the
package or the class in a way that it is clear that this is bound to
javax.json and not a general purpose json util sounds like the right
thing to do.

I understand that for semantic versioning we have to increase the major
version of the api. How do we deal with all the code out there currently
importing 1.x? Can we find a way that does not require everyone to
change her code?

Regards

 Carsten

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: release Apache Johnzon Wrapper Library soon?

[Karl Pauls]

+1 sounds good to me (if you want me to I can do the release as well -
your call).

regards,

Karl

On Tue, Apr 25, 2017 at 12:01 PM, Stefan Seifert  wrote:
> i would like to release our new "Apache Johnzon Wrapper Library" soon with 
> version 1.0.0.
> if no one objects i will start the release tomorrow.
>
> stefan
>



-- 
Karl Pauls
karlpa...@gmail.com

move o.a.s.xss.JSONUtil into a separate package

[Karl Pauls]

Hi,

as discussed with Stefan Seifert on SLING-6685, we would like to move
the JSONUtil class out of the o.a.s.xss package into a separate sub
package (o.a.s.xss.json).

Right now, it introduces a dependency on the javax.json package for
the o.a.s.xss package. That is the reason we have to bump the version
to 2.0.0 due to the commons.json removable. If we move it into its own
package we wouldn't have to do that if we every switch json providers
again :-).

As we are bumping the major version anyways, I don't think this is a
big deal - hence, I'm calling for lazy consensus (in other words, if
you object, speak up now).

regards,

Karl

-- 
Karl Pauls
karlpa...@gmail.com

[jira] [Commented] (SLING-6685) Replace commons.json usage in org.apache.sling.xss

[Karl Pauls (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15982661#comment-15982661
 ] 

Karl Pauls commented on SLING-6685:
---

[~radu.cotescu], sorry - I got sidetracked on other issues. I'll try to move 
this forward right now. 

[~sseif...@pro-vision.de], I will write a short mail to the dev list and ask 
whether we should move it into a separate package.

> Replace commons.json usage in org.apache.sling.xss
> --
>
> Key: SLING-6685
> URL: https://issues.apache.org/jira/browse/SLING-6685
> Project: Sling
>  Issue Type: Sub-task
>  Components: XSS Protection API
>Affects Versions: XSS Protection API 1.0.18
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>  Labels: patch-available
> Fix For: XSS Protection API 1.0.20
>
> Attachments: SLING-6685-2.patch, SLING-6685.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

release Apache Johnzon Wrapper Library soon?

[Stefan Seifert]

i would like to release our new "Apache Johnzon Wrapper Library" soon with 
version 1.0.0.
if no one objects i will start the release tomorrow.

stefan

[jira] [Commented] (SLING-6788) Context-Aware Config: Make filtered property names for configuration persistence configurable

[Bertrand Delacretaz (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15982648#comment-15982648
 ] 

Bertrand Delacretaz commented on SLING-6788:


thanks! the docs work for me.

> Context-Aware Config: Make filtered property names for configuration 
> persistence configurable
> -
>
> Key: SLING-6788
> URL: https://issues.apache.org/jira/browse/SLING-6788
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: Context-Aware Configuration Impl 1.3.2
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration Impl 1.4.0
>
>
> currently, a hard-coded list of filtered property names is applied in the 
> configuration manager implementation and the default configuration 
> persistence implementation:
> {noformat}
> jcr:primaryType
> jcr:mixinTypes
> jcr:created
> jcr:createdBy
> jcr:lastModified
> jcr:lastModifiedBy
> jcr:uuid
> {noformat}
> this list should be made configurable because in upstream applications more 
> properties might need to be filtered e.g. to track replication status.
> the possibility to filter a list of property names by name or regex should be 
> made accessible in the ConfigurationManager API that is part of the 
> Management API so other configuration persistence applications may use it as 
> well.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6788) Context-Aware Config: Make filtered property names for configuration persistence configurable

[Stefan Seifert (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15982640#comment-15982640
 ] 

Stefan Seifert commented on SLING-6788:
---

good hint - i've added a new section about the "Management API" covering also 
this filtering
http://sling.apache.org/documentation/bundles/context-aware-configuration/context-aware-configuration.html#management-api

i also forgot to mention that with this ticket i changed the default filtering 
from the list above to all properties within the "jcr:" namespace. but it is 
configurable now. in most cases configuration property names will not contain 
any namespaces.

> Context-Aware Config: Make filtered property names for configuration 
> persistence configurable
> -
>
> Key: SLING-6788
> URL: https://issues.apache.org/jira/browse/SLING-6788
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: Context-Aware Configuration Impl 1.3.2
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration Impl 1.4.0
>
>
> currently, a hard-coded list of filtered property names is applied in the 
> configuration manager implementation and the default configuration 
> persistence implementation:
> {noformat}
> jcr:primaryType
> jcr:mixinTypes
> jcr:created
> jcr:createdBy
> jcr:lastModified
> jcr:lastModifiedBy
> jcr:uuid
> {noformat}
> this list should be made configurable because in upstream applications more 
> properties might need to be filtered e.g. to track replication status.
> the possibility to filter a list of property names by name or regex should be 
> made accessible in the ConfigurationManager API that is part of the 
> Management API so other configuration persistence applications may use it as 
> well.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6787) HTMLRendererServlet shoud properly encode output

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15982572#comment-15982572
 ] 

Carsten Ziegeler commented on SLING-6787:
-

[~acollign] Thanks, I understand the difference but is there anything in this 
context which StringEscapeUtils.escapeHtml doesn't catch?
Now, the dependency is one thing, but we use that method (or similar mechanism) 
in other places, so if that is not safe to use, we probably should replace it 
everywhere

> HTMLRendererServlet shoud properly encode output
> 
>
> Key: SLING-6787
> URL: https://issues.apache.org/jira/browse/SLING-6787
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Affects Versions: Servlets Get 2.1.18
>Reporter: Alex COLLIGNON
> Fix For: Servlets Get 2.1.24
>
> Attachments: 
> 0001-SLING-6787-HTMLRendererServlet-shoud-properly-encode.patch
>
>
> Some of the values rendered by HTMLRendererServlet can be (better) encoded.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (SLING-6790) Enable aliases even if referenced format is disabled

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler resolved SLING-6790.
-
Resolution: Fixed

Fixed in rev 1792588
I've also added a warning if an alias can't be enabled

> Enable aliases even if referenced format is disabled
> 
>
> Key: SLING-6790
> URL: https://issues.apache.org/jira/browse/SLING-6790
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Servlets Get 2.1.24
>
>
> When one of the default renderings is disabled and an alias exists for this, 
> the alias rendering is disabled as well. For example, it is common to have 
> the PDF rendering as an alias for XML (as the PDF rendering is based on using 
> an XML pipeline including XSLT to generate PDF). If XML is disabled, PDF 
> doesn't work either and right now, the only way to get PDF rendering work is 
> enabling XML as well. Which might not be what you want.
> So I think, if an alias exists - which is an explicit  configuration - this 
> should be enabled, regardless whether the underlying direct rendering is 
> disabled.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (SLING-6790) Enable aliases even if referenced format is disabled

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler reassigned SLING-6790:
---

Assignee: Carsten Ziegeler

> Enable aliases even if referenced format is disabled
> 
>
> Key: SLING-6790
> URL: https://issues.apache.org/jira/browse/SLING-6790
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Servlets Get 2.1.24
>
>
> When one of the default renderings is disabled and an alias exists for this, 
> the alias rendering is disabled as well. For example, it is common to have 
> the PDF rendering as an alias for XML (as the PDF rendering is based on using 
> an XML pipeline including XSLT to generate PDF). If XML is disabled, PDF 
> doesn't work either and right now, the only way to get PDF rendering work is 
> enabling XML as well. Which might not be what you want.
> So I think, if an alias exists - which is an explicit  configuration - this 
> should be enabled, regardless whether the underlying direct rendering is 
> disabled.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (SLING-6790) Enable aliases even if referenced format is disabled

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created SLING-6790:
---

 Summary: Enable aliases even if referenced format is disabled
 Key: SLING-6790
 URL: https://issues.apache.org/jira/browse/SLING-6790
 Project: Sling
  Issue Type: Improvement
  Components: Servlets
Reporter: Carsten Ziegeler
 Fix For: Servlets Get 2.1.24


When one of the default renderings is disabled and an alias exists for this, 
the alias rendering is disabled as well. For example, it is common to have the 
PDF rendering as an alias for XML (as the PDF rendering is based on using an 
XML pipeline including XSLT to generate PDF). If XML is disabled, PDF doesn't 
work either and right now, the only way to get PDF rendering work is enabling 
XML as well. Which might not be what you want.
So I think, if an alias exists - which is an explicit  configuration - this 
should be enabled, regardless whether the underlying direct rendering is 
disabled.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6787) HTMLRendererServlet shoud properly encode output

[Alex COLLIGNON (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15982563#comment-15982563
 ] 

Alex COLLIGNON commented on SLING-6787:
---

Hi [~cziegeler], 

bq. Thanks for the patch. 

You're welcome.

bq. I see that you replaced the usage of StringEscapeUtils.escapeHtml with 
using the xss api service.  Is this really required, or can't we simply use 
StringEscapeUtils.escapeHtml in all the places?

{{StringEscapeUtils.escapeHtml}} is meant to not break HTML context while the 
{{XSS Api}} is meant to make it safe - think javascript payload.

bq.  I'm asking as this introduces a new dependency to the xss service

I think it is worth introducing the dependency but I might be a little bias 
here ;-).

> HTMLRendererServlet shoud properly encode output
> 
>
> Key: SLING-6787
> URL: https://issues.apache.org/jira/browse/SLING-6787
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Affects Versions: Servlets Get 2.1.18
>Reporter: Alex COLLIGNON
> Fix For: Servlets Get 2.1.24
>
> Attachments: 
> 0001-SLING-6787-HTMLRendererServlet-shoud-properly-encode.patch
>
>
> Some of the values rendered by HTMLRendererServlet can be (better) encoded.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6787) HTMLRendererServlet shoud properly encode output

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler updated SLING-6787:

Fix Version/s: Servlets Get 2.1.24

> HTMLRendererServlet shoud properly encode output
> 
>
> Key: SLING-6787
> URL: https://issues.apache.org/jira/browse/SLING-6787
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Affects Versions: Servlets Get 2.1.18
>Reporter: Alex COLLIGNON
> Fix For: Servlets Get 2.1.24
>
> Attachments: 
> 0001-SLING-6787-HTMLRendererServlet-shoud-properly-encode.patch
>
>
> Some of the values rendered by HTMLRendererServlet can be (better) encoded.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6787) HTMLRendererServlet shoud properly encode output

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15982542#comment-15982542
 ] 

Carsten Ziegeler commented on SLING-6787:
-

[~acollign] Thanks for the patch. I see that you replaced the usage of 
StringEscapeUtils.escapeHtml with using the xss api service.
Is this really required, or can't we simply use StringEscapeUtils.escapeHtml in 
all the places?
I'm asking as this introduces a new dependency to the xss service

> HTMLRendererServlet shoud properly encode output
> 
>
> Key: SLING-6787
> URL: https://issues.apache.org/jira/browse/SLING-6787
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Affects Versions: Servlets Get 2.1.18
>Reporter: Alex COLLIGNON
> Attachments: 
> 0001-SLING-6787-HTMLRendererServlet-shoud-properly-encode.patch
>
>
> Some of the values rendered by HTMLRendererServlet can be (better) encoded.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6788) Context-Aware Config: Make filtered property names for configuration persistence configurable

[Bertrand Delacretaz (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15982529#comment-15982529
 ] 

Bertrand Delacretaz commented on SLING-6788:


I don't find the word "filter" at 
https://sling.apache.org/documentation/bundles/context-aware-configuration/context-aware-configuration.html
 , is this feature documented?

> Context-Aware Config: Make filtered property names for configuration 
> persistence configurable
> -
>
> Key: SLING-6788
> URL: https://issues.apache.org/jira/browse/SLING-6788
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: Context-Aware Configuration Impl 1.3.2
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration Impl 1.4.0
>
>
> currently, a hard-coded list of filtered property names is applied in the 
> configuration manager implementation and the default configuration 
> persistence implementation:
> {noformat}
> jcr:primaryType
> jcr:mixinTypes
> jcr:created
> jcr:createdBy
> jcr:lastModified
> jcr:lastModifiedBy
> jcr:uuid
> {noformat}
> this list should be made configurable because in upstream applications more 
> properties might need to be filtered e.g. to track replication status.
> the possibility to filter a list of property names by name or regex should be 
> made accessible in the ConfigurationManager API that is part of the 
> Management API so other configuration persistence applications may use it as 
> well.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (SLING-6789) Support CAConfig Impl 1.4.0

[Stefan Seifert (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Seifert resolved SLING-6789.
---
Resolution: Fixed

Completed: At revision: 1792579  


> Support CAConfig Impl 1.4.0
> ---
>
> Key: SLING-6789
> URL: https://issues.apache.org/jira/browse/SLING-6789
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: Context-Aware Configuration Mock Plugin 1.1.0
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
> Fix For: Context-Aware Configuration Mock Plugin 1.2.0
>
>
> the mock plugin should support the latest implementation details of CAConfig 
> Impl 1.4.0.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (SLING-6788) Context-Aware Config: Make filtered property names for configuration persistence configurable

[Stefan Seifert (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Seifert resolved SLING-6788.
---
Resolution: Fixed

Completed: At revision: 1792578  


> Context-Aware Config: Make filtered property names for configuration 
> persistence configurable
> -
>
> Key: SLING-6788
> URL: https://issues.apache.org/jira/browse/SLING-6788
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: Context-Aware Configuration Impl 1.3.2
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration Impl 1.4.0
>
>
> currently, a hard-coded list of filtered property names is applied in the 
> configuration manager implementation and the default configuration 
> persistence implementation:
> {noformat}
> jcr:primaryType
> jcr:mixinTypes
> jcr:created
> jcr:createdBy
> jcr:lastModified
> jcr:lastModifiedBy
> jcr:uuid
> {noformat}
> this list should be made configurable because in upstream applications more 
> properties might need to be filtered e.g. to track replication status.
> the possibility to filter a list of property names by name or regex should be 
> made accessible in the ConfigurationManager API that is part of the 
> Management API so other configuration persistence applications may use it as 
> well.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (SLING-6789) Support CAConfig Impl 1.4.0

[Stefan Seifert (JIRA)]

Stefan Seifert created SLING-6789:
-

 Summary: Support CAConfig Impl 1.4.0
 Key: SLING-6789
 URL: https://issues.apache.org/jira/browse/SLING-6789
 Project: Sling
  Issue Type: Improvement
  Components: Testing
Affects Versions: Context-Aware Configuration Mock Plugin 1.1.0
Reporter: Stefan Seifert
Assignee: Stefan Seifert
 Fix For: Context-Aware Configuration Mock Plugin 1.2.0


the mock plugin should support the latest implementation details of CAConfig 
Impl 1.4.0.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6788) Context-Aware Config: Make filtered property names for configuration persistence configurable

[Stefan Seifert (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Seifert updated SLING-6788:
--
Issue Type: New Feature  (was: Improvement)

> Context-Aware Config: Make filtered property names for configuration 
> persistence configurable
> -
>
> Key: SLING-6788
> URL: https://issues.apache.org/jira/browse/SLING-6788
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: Context-Aware Configuration Impl 1.3.2
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration Impl 1.4.0
>
>
> currently, a hard-coded list of filtered property names is applied in the 
> configuration manager implementation and the default configuration 
> persistence implementation:
> {noformat}
> jcr:primaryType
> jcr:mixinTypes
> jcr:created
> jcr:createdBy
> jcr:lastModified
> jcr:lastModifiedBy
> jcr:uuid
> {noformat}
> this list should be made configurable because in upstream applications more 
> properties might need to be filtered e.g. to track replication status.
> the possibility to filter a list of property names by name or regex should be 
> made accessible in the ConfigurationManager API that is part of the 
> Management API so other configuration persistence applications may use it as 
> well.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)