Jenkins build is still unstable: sling-contrib-1.7 #129
See https://builds.apache.org/job/sling-contrib-1.7/129/
Re: [RT] New resource query API
On 28.05.2015, at 09:32, Carsten Ziegeler cziege...@apache.org wrote: Am 28.05.15 um 18:25 schrieb Alexander Klimetschek: On 27.05.2015, at 01:35, Bertrand Delacretaz bdelacre...@apache.org wrote: I'm happy to collaborate on creating these examples (which can simply be unit tests for a relevant ResourceProvider) but before that I'd like to discuss what the alternatives are, before we invent YAQA (*). We have the querybuilder [1] in our CQ/AEM product, we could contribute this to Sling, I think (pending internal legal processes of course). I guess that would be nice, but isnt the query builder an http api? How is that translated to resource queries? No, it's both. It is a normal API [1], usage example at [2], but it also has a form that is easy to transport over http using GET/POST parameters and comes with a (popular) servlet that provides the result as json. The general predicate format is not depending on an order or correctly nested brackets, so you can easily build advanced search forms. [1] https://docs.adobe.com/docs/en/aem/6-0/develop/ref/javadoc/com/day/cq/search/package-summary.html [2] https://docs.adobe.com/docs/en/aem/6-0/develop/ref/javadoc/com/day/cq/search/QueryBuilder.html Cheers, Alex
Re: [RT] New resource query API
When you run a query across multiple backends, you have to aggregate the results. This is non-trivial an in most cases you are better off using an external search index that covers everything. And from my experience, you usually you don't have the use case to search across different providers, e.g. if you have a) a file system provider for bundles and code and b) a database provider providing ecommerce order entries, you never search across both at the same time. Cheers, Alex On 28.05.2015, at 11:06, Carsten Ziegeler cziege...@apache.org wrote: Just to clarify as it seems people got the proposal wrong: this is about a new API, not an implementation. It's an abstraction on the resource level. Of course with a JCR provider underneath, the search is delegated to that provider. Same with other providers. It should be easy for every provider to implement the api. Typical use cases are for example the job handling which searches for jobs in the resource tree or the resource resolver implementation looking for vanity paths etc. Right now - although these parts use the resource api - it's not possible to run them with a different provider than jcr. Carsten Am 18.05.15 um 08:17 schrieb Carsten Ziegeler: The current resource query api has several problems: - it's using the JCR spec to define a query - it's not clear which queries are supported by providers - queries are string based - implementing queries in a resource provider is way too hard as this would require to implement the complete jcr query api. I've created a draft for a new, object based API at [1]. The main idea is to use a builder pattern to create Query objects. This are immutable and have a unique identifier. The QueryManager service can be used to execute a query in the context of a resource resolver. The manager delegates the query to the providers. As each Query object has this identifier, implementations can use this to cache the parsing of the query. In addition to the query object you can pass in query instructions to specify a limit or range for the query. Obviously this is a reduced set compared to the full fledged jcr search api, however it should be suitable for the majority of use cases. [1] https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler/api-v3/src/main/java/org/apache/sling/api/resource/query/ Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Jenkins build is still unstable: sling-trunk-1.8 #1154
See https://builds.apache.org/job/sling-trunk-1.8/changes
Re: Deprecating the json.org parser in sling commons json
On 28.05.2015, at 12:55, Konrad Windszus konra...@gmx.de wrote: If we deprecate the parsing functionality of commons.json we should rather point to JSR 353 Good point, we should point to all of them. These seem to be pretty new, so not sure how ready they are. (https://json-processing-spec.java.net/nonav/releases/1.0/fcs/javadocs/index.html) and one of the implementations (https://jsonp.java.net/ or http://owlike.github.io/genson/ AFAIK) as an alternative instead of the not really maintained json.org implementation (https://github.com/douglascrockford/JSON-java/blob/master/README). FWIW, it is maintained by someone else now, see commit history: https://github.com/douglascrockford/JSON-java/commits/master Cheers, Alex
[jira] [Created] (SLING-4761) Latest view seems to get marked as not current
Carsten Ziegeler created SLING-4761: --- Summary: Latest view seems to get marked as not current Key: SLING-4761 URL: https://issues.apache.org/jira/browse/SLING-4761 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Discovery Impl 1.1.2 Reporter: Carsten Ziegeler Fix For: Discovery Impl 1.1.4 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4761) Latest view seems to get marked as not current
[ https://issues.apache.org/jira/browse/SLING-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14563386#comment-14563386 ] Carsten Ziegeler commented on SLING-4761: - It seems that the last view you get via a topology listener might get mark as old (not current), this is the events I see: 28.05.2015 19:58:57.015 Received topology event PROPERTIES_CHANGED, hash code 2037323133, current : true 28.05.2015 19:58:57.022 Received topology event PROPERTIES_CHANGED, hash code 2037323133, current : true 28.05.2015 19:59:06.995 active check, hash code 2037323133, current : false The interesting thing is that the properties changed event is received twice, with the same new view object, ten seconds later the view is not current anymore but no topology event / change has been received by the listener. I experienced this with 1.1.0 and can reproduce this. Trying 1.1.2 now Latest view seems to get marked as not current -- Key: SLING-4761 URL: https://issues.apache.org/jira/browse/SLING-4761 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Discovery Impl 1.1.0 Reporter: Carsten Ziegeler Fix For: Discovery Impl 1.1.4 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4761) Latest view seems to get marked as not current
[ https://issues.apache.org/jira/browse/SLING-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14563416#comment-14563416 ] Carsten Ziegeler commented on SLING-4761: - [~egli] WDYT? It still happens to me with 1.1.2 Latest view seems to get marked as not current -- Key: SLING-4761 URL: https://issues.apache.org/jira/browse/SLING-4761 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Discovery Impl 1.1.0, Discovery Impl 1.1.2 Reporter: Carsten Ziegeler Fix For: Discovery Impl 1.1.4 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4761) Latest view seems to get marked as not current
[ https://issues.apache.org/jira/browse/SLING-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-4761: Affects Version/s: (was: Discovery Impl 1.1.2) Discovery Impl 1.1.0 Latest view seems to get marked as not current -- Key: SLING-4761 URL: https://issues.apache.org/jira/browse/SLING-4761 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Discovery Impl 1.1.0 Reporter: Carsten Ziegeler Fix For: Discovery Impl 1.1.4 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Deprecating the json.org parser in sling commons json
If we deprecate the parsing functionality of commons.json we should rather point to JSR 353 (https://json-processing-spec.java.net/nonav/releases/1.0/fcs/javadocs/index.html) and one of the implementations (https://jsonp.java.net/ or http://owlike.github.io/genson/ AFAIK) as an alternative instead of the not really maintained json.org implementation (https://github.com/douglascrockford/JSON-java/blob/master/README). Since JSR 353 does provide a streaming API (https://json-processing-spec.java.net/nonav/releases/1.0/fcs/javadocs/javax/json/stream/package-summary.html) and JSR 353 together with the reference implementation is part of Java EE 7 I consider it the most reasonable choice nowadays. I cannot really say whether that would be a good choice for writing JSON objects in Sling as well, because i guess its streaming API keeps the order. Konrad Am 28.05.2015 um 21:06 schrieb Alexander Klimetschek aklim...@adobe.com: tl;dr deprecate json.org classes in sling commons json, and point people to use the real json.org library Hi, Sling commons.json includes a very old version of the json.org implementations (state pre 2009, apart from few important bug fixes). Most notably, it is not useful for parsing json, since the sling version can only work with strings [1] as input. This is obviously bad for memory usage and performance, espcially with larger json files, if you have to convert a request stream or binary (from a resource) into a string first, meaning you end up with potentially 3 in-memory representations of the json (binary stream, string parsed jsonobject structure). json.org has stream reader support for a long time [2]. (Also, Apache Jackrabbit has a streaming parser that can be useful for some cases, but that's a different topic [3]). However, just updating the copy of these classes in commons.json to the newest version or json.org won't work, since the APIs are not backwards compatible (most notably, JsonTokener methods now throwing JsonExceptions they did not before). You could find a hacky way to port it, but then future updates will be again difficult. The sling commons.json was added and used in Sling mainly for _generating_ json, not _parsing_ it (to dump jcr structures as json or write servlets generating json for client-side consumption). It also has a bunch of extra stuff for that case (groovy, jsonwriter etc.). IIRC, it also keeps the order when writing json objects, which isn't standardized in json, and doesn't apply when you parse json (and sling has an option to use arrays nowadays for exporting jcr as json). However, people using the sling stack will naturally start using Sling commons json for all their json stuff, so they unknowingly will run into the above problem(s) when they use it for parsing. Therefore I think there should be a clear deprecation note on the JSONObject et al classes, when you use this for parsing json, use org.json instead. wdyt? [1] https://github.com/apache/sling/blob/trunk/bundles/commons/json/src/main/java/org/apache/sling/commons/json/JSONTokener.java#L53 [2] https://github.com/douglascrockford/JSON-java/blob/master/JSONTokener.java#L74 [3] http://jackrabbit.apache.org/api/2.2/org/apache/jackrabbit/commons/json/JsonParser.html Cheers, Alex
Deprecating the json.org parser in sling commons json
tl;dr deprecate json.org classes in sling commons json, and point people to use the real json.org library Hi, Sling commons.json includes a very old version of the json.org implementations (state pre 2009, apart from few important bug fixes). Most notably, it is not useful for parsing json, since the sling version can only work with strings [1] as input. This is obviously bad for memory usage and performance, espcially with larger json files, if you have to convert a request stream or binary (from a resource) into a string first, meaning you end up with potentially 3 in-memory representations of the json (binary stream, string parsed jsonobject structure). json.org has stream reader support for a long time [2]. (Also, Apache Jackrabbit has a streaming parser that can be useful for some cases, but that's a different topic [3]). However, just updating the copy of these classes in commons.json to the newest version or json.org won't work, since the APIs are not backwards compatible (most notably, JsonTokener methods now throwing JsonExceptions they did not before). You could find a hacky way to port it, but then future updates will be again difficult. The sling commons.json was added and used in Sling mainly for _generating_ json, not _parsing_ it (to dump jcr structures as json or write servlets generating json for client-side consumption). It also has a bunch of extra stuff for that case (groovy, jsonwriter etc.). IIRC, it also keeps the order when writing json objects, which isn't standardized in json, and doesn't apply when you parse json (and sling has an option to use arrays nowadays for exporting jcr as json). However, people using the sling stack will naturally start using Sling commons json for all their json stuff, so they unknowingly will run into the above problem(s) when they use it for parsing. Therefore I think there should be a clear deprecation note on the JSONObject et al classes, when you use this for parsing json, use org.json instead. wdyt? [1] https://github.com/apache/sling/blob/trunk/bundles/commons/json/src/main/java/org/apache/sling/commons/json/JSONTokener.java#L53 [2] https://github.com/douglascrockford/JSON-java/blob/master/JSONTokener.java#L74 [3] http://jackrabbit.apache.org/api/2.2/org/apache/jackrabbit/commons/json/JsonParser.html Cheers, Alex
Jenkins build is still unstable: sling-contrib-1.7 #128
See https://builds.apache.org/job/sling-contrib-1.7/changes
Jenkins build is back to stable : sling-trunk-1.7 #1862
See https://builds.apache.org/job/sling-trunk-1.7/1862/changes
[jira] [Updated] (SLING-4761) Latest view seems to get marked as not current
[ https://issues.apache.org/jira/browse/SLING-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-4761: Affects Version/s: Discovery Impl 1.1.2 Latest view seems to get marked as not current -- Key: SLING-4761 URL: https://issues.apache.org/jira/browse/SLING-4761 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Discovery Impl 1.1.0, Discovery Impl 1.1.2 Reporter: Carsten Ziegeler Fix For: Discovery Impl 1.1.4 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [RT] New resource query API
Just to clarify as it seems people got the proposal wrong: this is about a new API, not an implementation. It's an abstraction on the resource level. Of course with a JCR provider underneath, the search is delegated to that provider. Same with other providers. It should be easy for every provider to implement the api. Typical use cases are for example the job handling which searches for jobs in the resource tree or the resource resolver implementation looking for vanity paths etc. Right now - although these parts use the resource api - it's not possible to run them with a different provider than jcr. Carsten Am 18.05.15 um 08:17 schrieb Carsten Ziegeler: The current resource query api has several problems: - it's using the JCR spec to define a query - it's not clear which queries are supported by providers - queries are string based - implementing queries in a resource provider is way too hard as this would require to implement the complete jcr query api. I've created a draft for a new, object based API at [1]. The main idea is to use a builder pattern to create Query objects. This are immutable and have a unique identifier. The QueryManager service can be used to execute a query in the context of a resource resolver. The manager delegates the query to the providers. As each Query object has this identifier, implementations can use this to cache the parsing of the query. In addition to the query object you can pass in query instructions to specify a limit or range for the query. Obviously this is a reduced set compared to the full fledged jcr search api, however it should be suitable for the majority of use cases. [1] https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler/api-v3/src/main/java/org/apache/sling/api/resource/query/ Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Reopened] (SLING-4634) Directly check if view is still current
[ https://issues.apache.org/jira/browse/SLING-4634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reopened SLING-4634: - Reopening due to SLING-4761 Directly check if view is still current --- Key: SLING-4634 URL: https://issues.apache.org/jira/browse/SLING-4634 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Event 3.6.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Event 3.7.0 Currently, the job handler continues until it receives a topology event (changing/changed/init). However , the current view object can directly be checked whether it's current -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4761) Latest view seems to get marked as not current
[ https://issues.apache.org/jira/browse/SLING-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14563449#comment-14563449 ] Carsten Ziegeler commented on SLING-4761: - Forgot one detail: Although this is random (sometimes it seems to work), it's often reproducible Latest view seems to get marked as not current -- Key: SLING-4761 URL: https://issues.apache.org/jira/browse/SLING-4761 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Discovery Impl 1.1.0, Discovery Impl 1.1.2 Reporter: Carsten Ziegeler Fix For: Discovery Impl 1.1.4 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4694) Add ability to identify mime type based on file content
[
https://issues.apache.org/jira/browse/SLING-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14562449#comment-14562449
]
Satya Deep Maheshwari commented on SLING-4694:
--
[~bdelacretaz], thanks for your guidance in taking this to a conclusion.
Marking closed.
Add ability to identify mime type based on file content
---
Key: SLING-4694
URL: https://issues.apache.org/jira/browse/SLING-4694
Project: Sling
Issue Type: Improvement
Components: Servlets
Affects Versions: JCR Webdav 2.2.2
Reporter: Satya Deep Maheshwari
Assignee: Bertrand Delacretaz
Attachments: SLING-4694.patch
*Problem description:* I am facing a problem with the mime type detection of
a file. While debugging, I see that SlingTikaDetector.detect method is used
for detecting the mime type of my file. See [1]. This method just seems to
rely on the name of the file for detecting its mime type. Even though its
passed an inputstream of the file, it does not seem to use it for mime type
detection. So if my file name is something like xyz.tmp, it detects its mime
type as application/octet-stream (the default) while it may actually be a png
file. This is a common scenario with webdav clients wherein temporary files
get created with such names while being edited.
*Suggested Solution:*
Quoting [~rombert]
{quote}
Following the discussions at SLING-1059 [1] and SLING-255 [2] I can
infer that we more or less opted out of the 'heavy-weight' approach of
actually parsing the input stream. Not sure if we want to revisit that
TBH. At any rate, our MimeTypeService does not have an API for getting
the file content based on the input stream.
I think though there's a way around it, but only at the code level.
The org.apache.sling.jcr.webdav.impl.helper.SlingResourceConfig class
hardcodes the Detector implementation to be a SlingTikaDetector.
I think it is worthwile to raise a Jira issue for this and it would
definitely expedite the fix if you're willing to submit a patch / pull
request. I think it can be as simple as adding a @Reference to a Tika
Detector to the SlingWebDavServlet and then passing that to the
SlingServletConfig.
Cheers,
Robert
[1]: https://issues.apache.org/jira/browse/SLING-1059
[2]: https://issues.apache.org/jira/browse/SLING-255
{quote}
Related mailing-list thread on this:
http://apache-sling.73963.n3.nabble.com/mime-type-detection-td4050586.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (SLING-4694) Add ability to identify mime type based on file content
[
https://issues.apache.org/jira/browse/SLING-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Satya Deep Maheshwari closed SLING-4694.
Add ability to identify mime type based on file content
---
Key: SLING-4694
URL: https://issues.apache.org/jira/browse/SLING-4694
Project: Sling
Issue Type: Improvement
Components: Servlets
Affects Versions: JCR Webdav 2.2.2
Reporter: Satya Deep Maheshwari
Assignee: Bertrand Delacretaz
Attachments: SLING-4694.patch
*Problem description:* I am facing a problem with the mime type detection of
a file. While debugging, I see that SlingTikaDetector.detect method is used
for detecting the mime type of my file. See [1]. This method just seems to
rely on the name of the file for detecting its mime type. Even though its
passed an inputstream of the file, it does not seem to use it for mime type
detection. So if my file name is something like xyz.tmp, it detects its mime
type as application/octet-stream (the default) while it may actually be a png
file. This is a common scenario with webdav clients wherein temporary files
get created with such names while being edited.
*Suggested Solution:*
Quoting [~rombert]
{quote}
Following the discussions at SLING-1059 [1] and SLING-255 [2] I can
infer that we more or less opted out of the 'heavy-weight' approach of
actually parsing the input stream. Not sure if we want to revisit that
TBH. At any rate, our MimeTypeService does not have an API for getting
the file content based on the input stream.
I think though there's a way around it, but only at the code level.
The org.apache.sling.jcr.webdav.impl.helper.SlingResourceConfig class
hardcodes the Detector implementation to be a SlingTikaDetector.
I think it is worthwile to raise a Jira issue for this and it would
definitely expedite the fix if you're willing to submit a patch / pull
request. I think it can be as simple as adding a @Reference to a Tika
Detector to the SlingWebDavServlet and then passing that to the
SlingServletConfig.
Cheers,
Robert
[1]: https://issues.apache.org/jira/browse/SLING-1059
[2]: https://issues.apache.org/jira/browse/SLING-255
{quote}
Related mailing-list thread on this:
http://apache-sling.73963.n3.nabble.com/mime-type-detection-td4050586.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4757) Improve test coverage and add integration tests to the contentdetection module
[ https://issues.apache.org/jira/browse/SLING-4757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated SLING-4757: --- Assignee: Petr Shypila Improve test coverage and add integration tests to the contentdetection module -- Key: SLING-4757 URL: https://issues.apache.org/jira/browse/SLING-4757 Project: Sling Issue Type: Improvement Components: Commons Reporter: Bertrand Delacretaz Assignee: Petr Shypila The new SLING-4694 contentdetection module has reasonable test coverage but there are some gaps, and it's also missing some integration tests to verify that the the services provided by the bundle are correctly made available in an OSGI environment. I'll take this opportunity to ask our GSoC student [~petr.shypila] to expand these tests, as that's a good example of what we're trying to do with his tests improvement project. So [~petr.shypila] here's you mission ;-) Buliding bundles/commons/contentdetection with with -Pjacoco-report and looking at target/site/jacoco/index.html shows that a few things are not tested. The first step is to add the missing unit tests to improve that, maybe provide a first patch with just that. Then, we'd like to add integration tests that start this bundle in an OSGi environment and verify that the ContentAwareMimeTypeService and FileNameExtractor services are available and work. No need to duplicate the unit tests, just verify that the services are here and work in a simple case. The best way to do this is probably with Pax Exam, the ResourceBundleProviderIT. is a good example of that and there are other examples in our codebase if you search for *IT.java files that contain pax.exam. As usual, try to minimize changes to the pom (except for what's directly related to testing) and to non-test code. Feel free to ask if you have any questions of course, either here for minor ones or on the dev list for larger discussions. [1] https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/i18n/src/test/java/org/apache/sling/i18n/it/ResourceBundleProviderIT.java -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: SLING-1437 as a part of Google Summer of Code 2015
Hi Petr, On Wed, May 27, 2015 at 11:16 PM, Petr Shypila ikrump...@gmail.com wrote: ...Just want to notify that I have updated my previous report. First for all I have attached a new patch with new unit tests(But I think you should apply previous one as well)... Ok I'll have a look at that later, thanks! You can find an updated patch file on JIRA ticket and wiki page... Please include URLs when you mention these things, otherwise it's hard to make sense of that later in this list's archives. ...As I wrote in my PPP report I'm going start to write new tests for commons.threads module... In the meantime I have a new mission for you that fits well within this phase, see https://issues.apache.org/jira/browse/SLING-4757 and feel free to ask if any question arises! -Bertrand
[jira] [Created] (SLING-4757) Improve test coverage and add integration tests to the contentdetection module
Bertrand Delacretaz created SLING-4757: -- Summary: Improve test coverage and add integration tests to the contentdetection module Key: SLING-4757 URL: https://issues.apache.org/jira/browse/SLING-4757 Project: Sling Issue Type: Improvement Components: Commons Reporter: Bertrand Delacretaz The new SLING-4694 contentdetection module has reasonable test coverage but there are some gaps, and it's also missing some integration tests to verify that the the services provided by the bundle are correctly made available in an OSGI environment. I'll take this opportunity to ask our GSoC student [~petr.shypila] to expand these tests, as that's a good example of what we're trying to do with his tests improvement project. So [~petr.shypila] here's you mission ;-) Buliding bundles/commons/contentdetection with with -Pjacoco-report and looking at target/site/jacoco/index.html shows that a few things are not tested. The first step is to add the missing unit tests to improve that, maybe provide a first patch with just that. Then, we'd like to add integration tests that start this bundle in an OSGi environment and verify that the ContentAwareMimeTypeService and FileNameExtractor services are available and work. No need to duplicate the unit tests, just verify that the services are here and work in a simple case. The best way to do this is probably with Pax Exam, the ResourceBundleProviderIT. is a good example of that and there are other examples in our codebase if you search for *IT.java files that contain pax.exam. As usual, try to minimize changes to the pom (except for what's directly related to testing) and to non-test code. Feel free to ask if you have any questions of course, either here for minor ones or on the dev list for larger discussions. [1] https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/i18n/src/test/java/org/apache/sling/i18n/it/ResourceBundleProviderIT.java -- This message was sent by Atlassian JIRA (v6.3.4#6332)
security risk of allow empty referrer in Apache Sling Referrer Filter
Hi , Checking “Allow Empty” checkbox in Apache Sling Referrer Filter is not recommended in production service. I’d like to know what specific security risks we face if we turn it on for production service. Best Regards, Daniel Sungjin Jung strategic accounts specialist critical situation manager, digital marketing | adobe | •:: +82 (2) 530-8050 | •:: suj...@adobe.commailto:suj...@adobe.com
[jira] [Resolved] (SLING-4758) Make the DEA bundle usable on older Sling installations
[ https://issues.apache.org/jira/browse/SLING-4758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-4758. - Resolution: Fixed Fix Version/s: (was: Distributed Event Admin 1.0.0) Distributed Event Admin 1.0.2 Fixed in rev 1682177 Make the DEA bundle usable on older Sling installations --- Key: SLING-4758 URL: https://issues.apache.org/jira/browse/SLING-4758 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Distributed Event Admin 1.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Distributed Event Admin 1.0.2 The DEA currently requires an R5 framework and a newer Sling API than the old code which was part of the Event bundle. Therefore simply replacing the event bundle with a new version + DEA does not work as it would require to update the framework, Sling API and implementations etc. There is no need for the increase of the dependencies. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4694) Add ability to identify mime type based on file content
[
https://issues.apache.org/jira/browse/SLING-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Delacretaz resolved SLING-4694.
Resolution: Fixed
Assignee: Bertrand Delacretaz
I have cleaned a few things up, the new module is at
https://svn.apache.org/repos/asf/sling/trunk/bundles/commons/contentdetection ,
thanks again for your contribution! Marking this fixed.
Add ability to identify mime type based on file content
---
Key: SLING-4694
URL: https://issues.apache.org/jira/browse/SLING-4694
Project: Sling
Issue Type: Improvement
Components: Servlets
Affects Versions: JCR Webdav 2.2.2
Reporter: Satya Deep Maheshwari
Assignee: Bertrand Delacretaz
Attachments: SLING-4694.patch
*Problem description:* I am facing a problem with the mime type detection of
a file. While debugging, I see that SlingTikaDetector.detect method is used
for detecting the mime type of my file. See [1]. This method just seems to
rely on the name of the file for detecting its mime type. Even though its
passed an inputstream of the file, it does not seem to use it for mime type
detection. So if my file name is something like xyz.tmp, it detects its mime
type as application/octet-stream (the default) while it may actually be a png
file. This is a common scenario with webdav clients wherein temporary files
get created with such names while being edited.
*Suggested Solution:*
Quoting [~rombert]
{quote}
Following the discussions at SLING-1059 [1] and SLING-255 [2] I can
infer that we more or less opted out of the 'heavy-weight' approach of
actually parsing the input stream. Not sure if we want to revisit that
TBH. At any rate, our MimeTypeService does not have an API for getting
the file content based on the input stream.
I think though there's a way around it, but only at the code level.
The org.apache.sling.jcr.webdav.impl.helper.SlingResourceConfig class
hardcodes the Detector implementation to be a SlingTikaDetector.
I think it is worthwile to raise a Jira issue for this and it would
definitely expedite the fix if you're willing to submit a patch / pull
request. I think it can be as simple as adding a @Reference to a Tika
Detector to the SlingWebDavServlet and then passing that to the
SlingServletConfig.
Cheers,
Robert
[1]: https://issues.apache.org/jira/browse/SLING-1059
[2]: https://issues.apache.org/jira/browse/SLING-255
{quote}
Related mailing-list thread on this:
http://apache-sling.73963.n3.nabble.com/mime-type-detection-td4050586.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-4758) Make the DEA bundle usable on older Sling installations
Carsten Ziegeler created SLING-4758: --- Summary: Make the DEA bundle usable on older Sling installations Key: SLING-4758 URL: https://issues.apache.org/jira/browse/SLING-4758 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Distributed Event Admin 1.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Distributed Event Admin 1.0.0 The DEA currently requires an R5 framework and a newer Sling API than the old code which was part of the Event bundle. Therefore simply replacing the event bundle with a new version + DEA does not work as it would require to update the framework, Sling API and implementations etc. There is no need for the increase of the dependencies. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Jenkins build is unstable: sling-trunk-1.7 #1859
See https://builds.apache.org/job/sling-trunk-1.7/1859/changes
[jira] [Commented] (SLING-4694) Add ability to identify mime type based on file content
[
https://issues.apache.org/jira/browse/SLING-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14562602#comment-14562602
]
Bertrand Delacretaz commented on SLING-4694:
I have added some basic docs about this new bundle to
http://sling.apache.org/documentation/bundles/mime-type-support-commons-mime.html
Add ability to identify mime type based on file content
---
Key: SLING-4694
URL: https://issues.apache.org/jira/browse/SLING-4694
Project: Sling
Issue Type: Improvement
Components: Servlets
Affects Versions: JCR Webdav 2.2.2
Reporter: Satya Deep Maheshwari
Assignee: Bertrand Delacretaz
Attachments: SLING-4694.patch
*Problem description:* I am facing a problem with the mime type detection of
a file. While debugging, I see that SlingTikaDetector.detect method is used
for detecting the mime type of my file. See [1]. This method just seems to
rely on the name of the file for detecting its mime type. Even though its
passed an inputstream of the file, it does not seem to use it for mime type
detection. So if my file name is something like xyz.tmp, it detects its mime
type as application/octet-stream (the default) while it may actually be a png
file. This is a common scenario with webdav clients wherein temporary files
get created with such names while being edited.
*Suggested Solution:*
Quoting [~rombert]
{quote}
Following the discussions at SLING-1059 [1] and SLING-255 [2] I can
infer that we more or less opted out of the 'heavy-weight' approach of
actually parsing the input stream. Not sure if we want to revisit that
TBH. At any rate, our MimeTypeService does not have an API for getting
the file content based on the input stream.
I think though there's a way around it, but only at the code level.
The org.apache.sling.jcr.webdav.impl.helper.SlingResourceConfig class
hardcodes the Detector implementation to be a SlingTikaDetector.
I think it is worthwile to raise a Jira issue for this and it would
definitely expedite the fix if you're willing to submit a patch / pull
request. I think it can be as simple as adding a @Reference to a Tika
Detector to the SlingWebDavServlet and then passing that to the
SlingServletConfig.
Cheers,
Robert
[1]: https://issues.apache.org/jira/browse/SLING-1059
[2]: https://issues.apache.org/jira/browse/SLING-255
{quote}
Related mailing-list thread on this:
http://apache-sling.73963.n3.nabble.com/mime-type-detection-td4050586.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4757) Improve test coverage and add integration tests to the contentdetection module
[ https://issues.apache.org/jira/browse/SLING-4757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated SLING-4757: --- Description: The new SLING-4694 contentdetection module has reasonable test coverage but there are some gaps, and it's also missing some integration tests to verify that the services provided by the bundle are correctly made available in an OSGI environment. I'll take this opportunity to ask our GSoC student [~petr.shypila] to expand these tests, as that's a good example of what we're trying to do with his tests improvement project. So [~petr.shypila] here's your mission ;-) Buliding bundles/commons/contentdetection with with -Pjacoco-report and looking at target/site/jacoco/index.html shows that a few things are not tested. The first step is to add the missing unit tests to improve that, maybe provide a first patch with just that. Then, we'd like to add integration tests that start this bundle in an OSGi environment and verify that the ContentAwareMimeTypeService and FileNameExtractor services are available and work. No need to duplicate the unit tests, just verify that the services are here and work in a simple case. The best way to do this is probably with Pax Exam, the ResourceBundleProviderIT. is a good example of that and there are other examples in our codebase if you search for *IT.java files that contain pax.exam. As usual, try to minimize changes to the pom (except for what's directly related to testing) and to non-test code. Feel free to ask if you have any questions of course, either here for minor ones or on the dev list for larger discussions. [1] https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/i18n/src/test/java/org/apache/sling/i18n/it/ResourceBundleProviderIT.java was: The new SLING-4694 contentdetection module has reasonable test coverage but there are some gaps, and it's also missing some integration tests to verify that the the services provided by the bundle are correctly made available in an OSGI environment. I'll take this opportunity to ask our GSoC student [~petr.shypila] to expand these tests, as that's a good example of what we're trying to do with his tests improvement project. So [~petr.shypila] here's you mission ;-) Buliding bundles/commons/contentdetection with with -Pjacoco-report and looking at target/site/jacoco/index.html shows that a few things are not tested. The first step is to add the missing unit tests to improve that, maybe provide a first patch with just that. Then, we'd like to add integration tests that start this bundle in an OSGi environment and verify that the ContentAwareMimeTypeService and FileNameExtractor services are available and work. No need to duplicate the unit tests, just verify that the services are here and work in a simple case. The best way to do this is probably with Pax Exam, the ResourceBundleProviderIT. is a good example of that and there are other examples in our codebase if you search for *IT.java files that contain pax.exam. As usual, try to minimize changes to the pom (except for what's directly related to testing) and to non-test code. Feel free to ask if you have any questions of course, either here for minor ones or on the dev list for larger discussions. [1] https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/i18n/src/test/java/org/apache/sling/i18n/it/ResourceBundleProviderIT.java Improve test coverage and add integration tests to the contentdetection module -- Key: SLING-4757 URL: https://issues.apache.org/jira/browse/SLING-4757 Project: Sling Issue Type: Improvement Components: Commons Reporter: Bertrand Delacretaz Assignee: Petr Shypila The new SLING-4694 contentdetection module has reasonable test coverage but there are some gaps, and it's also missing some integration tests to verify that the services provided by the bundle are correctly made available in an OSGI environment. I'll take this opportunity to ask our GSoC student [~petr.shypila] to expand these tests, as that's a good example of what we're trying to do with his tests improvement project. So [~petr.shypila] here's your mission ;-) Buliding bundles/commons/contentdetection with with -Pjacoco-report and looking at target/site/jacoco/index.html shows that a few things are not tested. The first step is to add the missing unit tests to improve that, maybe provide a first patch with just that. Then, we'd like to add integration tests that start this bundle in an OSGi environment and verify that the ContentAwareMimeTypeService and FileNameExtractor services are available and work. No need to duplicate the unit tests, just verify that the services are here and work in a simple case.
[GSoC] 3P project reporting
Hi Petr, On Wednesday, May 27, 2015, Petr Shypila ikrump...@gmail.com wrote: ...Just want to notify that I have updated my previous report.. Thanks very much, I have reviewed [1] now. The idea with the 3P reports is a bit different: I'd like you to provide a new report (Progress, Problems, Perspectives) every week, as a timeline of what you did, and you don't modify them once they are entered. That creates a useful trace of what you did, and can help other GSoC students or Sling contributors see how you found your way into our codebase. It basically writes the high-level history of your project. You can either add those at the end of [1], or create a subpage for the reports if you prefer. For now I have reformatted your report there to reflect what I'd like to see, and removed some parts that I felt were too detailed - the details should be in the jira tickets as needed. But we aim for minimal, useful reporting, let's not create more process than strictly needed. Feel free to tweak/move it as appropriate of course in this phase of defining how you're going to report. In the problems section I see mostly technical questions, those should come here, one thread per question. The 3P problems section is more for high-level things like the cat ate my router and I had no Internet for 2 days or other big issues that prevent you from progressing. Thanks very much for your work so far! -Bertrand [1] https://cwiki.apache.org/confluence/display/SLING/GSoC+2015.+%5BSLING-1437%5D+Unit+and+Integration+tests
Jenkins build is back to stable : sling-trunk-1.8 #1150
See https://builds.apache.org/job/sling-trunk-1.8/1150/changes
Re: security risk of allow empty referrer in Apache Sling Referrer Filter
Hello Daniel On 28.05.2015 10:11, Daniel Sungjin Jung wrote: Checking “Allow Empty” checkbox in Apache Sling Referrer Filter is not recommended in production service. I’d like to know what specific security risks we face if we turn it on for production service. Apart from the obvious cases (bugs in browser/plugins, MitM) which allow for HTTP header manipulation but often allow complete circumvention of CSRF protections anyway, there have been several cases where it was possible to strip the referrer header client-side using some tricks with javascript and iframes (e.g. [0], [1]). Best greetings Lars [0] http://homakov.blogspot.com/2012/04/playing-with-referer-origin-disquscom.html [1] http://webstersprodigy.net/2013/02/01/stripping-the-referer-in-a-cross-domain-post-request/
Moving to Java 7 ( was: Make ResourceResolver implement Closeable)
This might've been buried under the 'Closeable' thread so resending so that it does not suprise anyone. Currently our projects can use either Java 5 or 6, with 5 being the default. This is very much out of date and we're missing out on language improvements. I would suggest changing the supported Java versions from - 5 (default), 6 - 6, 7 (default) I would have preferred - 6, 7 (default), 8 But Java 8 support is blocked due to SLING-4702 [1]. Thoughts on the proposed change for the supported Java versions? Cheers, Robert [1]: https://issues.apache.org/jira/browse/SLING-4702 On Tue, 2015-05-26 at 16:38 +0200, Carsten Ziegeler wrote: Am 26.05.15 um 16:14 schrieb Robert Munteanu: Hi Roy, On Tue, 2015-05-26 at 15:51 +0200, Roy Teeuwen wrote: Hello, As of Java 7, it is possible by implementing the Closeable or AutoCloseable to use the try-with-resources statement. This makes the notation a lot shorter than the try-finally block. Is there a reason that the ResourceResolver does not implement the Closeable interface, and would it be possible to let it implement it? We should just move to Java 7 by default. +1 Carsten
Jenkins build is still unstable: sling-contrib-1.7 #125
See https://builds.apache.org/job/sling-contrib-1.7/changes
[jira] [Commented] (SLING-4757) Improve test coverage and add integration tests to the contentdetection module
[ https://issues.apache.org/jira/browse/SLING-4757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14562564#comment-14562564 ] Bertrand Delacretaz commented on SLING-4757: We should also check that the jacoco report takes the integration tests into account. I think it should be the case but we need to check it. Improve test coverage and add integration tests to the contentdetection module -- Key: SLING-4757 URL: https://issues.apache.org/jira/browse/SLING-4757 Project: Sling Issue Type: Improvement Components: Commons Reporter: Bertrand Delacretaz Assignee: Petr Shypila The new SLING-4694 contentdetection module has reasonable test coverage but there are some gaps, and it's also missing some integration tests to verify that the services provided by the bundle are correctly made available in an OSGI environment. I'll take this opportunity to ask our GSoC student [~petr.shypila] to expand these tests, as that's a good example of what we're trying to do with his tests improvement project. So [~petr.shypila] here's your mission ;-) Buliding bundles/commons/contentdetection with with -Pjacoco-report and looking at target/site/jacoco/index.html shows that a few things are not tested. The first step is to add the missing unit tests to improve that, maybe provide a first patch with just that. Then, we'd like to add integration tests that start this bundle in an OSGi environment and verify that the ContentAwareMimeTypeService and FileNameExtractor services are available and work. No need to duplicate the unit tests, just verify that the services are here and work in a simple case. The best way to do this is probably with Pax Exam, the ResourceBundleProviderIT. is a good example of that and there are other examples in our codebase if you search for *IT.java files that contain pax.exam. As usual, try to minimize changes to the pom (except for what's directly related to testing) and to non-test code. Feel free to ask if you have any questions of course, either here for minor ones or on the dev list for larger discussions. [1] https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/i18n/src/test/java/org/apache/sling/i18n/it/ResourceBundleProviderIT.java -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4735) New tests for commons.scheduler module
[ https://issues.apache.org/jira/browse/SLING-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz resolved SLING-4735. Thanks very much, I have committed your tests in http://svn.apache.org/r1682221 - please cross-check. I made minor changes to the pom to avoid snapshots and avoid depending on maven-scm-client which is not needed AFAICS. I have also improved the WebConsolePrinterTest in http://svn.apache.org/r1682225 to use less fragile regular expressions matching. Please use this technique where appropriate in the future, as exact matches are more likely to break if behavior changes just slightly in the future. Test coverage is good now, marking this fixed. Note that you can overwrite jira attachments by re-uploading a file with the same name, that's useful if you revise your patches as we go. New tests for commons.scheduler module -- Key: SLING-4735 URL: https://issues.apache.org/jira/browse/SLING-4735 Project: Sling Issue Type: Test Components: Commons Reporter: Petr Shypila Assignee: Petr Shypila Priority: Minor Labels: gsoc2015 Attachments: week0-commons-scheduler-tests.patch, week0-ver2.patch In scope of this issue I should cover commons.scheduler module with unit and integration tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Jenkins build became unstable: sling-trunk-1.8 #1151
See https://builds.apache.org/job/sling-trunk-1.8/1151/changes
[jira] [Resolved] (SLING-4759) Queue might be closed while job is waiting for retry
[ https://issues.apache.org/jira/browse/SLING-4759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-4759. - Added extra guard in rev 1682229 Queue might be closed while job is waiting for retry Key: SLING-4759 URL: https://issues.apache.org/jira/browse/SLING-4759 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Event 3.5.4, Event 3.6.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Event 3.7.0 If a job is waiting for a retry (using the scheduler), the queue might be closed. As jobs are periodically retried this is since 3.6.0 no problem, however not optimal either as the job has to wait for the periodic retry. It would be better to not close the job in this situation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Jenkins build is still unstable: sling-contrib-1.7 #126
See https://builds.apache.org/job/sling-contrib-1.7/changes
Jenkins build is still unstable: sling-trunk-1.7 #1860
See https://builds.apache.org/job/sling-trunk-1.7/changes
Jenkins build is still unstable: sling-contrib-1.7 #127
See https://builds.apache.org/job/sling-contrib-1.7/changes
Jenkins build is still unstable: sling-trunk-1.7 #1861
See https://builds.apache.org/job/sling-trunk-1.7/changes
[jira] [Comment Edited] (SLING-4757) Improve test coverage and add integration tests to the contentdetection module
[ https://issues.apache.org/jira/browse/SLING-4757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14562564#comment-14562564 ] Bertrand Delacretaz edited comment on SLING-4757 at 5/28/15 3:00 PM: - We should also check that the jacoco report takes the integration tests into account. I think it should be the case but we need to check it. _Update: see SLING-4760 about this_. was (Author: bdelacretaz): We should also check that the jacoco report takes the integration tests into account. I think it should be the case but we need to check it. Improve test coverage and add integration tests to the contentdetection module -- Key: SLING-4757 URL: https://issues.apache.org/jira/browse/SLING-4757 Project: Sling Issue Type: Improvement Components: Commons Reporter: Bertrand Delacretaz Assignee: Petr Shypila The new SLING-4694 contentdetection module has reasonable test coverage but there are some gaps, and it's also missing some integration tests to verify that the services provided by the bundle are correctly made available in an OSGI environment. I'll take this opportunity to ask our GSoC student [~petr.shypila] to expand these tests, as that's a good example of what we're trying to do with his tests improvement project. So [~petr.shypila] here's your mission ;-) Buliding bundles/commons/contentdetection with with -Pjacoco-report and looking at target/site/jacoco/index.html shows that a few things are not tested. The first step is to add the missing unit tests to improve that, maybe provide a first patch with just that. Then, we'd like to add integration tests that start this bundle in an OSGi environment and verify that the ContentAwareMimeTypeService and FileNameExtractor services are available and work. No need to duplicate the unit tests, just verify that the services are here and work in a simple case. The best way to do this is probably with Pax Exam, the ResourceBundleProviderIT. is a good example of that and there are other examples in our codebase if you search for *IT.java files that contain pax.exam. As usual, try to minimize changes to the pom (except for what's directly related to testing) and to non-test code. Feel free to ask if you have any questions of course, either here for minor ones or on the dev list for larger discussions. [1] https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/i18n/src/test/java/org/apache/sling/i18n/it/ResourceBundleProviderIT.java -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Jenkins build is still unstable: sling-trunk-1.8 #1152
See https://builds.apache.org/job/sling-trunk-1.8/changes
[jira] [Created] (SLING-4760) jacoco-report Maven profile should aggregate unit and integration tests
Bertrand Delacretaz created SLING-4760:
--
Summary: jacoco-report Maven profile should aggregate unit and
integration tests
Key: SLING-4760
URL: https://issues.apache.org/jira/browse/SLING-4760
Project: Sling
Issue Type: Improvement
Components: Testing
Reporter: Bertrand Delacretaz
Assignee: Bertrand Delacretaz
Priority: Minor
Fix For: Parent 23
The {{jacoco-report}} profile defined in our parent pom should aggregate unit
and integration tests of a given module so that we can get the full test
coverage picture.
This won't take into account the launchpad integration tests, but I think over
time we should move (at least most of) those tests to the relevant modules
anyway.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-4760) jacoco-report Maven profile should aggregate unit and integration tests
[
https://issues.apache.org/jira/browse/SLING-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Delacretaz resolved SLING-4760.
Resolution: Fixed
Implemented in http://svn.apache.org/r1682257 - with this, {{mvn clean install
-P jacoco-report}} provides up to 3 coverage reports:
* target/site/jacoco-unit: unit tests coverage
* target/site/jacoco-it: integration tests coverage
* target/site/jacoco-merged: aggregate test coverage
The jacoco-it report is absent if there are no integration tests.
This is in the 23-SNAPSHOT parent pom, so to use it for now you'll need to set
that version in your module's pom, and {{mvn clean install}} that parent pom.
jacoco-report Maven profile should aggregate unit and integration tests
---
Key: SLING-4760
URL: https://issues.apache.org/jira/browse/SLING-4760
Project: Sling
Issue Type: Improvement
Components: Testing
Reporter: Bertrand Delacretaz
Assignee: Bertrand Delacretaz
Priority: Minor
Fix For: Parent 23
The {{jacoco-report}} profile defined in our parent pom should aggregate unit
and integration tests of a given module so that we can get the full test
coverage picture.
This won't take into account the launchpad integration tests, but I think
over time we should move (at least most of) those tests to the relevant
modules anyway.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [RT] New resource query API
On 27.05.2015, at 01:35, Bertrand Delacretaz bdelacre...@apache.org wrote: I'm happy to collaborate on creating these examples (which can simply be unit tests for a relevant ResourceProvider) but before that I'd like to discuss what the alternatives are, before we invent YAQA (*). We have the querybuilder [1] in our CQ/AEM product, we could contribute this to Sling, I think (pending internal legal processes of course). [1] https://docs.adobe.com/docs/en/aem/6-1/develop/search/querybuilder-api.html Cheers, Alex
Re: [RT] New resource query API
Am 28.05.15 um 18:25 schrieb Alexander Klimetschek: On 27.05.2015, at 01:35, Bertrand Delacretaz bdelacre...@apache.org wrote: I'm happy to collaborate on creating these examples (which can simply be unit tests for a relevant ResourceProvider) but before that I'd like to discuss what the alternatives are, before we invent YAQA (*). We have the querybuilder [1] in our CQ/AEM product, we could contribute this to Sling, I think (pending internal legal processes of course). I guess that would be nice, but isnt the query builder an http api? How is that translated to resource queries? Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
RE: Moving to Java 7 ( was: Make ResourceResolver implement Closeable)
why not drop Java 6 support for new released bundles at all? +1 for using Java 7 as default and minimum Java version. stefan -Original Message- From: Robert Munteanu [mailto:romb...@apache.org] Sent: Thursday, May 28, 2015 11:58 AM To: dev@sling.apache.org Subject: Moving to Java 7 ( was: Make ResourceResolver implement Closeable) This might've been buried under the 'Closeable' thread so resending so that it does not suprise anyone. Currently our projects can use either Java 5 or 6, with 5 being the default. This is very much out of date and we're missing out on language improvements. I would suggest changing the supported Java versions from - 5 (default), 6 - 6, 7 (default) I would have preferred - 6, 7 (default), 8 But Java 8 support is blocked due to SLING-4702 [1]. Thoughts on the proposed change for the supported Java versions? Cheers, Robert [1]: https://issues.apache.org/jira/browse/SLING-4702 On Tue, 2015-05-26 at 16:38 +0200, Carsten Ziegeler wrote: Am 26.05.15 um 16:14 schrieb Robert Munteanu: Hi Roy, On Tue, 2015-05-26 at 15:51 +0200, Roy Teeuwen wrote: Hello, As of Java 7, it is possible by implementing the Closeable or AutoCloseable to use the try-with-resources statement. This makes the notation a lot shorter than the try-finally block. Is there a reason that the ResourceResolver does not implement the Closeable interface, and would it be possible to let it implement it? We should just move to Java 7 by default. +1 Carsten
Jenkins build is still unstable: sling-trunk-1.8 #1153
See https://builds.apache.org/job/sling-trunk-1.8/changes
