[jira] [Resolved] (SLING-7592) Add missing OSGi capabilities

[Oliver Lietz (JIRA)]

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

Oliver Lietz resolved SLING-7592.
-
Resolution: Done

> Add missing OSGi capabilities
> -
>
> Key: SLING-7592
> URL: https://issues.apache.org/jira/browse/SLING-7592
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>Priority: Major
> Fix For: Resource Resolver 1.6.2
>
>
> {noformat}
> osgi.service;objectClass=javax.servlet.Servlet
> osgi.service;objectClass=org.apache.sling.api.resource.ResourceResolverFactory
> osgi.service;objectClass=org.apache.sling.api.resource.observation.ResourceChangeListener
> osgi.service;objectClass=org.apache.sling.api.resource.runtime.RuntimeService
> osgi.service;objectClass=org.apache.sling.spi.resource.provider.ResourceProvider
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SLING-7592) Add missing OSGi capabilities

[Oliver Lietz (JIRA)]

Oliver Lietz created SLING-7592:
---

 Summary: Add missing OSGi capabilities
 Key: SLING-7592
 URL: https://issues.apache.org/jira/browse/SLING-7592
 Project: Sling
  Issue Type: Improvement
  Components: ResourceResolver
Reporter: Oliver Lietz
Assignee: Oliver Lietz
 Fix For: Resource Resolver 1.6.2


{noformat}
osgi.service;objectClass=javax.servlet.Servlet
osgi.service;objectClass=org.apache.sling.api.resource.ResourceResolverFactory
osgi.service;objectClass=org.apache.sling.api.resource.observation.ResourceChangeListener
osgi.service;objectClass=org.apache.sling.api.resource.runtime.RuntimeService
osgi.service;objectClass=org.apache.sling.spi.resource.provider.ResourceProvider
{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Failed Pipeline: sling-ide-tooling » master #9

[Apache Jenkins Server]

See https://builds.apache.org/job/sling-ide-tooling/job/master/9/

Re: [VOTE] Release Apache Sling File System Resource Provider version 2.1.14

[Julian Sedding]

Thanks Radu for noticing and correcting the link! You are absolutely
correct, of course.

Regards
Julian

On Wed, Apr 18, 2018 at 11:19 AM, Radu Cotescu  wrote:
> +1 (I’ve only verified signatures and digests for the artifacts staged in 
> 1894 - see my previous email)
>
>> On 18 Apr 2018, at 09:40, Julian Sedding  wrote:
>>
>> Please vote to approve this release:
>>
>>  [ ] +1 Approve the release
>>  [ ]  0 Don't care
>>  [ ] -1 Don't release, because ...
>>
>> This majority vote is open for at least 72 hours.
>>
>> Regards
>> Julian
>

[Discussion] Date handling inconsistencies - resend

[Jason E Bailey]

I'm re-sending this as I had a problem with my webmail and the formatting got 
messed up for the text view.

We have inconsistencies on how dates are presented and the formats that are 
acceptable. This only includes inconsistent handling of the time zone offset. 
Fixing these would mean a change to the respective bundles to support java 8 by 
default or to make changes to what the current default format is.

The problem:
Prior to Java 8 there was no out of the box way to support the parsing of a 
String into a Date that would keep the time zone offset. The java.util.Date 
object does not contain information about the offset and assumes everything 
from a UTC. The Calendar object does maintain a time zone but uses the system 
time zone as a default.

There is a Standard for time strings called ISO-8601 which is used by the JCR, 
there is a utility class used by several bundles that utilizes this class and 
this will create a Calendar object with the correct time zone offset. However 
not all bundles use this.

Current Areas of Concern:
Content Loader with  a JSON payload, only recognizes a value as a Date if it 
uses the ISO-8601 format, however the Content Loader uses the java 
SimpleDateFormatter instead of the ISO8601 util so time zone offset it lost.

Content Parser recognizes ISO-8601 and an ECMA format, ECMA format does not 
support offset.

Form Post handling with a TypeHint of Date will recognize multiple formats 
including ISO-8601, will only keep the time zone offset with the ISO-8601 
format.

Default JSON handler is returning dates as an ECMA format, not as ISO-8601 the 
ECMA format is a format that was primarily used by browsers. This format is not 
the default for browsers anymore, the default format for browsers is the 
ISO-8601 format.

Solutions:
The easiest way of parsing date strings and keeping offsets would be to use the 
java.time package from java 8 which would upgrade the dependencies in those 
bundles mentioned.

Other options would be to have any usage of the ISO-8601 format be parsed with 
the ISO8601 utility class and to have ALL exports of Date Strings use the 8601 
format as default. We could then state that if you want to keep the offset use 
the standard date string format. That would require a change in the default 
JSON handler.

Other options and opinions would be great.

- Jason

[GitHub] rombert closed pull request #3: SLING-7587 - Create a CLI-only tool to sync content

[GitBox]

rombert closed pull request #3: SLING-7587 - Create a CLI-only tool to sync 
content
URL: https://github.com/apache/sling-ide-tooling/pull/3
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Failed Pipeline: sling-ide-tooling » feature/SLING-7587 #4

[Apache Jenkins Server]

See 
https://builds.apache.org/job/sling-ide-tooling/job/feature%252FSLING-7587/4/

Failed Pipeline: sling-ide-tooling » feature/SLING-7587 #3

[Apache Jenkins Server]

See 
https://builds.apache.org/job/sling-ide-tooling/job/feature%252FSLING-7587/3/

[Discussion] Date handling inconsistencies

[Jason E Bailey]

We have inconsistencies on how dates are presented and the formats that
are acceptable. This only includes inconsistent handling of the time
zone offset.
Fixing these would mean a change to the bundle to support java 8 by
default or changes to what the current default format is.
The problem:
Prior to Java 8 there was no out of the box way to support the parsing
of a String into a Date that would keep the time zone offset. The
java.util.Date object does not contain information about the offset and
assumes everything from a UTC. The Calendar object does maintain a time
zone but uses the system time zone as a default.
There is a Standard for time strings called ISO-8601 which is used by
the JCR, there is a utility class used by several bundles that utilizes
this class and this will create a Calendar object with the correct time
zone offset. However not all bundles use this.
Current Areas of Concern:
Content Loader with  a JSON payload, only recognizes a value as a Date
if it uses the ISO-8601 format, however the Content Loader uses the
java SimpleDateFormatter instead of the ISO8601 util so time zone
offset it lost.
Content Parser recognizes ISO-8601 and an ECMA format, ECMA format does
not support offset.
Form Post handling with a TypeHint of Date will recognize multiple
formats including ISO-8601, will only keep the time zone offset with the
ISO-8601 format.
Default JSON handler is returning dates as an ECMA format, not as ISO-
8601 the ECMA format is a format that was primarily used by browsers.
This format is not the default for browsers anymore, the default format
for browsers is the ISO-8601 format.
Solutions:
The easiest way of parsing date strings and keeping offsets would be to
use the java.time package from java 8 which would upgrade the
dependencies in those bundles mentioned.
Other options would be to have any usage of the ISO-8601 format be
parsed with the ISO8601 utility class and to have ALL exports of Date
Strings use the 8601 format as default. We could then state that if you
want to keep the offset use the standard date string format. That would
require a change in the default JSON handler.
Other options and opinions would be great.

- Jason

[jira] [Commented] (SLING-7590) Content Loaders not respecting time zone for Dates

[Jason E Bailey (JIRA)]

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

Jason E Bailey commented on SLING-7590:
---

[~sseif...@pro-vision.de] This gets confusing because each module has come up 
with it's own way of doing things. The content loader *only* recognizes an 
ISO-8601 format as a Date, but doesn't use the ISO8601 utility class, and so it 
doesn't keep the offset. So right now, if you use a GET for JSON and turn 
around and POST that JSON back into sling it won't recognize the date string as 
a date.

Browsers now use the ISO-8601 format for dates and will fall back to the ECMA 
format as a fail over. I don't know why we're returning a JSON date using that 
format because it;s not the format that the XML response used. The XM used the 
ISO-8601. Which is a standard, and we should switch things to use a standard, 
at least as the default.

I'll write something up for the mailing list.

> Content Loaders not respecting time zone for Dates
> --
>
> Key: SLING-7590
> URL: https://issues.apache.org/jira/browse/SLING-7590
> Project: Sling
>  Issue Type: Improvement
>Reporter: Jason E Bailey
>Priority: Major
>
> When importing content, the JCR supports the setting of the time zone for a  
> jcr Date. However we currently have several processes that fail to set the 
> time zone correctly.
> org.apache.sling.jcr.contentparser.impl.ParserHelper
>  org.apache.sling.jcr.contentloader.internal.DefaultContentCreator
> org.apache.sling.servlets.post.impl.helper.DateParser
> Take a String based time representation that includes a time offset and 
> convert it to Date that looses that information, before conversion to a 
> Calendar object.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

RE: [PROPOSAL] replace sling committer list with link to apache phonebook

[Stefan Seifert]

i replaced the committers list with a link to the phonebook:
https://sling.apache.org/project-information/project-team.html

if required we can think about fetching more information from the phonebook, 
but this would need more effort.

stefan


>-Original Message-
>From: Stefan Seifert [mailto:sseif...@pro-vision.de]
>Sent: Tuesday, April 10, 2018 3:01 PM
>To: dev@sling.apache.org
>Subject: [PROPOSAL] replace sling committer list with link to apache
>phonebook
>
>currently we maintain a list of all committers and PMC members in a CMS
>page on [1].
>this page is currently outdated, some committers are missing (e.g. david
>bosschaert).
>
>my proposal is to remove this manually maintained list and replace it with
>a link to the apache phonebook [2]
>
>pro:
>- no redundant data, no manual maintenance: phonebook is always based on
>the "true source"
>- distinction between PMC members, chair and committers is clearly visible
>(for vote counting)
>
>con:
>- we lose some probably important information currently present on this
>page:
>  - organization (not maintained for all members)
>  - role
>
>the page [1] contains also additional sections with emeritus members,
>thanks etc. - these sections would remain untouched.
>
>WDYT?
>
>stefan
>
>[1] https://sling.apache.org/project-information/project-team.html
>[2] https://people.apache.org/phonebook.html?pmc=sling
>
>

Re: [VOTE] Release Apache Sling File System Resource Provider version 2.1.14

[Radu Cotescu]

+1 (I’ve only verified signatures and digests for the artifacts staged in 1894 
- see my previous email)

> On 18 Apr 2018, at 09:40, Julian Sedding  wrote:
> 
> Please vote to approve this release:
> 
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
> 
> This majority vote is open for at least 72 hours.
> 
> Regards
> Julian

Re: [VOTE] Release Apache Sling File System Resource Provider version 2.1.14

[Radu Cotescu]

Hi Julian,

> On 18 Apr 2018, at 09:40, Julian Sedding  wrote:
> 
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1849/ 
> 

I think you pasted the wrong link. The correct staging repository seems to be 
https://repository.apache.org/content/repositories/orgapachesling-1894 
.

Cheers,
Radu

[jira] [Commented] (SLING-7583) Log tracer runs into ClassCastException for oak-queries

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra commented on SLING-7583:


{quote}I would propose to use {{String.valueOf()}} here to get the proper 
{{toString()}} implementation of the {{QueryImpl}} object.
{quote}
+1. Fixed as per your suggestion in 
[commit|https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-tracer.git;a=commit;h=ee13d5caf8ef714bcd2ad51d4ae414ccfbb37946]

> Log tracer runs into ClassCastException for oak-queries
> ---
>
> Key: SLING-7583
> URL: https://issues.apache.org/jira/browse/SLING-7583
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Log Tracer 1.0.6, Log Tracer 1.0.4
>Reporter: Dirk Rudolph
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: Log Tracer 1.0.8
>
>
> Oak's {{QueryEngineImpl}} logs the following "cost: {} for query {}" with the 
> first parameter being a primitive {{double}} and the second being an instance 
> of {{QueryImpl}} [1]. On the other hand the TraceContext casts thats second 
> parameter to {{String}} without a type check [2]. I would propose to use 
> {{String.valueOf()}} here to get the proper {{toString()}} implementation of 
> the {{QueryImpl}} object.
>   
> [1] 
> [https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.6.7/oak-core/src/main/java/org/apache/jackrabbit/oak/query/QueryEngineImpl.java#L311]
>  [2] 
> [https://github.com/apache/sling-org-apache-sling-tracer/blob/master/src/main/java/org/apache/sling/tracer/internal/TracerContext.java#L92]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (SLING-7583) Log tracer runs into ClassCastException for oak-queries

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra resolved SLING-7583.

   Resolution: Fixed
Fix Version/s: Log Tracer 1.0.8

> Log tracer runs into ClassCastException for oak-queries
> ---
>
> Key: SLING-7583
> URL: https://issues.apache.org/jira/browse/SLING-7583
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Log Tracer 1.0.6, Log Tracer 1.0.4
>Reporter: Dirk Rudolph
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: Log Tracer 1.0.8
>
>
> Oak's {{QueryEngineImpl}} logs the following "cost: {} for query {}" with the 
> first parameter being a primitive {{double}} and the second being an instance 
> of {{QueryImpl}} [1]. On the other hand the TraceContext casts thats second 
> parameter to {{String}} without a type check [2]. I would propose to use 
> {{String.valueOf()}} here to get the proper {{toString()}} implementation of 
> the {{QueryImpl}} object.
>   
> [1] 
> [https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.6.7/oak-core/src/main/java/org/apache/jackrabbit/oak/query/QueryEngineImpl.java#L311]
>  [2] 
> [https://github.com/apache/sling-org-apache-sling-tracer/blob/master/src/main/java/org/apache/sling/tracer/internal/TracerContext.java#L92]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (SLING-7583) Log tracer runs into ClassCastException for oak-queries

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra reassigned SLING-7583:
--

Assignee: Chetan Mehrotra

> Log tracer runs into ClassCastException for oak-queries
> ---
>
> Key: SLING-7583
> URL: https://issues.apache.org/jira/browse/SLING-7583
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Log Tracer 1.0.6, Log Tracer 1.0.4
>Reporter: Dirk Rudolph
>Assignee: Chetan Mehrotra
>Priority: Minor
>
> Oak's {{QueryEngineImpl}} logs the following "cost: {} for query {}" with the 
> first parameter being a primitive {{double}} and the second being an instance 
> of {{QueryImpl}} [1]. On the other hand the TraceContext casts thats second 
> parameter to {{String}} without a type check [2]. I would propose to use 
> {{String.valueOf()}} here to get the proper {{toString()}} implementation of 
> the {{QueryImpl}} object.
>   
> [1] 
> [https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.6.7/oak-core/src/main/java/org/apache/jackrabbit/oak/query/QueryEngineImpl.java#L311]
>  [2] 
> [https://github.com/apache/sling-org-apache-sling-tracer/blob/master/src/main/java/org/apache/sling/tracer/internal/TracerContext.java#L92]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[VOTE] Release Apache Sling File System Resource Provider version 2.1.14

[Julian Sedding]

Hi,

We solved 2 issues in the Apache Sling File System Resource Provider
2.1.14 release:
https://issues.apache.org/jira/projects/SLING/versions/12342709

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-1849/

You can use this UNIX script to download the release and verify the signatures:
https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD

Usage:
sh check_staged_release.sh 1849 /tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Regards
Julian

[jira] [Resolved] (SLING-7578) FS Resource Provider has OS-dependent (unstable?) ordering of file-based resources

[Julian Sedding (JIRA)]

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

Julian Sedding resolved SLING-7578.
---
Resolution: Fixed

Fixed in 
[2ab615f|https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-fsresource.git;a=commitdiff;h=2ab615f].

> FS Resource Provider has OS-dependent (unstable?) ordering of file-based 
> resources
> --
>
> Key: SLING-7578
> URL: https://issues.apache.org/jira/browse/SLING-7578
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Affects Versions: File System Resource Provider 2.1.12
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Major
> Fix For: File System Resource Provider 2.1.14
>
>
> The file-system resource provider, using Sling initial-content compatible 
> JSON, does not provide a stable order for resources that are defined by the 
> presence of a JSON file or a folder (i.e. not defined inside of a JSON file).
> To allow stable testing against FS resource-based setups, a stable ordering 
> should be guaranteed. I propose to sort files in alphabetical order according 
> to their filename and to list file-based resources after JSON-defined 
> resources.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (SLING-7577) FS Resource Provider slow due to frequent file stat access

[Julian Sedding (JIRA)]

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

Julian Sedding resolved SLING-7577.
---
Resolution: Fixed

Fixed in 
[221bcc1|https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-fsresource.git;a=commitdiff;h=221bcc1].

> FS Resource Provider slow due to frequent file stat access
> --
>
> Key: SLING-7577
> URL: https://issues.apache.org/jira/browse/SLING-7577
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Affects Versions: File System Resource Provider 2.1.12
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Major
> Fix For: File System Resource Provider 2.1.14
>
>
> The file-system resource provider is relatively slow, because it frequently 
> checks for file existence, for whether a file is a directory or a file and 
> for the last modified time.
> Normally this is not an issue, but in a setup where context aware 
> configurations are used via FSRP, there are a lot of lookups for non-existing 
> resources, which are not cached in any way. In the scenario I experienced, 
> the same lookups occurred frequently during a single HTTP request and caused 
> page-rendering to take ~5s.
> To improve this, I propose to cache file stats, including non-existence of a 
> file.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)