Re: [VOTE] Release Apache Sling i18n 2.4.8
+1 Ian On 5 August 2016 at 06:08, Carsten Ziegeler wrote: > Hi, we're missing one binding vote, anyone please? > > Thanks > > Carsten > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org > > >
Re: [VOTE] Release Apache Sling Feature Flags 1.1.0
+1 Ian On 5 August 2016 at 06:08, Carsten Ziegeler wrote: > Hi, we're missing one binding vote, anyone please? > > Thanks > Carsten > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org > >
[jira] [Assigned] (SLING-5948) Support Streaming uploads.
[ https://issues.apache.org/jira/browse/SLING-5948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston reassigned SLING-5948: - Assignee: Ian Boston > Support Streaming uploads. > -- > > Key: SLING-5948 > URL: https://issues.apache.org/jira/browse/SLING-5948 > Project: Sling > Issue Type: Bug > Components: Engine >Affects Versions: Engine 2.5.0 >Reporter: Ian Boston >Assignee: Ian Boston > > Currently multipart POST request made to sling use the commons file upload > component that parses the request fully before processing. If uploads are > small they are stored in byte[], over a configurable limit they are sent to > disk. This creates additional IO overhead, increases heap usage and increases > upload time. > Having searched the SLing jira, and sling-dev I have failed to find an issue > relating to this area, although it has been discussed in the past. > I have 2 proposals. > The SlingMain Servlet processes all requests, identifying the request type > and parsing the request body. If the body is multipart the Commons File > Upload library is used to process the request body in full when the > SlingServletRequest is created or the first parameter is requested. To enable > streaming of a request this behaviour needs to be modified. Unfortunately, > processing a streamed request requires that the ultimate processor requests > multipar parts in a the correct order to avoid non streaming, so a streaming > behaviour will not be suitable for most POST requests and can only be used if > the ultimate Servlet has been written to process a stream rather than a map > of parameters. > Both proposals need to identify requests that should be processed as a > stream. This identification must happen in the headers or URI as any > identification later than the headers may be too late. Something like a > custom header (x-uploadmode: stream) or a query string (?uploadmode=stream) > or possibly a selector (/path/to/target.stream) would work and each have > advantages and disadvantages. > h1. Proposal 1 > When a POST request is identified as multipart and streaming, create a > LazyParameterMap that uses the Commons File Upload Streaming API > (https://commons.apache.org/proper/commons-fileupload/streaming.html) to > process the request on demand as parameters are requested. If parameters are > requested out of sequence, do something sensible attempting to maintain > streaming behaviour, but if the code really breaks streaming, throw an > exception to alert servlet developer early. > h2. Pros > * Follows a similar pattern to currently using the Servlet API. > h2. Cons > * [] params will be hard to support when the [] is out of order, and almost > impossible if the [] is an upload body. > * May not work when a request is routed incorrectly as getParameter requests > will be out of streaming sequence. > h2. Proposal 2 > When a POST request is identified as multipart and streaming, create a > NullParameterMap that returns null for all parameter get operations. In > addition set a request Attribute containing a RequestStream API object that > allows access to the request stream in a similar way to the Commons File > Upload Streaming API. Servlets that process uploads streams will use the > RequestStream API object retrieved from the request. > h2. Pros > * Won't get broken by existing getParameter calls, which all return null and > do no harm to the stream. > * Far simpler implementation as the Servlet implementation has to get the > request data in streaming order. > h2. Cons > * Requires new API Objects. > To support both methods a standard Servlet to handle streamed uploads would > be needed, connecting the file request stream to the Resource output stream. > In some cases (Oak S3 DS Async Uploads, Mongo DS) this wont entirely > eliminate local disk IO, although in most cases the Resource output stream > wrapps the final output stream. To maintain streaming a save operation may > need to be performed for each upload to cause the request stream to be read. > If this is a duplicate issue, please link. > If you have input, please share. > Have some patches in progress, would prefer Proposal 2, as Proposal 1 looks > messy at the moment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-5948) Support Streaming uploads.
Ian Boston created SLING-5948: - Summary: Support Streaming uploads. Key: SLING-5948 URL: https://issues.apache.org/jira/browse/SLING-5948 Project: Sling Issue Type: Bug Components: Engine Affects Versions: Engine 2.5.0 Reporter: Ian Boston Currently multipart POST request made to sling use the commons file upload component that parses the request fully before processing. If uploads are small they are stored in byte[], over a configurable limit they are sent to disk. This creates additional IO overhead, increases heap usage and increases upload time. Having searched the SLing jira, and sling-dev I have failed to find an issue relating to this area, although it has been discussed in the past. I have 2 proposals. The SlingMain Servlet processes all requests, identifying the request type and parsing the request body. If the body is multipart the Commons File Upload library is used to process the request body in full when the SlingServletRequest is created or the first parameter is requested. To enable streaming of a request this behaviour needs to be modified. Unfortunately, processing a streamed request requires that the ultimate processor requests multipar parts in a the correct order to avoid non streaming, so a streaming behaviour will not be suitable for most POST requests and can only be used if the ultimate Servlet has been written to process a stream rather than a map of parameters. Both proposals need to identify requests that should be processed as a stream. This identification must happen in the headers or URI as any identification later than the headers may be too late. Something like a custom header (x-uploadmode: stream) or a query string (?uploadmode=stream) or possibly a selector (/path/to/target.stream) would work and each have advantages and disadvantages. h1. Proposal 1 When a POST request is identified as multipart and streaming, create a LazyParameterMap that uses the Commons File Upload Streaming API (https://commons.apache.org/proper/commons-fileupload/streaming.html) to process the request on demand as parameters are requested. If parameters are requested out of sequence, do something sensible attempting to maintain streaming behaviour, but if the code really breaks streaming, throw an exception to alert servlet developer early. h2. Pros * Follows a similar pattern to currently using the Servlet API. h2. Cons * [] params will be hard to support when the [] is out of order, and almost impossible if the [] is an upload body. * May not work when a request is routed incorrectly as getParameter requests will be out of streaming sequence. h2. Proposal 2 When a POST request is identified as multipart and streaming, create a NullParameterMap that returns null for all parameter get operations. In addition set a request Attribute containing a RequestStream API object that allows access to the request stream in a similar way to the Commons File Upload Streaming API. Servlets that process uploads streams will use the RequestStream API object retrieved from the request. h2. Pros * Won't get broken by existing getParameter calls, which all return null and do no harm to the stream. * Far simpler implementation as the Servlet implementation has to get the request data in streaming order. h2. Cons * Requires new API Objects. To support both methods a standard Servlet to handle streamed uploads would be needed, connecting the file request stream to the Resource output stream. In some cases (Oak S3 DS Async Uploads, Mongo DS) this wont entirely eliminate local disk IO, although in most cases the Resource output stream wrapps the final output stream. To maintain streaming a save operation may need to be performed for each upload to cause the request stream to be read. If this is a duplicate issue, please link. If you have input, please share. Have some patches in progress, would prefer Proposal 2, as Proposal 1 looks messy at the moment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release Apache Sling i18n 2.4.8
Hi, we're missing one binding vote, anyone please? Thanks Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org signature.asc Description: OpenPGP digital signature
Re: [VOTE] Release Apache Sling Feature Flags 1.1.0
Hi, we're missing one binding vote, anyone please? Thanks Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Commented] (SLING-1172) Allow uploading JSON files to create content structures
[ https://issues.apache.org/jira/browse/SLING-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15408083#comment-15408083 ] Dan Bourque commented on SLING-1172: Nice work! Could someone update the Confluence site's FAQ at https://cwiki.apache.org/confluence/display/SLING/FAQ#FAQ-HowdoIcreateanodebypostingajsondocumenttoaURL? > Allow uploading JSON files to create content structures > --- > > Key: SLING-1172 > URL: https://issues.apache.org/jira/browse/SLING-1172 > Project: Sling > Issue Type: New Feature > Components: Servlets >Affects Versions: Servlets Post 2.0.4 >Reporter: Felix Meschberger >Assignee: Eric Norman > Fix For: Servlets Post 2.1.0, JCR ContentLoader 2.1.0 > > > Currently uploading a JSON file will just create the file node. > On the other hand it would be useful if uploading to a node with a request > extension of JSON, the JSON would be unpacked and handled as if it would be a > modification request with the JSON data being the content to store. > This would be similar to JSON upload supported by CouchDB. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-5815) Expose DistributionContentSerializer
[
https://issues.apache.org/jira/browse/SLING-5815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili updated SLING-5815:
---
Attachment: SLING-5815.1.patch
attached additional draft patch (for distribution.core only) with
{{DistributionExportOptions}} holding a {{DistributionExportFilter}}.
The good part of this approach is that the resource tree is not traversed
before serialization happens, it mimics a bit the VLT filters, but can be
reused for other formats without introducing a dependency on VLT. The not so
good part is that for {{FileVaultContentSerializer}} it requires to remap the
{{DistributionExportFilter}} into a {{WorkspaceFilter}}; as a mitigation we
could keep the {{DistributionRequest}} inside the {{DistributionExportOptions}}
so that VLT serialization can better leverage that while other formats would
use the information contained in the {{DistributionExportFIlter}}.
Not going the {{ResourceMapper}} way until we can clarify a bit further
expected usage.
> Expose DistributionContentSerializer
> -
>
> Key: SLING-5815
> URL: https://issues.apache.org/jira/browse/SLING-5815
> Project: Sling
> Issue Type: Improvement
> Components: Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution 0.2.0
>
> Attachments: SLING-5815.0.patch, SLING-5815.1.patch
>
>
> Expose {{DistributionContentSerializer}} API from
> _org.apache.sling.distribution.core_ in order to allow implementation of
> custom serialization formats (e.g. Avro and Kryo defined in
> _org.apache.sling.distribution.extensions_).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-5730) Avoid creating a File of a package when it's small enough to fit in memory
[
https://issues.apache.org/jira/browse/SLING-5730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi updated SLING-5730:
--
Attachment: SLING-5730.4.patch
Hi again [~teofili],
please have a look at a new improvement in the latest patch: when swapping to
file, rather than re-writing the whole in-memory data to the tmp file, only the
resting data will be written on disk... it should help improving the
performances.
HTH, please let me know if more work is required in order to improve that
feature!
> Avoid creating a File of a package when it's small enough to fit in memory
> --
>
> Key: SLING-5730
> URL: https://issues.apache.org/jira/browse/SLING-5730
> Project: Sling
> Issue Type: Improvement
> Components: Distribution
>Reporter: Tommaso Teofili
>Assignee: Simone Tripodi
> Fix For: Content Distribution 0.2.0
>
> Attachments: SLING-5730.1.patch, SLING-5730.2.patch,
> SLING-5730.3.patch, SLING-5730.4.patch, SLING-5730.patch
>
>
> {{ResourcePackageBuilder}} creates a temporary file holding the actual
> package stream, it'd be good to avoid that when the size of the stream is
> small enough to quickly fit into memory.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-5866) DefaultGetServlet obtains input stream for binary even if request is a HEAD
[ https://issues.apache.org/jira/browse/SLING-5866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz resolved SLING-5866. Resolution: Fixed Assignee: Bertrand Delacretaz Fix Version/s: Servlets Get 2.1.18 I have applied your patch in http://svn.apache.org/r1755178 , thanks very much for your contribution! > DefaultGetServlet obtains input stream for binary even if request is a HEAD > --- > > Key: SLING-5866 > URL: https://issues.apache.org/jira/browse/SLING-5866 > Project: Sling > Issue Type: Improvement > Components: Servlets >Affects Versions: Servlets Get 2.1.14 >Reporter: Ankit Agarwal >Assignee: Bertrand Delacretaz > Fix For: Servlets Get 2.1.18 > > > As per current implementation any HEAD request will be handled by > defaultHeadServlet which majorly does two changes > 1.) coverts response output stream to be null so that there should be no > message body in response > 2.) coverts HEAD request to GET request. > Now this request is dispatched and served by defaultGetServlet. > With this approach, we get the desired output but response is delayed as it > reads the complete binary data of a resource. and also it increases data > transfer which is not needed. > So IMO this approach should be improved. > thanks, -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5886) Sling Context-Aware Configuration - Initial Contribution
[ https://issues.apache.org/jira/browse/SLING-5886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15407671#comment-15407671 ] Carsten Ziegeler commented on SLING-5886: - I didn't commit the SPI interfaces as I'm not sure about those, but we can definitely discuss them I've also changed the adapter factory as I think that the flexible version might cause trouble over time, you can now adapt to the configuration builder and convert to the wanted classes - this is not that elegant, but I think it's causing less trouble - but again something we can discuss > Sling Context-Aware Configuration - Initial Contribution > > > Key: SLING-5886 > URL: https://issues.apache.org/jira/browse/SLING-5886 > Project: Sling > Issue Type: New Feature > Components: Extensions >Reporter: Stefan Seifert >Assignee: Stefan Seifert > > as discussed in the mailing list (see [my post from april > 2016|http://apache-sling.73963.n3.nabble.com/RT-Use-cases-for-content-specific-configurations-in-Sling-amp-Contribution-td4060813.html]) > i want to contribute the wcm.io Configuration parts that are not > AEM-specific. > the current features of wcm.io Configuration are described here: > http://wcm.io/config/ > the main goal is to support "context-specific" configuration, that means > configuration that is different for different content paths (e.g. sites, > tenants). > during the contribution some changes and refactorings are required/planned, > e.g.: > * remove some dependencies to wcm.io build environment, Guava and others > * remove the "application" distinction currently part of wcm.io Configuration > in favor or a more path-based distinction > * refactor the user-faced configuration API to further simplify it and > support OSGi R6-style annotation classed for typed configuration access > _Update: as discussed at http://sling.markmail.org/thread/ka3ewlswfgjy7rpu > the name of this new module is Context-Aware Configuration_ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5886) Sling Context-Aware Configuration - Initial Contribution
[ https://issues.apache.org/jira/browse/SLING-5886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15407630#comment-15407630 ] Carsten Ziegeler commented on SLING-5886: - I've added a first implementation with tests for the resource resolving. Tests for creating the configuration objects will follow - this depends a little bit on the progression of the Converter service implementation which will provide the heavy lifting for us. Also added a simple web console plugin I think we need to discuss some things in the API (things like is null an allowed return value etc.) > Sling Context-Aware Configuration - Initial Contribution > > > Key: SLING-5886 > URL: https://issues.apache.org/jira/browse/SLING-5886 > Project: Sling > Issue Type: New Feature > Components: Extensions >Reporter: Stefan Seifert >Assignee: Stefan Seifert > > as discussed in the mailing list (see [my post from april > 2016|http://apache-sling.73963.n3.nabble.com/RT-Use-cases-for-content-specific-configurations-in-Sling-amp-Contribution-td4060813.html]) > i want to contribute the wcm.io Configuration parts that are not > AEM-specific. > the current features of wcm.io Configuration are described here: > http://wcm.io/config/ > the main goal is to support "context-specific" configuration, that means > configuration that is different for different content paths (e.g. sites, > tenants). > during the contribution some changes and refactorings are required/planned, > e.g.: > * remove some dependencies to wcm.io build environment, Guava and others > * remove the "application" distinction currently part of wcm.io Configuration > in favor or a more path-based distinction > * refactor the user-faced configuration API to further simplify it and > support OSGi R6-style annotation classed for typed configuration access > _Update: as discussed at http://sling.markmail.org/thread/ka3ewlswfgjy7rpu > the name of this new module is Context-Aware Configuration_ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-5947) MockSlingHttpServletRequest used with SlingRequestProcessor causes UnsupportedOperationException
Dirk Rudolph created SLING-5947:
---
Summary: MockSlingHttpServletRequest used with
SlingRequestProcessor causes UnsupportedOperationException
Key: SLING-5947
URL: https://issues.apache.org/jira/browse/SLING-5947
Project: Sling
Issue Type: Bug
Components: Extensions
Affects Versions: Servlet Helpers 1.0.0
Reporter: Dirk Rudolph
Fix For: Servlet Helpers 1.0.2
{{getServletPath() throws the UnsupportedOperationException in
MockSlingHttpServletRequest
http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/servlet-helpers/src/main/java/org/apache/sling/servlethelpers/MockSlingHttpServletRequest.java?revision=1728734&view=markup#l685
It gets called from the SlingHttpServletRequestImpl constructor
http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/SlingHttpServletRequestImpl.java?view=markup#l71
causing the following stacktrace:
{code}
Caused by: java.lang.UnsupportedOperationException: null
at
org.apache.sling.servlethelpers.MockSlingHttpServletRequest.getServletPath(MockSlingHttpServletRequest.java:685)
at
org.apache.sling.engine.impl.SlingHttpServletRequestImpl.(SlingHttpServletRequestImpl.java:71)
at
org.apache.sling.engine.impl.request.RequestData$1.createRequest(RequestData.java:700)
at
org.apache.sling.engine.impl.request.RequestData.(RequestData.java:215)
at
org.apache.sling.engine.impl.SlingRequestProcessorImpl.doProcessRequest(SlingRequestProcessorImpl.java:121)
at
org.apache.sling.engine.impl.SlingRequestProcessorImpl.processRequest(SlingRequestProcessorImpl.java:247)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-5947) MockSlingHttpServletRequest used with SlingRequestProcessor causes UnsupportedOperationException
[
https://issues.apache.org/jira/browse/SLING-5947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated SLING-5947:
Description:
{{getServletPath()}} throws the UnsupportedOperationException in
MockSlingHttpServletRequest
http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/servlet-helpers/src/main/java/org/apache/sling/servlethelpers/MockSlingHttpServletRequest.java?revision=1728734&view=markup#l685
It gets called from the SlingHttpServletRequestImpl constructor
http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/SlingHttpServletRequestImpl.java?view=markup#l71
causing the following stacktrace:
{code}
Caused by: java.lang.UnsupportedOperationException: null
at
org.apache.sling.servlethelpers.MockSlingHttpServletRequest.getServletPath(MockSlingHttpServletRequest.java:685)
at
org.apache.sling.engine.impl.SlingHttpServletRequestImpl.(SlingHttpServletRequestImpl.java:71)
at
org.apache.sling.engine.impl.request.RequestData$1.createRequest(RequestData.java:700)
at
org.apache.sling.engine.impl.request.RequestData.(RequestData.java:215)
at
org.apache.sling.engine.impl.SlingRequestProcessorImpl.doProcessRequest(SlingRequestProcessorImpl.java:121)
at
org.apache.sling.engine.impl.SlingRequestProcessorImpl.processRequest(SlingRequestProcessorImpl.java:247)
{code}
was:
{{getServletPath() throws the UnsupportedOperationException in
MockSlingHttpServletRequest
http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/servlet-helpers/src/main/java/org/apache/sling/servlethelpers/MockSlingHttpServletRequest.java?revision=1728734&view=markup#l685
It gets called from the SlingHttpServletRequestImpl constructor
http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/SlingHttpServletRequestImpl.java?view=markup#l71
causing the following stacktrace:
{code}
Caused by: java.lang.UnsupportedOperationException: null
at
org.apache.sling.servlethelpers.MockSlingHttpServletRequest.getServletPath(MockSlingHttpServletRequest.java:685)
at
org.apache.sling.engine.impl.SlingHttpServletRequestImpl.(SlingHttpServletRequestImpl.java:71)
at
org.apache.sling.engine.impl.request.RequestData$1.createRequest(RequestData.java:700)
at
org.apache.sling.engine.impl.request.RequestData.(RequestData.java:215)
at
org.apache.sling.engine.impl.SlingRequestProcessorImpl.doProcessRequest(SlingRequestProcessorImpl.java:121)
at
org.apache.sling.engine.impl.SlingRequestProcessorImpl.processRequest(SlingRequestProcessorImpl.java:247)
{code}
> MockSlingHttpServletRequest used with SlingRequestProcessor causes
> UnsupportedOperationException
>
>
> Key: SLING-5947
> URL: https://issues.apache.org/jira/browse/SLING-5947
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Servlet Helpers 1.0.0
>Reporter: Dirk Rudolph
> Fix For: Servlet Helpers 1.0.2
>
>
> {{getServletPath()}} throws the UnsupportedOperationException in
> MockSlingHttpServletRequest
> http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/servlet-helpers/src/main/java/org/apache/sling/servlethelpers/MockSlingHttpServletRequest.java?revision=1728734&view=markup#l685
> It gets called from the SlingHttpServletRequestImpl constructor
> http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/SlingHttpServletRequestImpl.java?view=markup#l71
> causing the following stacktrace:
> {code}
> Caused by: java.lang.UnsupportedOperationException: null
> at
> org.apache.sling.servlethelpers.MockSlingHttpServletRequest.getServletPath(MockSlingHttpServletRequest.java:685)
> at
> org.apache.sling.engine.impl.SlingHttpServletRequestImpl.(SlingHttpServletRequestImpl.java:71)
> at
> org.apache.sling.engine.impl.request.RequestData$1.createRequest(RequestData.java:700)
> at
> org.apache.sling.engine.impl.request.RequestData.(RequestData.java:215)
> at
> org.apache.sling.engine.impl.SlingRequestProcessorImpl.doProcessRequest(SlingRequestProcessorImpl.java:121)
> at
> org.apache.sling.engine.impl.SlingRequestProcessorImpl.processRequest(SlingRequestProcessorImpl.java:247)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-920) Sling Jenkins setup
[
https://issues.apache.org/jira/browse/SLING-920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15407571#comment-15407571
]
Robert Munteanu commented on SLING-920:
---
Switched all builds to use {{Maven 3.3.9}} since the tool names have changed (
see https://cwiki.apache.org/confluence/display/INFRA/Maven+Installation+Matrix
)
> Sling Jenkins setup
> ---
>
> Key: SLING-920
> URL: https://issues.apache.org/jira/browse/SLING-920
> Project: Sling
> Issue Type: Task
> Components: Testing
>Reporter: Bertrand Delacretaz
>
> Use this issue to record changes to the Jenkins setup at
> https://builds.apache.org/view/S-Z/view/Sling/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [Context Aware Configs] Merging?
>> * Puppet (not too sure about the others) is not exactly great at dealing >> with xml files >> * FileVault [1] is only available in Java, if you want to create proper >> packages with it you have to call out to java from other languages > > Packages are zip files with a defined structure and some required files. > If you have a template, a few lines of bash (cp -r, sed, zip) will create > a package containing OSGi configs. This works well in Kubernetes within > Docker images. (btw, without a package and its version number, the > OSGIPackageInstaller doesnt install replacement config files) Simple property filtering works fine yes, but to implement a replacement for server side config merging you quickly come to a situation where you would have to read the structure of xml files and add config xml files and filter rules for it dynamically (think of creating a config /conf/tenant/myprof/path/to/my/page/myconfig.xml iff the prop puppetproproot.myprof.path.to.my.page.myconfig.theOneConfigPropToBeOverWrittenHere exists), doing so using FileVault/XmlApis is more robust/easier than using manual, text-based assembly. -Georg
[jira] [Updated] (SLING-5941) [SCD] Verify the uploaded distribution packages integrity via checksums
[
https://issues.apache.org/jira/browse/SLING-5941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi updated SLING-5941:
--
Attachment: SLING-5941.2.patch
Hi again [~teofili],
please have a look at the new attached patch where {{DigestUtils}} is not
missing and the {{DistributionPackageImporterServlet}} handles the request by
analysing the message body digest.
HTH, any feedback is welcome! :)
> [SCD] Verify the uploaded distribution packages integrity via checksums
> ---
>
> Key: SLING-5941
> URL: https://issues.apache.org/jira/browse/SLING-5941
> Project: Sling
> Issue Type: New Feature
> Components: Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Simone Tripodi
>Assignee: Tommaso Teofili
>Priority: Minor
> Fix For: Content Distribution 0.2.0
>
> Attachments: SLING-5941.1.patch, SLING-5941.2.patch, SLING-5941.patch
>
>
> Currently, there is no way to understand if a received package is (not)
> corrupted when transported, so adding a checksum generation/validation would
> be a solution to this problem
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [VOTE] Release Apache Sling XSS Protection Bundle version 1.0.10
+1 -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Updated] (SLING-4293) [XSS] Reduce footprint and dependencies
[ https://issues.apache.org/jira/browse/SLING-4293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-4293: --- Fix Version/s: (was: XSS Protection API 1.0.10) XSS Protection API 1.0.12 > [XSS] Reduce footprint and dependencies > --- > > Key: SLING-4293 > URL: https://issues.apache.org/jira/browse/SLING-4293 > Project: Sling > Issue Type: Improvement > Components: Extensions >Affects Versions: XSS Protection API 1.0.0 >Reporter: Felix Meschberger > Fix For: XSS Protection API 1.0.12 > > Attachments: SLING-4293.patch > > > The XSS bundle currently embeds all of the Antisamy, ESAPI, and Encoder > libraries as well as substantial parts of Batik, NekoHTML, and Xerces. This > is done by means of Private-Package and Embed-Dependency statements. > Leveraging the BND Conditional-Package statement, both the size of the XSS > bundle and the dependencies of it can be drastically reduced. The > Conditional-Package statement basically causes just to include those packages > that are actually needed to be embedded. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4273) Check list of required imports
[ https://issues.apache.org/jira/browse/SLING-4273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-4273: --- Fix Version/s: (was: XSS Protection API 1.0.10) XSS Protection API 1.0.12 > Check list of required imports > -- > > Key: SLING-4273 > URL: https://issues.apache.org/jira/browse/SLING-4273 > Project: Sling > Issue Type: Task > Components: Extensions >Affects Versions: XSS Protection API 1.0.0 >Reporter: Carsten Ziegeler > Fix For: XSS Protection API 1.0.12 > > > This is the current list of required imports for the xss module: > javax.annotation, > javax.crypto, > javax.crypto.spec, > javax.mail.internet, > javax.naming,j > avax.servlet, > javax.servlet.http, > javax.servlet.jsp, > javax.servlet.jsp.tagext, > javax.sql, > javax.swing, > javax.swing.border, > javax.swing.event, > javax.swing.filechooser, > javax.swing.table, > javax.swing.text, > javax.swing.tree, > javax.xml.datatype, > javax.xml.namespace, > javax.xml.parsers, > javax.xml.transform, > javax.xml.transform.dom, > javax.xml.transform.sax, > javax.xml.transform.stream, > javax.xml.validation, > org.apache.commons.codec.binary, > org.apache.commons.collections, > org.apache.commons.collections.comparators, > org.apache.commons.collections.iterators, > org.apache.commons.collections.keyvalue, > org.apache.commons.collections.list, > org.apache.commons.collections.map, > org.apache.commons.collections.set, > org.apache.commons.fileupload, > org.apache.commons.fileupload.disk, > org.apache.commons.fileupload.servlet, > org.apache.commons.fileupload.util, > org.apache.commons.httpclient, > org.apache.commons.httpclient.methods, > org.apache.commons.httpclient.params, > org.apache.commons.lang, > org.apache.commons.lang.exception, > org.apache.commons.lang.text, > org.apache.commons.logging, > org.apache.log4j, > org.apache.sling.api;version="[2.1,3)", > org.apache.sling.api.adapter;version="[2.2,3)", > org.apache.sling.api.resource;version="[2.1,3)", > org.apache.sling.commons.json;version="[2.0,3)", > org.apache.sling.commons.json.io;version="[2.0,3)", > org.apache.sling.xss;version="[1.0,1.1)", > org.osgi.service.event;version="[1.1,2)", > org.slf4j;version="[1.5,2)", > org.w3c.dom, > org.w3c.dom.css, > org.w3c.dom.events, > org.w3c.dom.html, > org.w3c.dom.ls, > org.w3c.dom.ranges, > org.w3c.dom.traversal, > org.w3c.dom.views, > org.xml.sax, > org.xml.sax.ext, > org.xml.sax.helpers > Some of them shouldn't really be required like javax.mail.internet or the jsp > api; for others like the apache commons stuff it would be nice to have > versioned imports -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-5234) Remove getAdministrativeResourceResolver() usage from org.apache.sling.xss
[ https://issues.apache.org/jira/browse/SLING-5234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-5234: --- Fix Version/s: (was: XSS Protection API 1.0.10) XSS Protection API 1.0.12 > Remove getAdministrativeResourceResolver() usage from org.apache.sling.xss > -- > > Key: SLING-5234 > URL: https://issues.apache.org/jira/browse/SLING-5234 > Project: Sling > Issue Type: Improvement > Components: Extensions >Affects Versions: XSS Protection API 1.0.6 >Reporter: Antonio Sanso >Assignee: Radu Cotescu > Fix For: XSS Protection API 1.0.12 > > > counted 1 occurrence -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4560) XSSAPI#getValidHref is empty for valid Bengali or Hindi characters
[
https://issues.apache.org/jira/browse/SLING-4560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-4560:
---
Fix Version/s: (was: XSS Protection API 1.0.10)
XSS Protection API 1.0.12
> XSSAPI#getValidHref is empty for valid Bengali or Hindi characters
> --
>
> Key: SLING-4560
> URL: https://issues.apache.org/jira/browse/SLING-4560
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: XSS Protection API 1.0.0
>Reporter: Jean-Christophe Kautzmann
> Fix For: XSS Protection API 1.0.12
>
>
> I added (locally) 2 test cases to
> org.apache.sling.xss.impl.XSSAPIImplTest#testGetValidHref:
> {code}
> {"/etc/commerce/collections/中文", "/etc/commerce/collections/中文"},
> {"/etc/commerce/collections/⺁〡〢☉⊕〒", "/etc/commerce/collections/⺁〡〢☉⊕〒"},
> {code}
> the first test passes (chinese characters), the 2nd fails (bengali/hindi
> characters) although it should pass as they are valid characters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [VOTE] Release Apache Sling XSS Protection Bundle version 1.0.10
On Thu, 2016-08-04 at 11:11 +0200, Konrad Windszus wrote: > Can you move the other yet unresolved tickets to the upcoming bundle > version then? > https://issues.apache.org/jira/browse/SLING-4365?jql=project%20%3D%20 > SLING%20AND%20fixVersion%20%3D%20%22XSS%20Protection%20API%201.0.10%2 > 2%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20DESC > Good point, did so now. Thanks, Robert
[jira] [Updated] (SLING-4365) Streamline ESAPI configuration
[ https://issues.apache.org/jira/browse/SLING-4365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-4365: --- Fix Version/s: (was: XSS Protection API 1.0.10) XSS Protection API 1.0.12 > Streamline ESAPI configuration > -- > > Key: SLING-4365 > URL: https://issues.apache.org/jira/browse/SLING-4365 > Project: Sling > Issue Type: Improvement > Components: Extensions >Affects Versions: XSS Protection API 1.0.0 >Reporter: Felix Meschberger > Fix For: XSS Protection API 1.0.12 > > > Currently the ESAPI is configured using the DefaultSecurityConfiguration > class. This configuration is configured such as to: > * read configuration from various file system locations, e.g. the user's > home folder > * list the helper classes to be used > * configure the checking > * configure logging > In our context and setup, we don't want to have different classes configured, > we want logging to always go through SLF4J logging and we want to limit and > control where the configuration is read from. > This issues is about creating a custom SecurityConfiguration class : > * read from defined locations, probably one in the repository and one > embedded in the bundle as a fallback. For example using the same > configuration file as embedded default as for Sling Initial Content > installation in the repository. > * always log to SLF4J, maybe requiring an SLF4J based ESAPI LogFactory > implementation. As a fallback, Log4J or commons logging APIs could still be > used through the existing *-to-SLF4J API bridges we use. > * Only support configuration of validation patterns (hence all classes > "statically" defined) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release Apache Sling XSS Protection Bundle version 1.0.10
Can you move the other yet unresolved tickets to the upcoming bundle version then? https://issues.apache.org/jira/browse/SLING-4365?jql=project%20%3D%20SLING%20AND%20fixVersion%20%3D%20%22XSS%20Protection%20API%201.0.10%22%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20DESC Thanks, Konrad > On 04 Aug 2016, at 11:05, Robert Munteanu wrote: > > On Thu, 2016-08-04 at 12:04 +0300, Robert Munteanu wrote: >> sh check_staged_release.sh 1493 /tmp/sling-staging > > +1 > > Robert
[jira] [Comment Edited] (SLING-5815) Expose DistributionContentSerializer
[
https://issues.apache.org/jira/browse/SLING-5815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15407455#comment-15407455
]
Tommaso Teofili edited comment on SLING-5815 at 8/4/16 9:10 AM:
bq. The thing is that path mapping might be more difficult to support as the
serialization format might be hierarchical and mapping to another tree might
break the format
[~mpetria] what do you mean exactly ?
I think I prefer the idea of the {{ResourceMapper}} because it's basically
transforming {{Resources}}. I think it's important to understand what's the
usage of such mappers, in my view they can be used to:
- filter undesired properties at export/import time
- expand the path of a resource to sit under a certain subtree, e.g. for multi
tenant receivers
- other ?
Or would you want to use such mappers also to substitute the current filtering
based on information in {{DistributionRequest}} ?
was (Author: teofili):
bq. The thing is that path mapping might be more difficult to support as the
serialization format might be hierarchical and mapping to another tree might
break the format
[~mpetria] what do you mean exactly ?
I think I prefer the idea of the {{ResourceMapper}} because it's basically
transforming {{Resources}}, which I think is the idea behind that, right ? As
it's important to understand what's the usage of such mappers, in my view they
can be used to:
- filter undesired properties at export/import time
- expand the path of a resource to sit under a certain subtree, e.g. for multi
tenant receivers
Or would you want to use such mappers also to substitute the current filtering
based on information in {{DistributionRequest}} ?
> Expose DistributionContentSerializer
> -
>
> Key: SLING-5815
> URL: https://issues.apache.org/jira/browse/SLING-5815
> Project: Sling
> Issue Type: Improvement
> Components: Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution 0.2.0
>
> Attachments: SLING-5815.0.patch
>
>
> Expose {{DistributionContentSerializer}} API from
> _org.apache.sling.distribution.core_ in order to allow implementation of
> custom serialization formats (e.g. Avro and Kryo defined in
> _org.apache.sling.distribution.extensions_).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5815) Expose DistributionContentSerializer
[
https://issues.apache.org/jira/browse/SLING-5815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15407455#comment-15407455
]
Tommaso Teofili commented on SLING-5815:
bq. The thing is that path mapping might be more difficult to support as the
serialization format might be hierarchical and mapping to another tree might
break the format
what do you mean exactly ?
I think I prefer the idea of the {{ResourceMapper}} because it's basically
transforming {{Resources}}, which I think is the idea behind that, right ? As
it's important to understand what's the usage of such mappers, in my view they
can be used to:
- filter undesired properties at export/import time
- expand the path of a resource to sit under a certain subtree, e.g. for multi
tenant receivers
Or would you want to use such mappers also to substitute the current filtering
based on information in {{DistributionRequest}} ?
> Expose DistributionContentSerializer
> -
>
> Key: SLING-5815
> URL: https://issues.apache.org/jira/browse/SLING-5815
> Project: Sling
> Issue Type: Improvement
> Components: Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution 0.2.0
>
> Attachments: SLING-5815.0.patch
>
>
> Expose {{DistributionContentSerializer}} API from
> _org.apache.sling.distribution.core_ in order to allow implementation of
> custom serialization formats (e.g. Avro and Kryo defined in
> _org.apache.sling.distribution.extensions_).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SLING-5815) Expose DistributionContentSerializer
[
https://issues.apache.org/jira/browse/SLING-5815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15407455#comment-15407455
]
Tommaso Teofili edited comment on SLING-5815 at 8/4/16 9:09 AM:
bq. The thing is that path mapping might be more difficult to support as the
serialization format might be hierarchical and mapping to another tree might
break the format
[~mpetria] what do you mean exactly ?
I think I prefer the idea of the {{ResourceMapper}} because it's basically
transforming {{Resources}}, which I think is the idea behind that, right ? As
it's important to understand what's the usage of such mappers, in my view they
can be used to:
- filter undesired properties at export/import time
- expand the path of a resource to sit under a certain subtree, e.g. for multi
tenant receivers
Or would you want to use such mappers also to substitute the current filtering
based on information in {{DistributionRequest}} ?
was (Author: teofili):
bq. The thing is that path mapping might be more difficult to support as the
serialization format might be hierarchical and mapping to another tree might
break the format
what do you mean exactly ?
I think I prefer the idea of the {{ResourceMapper}} because it's basically
transforming {{Resources}}, which I think is the idea behind that, right ? As
it's important to understand what's the usage of such mappers, in my view they
can be used to:
- filter undesired properties at export/import time
- expand the path of a resource to sit under a certain subtree, e.g. for multi
tenant receivers
Or would you want to use such mappers also to substitute the current filtering
based on information in {{DistributionRequest}} ?
> Expose DistributionContentSerializer
> -
>
> Key: SLING-5815
> URL: https://issues.apache.org/jira/browse/SLING-5815
> Project: Sling
> Issue Type: Improvement
> Components: Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution 0.2.0
>
> Attachments: SLING-5815.0.patch
>
>
> Expose {{DistributionContentSerializer}} API from
> _org.apache.sling.distribution.core_ in order to allow implementation of
> custom serialization formats (e.g. Avro and Kryo defined in
> _org.apache.sling.distribution.extensions_).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [VOTE] Release Apache Sling XSS Protection Bundle version 1.0.10
On Thu, 2016-08-04 at 12:04 +0300, Robert Munteanu wrote: > sh check_staged_release.sh 1493 /tmp/sling-staging +1 Robert signature.asc Description: This is a digitally signed message part
[VOTE] Release Apache Sling XSS Protection Bundle version 1.0.10
Hi, We solved 2 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12334729 There are still some outstanding issues: https://issues.apache.org/jira/browse/SLING/component/12312240 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1493 You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1493 /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.
[jira] [Resolved] (SLING-5946) XSSAPI#encodeForJSString is not restrictive enough
[
https://issues.apache.org/jira/browse/SLING-5946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu resolved SLING-5946.
Resolution: Fixed
Applied in https://svn.apache.org/r1755147, thanks for the contribution!
> XSSAPI#encodeForJSString is not restrictive enough
> --
>
> Key: SLING-5946
> URL: https://issues.apache.org/jira/browse/SLING-5946
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: XSS Protection API 1.0.8
>Reporter: Vlad Bailescu
>Assignee: Robert Munteanu
> Fix For: XSS Protection API 1.0.10
>
> Attachments: SLING_5946.patch
>
>
> Since SLING-5445, {{XSSAPI#encodeForJSString}} is no longer properly encoding
> {{}} and {{
[jira] [Assigned] (SLING-5946) XSSAPI#encodeForJSString is not restrictive enough
[
https://issues.apache.org/jira/browse/SLING-5946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu reassigned SLING-5946:
--
Assignee: Robert Munteanu
> XSSAPI#encodeForJSString is not restrictive enough
> --
>
> Key: SLING-5946
> URL: https://issues.apache.org/jira/browse/SLING-5946
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: XSS Protection API 1.0.8
>Reporter: Vlad Bailescu
>Assignee: Robert Munteanu
> Fix For: XSS Protection API 1.0.10
>
> Attachments: SLING_5946.patch
>
>
> Since SLING-5445, {{XSSAPI#encodeForJSString}} is no longer properly encoding
> {{}} and {{
[jira] [Commented] (SLING-5941) [SCD] Verify the uploaded distribution packages integrity via checksums
[
https://issues.apache.org/jira/browse/SLING-5941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15407420#comment-15407420
]
Simone Tripodi commented on SLING-5941:
---
Please apologise [~teofili], I completely forgot to add the {{DigestUtils}}
class in order to produce the patch :(
I'll provide a new patch as soon as I plugged the digest verification on the
receiver side.
Thanks for reviewing and for the hints! :)
> [SCD] Verify the uploaded distribution packages integrity via checksums
> ---
>
> Key: SLING-5941
> URL: https://issues.apache.org/jira/browse/SLING-5941
> Project: Sling
> Issue Type: New Feature
> Components: Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Simone Tripodi
>Assignee: Tommaso Teofili
>Priority: Minor
> Fix For: Content Distribution 0.2.0
>
> Attachments: SLING-5941.1.patch, SLING-5941.patch
>
>
> Currently, there is no way to understand if a received package is (not)
> corrupted when transported, so adding a checksum generation/validation would
> be a solution to this problem
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [ANN] New Apache Sling committer: Timothee Maret
Hi Carsten, Thanks for following up on this! I have added myself in the commit r1755144 and published the change via https://cms.apache.org/sling/publish. The pipes look correctly setup! Regards, Timothee 2016-08-03 14:28 GMT+02:00 Carsten Ziegeler : > Welcome Tim! > > Your account is created now and you should be able to directly to commit > to Sling. > > As a first step I suggest adding yourself to the list of committers in > the https://svn.apache.org/repos/asf/sling/site repository > > Regards > Carsten > > > Hi *, > > > > Please welcome Timothee Maret as a new committer of the Apache Sling > project. > > The Apache Sling PMC recently decided to offer Timothee committership > based on his contributions. > > I'm happy to announce that he accepted the offer. > > > > Welcome to the team, Timothee! > > > > @Timothee if you want to honor the old tradition of new committers > > briefly introducing themselves to the list, feel free. > > > > regards > > > > antonio > > > > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org > >
