[jira] [Commented] (SLING-8921) requestPath must to be encoded in SlingClient#doGet()
[ https://issues.apache.org/jira/browse/SLING-8921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17239192#comment-17239192 ] Satya Deep Maheshwari commented on SLING-8921: -- Would it be right to assume that this change is backwards incompatible with Sling-testing-client-1.2.4 and the consumers of sling-testing-client need to adapt accordingly? cc [~akrainiouk] [~volteanu] > requestPath must to be encoded in SlingClient#doGet() > - > > Key: SLING-8921 > URL: https://issues.apache.org/jira/browse/SLING-8921 > Project: Sling > Issue Type: Bug > Components: Apache Sling Testing Clients >Reporter: Valentin Olteanu >Assignee: Andrei Dulvac >Priority: Minor > Fix For: Apache Sling Testing Clients 1.2.6 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > [SlingClient#doGet()|https://github.com/apache/sling-org-apache-sling-testing-clients/blob/609cb61fd2dec08657556b9adc91e889911a230e/src/main/java/org/apache/sling/testing/clients/AbstractSlingClient.java#L492] > requires `requestPath` to be encoded (because it's passed to multiple URI > constructors). > The contract should be uniform: all the parameters are passed decoded and the > method takes care to encode them properly before creating the request. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SLING-7350) StreamRendererServlet redirects HEAD requests to external uri if available
[ https://issues.apache.org/jira/browse/SLING-7350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Satya Deep Maheshwari resolved SLING-7350. -- Resolution: Not A Problem > StreamRendererServlet redirects HEAD requests to external uri if available > -- > > Key: SLING-7350 > URL: https://issues.apache.org/jira/browse/SLING-7350 > Project: Sling > Issue Type: Bug > Components: Servlets >Affects Versions: Servlets Get 2.1.30 >Reporter: Satya Deep Maheshwari >Priority: Major > Attachments: SLING-7350.diff > > > SLING-7140 added a feature to support redirects to external uri of a resource > if available. This handled by StreamRendererServlet. See [1]. As per the > current implementation, if there's a uri available, a redirect is done for a > http HEAD request as well. This can be problematic for clients which expect > the response as sent by the servlet as of now if the response is different > from the redirected HEAD request. > Would it be correct to handle the HEAD request *before* the redirect so that > its current behavior is retained? > [1] - > https://github.com/apache/sling-org-apache-sling-servlets-get/blob/8ba11a174996ca4b7237c54879d1db8f14796f4d/src/main/java/org/apache/sling/servlets/get/impl/helpers/StreamRendererServlet.java#L171-L173 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (SLING-7350) StreamRendererServlet redirects HEAD requests to external uri if available
[ https://issues.apache.org/jira/browse/SLING-7350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Satya Deep Maheshwari closed SLING-7350. > StreamRendererServlet redirects HEAD requests to external uri if available > -- > > Key: SLING-7350 > URL: https://issues.apache.org/jira/browse/SLING-7350 > Project: Sling > Issue Type: Bug > Components: Servlets >Affects Versions: Servlets Get 2.1.30 >Reporter: Satya Deep Maheshwari >Priority: Major > Attachments: SLING-7350.diff > > > SLING-7140 added a feature to support redirects to external uri of a resource > if available. This handled by StreamRendererServlet. See [1]. As per the > current implementation, if there's a uri available, a redirect is done for a > http HEAD request as well. This can be problematic for clients which expect > the response as sent by the servlet as of now if the response is different > from the redirected HEAD request. > Would it be correct to handle the HEAD request *before* the redirect so that > its current behavior is retained? > [1] - > https://github.com/apache/sling-org-apache-sling-servlets-get/blob/8ba11a174996ca4b7237c54879d1db8f14796f4d/src/main/java/org/apache/sling/servlets/get/impl/helpers/StreamRendererServlet.java#L171-L173 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-7350) StreamRendererServlet redirects HEAD requests to external uri if available
[ https://issues.apache.org/jira/browse/SLING-7350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16366785#comment-16366785 ] Satya Deep Maheshwari commented on SLING-7350: -- [~ianeboston], I agree that treating HEAD and GET any differently would be incorrect behavior. [https://tools.ietf.org/html/rfc7231#section-4.3.2] and [https://tools.ietf.org/html/rfc2616#section-10.3.3] both mention it on similar lines. I came across this problem while using a client coded within a proprietary software. > StreamRendererServlet redirects HEAD requests to external uri if available > -- > > Key: SLING-7350 > URL: https://issues.apache.org/jira/browse/SLING-7350 > Project: Sling > Issue Type: Bug > Components: Servlets >Affects Versions: Servlets Get 2.1.30 >Reporter: Satya Deep Maheshwari >Priority: Major > Attachments: SLING-7350.diff > > > SLING-7140 added a feature to support redirects to external uri of a resource > if available. This handled by StreamRendererServlet. See [1]. As per the > current implementation, if there's a uri available, a redirect is done for a > http HEAD request as well. This can be problematic for clients which expect > the response as sent by the servlet as of now if the response is different > from the redirected HEAD request. > Would it be correct to handle the HEAD request *before* the redirect so that > its current behavior is retained? > [1] - > https://github.com/apache/sling-org-apache-sling-servlets-get/blob/8ba11a174996ca4b7237c54879d1db8f14796f4d/src/main/java/org/apache/sling/servlets/get/impl/helpers/StreamRendererServlet.java#L171-L173 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (SLING-7350) StreamRendererServlet redirects HEAD requests to external uri if available
[ https://issues.apache.org/jira/browse/SLING-7350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16309604#comment-16309604 ] Satya Deep Maheshwari edited comment on SLING-7350 at 1/3/18 12:54 PM: --- Attaching a proposed change at [^SLING-7350.diff]. cc [~i...@tfd.co.uk] was (Author: satyadeep): Attaching a proposed change. cc [~i...@tfd.co.uk] > StreamRendererServlet redirects HEAD requests to external uri if available > -- > > Key: SLING-7350 > URL: https://issues.apache.org/jira/browse/SLING-7350 > Project: Sling > Issue Type: Bug > Components: Servlets >Affects Versions: Servlets Get 2.1.30 >Reporter: Satya Deep Maheshwari > Attachments: SLING-7350.diff > > > SLING-7140 added a feature to support redirects to external uri of a resource > if available. This handled by StreamRendererServlet. See [1]. As per the > current implementation, if there's a uri available, a redirect is done for a > http HEAD request as well. This can be problematic for clients which expect > the response as sent by the servlet as of now if the response is different > from the redirected HEAD request. > Would it be correct to handle the HEAD request *before* the redirect so that > its current behavior is retained? > [1] - > https://github.com/apache/sling-org-apache-sling-servlets-get/blob/8ba11a174996ca4b7237c54879d1db8f14796f4d/src/main/java/org/apache/sling/servlets/get/impl/helpers/StreamRendererServlet.java#L171-L173 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SLING-7350) StreamRendererServlet redirects HEAD requests to external uri if available
[ https://issues.apache.org/jira/browse/SLING-7350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Satya Deep Maheshwari updated SLING-7350: - Attachment: SLING-7350.diff Attaching a proposed change. cc [~i...@tfd.co.uk] > StreamRendererServlet redirects HEAD requests to external uri if available > -- > > Key: SLING-7350 > URL: https://issues.apache.org/jira/browse/SLING-7350 > Project: Sling > Issue Type: Bug > Components: Servlets >Affects Versions: Servlets Get 2.1.30 >Reporter: Satya Deep Maheshwari > Attachments: SLING-7350.diff > > > SLING-7140 added a feature to support redirects to external uri of a resource > if available. This handled by StreamRendererServlet. See [1]. As per the > current implementation, if there's a uri available, a redirect is done for a > http HEAD request as well. This can be problematic for clients which expect > the response as sent by the servlet as of now if the response is different > from the redirected HEAD request. > Would it be correct to handle the HEAD request *before* the redirect so that > its current behavior is retained? > [1] - > https://github.com/apache/sling-org-apache-sling-servlets-get/blob/8ba11a174996ca4b7237c54879d1db8f14796f4d/src/main/java/org/apache/sling/servlets/get/impl/helpers/StreamRendererServlet.java#L171-L173 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SLING-7350) StreamRendererServlet redirects HEAD requests to external uri if available
Satya Deep Maheshwari created SLING-7350: Summary: StreamRendererServlet redirects HEAD requests to external uri if available Key: SLING-7350 URL: https://issues.apache.org/jira/browse/SLING-7350 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Get 2.1.30 Reporter: Satya Deep Maheshwari SLING-7140 added a feature to support redirects to external uri of a resource if available. This handled by StreamRendererServlet. See [1]. As per the current implementation, if there's a uri available, a redirect is done for a http HEAD request as well. This can be problematic for clients which expect the response as sent by the servlet as of now if the response is different from the redirected HEAD request. Would it be correct to handle the HEAD request *before* the redirect so that its current behavior is retained? [1] - https://github.com/apache/sling-org-apache-sling-servlets-get/blob/8ba11a174996ca4b7237c54879d1db8f14796f4d/src/main/java/org/apache/sling/servlets/get/impl/helpers/StreamRendererServlet.java#L171-L173 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SLING-7237) JcrValueMap escapes legal ':' character in namespace
[
https://issues.apache.org/jira/browse/SLING-7237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Satya Deep Maheshwari updated SLING-7237:
-
Description:
See [1] wherein while reading a jcr property,
the name is escaped of illegal jcr character ':' . For e.g. if I say
{{valueMap.get("jcr:content/xyz")}} then it is escaped as {{jcr%3Acontent/xyz}}
. This is not correct if I have a namespace by the name "jcr" registered
already because then {{jcr:content/xyz}} is a valid property path.
[1] -
https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/util/Text.java#L482
was:
See [1] wherein while reading a jcr property,
the name is escaped of illegal jcr character ':' . For e.g. if I say
{{valueMap.get("jcr:content/xyz")}} then it is escaped as {{jcr%3Acontent/xyz}}
. This is not correct if I have a namespace by the name "jcr" registered
already because then {{jcr:content/xyz}} is a valid property name.
[1] -
https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/util/Text.java#L482
> JcrValueMap escapes legal ':' character in namespace
>
>
> Key: SLING-7237
> URL: https://issues.apache.org/jira/browse/SLING-7237
> Project: Sling
> Issue Type: Bug
> Components: JCR
>Affects Versions: JCR Resource 3.0.6
>Reporter: Satya Deep Maheshwari
>
> See [1] wherein while reading a jcr property,
> the name is escaped of illegal jcr character ':' . For e.g. if I say
> {{valueMap.get("jcr:content/xyz")}} then it is escaped as
> {{jcr%3Acontent/xyz}} . This is not correct if I have a namespace by the name
> "jcr" registered already because then {{jcr:content/xyz}} is a valid property
> path.
> [1] -
> https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/util/Text.java#L482
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (SLING-7237) JcrValueMap escapes legal ':' character in namespace
Satya Deep Maheshwari created SLING-7237:
Summary: JcrValueMap escapes legal ':' character in namespace
Key: SLING-7237
URL: https://issues.apache.org/jira/browse/SLING-7237
Project: Sling
Issue Type: Bug
Components: JCR
Affects Versions: JCR Resource 3.0.6
Reporter: Satya Deep Maheshwari
See [1] wherein while reading a jcr property,
the name is escaped of illegal jcr character ':' . For e.g. if I say
{{valueMap.get("jcr:content/xyz")}} then it is escaped as {{jcr%3Acontent/xyz}}
. This is not correct if I have a namespace by the name "jcr" registered
already because then {{jcr:content/xyz}} is a valid property name.
[1] -
https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/util/Text.java#L482
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SLING-6501) Incorrect normalization of path of an asset with name beginning with '.'
[
https://issues.apache.org/jira/browse/SLING-6501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16224852#comment-16224852
]
Satya Deep Maheshwari commented on SLING-6501:
--
Here's a suggested patch for resolving this problem:
https://github.com/apache/sling-org-apache-sling-api/compare/master...sdmcraft:SLING-6501?expand=1
[~cziegeler] , [~ianeboston], could you please review?
> Incorrect normalization of path of an asset with name beginning with '.'
>
>
> Key: SLING-6501
> URL: https://issues.apache.org/jira/browse/SLING-6501
> Project: Sling
> Issue Type: Bug
> Components: API
>Reporter: Gaurav Gupta
>Priority: Critical
> Fix For: API 2.16.4
>
>
> When a new asset named ".jpg" is being modified in JCR,
> [ResourceUtil.normalize()|https://sling.apache.org/apidocs/sling7/org/apache/sling/api/resource/ResourceUtil.html#normalize-java.lang.String-]
> method returns an incorrect normalized path which leads to the creation of a
> folder named '.jp' under the same parent node. A small test shows this
> anomaly.
> {code:java}
> public class RUNormalizeTest {
> public static String toPropertyPath(String paramName, String path) {
> if (!paramName.startsWith("/")) {
> paramName = ResourceUtil.normalize(path + '/' + paramName);
> }
> return paramName;
> }
>
> public static void main(String[] args) {
> String pName =
> "./jpg_folder/.jpg/jcr:content/metadata/dc:title";
> String path = "/content/dam";
> System.out.println(toPropertyPath(pName,path));
> }
> }
> {code}
> Expected output: /content/dam/jpg_folder/.jpg/jcr:content/metadata/dc:title
> Output: /content/dam/jpg_folder/.jp/jcr:content/metadata/dc:title
> In the above code, the properties of an asset named '.jpg' are being
> modified. However, the normalize method returns an incorrect path for the
> input path.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SLING-6017) Streaming Uploads detection of request parameters is wrong.
[ https://issues.apache.org/jira/browse/SLING-6017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15470074#comment-15470074 ] Satya Deep Maheshwari commented on SLING-6017: -- [~ianeboston], I verified that the fix works fine. Can you please release the related artifacts so that I can use the released version? cc [~shgu...@adobe.com] > Streaming Uploads detection of request parameters is wrong. > --- > > Key: SLING-6017 > URL: https://issues.apache.org/jira/browse/SLING-6017 > Project: Sling > Issue Type: Bug > Components: Engine >Affects Versions: Engine 2.6.2 >Reporter: Ian Boston >Assignee: Ian Boston > Fix For: Servlets Post 2.3.14, Engine 2.6.4 > > > The way in which a request field that is not a file upload is detected is > wrong. Reported in SLING-5948. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-6017) Streaming Uplads detection of request parameters is wrong.
[
https://issues.apache.org/jira/browse/SLING-6017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15458155#comment-15458155
]
Satya Deep Maheshwari commented on SLING-6017:
--
[~ianeboston], if I use a POST request as follows:
{code}
curl -v -F key1=value1 -F file=@test.jpg
http://admin:admin@localhost:4502/content/test?uploadmode=stream
{code}
then for the {{part}} containing the file binary,
{{part.getSubmittedFileName()}} returns {{file}} rather than {{test.jpg}} .
This seems incorrect as per the expected behavior of
{{part.getSubmittedFileName()}} documented at this
[link|https://tomcat.apache.org/tomcat-8.0-doc/servletapi/javax/servlet/http/Part.html].
cc [~shgu...@adobe.com]
> Streaming Uplads detection of request parameters is wrong.
> --
>
> Key: SLING-6017
> URL: https://issues.apache.org/jira/browse/SLING-6017
> Project: Sling
> Issue Type: Bug
> Components: Engine
>Affects Versions: Engine 2.6.2
>Reporter: Ian Boston
>Assignee: Ian Boston
> Fix For: Engine 2.6.4
>
>
> The way in which a request field that is not a file upload is detected is
> wrong. Reported in SLING-5948.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5948) Support Streaming uploads.
[
https://issues.apache.org/jira/browse/SLING-5948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15448766#comment-15448766
]
Satya Deep Maheshwari commented on SLING-5948:
--
[~ianeboston], while trying this out, I am seeing that the form fields that I
am sending are getting detected as file which is to be streamed. For e.g. ,
here's the curl command that I am using:
{code}
curl -o /dev/null -v -F key1=value1 -F file=@file.txt -w
%{time_connect}:%{time_starttransfer}:%{time_total}
http://admin:admin@localhost:8080/temp/file4?uploadmode=stream
{code}
While trying to debug this, I see that on the server, at (1), the part
containing {{key1=value1}} gets detected as a file. This seems to be because of
the way {{RequestPartsIterator.getSubmittedFileName}} is implemented at (2),
Should it be implemented such that it specifically searches for the
{{filename}} header for returning the submitted filename?The multipart rfc at
(3) indicates that {{filename}} is a legitimate header for the part containing
the file in a multipart request. Roughly, can we implement it as below?
{code}
//Taken from https://java.net/jira/browse/SERVLET_SPEC-57
public String getSubmittedFileName() {
String header = this.getHeader("content-disposition");
if(header == null)
return null;
for(String headerPart : header.split(";"))
{
if(headerPart.trim().startsWith("filename"))
{
return headerPart.substring(headerPart.indexOf('=') +
1).trim()
.replace("\"", "");
}
}
return null;
}
{code}
cc [~shgu...@adobe.com]
(1) -
https://github.com/apache/sling/blob/trunk/bundles/servlets/post/src/main/java/org/apache/sling/servlets/post/impl/operations/StreamedUploadOperation.java#L95
(2) -
https://github.com/apache/sling/blob/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/parameters/RequestPartsIterator.java#L148
(3) - https://www.ietf.org/rfc/rfc2388.txt
> Support Streaming uploads.
> --
>
> Key: SLING-5948
> URL: https://issues.apache.org/jira/browse/SLING-5948
> Project: Sling
> Issue Type: Bug
> Components: Engine, Servlets
>Affects Versions: Servlets Post 2.3.12, Engine 2.5.0
>Reporter: Ian Boston
>Assignee: Ian Boston
> Labels: Sling-9-ReleaseNotes
> Fix For: Servlets Post 2.3.14, Engine 2.6.0
>
> Attachments: SLING-5948-Proposal1-illustration.patch,
> SLING-5948-Proposal2v2.patch, SLING-5948-Proposal2v3.patch,
> TarMKDSNotStreamed.png, TarMKDSStreamed.png, TarMKStreamed.png
>
>
> 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
> *
[jira] [Created] (SLING-5317) PropertiesUtil does not have a toFloat method
Satya Deep Maheshwari created SLING-5317: Summary: PropertiesUtil does not have a toFloat method Key: SLING-5317 URL: https://issues.apache.org/jira/browse/SLING-5317 Project: Sling Issue Type: Improvement Components: API Reporter: Satya Deep Maheshwari Priority: Minor org.apache.sling.commons.osgi.PropertiesUtil does not have a toFloat method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4825) Add ability to handle webdav based DELETE requests
[ https://issues.apache.org/jira/browse/SLING-4825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Satya Deep Maheshwari closed SLING-4825. > Add ability to handle webdav based DELETE requests > -- > > Key: SLING-4825 > URL: https://issues.apache.org/jira/browse/SLING-4825 > Project: Sling > Issue Type: Improvement > Components: JCR >Reporter: Satya Deep Maheshwari >Assignee: Bertrand Delacretaz > Fix For: JCR Webdav 2.3.2, Launchpad Builder 8 > > Attachments: SLING-4825.patch > > > Recently 'delete handler' was added in jackrabbit. This provides the ability > to add handlers for handling webdav based 'delete' requests. See JCR-3884 > containing details on this feature. Earlier this ability was just available > for other webdav operations like to copy/move etc. but was missing for > 'delete' . > Sling has written its own managers to keep track of these handlers. See [1] > which has pre-existing handler managers like SlingCopyMoveManager. > The intent of this jira issue is to add a delete handler manager so that the > delete handler functionality can now be leveraged in Sling. > [1] - > https://github.com/apache/sling/tree/trunk/bundles/jcr/webdav/src/main/java/org/apache/sling/jcr/webdav/impl/handler -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4825) Add ability to handle webdav based DELETE requests
[ https://issues.apache.org/jira/browse/SLING-4825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14744900#comment-14744900 ] Satya Deep Maheshwari commented on SLING-4825: -- Thanks. > Add ability to handle webdav based DELETE requests > -- > > Key: SLING-4825 > URL: https://issues.apache.org/jira/browse/SLING-4825 > Project: Sling > Issue Type: Improvement > Components: JCR >Reporter: Satya Deep Maheshwari >Assignee: Bertrand Delacretaz > Fix For: JCR Webdav 2.3.2, Launchpad Builder 8 > > Attachments: SLING-4825.patch > > > Recently 'delete handler' was added in jackrabbit. This provides the ability > to add handlers for handling webdav based 'delete' requests. See JCR-3884 > containing details on this feature. Earlier this ability was just available > for other webdav operations like to copy/move etc. but was missing for > 'delete' . > Sling has written its own managers to keep track of these handlers. See [1] > which has pre-existing handler managers like SlingCopyMoveManager. > The intent of this jira issue is to add a delete handler manager so that the > delete handler functionality can now be leveraged in Sling. > [1] - > https://github.com/apache/sling/tree/trunk/bundles/jcr/webdav/src/main/java/org/apache/sling/jcr/webdav/impl/handler -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4825) Add ability to handle webdav based DELETE requests
[ https://issues.apache.org/jira/browse/SLING-4825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14738173#comment-14738173 ] Satya Deep Maheshwari commented on SLING-4825: -- Please review. Looking forward towards having this feature available in sling. > Add ability to handle webdav based DELETE requests > -- > > Key: SLING-4825 > URL: https://issues.apache.org/jira/browse/SLING-4825 > Project: Sling > Issue Type: Improvement > Components: JCR >Reporter: Satya Deep Maheshwari > Attachments: SLING-4825.patch > > > Recently 'delete handler' was added in jackrabbit. This provides the ability > to add handlers for handling webdav based 'delete' requests. See JCR-3884 > containing details on this feature. Earlier this ability was just available > for other webdav operations like to copy/move etc. but was missing for > 'delete' . > Sling has written its own managers to keep track of these handlers. See [1] > which has pre-existing handler managers like SlingCopyMoveManager. > The intent of this jira issue is to add a delete handler manager so that the > delete handler functionality can now be leveraged in Sling. > [1] - > https://github.com/apache/sling/tree/trunk/bundles/jcr/webdav/src/main/java/org/apache/sling/jcr/webdav/impl/handler -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SLING-4825) Add ability to handle webdav based DELETE requests
[ https://issues.apache.org/jira/browse/SLING-4825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14706447#comment-14706447 ] Satya Deep Maheshwari edited comment on SLING-4825 at 8/25/15 11:04 AM: Handler support for webdav DELETE requests is now released in jackrabbit version 2.11.0 . So I think we are now good to incorporate the proposed changes in sling. I am attaching a consolidated patch containing all the changes in sling to leverage this support. The patch also contains the integration-tests for testing this enhancement. Please review. was (Author: satyadeep): Handler support for webdav DELETE requests is now released in jackrabbit version 2.11.0 . So I think we are now good to incorporate the proposed changes in sling. I am attaching a consolidated patch containing all the changes in sling to leverage this support. The patch also contains the integration-tests for testing this enhancement. Please review. Add ability to handle webdav based DELETE requests -- Key: SLING-4825 URL: https://issues.apache.org/jira/browse/SLING-4825 Project: Sling Issue Type: Improvement Components: JCR Reporter: Satya Deep Maheshwari Attachments: SLING-4825.patch Recently 'delete handler' was added in jackrabbit. This provides the ability to add handlers for handling webdav based 'delete' requests. See JCR-3884 containing details on this feature. Earlier this ability was just available for other webdav operations like to copy/move etc. but was missing for 'delete' . Sling has written its own managers to keep track of these handlers. See [1] which has pre-existing handler managers like SlingCopyMoveManager. The intent of this jira issue is to add a delete handler manager so that the delete handler functionality can now be leveraged in Sling. [1] - https://github.com/apache/sling/tree/trunk/bundles/jcr/webdav/src/main/java/org/apache/sling/jcr/webdav/impl/handler -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4961) Add ability to handle webdav based LOCK/UNLOCK requests
Satya Deep Maheshwari created SLING-4961: Summary: Add ability to handle webdav based LOCK/UNLOCK requests Key: SLING-4961 URL: https://issues.apache.org/jira/browse/SLING-4961 Project: Sling Issue Type: Improvement Components: JCR Reporter: Satya Deep Maheshwari JCR-3895 intends to provide the ability to add handlers for handling webdav based 'lock/unlock' requests. Currently this ability is just available for other webdav operations like to copy/move etc. but is missing for 'lock/unlock' . Sling has written its own managers to keep track of these handlers. See [1] which has pre-existing handler managers like SlingCopyMoveManager. The intent of this jira issue is to add a lock handler manager so that the lock handler functionality can be leveraged in Sling whenever it becomes available. [1] - https://github.com/apache/sling/tree/trunk/bundles/jcr/webdav/src/main/java/org/apache/sling/jcr/webdav/impl/handler -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4825) Add ability to handle webdav based DELETE requests
[ https://issues.apache.org/jira/browse/SLING-4825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14706435#comment-14706435 ] Satya Deep Maheshwari commented on SLING-4825: -- I have logged SLING-4961 to keep track of adding a handler for lock requests. Add ability to handle webdav based DELETE requests -- Key: SLING-4825 URL: https://issues.apache.org/jira/browse/SLING-4825 Project: Sling Issue Type: Improvement Components: JCR Reporter: Satya Deep Maheshwari Attachments: SLING-4825-tests.patch Recently 'delete handler' was added in jackrabbit. This provides the ability to add handlers for handling webdav based 'delete' requests. See JCR-3884 containing details on this feature. Earlier this ability was just available for other webdav operations like to copy/move etc. but was missing for 'delete' . Sling has written its own managers to keep track of these handlers. See [1] which has pre-existing handler managers like SlingCopyMoveManager. The intent of this jira issue is to add a delete handler manager so that the delete handler functionality can now be leveraged in Sling. [1] - https://github.com/apache/sling/tree/trunk/bundles/jcr/webdav/src/main/java/org/apache/sling/jcr/webdav/impl/handler -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4825) Add ability to handle webdav based DELETE requests
[ https://issues.apache.org/jira/browse/SLING-4825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Satya Deep Maheshwari updated SLING-4825: - Attachment: (was: SLING-4825-tests.patch) Add ability to handle webdav based DELETE requests -- Key: SLING-4825 URL: https://issues.apache.org/jira/browse/SLING-4825 Project: Sling Issue Type: Improvement Components: JCR Reporter: Satya Deep Maheshwari Recently 'delete handler' was added in jackrabbit. This provides the ability to add handlers for handling webdav based 'delete' requests. See JCR-3884 containing details on this feature. Earlier this ability was just available for other webdav operations like to copy/move etc. but was missing for 'delete' . Sling has written its own managers to keep track of these handlers. See [1] which has pre-existing handler managers like SlingCopyMoveManager. The intent of this jira issue is to add a delete handler manager so that the delete handler functionality can now be leveraged in Sling. [1] - https://github.com/apache/sling/tree/trunk/bundles/jcr/webdav/src/main/java/org/apache/sling/jcr/webdav/impl/handler -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4825) Add ability to handle webdav based DELETE requests
[ https://issues.apache.org/jira/browse/SLING-4825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Satya Deep Maheshwari updated SLING-4825: - Attachment: SLING-4825.patch Handler support for webdav DELETE requests is now released in jackrabbit version 2.11.0 . So I think we are now good to incorporate the proposed changes in sling. I am attaching a consolidated patch containing all the changes in sling to leverage this support. The patch also contains the integration-tests for testing this enhancement. Please review. Add ability to handle webdav based DELETE requests -- Key: SLING-4825 URL: https://issues.apache.org/jira/browse/SLING-4825 Project: Sling Issue Type: Improvement Components: JCR Reporter: Satya Deep Maheshwari Attachments: SLING-4825.patch Recently 'delete handler' was added in jackrabbit. This provides the ability to add handlers for handling webdav based 'delete' requests. See JCR-3884 containing details on this feature. Earlier this ability was just available for other webdav operations like to copy/move etc. but was missing for 'delete' . Sling has written its own managers to keep track of these handlers. See [1] which has pre-existing handler managers like SlingCopyMoveManager. The intent of this jira issue is to add a delete handler manager so that the delete handler functionality can now be leveraged in Sling. [1] - https://github.com/apache/sling/tree/trunk/bundles/jcr/webdav/src/main/java/org/apache/sling/jcr/webdav/impl/handler -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4886) Testing tools bundles installer fails if there are no bundles to install
[ https://issues.apache.org/jira/browse/SLING-4886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Satya Deep Maheshwari updated SLING-4886: - Attachment: SLING-4886.patch Attaching patch containing proposed fix. Testing tools bundles installer fails if there are no bundles to install Key: SLING-4886 URL: https://issues.apache.org/jira/browse/SLING-4886 Project: Sling Issue Type: Bug Components: Testing Reporter: Satya Deep Maheshwari Priority: Minor Attachments: SLING-4886.patch Background: org.apache.sling.testing.tools.sling.BundlesInstaller.installBundles is invoked by org.apache.sling.testing.tools.sling.SlingTestBase.installAdditionalBundles for installing any additional bundles which may be necessary while running a test sling instance for some integration tests. Problem: The problem with BundlesInstaller.installBundles is that it fails if there are no bundles to install and hence the integration tests fail. Expectation: BundlesInstaller.installBundles should not fail if there are no bundles to install. It should just be a no-op. Fix: The problem is with a log message in this method which assumes that the bundles list will not be empty. Also the log text seems to incorrectly assume that the list contains bundles' folder path while it actually contains the bundle list. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4886) Testing tools bundles installer fails if there are no bundles to install
Satya Deep Maheshwari created SLING-4886: Summary: Testing tools bundles installer fails if there are no bundles to install Key: SLING-4886 URL: https://issues.apache.org/jira/browse/SLING-4886 Project: Sling Issue Type: Bug Components: Testing Reporter: Satya Deep Maheshwari Priority: Minor Background: org.apache.sling.testing.tools.sling.BundlesInstaller.installBundles is invoked by org.apache.sling.testing.tools.sling.SlingTestBase.installAdditionalBundles for installing any additional bundles which may be necessary while running a test sling instance for some integration tests. Problem: The problem with BundlesInstaller.installBundles is that it fails if there are no bundles to install and hence the integration tests fail. Expectation: BundlesInstaller.installBundles should not fail if there are no bundles to install. It should just be a no-op. Fix: The problem is with a log message in this method which assumes that the bundles list will not be empty. Also the log text seems to incorrectly assume that the list contains bundles' folder path while it actually contains the bundle list. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4825) Add ability to handle webdav based DELETE requests
[ https://issues.apache.org/jira/browse/SLING-4825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Satya Deep Maheshwari updated SLING-4825: - Attachment: SLING-4825-tests.patch I added tests for these changes. Please see [1] . Also attached a patch for the same. I am still waiting for the release of corresponding changes in jackrabbit JCR-3884 [1] - https://github.com/sdmcraft/sling/commit/918466c6a6f09fc99615dd3d0a8f566b2d9fd957 Add ability to handle webdav based DELETE requests -- Key: SLING-4825 URL: https://issues.apache.org/jira/browse/SLING-4825 Project: Sling Issue Type: Improvement Components: JCR Reporter: Satya Deep Maheshwari Assignee: Bertrand Delacretaz Attachments: SLING-4825-tests.patch Recently 'delete handler' was added in jackrabbit. This provides the ability to add handlers for handling webdav based 'delete' requests. See JCR-3884 containing details on this feature. Earlier this ability was just available for other webdav operations like to copy/move etc. but was missing for 'delete' . Sling has written its own managers to keep track of these handlers. See [1] which has pre-existing handler managers like SlingCopyMoveManager. The intent of this jira issue is to add a delete handler manager so that the delete handler functionality can now be leveraged in Sling. [1] - https://github.com/apache/sling/tree/trunk/bundles/jcr/webdav/src/main/java/org/apache/sling/jcr/webdav/impl/handler -- 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=14614728#comment-14614728
]
Satya Deep Maheshwari commented on SLING-4694:
--
For being able to use this improvement, I think it should be released so that
it can be utilized outside sling without snapshot dependencies? Also can a link
please be added to download it from [1].
[1] - https://sling.apache.org/downloads.cgi
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] [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=14615105#comment-14615105
]
Satya Deep Maheshwari commented on SLING-4694:
--
Thanks for releasing.
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] [Commented] (SLING-4825) Add ability to handle webdav based DELETE requests
[ https://issues.apache.org/jira/browse/SLING-4825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14609793#comment-14609793 ] Satya Deep Maheshwari commented on SLING-4825: -- Thanks for reviewing the patch. I have already asked the jackrabbit team to release this. Have sent a reminder now. Thanks for pointing me to launchpad/test-services. I was experimenting with pax-exam for adding ITs for this but could not figure out an easy way to test this :-( I'll add a delete handler in launchpad/test-services and its tests in SlingWebDavServletTest . Will come up with a patch for this. Add ability to handle webdav based DELETE requests -- Key: SLING-4825 URL: https://issues.apache.org/jira/browse/SLING-4825 Project: Sling Issue Type: Improvement Components: JCR Reporter: Satya Deep Maheshwari Assignee: Bertrand Delacretaz Recently 'delete handler' was added in jackrabbit. This provides the ability to add handlers for handling webdav based 'delete' requests. See JCR-3884 containing details on this feature. Earlier this ability was just available for other webdav operations like to copy/move etc. but was missing for 'delete' . Sling has written its own managers to keep track of these handlers. See [1] which has pre-existing handler managers like SlingCopyMoveManager. The intent of this jira issue is to add a delete handler manager so that the delete handler functionality can now be leveraged in Sling. [1] - https://github.com/apache/sling/tree/trunk/bundles/jcr/webdav/src/main/java/org/apache/sling/jcr/webdav/impl/handler -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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=14602456#comment-14602456
]
Satya Deep Maheshwari edited comment on SLING-4757 at 6/26/15 6:03 AM:
---
[~bdelacretaz] [~petr.shypila], if I run the integration tests without forking
a new thread (using -DforkCount=0 ) , the tests consistently fail on my
computer with the below error:
{{initializationError(org.apache.sling.commons.contentdetection.internal.it.ContentAwareMimeTypeServiceImplIT)
Time elapsed: 0.001 sec ERROR!
java.lang.RuntimeException: Error getting bundle list
mvn:org.apache.sling/org.apache.sling.launchpad/7/xml/bundlelist
at java.net.URL.init(URL.java:593)
at java.net.URL.init(URL.java:483)
at java.net.URL.init(URL.java:432)
at
org.apache.sling.paxexam.util.SlingPaxOptions.dumpMvnUrlToTmpFile(SlingPaxOptions.java:203)
at
org.apache.sling.paxexam.util.SlingPaxOptions.slingBundleList(SlingPaxOptions.java:121)
at
org.apache.sling.paxexam.util.SlingPaxOptions.slingLaunchpadBundles(SlingPaxOptions.java:188)
at
org.apache.sling.paxexam.util.SlingPaxOptions.defaultLaunchpadOptions(SlingPaxOptions.java:87)
at
org.apache.sling.commons.contentdetection.internal.it.U.paxConfig(U.java:37)
at
org.apache.sling.commons.contentdetection.internal.it.ContentAwareMimeTypeServiceImplIT.config(ContentAwareMimeTypeServiceImplIT.java:103)}}
Is this replicable on your computer? I encountered this while trying to debug
an IT for which I had to run it in a single thread.
was (Author: satyadeep):
[~bdelacretaz] [~petr.shypila], if I run the integration tests without forking
a new thread (using -DforkCount=0 ) , the tests consistently fail on my
computer with the below error:
{{
initializationError(org.apache.sling.commons.contentdetection.internal.it.ContentAwareMimeTypeServiceImplIT)
Time elapsed: 0.001 sec ERROR!
java.lang.RuntimeException: Error getting bundle list
mvn:org.apache.sling/org.apache.sling.launchpad/7/xml/bundlelist
at java.net.URL.init(URL.java:593)
at java.net.URL.init(URL.java:483)
at java.net.URL.init(URL.java:432)
at
org.apache.sling.paxexam.util.SlingPaxOptions.dumpMvnUrlToTmpFile(SlingPaxOptions.java:203)
at
org.apache.sling.paxexam.util.SlingPaxOptions.slingBundleList(SlingPaxOptions.java:121)
at
org.apache.sling.paxexam.util.SlingPaxOptions.slingLaunchpadBundles(SlingPaxOptions.java:188)
at
org.apache.sling.paxexam.util.SlingPaxOptions.defaultLaunchpadOptions(SlingPaxOptions.java:87)
at
org.apache.sling.commons.contentdetection.internal.it.U.paxConfig(U.java:37)
at
org.apache.sling.commons.contentdetection.internal.it.ContentAwareMimeTypeServiceImplIT.config(ContentAwareMimeTypeServiceImplIT.java:103)
}}
Is this replicable on your computer? I encountered this while trying to debug
an IT for which I had to run it in a single thread.
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
Attachments:
FileNameExtractorImpl_Injection_failed__ClassNotFoundException.patch,
content-tampering-test.patch, week2-part1-unit-tests.patch,
week2-part2-integration-tests.patch
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,
[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=14602456#comment-14602456
]
Satya Deep Maheshwari commented on SLING-4757:
--
[~bdelacretaz] [~petr.shypila], if I run the integration tests without forking
a new thread (using -DforkCount=0 ) , the tests consistently fail on my
computer with the below error:
{{
initializationError(org.apache.sling.commons.contentdetection.internal.it.ContentAwareMimeTypeServiceImplIT)
Time elapsed: 0.001 sec ERROR!
java.lang.RuntimeException: Error getting bundle list
mvn:org.apache.sling/org.apache.sling.launchpad/7/xml/bundlelist
at java.net.URL.init(URL.java:593)
at java.net.URL.init(URL.java:483)
at java.net.URL.init(URL.java:432)
at
org.apache.sling.paxexam.util.SlingPaxOptions.dumpMvnUrlToTmpFile(SlingPaxOptions.java:203)
at
org.apache.sling.paxexam.util.SlingPaxOptions.slingBundleList(SlingPaxOptions.java:121)
at
org.apache.sling.paxexam.util.SlingPaxOptions.slingLaunchpadBundles(SlingPaxOptions.java:188)
at
org.apache.sling.paxexam.util.SlingPaxOptions.defaultLaunchpadOptions(SlingPaxOptions.java:87)
at
org.apache.sling.commons.contentdetection.internal.it.U.paxConfig(U.java:37)
at
org.apache.sling.commons.contentdetection.internal.it.ContentAwareMimeTypeServiceImplIT.config(ContentAwareMimeTypeServiceImplIT.java:103)
}}
Is this replicable on your computer? I encountered this while trying to debug
an IT for which I had to run it in a single thread.
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
Attachments:
FileNameExtractorImpl_Injection_failed__ClassNotFoundException.patch,
content-tampering-test.patch, week2-part1-unit-tests.patch,
week2-part2-integration-tests.patch
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] [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=14602559#comment-14602559
]
Satya Deep Maheshwari commented on SLING-4757:
--
I need to remotely connect to the maven build while its executing the ITs to
debug something I was trying out. By default, surefire forks a different thread
for ITs. In order to be able to connect, I need it to run on the same thread as
the maven build. Please see [1]
The mvn based url (i.e. mvn://...) seems to be related to
{{java.protocol.handler.pkgsorg.ops4j.pax.url/java.protocol.handler.pkgs}}
[1] -
http://maven.apache.org/surefire/maven-surefire-plugin/examples/debugging.html
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
Attachments:
FileNameExtractorImpl_Injection_failed__ClassNotFoundException.patch,
content-tampering-test.patch, week2-part1-unit-tests.patch,
week2-part2-integration-tests.patch
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] [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=14602562#comment-14602562 ] Satya Deep Maheshwari commented on SLING-4757: -- And I am unable to execute the test from within the IDE (Intellij) as well as it fails with the same error. 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 Attachments: FileNameExtractorImpl_Injection_failed__ClassNotFoundException.patch, content-tampering-test.patch, week2-part1-unit-tests.patch, week2-part2-integration-tests.patch 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] [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=14602582#comment-14602582 ] Satya Deep Maheshwari commented on SLING-4757: -- Thanks. That works perfectly! 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 Attachments: FileNameExtractorImpl_Injection_failed__ClassNotFoundException.patch, content-tampering-test.patch, week2-part1-unit-tests.patch, week2-part2-integration-tests.patch 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] [Issue Comment Deleted] (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 ] Satya Deep Maheshwari updated SLING-4757: - Comment: was deleted (was: Thanks. That works perfectly!) 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 Attachments: FileNameExtractorImpl_Injection_failed__ClassNotFoundException.patch, content-tampering-test.patch, week2-part1-unit-tests.patch, week2-part2-integration-tests.patch 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] [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=14602581#comment-14602581 ] Satya Deep Maheshwari commented on SLING-4757: -- Thanks. That works perfectly! 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 Attachments: FileNameExtractorImpl_Injection_failed__ClassNotFoundException.patch, content-tampering-test.patch, week2-part1-unit-tests.patch, week2-part2-integration-tests.patch 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] [Commented] (SLING-4825) Add ability to handle webdav based DELETE requests
[ https://issues.apache.org/jira/browse/SLING-4825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14595729#comment-14595729 ] Satya Deep Maheshwari commented on SLING-4825: -- I have implemented a proposed implementation for this. Please see [1]. Its exactly similar to how the existing handler managers function in sling. [1] - https://github.com/sdmcraft/sling/commit/ecc472fd2215a0c4a04b79e62c7751202e8889f4 Add ability to handle webdav based DELETE requests -- Key: SLING-4825 URL: https://issues.apache.org/jira/browse/SLING-4825 Project: Sling Issue Type: Improvement Components: JCR Reporter: Satya Deep Maheshwari Recently 'delete handler' was added in jackrabbit. This provides the ability to add handlers for handling webdav based 'delete' requests. See JCR-3884 containing details on this feature. Earlier this ability was just available for other webdav operations like to copy/move etc. but was missing for 'delete' . Sling has written its own managers to keep track of these handlers. See [1] which has pre-existing handler managers like SlingCopyMoveManager. The intent of this jira issue is to add a delete handler manager so that the delete handler functionality can now be leveraged in Sling. [1] - https://github.com/apache/sling/tree/trunk/bundles/jcr/webdav/src/main/java/org/apache/sling/jcr/webdav/impl/handler -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4825) Add ability to handle webdav based DELETE requests
Satya Deep Maheshwari created SLING-4825: Summary: Add ability to handle webdav based DELETE requests Key: SLING-4825 URL: https://issues.apache.org/jira/browse/SLING-4825 Project: Sling Issue Type: Improvement Components: JCR Reporter: Satya Deep Maheshwari Recently 'delete handler' was added in jackrabbit. This provides the ability to add handlers for handling webdav based 'delete' requests. See JCR-3884 containing details on this feature. Earlier this ability was just available for other webdav operations like to copy/move etc. but was missing for 'delete' . Sling has written its own managers to keep track of these handlers. See [1] which has pre-existing handler managers like SlingCopyMoveManager. The intent of this jira issue is to add a delete handler manager so that the delete handler functionality can now be leveraged in Sling. [1] - https://github.com/apache/sling/tree/trunk/bundles/jcr/webdav/src/main/java/org/apache/sling/jcr/webdav/impl/handler -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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=14591701#comment-14591701 ] Satya Deep Maheshwari commented on SLING-4757: -- +1. Perhaps we can revisit this later if this gets addressed in the tika Detector api in future. 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 Attachments: FileNameExtractorImpl_Injection_failed__ClassNotFoundException.patch, content-tampering-test.patch, week2-part1-unit-tests.patch, week2-part2-integration-tests.patch 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] [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=14591637#comment-14591637 ] Satya Deep Maheshwari commented on SLING-4757: -- The test passes on my computer (CentOS 6.5, 64 bit)/java version 1.8.0_45. Also tried on java 1.7.0_71-b14 and it succeeds with it as well with MAVEN_OPTS=-Xmx1G -XX:MaxPermSize=256m . 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 Attachments: FileNameExtractorImpl_Injection_failed__ClassNotFoundException.patch, content-tampering-test.patch, week2-part1-unit-tests.patch, week2-part2-integration-tests.patch 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] [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=14589597#comment-14589597 ] Satya Deep Maheshwari edited comment on SLING-4757 at 6/17/15 10:29 AM: [~bdelacretaz] [~petr.shypila] , thanks for adding these tests. I think we should have one test to check that the content aware service does not manipulate the content in anyway while detecting the mime-type. I am attaching a patch which has this test. Please review. One more thing to note is that a tika detector expects that the content stream passed to it is able to support mark/reset. Please see [1] .I think that we should update the ContentAwareMimeTypeService docs to explicitly state that the content stream passed to it should support mark/reset. [1] - https://tika.apache.org/1.7/api/org/apache/tika/detect/Detector.html#detect(java.io.InputStream,%20org.apache.tika.metadata.Metadata) was (Author: satyadeep): [~bdelacretaz] [~petr.shypila] , thanks for adding these tests. I think we should have one test to check that the content aware service does not manipulate the content in anyway while detecting the mime-type. I am attaching a patch which has this test. Please review. One more thing to note is that a tika detector expects that the content stream passed to it is able to support mark/reset. Please see [1] .I think that we should update the ContentAwareMimeTypeService docs to explicitly state that the content stream passed to is should support mark/reset. [1] - https://tika.apache.org/1.7/api/org/apache/tika/detect/Detector.html#detect(java.io.InputStream,%20org.apache.tika.metadata.Metadata) 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 Attachments: FileNameExtractorImpl_Injection_failed__ClassNotFoundException.patch, content-tampering-test.patch, week2-part1-unit-tests.patch, week2-part2-integration-tests.patch 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] [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 ] Satya Deep Maheshwari updated SLING-4757: - Attachment: content-tampering-test.patch [~bdelacretaz] [~petr.shypila] , thanks for adding these tests. I think we should have one test to check that the content aware service does not manipulate the content in anyway while detecting the mime-type. I am attaching a patch which has this test. Please review. One more thing to note is that a tika detector expects that the content stream passed to it is able to support mark/reset. Please see [1] .I think that we should update the ContentAwareMimeTypeService docs to explicitly state that the content stream passed to is should support mark/reset. [1] - https://tika.apache.org/1.7/api/org/apache/tika/detect/Detector.html#detect(java.io.InputStream,%20org.apache.tika.metadata.Metadata) 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 Attachments: FileNameExtractorImpl_Injection_failed__ClassNotFoundException.patch, content-tampering-test.patch, week2-part1-unit-tests.patch, week2-part2-integration-tests.patch 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] [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] [Created] (SLING-4732) Enhance mime-type detection in webdav to optionally detect based on content
Satya Deep Maheshwari created SLING-4732: Summary: Enhance mime-type detection in webdav to optionally detect based on content Key: SLING-4732 URL: https://issues.apache.org/jira/browse/SLING-4732 Project: Sling Issue Type: Improvement Components: Servlets Reporter: Satya Deep Maheshwari Priority: Minor Currently the Sling webdav servlet detects the content's mime-type based on the filename. It is a common scenario with webdav clients wherein a temporary files get created with arbitrary names while being edited. The name of the temporary file is not good enough for inferring it mime-type. For such scenarios, it is needed to detect the mime-type based on the actual contents of the file. -- 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=14554108#comment-14554108
]
Satya Deep Maheshwari commented on SLING-4694:
--
Attached patch containing contentdetection module. Here's the related commit:
https://github.com/sdmcraft/sling/commit/83f396c1c24ed9509dfc43fa67cdcd87eff16c20
Logged SLING-4732 for tracking the webdav servlet enhancment.
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
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] [Comment Edited] (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=14554108#comment-14554108
]
Satya Deep Maheshwari edited comment on SLING-4694 at 5/21/15 11:05 AM:
Attached patch containing contentdetection module. Here's the related commit:
https://github.com/sdmcraft/sling/commit/83f396c1c24ed9509dfc43fa67cdcd87eff16c20
Logged SLING-4732 for tracking the webdav servlet enhancement.
was (Author: satyadeep):
Attached patch containing contentdetection module. Here's the related commit:
https://github.com/sdmcraft/sling/commit/83f396c1c24ed9509dfc43fa67cdcd87eff16c20
Logged SLING-4732 for tracking the webdav servlet enhancment.
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
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-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 updated SLING-4694:
-
Attachment: SLING-4694.patch
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
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] [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=14549909#comment-14549909
]
Satya Deep Maheshwari commented on SLING-4694:
--
Apart from that, are you planning more changes to your
bundles/commons/contentdetection module?
Nothing apart from a few clean up tasks around UTs and docs. And some code
cleanup as per https://maven.apache.org/developers/conventions/code.html. I'll
complete them and create a separate PR with just the contentdetection module
changes. I would be delighted if this module can be useful for others and can
become part of sling.
On the webdav servlet, the check is not only in the 'activate' method but also
in 'update' method and hence gets called whenever 'detectionmode' is changed or
the ContentAwareMimeTypeService get's binded/unbinded. Do you think it
mitigates your concern on the service becoming available/unavailable later?
I'd rather use a detectMimeType method which decides to use
ContentAwareMimeTypeService or MimeTypeService right when the detection
happens, to be more dynamic.
'detectMimeType is called by the SlingTikaDetector which does not know about
the detectionMode set on it invoker somewhere down the call stack. Could you
please provide some guidance as to how 'detectMimeType' can decide dynamically?
Maybe I'll log a separate jira for this webdav related change and we can take
it forward there and limit this jira for the contentdetection module only.
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
*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-4722) @TestReference annotation should support 'target' attribute
[ https://issues.apache.org/jira/browse/SLING-4722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Satya Deep Maheshwari updated SLING-4722: - Description: As per [1], I am trying to use @TestReference annotation to inject a reference in my test class. While it is working as expected, if I specify a 'target' attribute on this annotation as in [2], it does not get applied. Related user's forum mail thread on this at [3] [1] - https://sling.apache.org/documentation/development/sling-testing-tools.html [2] - http://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/scr-annotations.html#reference [3] - http://apache-sling.73963.n3.nabble.com/Using-TestReference-for-serverside-tests-td4050955.html was: As per [1], I am trying to use @TestReference annotation to inject a reference in my test class. While it working as expected, if I specify a 'target' attribute on this annotation as in [2], it does not get applied. Related user's forum mail thread on this at [3] [1] - https://sling.apache.org/documentation/development/sling-testing-tools.html [2] - http://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/scr-annotations.html#reference [3] - http://apache-sling.73963.n3.nabble.com/Using-TestReference-for-serverside-tests-td4050955.html @TestReference annotation should support 'target' attribute --- Key: SLING-4722 URL: https://issues.apache.org/jira/browse/SLING-4722 Project: Sling Issue Type: Wish Components: Testing Reporter: Satya Deep Maheshwari Priority: Minor As per [1], I am trying to use @TestReference annotation to inject a reference in my test class. While it is working as expected, if I specify a 'target' attribute on this annotation as in [2], it does not get applied. Related user's forum mail thread on this at [3] [1] - https://sling.apache.org/documentation/development/sling-testing-tools.html [2] - http://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/scr-annotations.html#reference [3] - http://apache-sling.73963.n3.nabble.com/Using-TestReference-for-serverside-tests-td4050955.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4722) @TestReference annotation should support 'target' attribute
Satya Deep Maheshwari created SLING-4722: Summary: @TestReference annotation should support 'target' attribute Key: SLING-4722 URL: https://issues.apache.org/jira/browse/SLING-4722 Project: Sling Issue Type: Wish Components: Testing Reporter: Satya Deep Maheshwari Priority: Minor As per [1], I am trying to use @TestReference annotation to inject a reference in my test class. While it working as expected, if I specify a 'target' attribute on this annotation as in [2], it does not get applied. Related user's forum mail thread on this at [3] [1] - https://sling.apache.org/documentation/development/sling-testing-tools.html [2] - http://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/scr-annotations.html#reference [3] - http://apache-sling.73963.n3.nabble.com/Using-TestReference-for-serverside-tests-td4050955.html -- 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=14543453#comment-14543453
]
Satya Deep Maheshwari commented on SLING-4694:
--
I have added the proposed config for mime type detection mode in webdav
servlet. Please review
https://github.com/sdmcraft/sling/commit/bc64ae883116274d09f10aea5cefdaa1686b795b
Meanwhile I am working on adding some test coverage for webdav to thoroughly
validate these changes.
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
*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] [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=14541784#comment-14541784
]
Satya Deep Maheshwari commented on SLING-4694:
--
I have updated the pull request as per the review comments. Details below:
* Removed empty activator
* Removed version of exported packages in pom
* Removed MimeDetectionConstants
* Removed DETECTION_MODE from the basic MimeTypeServiceImpl
* Removed all changes from mime bundle. No changes needed whatsoever.
* Added optional reference for ContentAwareMimeTypeService in webdav servlet.
webdav servlet would give preference to ContentAwareMimeTypeService if
available else it would fall back to basic MimeTypeService
metatype info is not in the component itself
[~cziegeler], can you please explain, what needs to be done for your above
comment?
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
*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] [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=14541849#comment-14541849
]
Satya Deep Maheshwari commented on SLING-4694:
--
OK, I see what you say. IIUC, you would want a flexibility in the service
consumer to indicate their service requirement as
optional/mandatory/not-needed.
I thought that this decision of whether to use this service (optionally or
compulsorily) or not at all would be made at the time of writing the code
itself. Like the webdav servlet enforces it in its code to use it optionally if
available.
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
*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] [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=14539464#comment-14539464
]
Satya Deep Maheshwari commented on SLING-4694:
--
Thanks for reviewing this.
I did not add the new API to MimeTypeService as that addition would not have
added any value to it unless it was itself made content aware and defeat the
purpose of introducing ContentAwareMimeTypeService
I think we might not need the MimeDetectionConstants.DETECTION_MODE
Yes it is of no use right now as we have just 2 modes (Tika and Filename) and
their respective interfaces. But I think this may become useful if we want to
have the flexibility of multiple content detection mechanisms (other than Tika)
. This setting provides a way to have multiple ContentAwareMimeTypeService
implementations and the ability for a client to choose one.
having two references in the client (SlingWebDavServlet)
Yes this makes sense. Having DETECTION_MODE on the basic MimeTypeService is not
needed. Will change this.
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
*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] [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=14539484#comment-14539484
]
Satya Deep Maheshwari commented on SLING-4694:
--
[~cziegeler], thanks for reviewing. I would address your observations from the
review.
I guess the most interesting question is how to enable this?
Would it be any different from how the webdav servlet uses it in the proposed
implementation? Can you please elaborate a bit on this? By opt-in/opt-out , do
you mean that the service should have an option of indicating that it can
handle the request or not?
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
*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] [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=14539284#comment-14539284
]
Satya Deep Maheshwari commented on SLING-4694:
--
Here's the pull request for the proposed implementation:
https://github.com/apache/sling/pull/89
[~bdelacretaz], please review.
It includes unit tests for the newly added contentdetection bundle. I haven't
yet add unit tests for the changes done in webdav and commons/mime bundles.
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
*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] [Issue Comment Deleted] (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 updated SLING-4694:
-
Comment: was deleted
(was: Best is probably to create a new commons/content-detection bundle
If I create a separate bundle, I lose the ability to extend the existing
concrete implementation of MimeTypeServiceImpl which is an internal class of
commons/mime bundle. Either I can copy it over to the new bundle or make it
abstract and export it from commons/mime. I would prefer to not do any of
these. Is there another way to do this?)
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
*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] [Comment Edited] (SLING-4694) SlingWebDavServlet should have a configurable Tika detector
[
https://issues.apache.org/jira/browse/SLING-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14532177#comment-14532177
]
Satya Deep Maheshwari edited comment on SLING-4694 at 5/7/15 7:32 AM:
--
I like this idea. One problem that I see with this though is that if the
current SlingTikaDetector uses ContentAwareMimeTypeService and
ContentAwareMimeTypeService may need a TikaDetector itself to figure out the
mime-type. So we have 2 detectors coming into picture to figure out the
mime-type. And these need to be different ones (how?) to avoid a recursive
situation.
I would want to have MimeTypeService configurable as you suggest but perhaps
also make SlingWebdavServlet configurable for the detector for this special
case wherein MimeTypeService is itself being used by a TikaDetector i.e
SlingTikaDetector.
was (Author: satyadeep):
I like this idea. One problem that I see with this though is that if the
current SlingTikaDetector uses ContentAwareMimeTypeService and
ContentAwareMimeTypeService would need a TikaDetector itself to figure out the
mime-type. So we have 2 detectors coming into picture to figure out the
mime-type. And these need to be different ones (how?) to avoid a recursive
situation.
I would want to have MimeTypeService configurable as you suggest but perhaps
also make SlingWebdavServlet configurable for the detector for this special
case wherein MimeTypeService is itself being used by a TikaDetector i.e
SlingTikaDetector.
SlingWebDavServlet should have a configurable Tika detector
---
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
*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] [Commented] (SLING-4694) SlingWebDavServlet should have a configurable Tika detector
[
https://issues.apache.org/jira/browse/SLING-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14532177#comment-14532177
]
Satya Deep Maheshwari commented on SLING-4694:
--
I like this idea. One problem that I see with this though is that if the
current SlingTikaDetector uses ContentAwareMimeTypeService and
ContentAwareMimeTypeService would need a TikaDetector itself to figure out the
mime-type. So we have 2 detectors coming into picture to figure out the
mime-type. And these need to be different ones (how?) to avoid a recursive
situation.
I would want to have MimeTypeService configurable as you suggest but perhaps
also make SlingWebdavServlet configurable for the detector for this special
case wherein MimeTypeService is itself being used by a TikaDetector i.e
SlingTikaDetector.
SlingWebDavServlet should have a configurable Tika detector
---
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
*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] [Commented] (SLING-4694) SlingWebDavServlet should have a configurable Tika detector
[
https://issues.apache.org/jira/browse/SLING-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14532132#comment-14532132
]
Satya Deep Maheshwari commented on SLING-4694:
--
It would be generally useful IMO to create an extended MimeTypeService
[~bdelacretaz] are you suggesting this in addition to making TikaDetector
configurable in WebDav servlet or an alternative way of implementing this?
SlingWebDavServlet should have a configurable Tika detector
---
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
*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] [Commented] (SLING-4694) SlingWebDavServlet should have a configurable Tika detector
[
https://issues.apache.org/jira/browse/SLING-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14532209#comment-14532209
]
Satya Deep Maheshwari commented on SLING-4694:
--
SlingTikaDetector uses Tika APIs but it can be just a bridge for the new
ContentAwareMimeTypeService, with no actual detection logic.
Makes sense. This clarifies things substantially.
SlingWebDavServlet should have a configurable Tika detector
---
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
*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-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 updated SLING-4694:
-
Summary: Add ability to identify mime type based on file content (was:
SlingWebDavServlet should have a configurable Tika detector)
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
*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] [Comment Edited] (SLING-4694) SlingWebDavServlet should have a configurable Tika detector
[
https://issues.apache.org/jira/browse/SLING-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14532399#comment-14532399
]
Satya Deep Maheshwari edited comment on SLING-4694 at 5/7/15 10:20 AM:
---
I'll try to come up with the implementation of {{ContentAwareMimeTypeService}}
as discussed.
was (Author: satyadeep):
I'll try to come up with the implementation of
preContentAwareMimeTypeService/pre as discussed.
SlingWebDavServlet should have a configurable Tika detector
---
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
*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] [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=14532543#comment-14532543
]
Satya Deep Maheshwari commented on SLING-4694:
--
Best is probably to create a new commons/content-detection bundle
If I create a separate bundle, I lose the ability to extend the existing
concrete implementation of MimeTypeServiceImpl which is an internal class of
commons/mime bundle. Either I can copy it over to the new bundle or make it
abstract and export it from commons/mime. I would prefer to not do any of
these. Is there another way to do this?
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
*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] [Commented] (SLING-4694) SlingWebDavServlet should have a configurable Tika detector
[
https://issues.apache.org/jira/browse/SLING-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14532399#comment-14532399
]
Satya Deep Maheshwari commented on SLING-4694:
--
I'll try to come up with the implementation of
preContentAwareMimeTypeService/pre as discussed.
SlingWebDavServlet should have a configurable Tika detector
---
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
*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] [Commented] (SLING-4694) SlingWebDavServlet should have a configurable Tika detector
[
https://issues.apache.org/jira/browse/SLING-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14530414#comment-14530414
]
Satya Deep Maheshwari commented on SLING-4694:
--
I am working on an approach wherein the Sling webdav servlet would be passed a
tika detector via @Reference . The current SlingTikaDetector would also expose
itself as a service and the webdav servlet will get its reference for further
use. Alternatively, one can pass another tika detector to the webdav servlet by
exposing it as a service. Sling quickstart already includes a Tika Osgi bundle
which provides the default TikaDetector which can be used as an alternative to
the internal SlingTikaDetector .
SlingWebDavServlet should have a configurable Tika detector
---
Key: SLING-4694
URL: https://issues.apache.org/jira/browse/SLING-4694
Project: Sling
Issue Type: Improvement
Components: Servlets
Reporter: Satya Deep Maheshwari
*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-4694) SlingWebDavServlet should have a configurable Tika detector
Satya Deep Maheshwari created SLING-4694:
Summary: SlingWebDavServlet should have a configurable Tika
detector
Key: SLING-4694
URL: https://issues.apache.org/jira/browse/SLING-4694
Project: Sling
Issue Type: Improvement
Components: Servlets
Reporter: Satya Deep Maheshwari
*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] [Commented] (SLING-4405) Unable to install new bundle using the jar upload mechanism
[ https://issues.apache.org/jira/browse/SLING-4405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14328791#comment-14328791 ] Satya Deep Maheshwari commented on SLING-4405: -- Thanks! This is working fine now. Unable to install new bundle using the jar upload mechanism --- Key: SLING-4405 URL: https://issues.apache.org/jira/browse/SLING-4405 Project: Sling Issue Type: Bug Components: IDE Affects Versions: Tooling Support Install 1.0.0 Reporter: Satya Deep Maheshwari Assignee: Robert Munteanu Fix For: Tooling Support Install 1.0.2 I am experimenting with sling IDE tooling. I am facing a problem wherein I am unable to deploy the bundle for the very first time using it. Once I have uploaded the bundle once using some other means, I am subsequently able to upload successfully using the ide tooling. On debugging this a bit, I see that the on installing the bundle for the very first time, the felix framework attempts to search for the bundle in a non-existent directory which fails with a FileNotFound exception. I compared this with the bundle install done from the felix web console. It looks like IDE tooling uses the InstallServlet mechanism while the web console does not. The InstallServlet tries to determine the location of this bundle if it already exists and if it does not, it sets it to null which later causes the above mentioned problem. Below is the exception trace: 11.02.2015 14:59:49.172 *ERROR* [qtp1941320881-42] ERROR: Error getting location from bundle archive. (java.io.FileNotFoundException: /home/satyadeep/code/sling/sling/felix/bundle181/bundle.location (No such file or directory)) java.io.FileNotFoundException: /home/satyadeep/code/sling/sling/felix/bundle181/bundle.location (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:146) at org.apache.felix.framework.util.SecureAction.getFileInputStream(SecureAction.java:453) at org.apache.felix.framework.cache.BundleArchive.readLocation(BundleArchive.java:1107) at org.apache.felix.framework.cache.BundleArchive.getLocation(BundleArchive.java:256) at org.apache.felix.framework.BundleImpl._getLocation(BundleImpl.java:621) at org.apache.felix.framework.BundleProtectionDomain$RevisionAsJarURL.create(BundleProtectionDomain.java:335) at org.apache.felix.framework.BundleProtectionDomain$RevisionAsJarURL.access$200(BundleProtectionDomain.java:234) at org.apache.felix.framework.BundleProtectionDomain.init(BundleProtectionDomain.java:385) at org.apache.felix.framework.Felix.setBundleProtectionDomain(Felix.java:938) at org.apache.felix.framework.BundleImpl.addRevision(BundleImpl.java:1219) at org.apache.felix.framework.BundleImpl.init(BundleImpl.java:114) at org.apache.felix.framework.Felix.installBundle(Felix.java:2976) at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:169) at org.apache.sling.tooling.support.install.impl.InstallServlet.installOrUpdateBundle(InstallServlet.java:242) at org.apache.sling.tooling.support.install.impl.InstallServlet.installBasedOnUploadedJar(InstallServlet.java:149) at org.apache.sling.tooling.support.install.impl.InstallServlet.doPost(InstallServlet.java:101) at javax.servlet.http.HttpServlet.service(HttpServlet.java:641) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:339) at org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:300) at org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:93) at org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:50) at org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:31) at org.apache.sling.launchpad.testservices.filters.TestFilter.doFilter(TestFilter.java:47) at org.apache.sling.launchpad.testservices.filters.HttpServiceExtFilter.doFilter(HttpServiceExtFilter.java:27) at org.apache.felix.http.base.internal.handler.FilterHandler.doHandle(FilterHandler.java:108) at org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:80) at org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:46) at org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:31) at
[jira] [Created] (SLING-4405) Unable to install bundle for the first time
Satya Deep Maheshwari created SLING-4405: Summary: Unable to install bundle for the first time Key: SLING-4405 URL: https://issues.apache.org/jira/browse/SLING-4405 Project: Sling Issue Type: Bug Components: IDE Reporter: Satya Deep Maheshwari I am experimenting with sling IDE tooling. I am facing a problem wherein I am unable to deploy the bundle for the very first time using it. Once I have uploaded the bundle once using some other means, I am subsequently able to upload successfully using the ide tooling. On debugging this a bit, I see that the on installing the bundle for the very first time, the felix framework attempts to search for the bundle in a non-existent directory which fails with a FileNotFound exception. I compared this with the bundle install done from the felix web console. It looks like IDE tooling uses the InstallServlet mechanism while the web console does not. The InstallServlet tries to determine the location of this bundle if it already exists and if it does not, it sets it to null which later causes the above mentioned problem. Below is the exception trace: 11.02.2015 14:59:49.172 *ERROR* [qtp1941320881-42] ERROR: Error getting location from bundle archive. (java.io.FileNotFoundException: /home/satyadeep/code/sling/sling/felix/bundle181/bundle.location (No such file or directory)) java.io.FileNotFoundException: /home/satyadeep/code/sling/sling/felix/bundle181/bundle.location (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:146) at org.apache.felix.framework.util.SecureAction.getFileInputStream(SecureAction.java:453) at org.apache.felix.framework.cache.BundleArchive.readLocation(BundleArchive.java:1107) at org.apache.felix.framework.cache.BundleArchive.getLocation(BundleArchive.java:256) at org.apache.felix.framework.BundleImpl._getLocation(BundleImpl.java:621) at org.apache.felix.framework.BundleProtectionDomain$RevisionAsJarURL.create(BundleProtectionDomain.java:335) at org.apache.felix.framework.BundleProtectionDomain$RevisionAsJarURL.access$200(BundleProtectionDomain.java:234) at org.apache.felix.framework.BundleProtectionDomain.init(BundleProtectionDomain.java:385) at org.apache.felix.framework.Felix.setBundleProtectionDomain(Felix.java:938) at org.apache.felix.framework.BundleImpl.addRevision(BundleImpl.java:1219) at org.apache.felix.framework.BundleImpl.init(BundleImpl.java:114) at org.apache.felix.framework.Felix.installBundle(Felix.java:2976) at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:169) at org.apache.sling.tooling.support.install.impl.InstallServlet.installOrUpdateBundle(InstallServlet.java:242) at org.apache.sling.tooling.support.install.impl.InstallServlet.installBasedOnUploadedJar(InstallServlet.java:149) at org.apache.sling.tooling.support.install.impl.InstallServlet.doPost(InstallServlet.java:101) at javax.servlet.http.HttpServlet.service(HttpServlet.java:641) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:339) at org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:300) at org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:93) at org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:50) at org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:31) at org.apache.sling.launchpad.testservices.filters.TestFilter.doFilter(TestFilter.java:47) at org.apache.sling.launchpad.testservices.filters.HttpServiceExtFilter.doFilter(HttpServiceExtFilter.java:27) at org.apache.felix.http.base.internal.handler.FilterHandler.doHandle(FilterHandler.java:108) at org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:80) at org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:46) at org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:31) at org.apache.sling.junit.impl.servlet.TestLogServlet$TestNameLoggingFilter.doFilter(TestLogServlet.java:244) at org.apache.felix.http.base.internal.handler.FilterHandler.doHandle(FilterHandler.java:108) at org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:80) at org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:46) at
[jira] [Commented] (SLING-4405) Unable to install bundle for the first time
[
https://issues.apache.org/jira/browse/SLING-4405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14316121#comment-14316121
]
Satya Deep Maheshwari commented on SLING-4405:
--
{quote}
Robert Munteanu romb...@apache.org
4:55 PM (39 minutes ago)
to users
Hi,
Can you please file a bug for this?
In the meantime, since it seems like you're using the 'jar' bundle
upload mechanism, you can try uploading from the local directory, if
Sling runs on the same machine.
{quote}
Unable to install bundle for the first time
---
Key: SLING-4405
URL: https://issues.apache.org/jira/browse/SLING-4405
Project: Sling
Issue Type: Bug
Components: IDE
Reporter: Satya Deep Maheshwari
I am experimenting with sling IDE tooling. I am facing a problem wherein I am
unable to deploy the bundle for the very first time using it. Once I have
uploaded the bundle once using some other means, I am subsequently able to
upload successfully using the ide tooling.
On debugging this a bit, I see that the on installing the bundle for the very
first time, the felix framework attempts to search for the bundle in a
non-existent directory which fails with a FileNotFound exception. I compared
this with the bundle install done from the felix web console. It looks like
IDE tooling uses the InstallServlet mechanism while the web console does not.
The InstallServlet tries to determine the location of this bundle if it
already exists and if it does not, it sets it to null which later causes the
above mentioned problem.
Below is the exception trace:
11.02.2015 14:59:49.172 *ERROR* [qtp1941320881-42] ERROR: Error getting
location from bundle archive. (java.io.FileNotFoundException:
/home/satyadeep/code/sling/sling/felix/bundle181/bundle.location (No such
file or directory))
java.io.FileNotFoundException:
/home/satyadeep/code/sling/sling/felix/bundle181/bundle.location (No such
file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.init(FileInputStream.java:146)
at
org.apache.felix.framework.util.SecureAction.getFileInputStream(SecureAction.java:453)
at
org.apache.felix.framework.cache.BundleArchive.readLocation(BundleArchive.java:1107)
at
org.apache.felix.framework.cache.BundleArchive.getLocation(BundleArchive.java:256)
at
org.apache.felix.framework.BundleImpl._getLocation(BundleImpl.java:621)
at
org.apache.felix.framework.BundleProtectionDomain$RevisionAsJarURL.create(BundleProtectionDomain.java:335)
at
org.apache.felix.framework.BundleProtectionDomain$RevisionAsJarURL.access$200(BundleProtectionDomain.java:234)
at
org.apache.felix.framework.BundleProtectionDomain.init(BundleProtectionDomain.java:385)
at
org.apache.felix.framework.Felix.setBundleProtectionDomain(Felix.java:938)
at
org.apache.felix.framework.BundleImpl.addRevision(BundleImpl.java:1219)
at org.apache.felix.framework.BundleImpl.init(BundleImpl.java:114)
at org.apache.felix.framework.Felix.installBundle(Felix.java:2976)
at
org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:169)
at
org.apache.sling.tooling.support.install.impl.InstallServlet.installOrUpdateBundle(InstallServlet.java:242)
at
org.apache.sling.tooling.support.install.impl.InstallServlet.installBasedOnUploadedJar(InstallServlet.java:149)
at
org.apache.sling.tooling.support.install.impl.InstallServlet.doPost(InstallServlet.java:101)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:641)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at
org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:339)
at
org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:300)
at
org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:93)
at
org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:50)
at
org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:31)
at
org.apache.sling.launchpad.testservices.filters.TestFilter.doFilter(TestFilter.java:47)
at
org.apache.sling.launchpad.testservices.filters.HttpServiceExtFilter.doFilter(HttpServiceExtFilter.java:27)
at
org.apache.felix.http.base.internal.handler.FilterHandler.doHandle(FilterHandler.java:108)
at
org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:80)
at
org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:46)
at
[jira] [Commented] (SLING-4405) Unable to install bundle for the first time
[ https://issues.apache.org/jira/browse/SLING-4405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14316147#comment-14316147 ] Satya Deep Maheshwari commented on SLING-4405: -- Yes uploading from local directory works. Unable to install bundle for the first time --- Key: SLING-4405 URL: https://issues.apache.org/jira/browse/SLING-4405 Project: Sling Issue Type: Bug Components: IDE Affects Versions: Tooling Support Install 1.0.0 Reporter: Satya Deep Maheshwari Assignee: Robert Munteanu Fix For: Tooling Support Install 1.0.2 I am experimenting with sling IDE tooling. I am facing a problem wherein I am unable to deploy the bundle for the very first time using it. Once I have uploaded the bundle once using some other means, I am subsequently able to upload successfully using the ide tooling. On debugging this a bit, I see that the on installing the bundle for the very first time, the felix framework attempts to search for the bundle in a non-existent directory which fails with a FileNotFound exception. I compared this with the bundle install done from the felix web console. It looks like IDE tooling uses the InstallServlet mechanism while the web console does not. The InstallServlet tries to determine the location of this bundle if it already exists and if it does not, it sets it to null which later causes the above mentioned problem. Below is the exception trace: 11.02.2015 14:59:49.172 *ERROR* [qtp1941320881-42] ERROR: Error getting location from bundle archive. (java.io.FileNotFoundException: /home/satyadeep/code/sling/sling/felix/bundle181/bundle.location (No such file or directory)) java.io.FileNotFoundException: /home/satyadeep/code/sling/sling/felix/bundle181/bundle.location (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:146) at org.apache.felix.framework.util.SecureAction.getFileInputStream(SecureAction.java:453) at org.apache.felix.framework.cache.BundleArchive.readLocation(BundleArchive.java:1107) at org.apache.felix.framework.cache.BundleArchive.getLocation(BundleArchive.java:256) at org.apache.felix.framework.BundleImpl._getLocation(BundleImpl.java:621) at org.apache.felix.framework.BundleProtectionDomain$RevisionAsJarURL.create(BundleProtectionDomain.java:335) at org.apache.felix.framework.BundleProtectionDomain$RevisionAsJarURL.access$200(BundleProtectionDomain.java:234) at org.apache.felix.framework.BundleProtectionDomain.init(BundleProtectionDomain.java:385) at org.apache.felix.framework.Felix.setBundleProtectionDomain(Felix.java:938) at org.apache.felix.framework.BundleImpl.addRevision(BundleImpl.java:1219) at org.apache.felix.framework.BundleImpl.init(BundleImpl.java:114) at org.apache.felix.framework.Felix.installBundle(Felix.java:2976) at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:169) at org.apache.sling.tooling.support.install.impl.InstallServlet.installOrUpdateBundle(InstallServlet.java:242) at org.apache.sling.tooling.support.install.impl.InstallServlet.installBasedOnUploadedJar(InstallServlet.java:149) at org.apache.sling.tooling.support.install.impl.InstallServlet.doPost(InstallServlet.java:101) at javax.servlet.http.HttpServlet.service(HttpServlet.java:641) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:339) at org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:300) at org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:93) at org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:50) at org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:31) at org.apache.sling.launchpad.testservices.filters.TestFilter.doFilter(TestFilter.java:47) at org.apache.sling.launchpad.testservices.filters.HttpServiceExtFilter.doFilter(HttpServiceExtFilter.java:27) at org.apache.felix.http.base.internal.handler.FilterHandler.doHandle(FilterHandler.java:108) at org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:80) at org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:46) at org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:31) at
[jira] [Commented] (SLING-4405) Unable to install bundle for the first time
[ https://issues.apache.org/jira/browse/SLING-4405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14316148#comment-14316148 ] Satya Deep Maheshwari commented on SLING-4405: -- Yes uploading from local directory works. Unable to install bundle for the first time --- Key: SLING-4405 URL: https://issues.apache.org/jira/browse/SLING-4405 Project: Sling Issue Type: Bug Components: IDE Affects Versions: Tooling Support Install 1.0.0 Reporter: Satya Deep Maheshwari Assignee: Robert Munteanu Fix For: Tooling Support Install 1.0.2 I am experimenting with sling IDE tooling. I am facing a problem wherein I am unable to deploy the bundle for the very first time using it. Once I have uploaded the bundle once using some other means, I am subsequently able to upload successfully using the ide tooling. On debugging this a bit, I see that the on installing the bundle for the very first time, the felix framework attempts to search for the bundle in a non-existent directory which fails with a FileNotFound exception. I compared this with the bundle install done from the felix web console. It looks like IDE tooling uses the InstallServlet mechanism while the web console does not. The InstallServlet tries to determine the location of this bundle if it already exists and if it does not, it sets it to null which later causes the above mentioned problem. Below is the exception trace: 11.02.2015 14:59:49.172 *ERROR* [qtp1941320881-42] ERROR: Error getting location from bundle archive. (java.io.FileNotFoundException: /home/satyadeep/code/sling/sling/felix/bundle181/bundle.location (No such file or directory)) java.io.FileNotFoundException: /home/satyadeep/code/sling/sling/felix/bundle181/bundle.location (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:146) at org.apache.felix.framework.util.SecureAction.getFileInputStream(SecureAction.java:453) at org.apache.felix.framework.cache.BundleArchive.readLocation(BundleArchive.java:1107) at org.apache.felix.framework.cache.BundleArchive.getLocation(BundleArchive.java:256) at org.apache.felix.framework.BundleImpl._getLocation(BundleImpl.java:621) at org.apache.felix.framework.BundleProtectionDomain$RevisionAsJarURL.create(BundleProtectionDomain.java:335) at org.apache.felix.framework.BundleProtectionDomain$RevisionAsJarURL.access$200(BundleProtectionDomain.java:234) at org.apache.felix.framework.BundleProtectionDomain.init(BundleProtectionDomain.java:385) at org.apache.felix.framework.Felix.setBundleProtectionDomain(Felix.java:938) at org.apache.felix.framework.BundleImpl.addRevision(BundleImpl.java:1219) at org.apache.felix.framework.BundleImpl.init(BundleImpl.java:114) at org.apache.felix.framework.Felix.installBundle(Felix.java:2976) at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:169) at org.apache.sling.tooling.support.install.impl.InstallServlet.installOrUpdateBundle(InstallServlet.java:242) at org.apache.sling.tooling.support.install.impl.InstallServlet.installBasedOnUploadedJar(InstallServlet.java:149) at org.apache.sling.tooling.support.install.impl.InstallServlet.doPost(InstallServlet.java:101) at javax.servlet.http.HttpServlet.service(HttpServlet.java:641) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:339) at org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:300) at org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:93) at org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:50) at org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:31) at org.apache.sling.launchpad.testservices.filters.TestFilter.doFilter(TestFilter.java:47) at org.apache.sling.launchpad.testservices.filters.HttpServiceExtFilter.doFilter(HttpServiceExtFilter.java:27) at org.apache.felix.http.base.internal.handler.FilterHandler.doHandle(FilterHandler.java:108) at org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:80) at org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:46) at org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:31) at
[jira] [Commented] (SLING-4405) Unable to install bundle for the first time
[ https://issues.apache.org/jira/browse/SLING-4405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14316146#comment-14316146 ] Satya Deep Maheshwari commented on SLING-4405: -- Yes uploading from local directory works. Unable to install bundle for the first time --- Key: SLING-4405 URL: https://issues.apache.org/jira/browse/SLING-4405 Project: Sling Issue Type: Bug Components: IDE Affects Versions: Tooling Support Install 1.0.0 Reporter: Satya Deep Maheshwari Assignee: Robert Munteanu Fix For: Tooling Support Install 1.0.2 I am experimenting with sling IDE tooling. I am facing a problem wherein I am unable to deploy the bundle for the very first time using it. Once I have uploaded the bundle once using some other means, I am subsequently able to upload successfully using the ide tooling. On debugging this a bit, I see that the on installing the bundle for the very first time, the felix framework attempts to search for the bundle in a non-existent directory which fails with a FileNotFound exception. I compared this with the bundle install done from the felix web console. It looks like IDE tooling uses the InstallServlet mechanism while the web console does not. The InstallServlet tries to determine the location of this bundle if it already exists and if it does not, it sets it to null which later causes the above mentioned problem. Below is the exception trace: 11.02.2015 14:59:49.172 *ERROR* [qtp1941320881-42] ERROR: Error getting location from bundle archive. (java.io.FileNotFoundException: /home/satyadeep/code/sling/sling/felix/bundle181/bundle.location (No such file or directory)) java.io.FileNotFoundException: /home/satyadeep/code/sling/sling/felix/bundle181/bundle.location (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:146) at org.apache.felix.framework.util.SecureAction.getFileInputStream(SecureAction.java:453) at org.apache.felix.framework.cache.BundleArchive.readLocation(BundleArchive.java:1107) at org.apache.felix.framework.cache.BundleArchive.getLocation(BundleArchive.java:256) at org.apache.felix.framework.BundleImpl._getLocation(BundleImpl.java:621) at org.apache.felix.framework.BundleProtectionDomain$RevisionAsJarURL.create(BundleProtectionDomain.java:335) at org.apache.felix.framework.BundleProtectionDomain$RevisionAsJarURL.access$200(BundleProtectionDomain.java:234) at org.apache.felix.framework.BundleProtectionDomain.init(BundleProtectionDomain.java:385) at org.apache.felix.framework.Felix.setBundleProtectionDomain(Felix.java:938) at org.apache.felix.framework.BundleImpl.addRevision(BundleImpl.java:1219) at org.apache.felix.framework.BundleImpl.init(BundleImpl.java:114) at org.apache.felix.framework.Felix.installBundle(Felix.java:2976) at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:169) at org.apache.sling.tooling.support.install.impl.InstallServlet.installOrUpdateBundle(InstallServlet.java:242) at org.apache.sling.tooling.support.install.impl.InstallServlet.installBasedOnUploadedJar(InstallServlet.java:149) at org.apache.sling.tooling.support.install.impl.InstallServlet.doPost(InstallServlet.java:101) at javax.servlet.http.HttpServlet.service(HttpServlet.java:641) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:339) at org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:300) at org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:93) at org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:50) at org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:31) at org.apache.sling.launchpad.testservices.filters.TestFilter.doFilter(TestFilter.java:47) at org.apache.sling.launchpad.testservices.filters.HttpServiceExtFilter.doFilter(HttpServiceExtFilter.java:27) at org.apache.felix.http.base.internal.handler.FilterHandler.doHandle(FilterHandler.java:108) at org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:80) at org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:46) at org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:31) at
[jira] [Issue Comment Deleted] (SLING-4405) Unable to install bundle for the first time
[ https://issues.apache.org/jira/browse/SLING-4405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Satya Deep Maheshwari updated SLING-4405: - Comment: was deleted (was: Yes uploading from local directory works.) Unable to install bundle for the first time --- Key: SLING-4405 URL: https://issues.apache.org/jira/browse/SLING-4405 Project: Sling Issue Type: Bug Components: IDE Affects Versions: Tooling Support Install 1.0.0 Reporter: Satya Deep Maheshwari Assignee: Robert Munteanu Fix For: Tooling Support Install 1.0.2 I am experimenting with sling IDE tooling. I am facing a problem wherein I am unable to deploy the bundle for the very first time using it. Once I have uploaded the bundle once using some other means, I am subsequently able to upload successfully using the ide tooling. On debugging this a bit, I see that the on installing the bundle for the very first time, the felix framework attempts to search for the bundle in a non-existent directory which fails with a FileNotFound exception. I compared this with the bundle install done from the felix web console. It looks like IDE tooling uses the InstallServlet mechanism while the web console does not. The InstallServlet tries to determine the location of this bundle if it already exists and if it does not, it sets it to null which later causes the above mentioned problem. Below is the exception trace: 11.02.2015 14:59:49.172 *ERROR* [qtp1941320881-42] ERROR: Error getting location from bundle archive. (java.io.FileNotFoundException: /home/satyadeep/code/sling/sling/felix/bundle181/bundle.location (No such file or directory)) java.io.FileNotFoundException: /home/satyadeep/code/sling/sling/felix/bundle181/bundle.location (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:146) at org.apache.felix.framework.util.SecureAction.getFileInputStream(SecureAction.java:453) at org.apache.felix.framework.cache.BundleArchive.readLocation(BundleArchive.java:1107) at org.apache.felix.framework.cache.BundleArchive.getLocation(BundleArchive.java:256) at org.apache.felix.framework.BundleImpl._getLocation(BundleImpl.java:621) at org.apache.felix.framework.BundleProtectionDomain$RevisionAsJarURL.create(BundleProtectionDomain.java:335) at org.apache.felix.framework.BundleProtectionDomain$RevisionAsJarURL.access$200(BundleProtectionDomain.java:234) at org.apache.felix.framework.BundleProtectionDomain.init(BundleProtectionDomain.java:385) at org.apache.felix.framework.Felix.setBundleProtectionDomain(Felix.java:938) at org.apache.felix.framework.BundleImpl.addRevision(BundleImpl.java:1219) at org.apache.felix.framework.BundleImpl.init(BundleImpl.java:114) at org.apache.felix.framework.Felix.installBundle(Felix.java:2976) at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:169) at org.apache.sling.tooling.support.install.impl.InstallServlet.installOrUpdateBundle(InstallServlet.java:242) at org.apache.sling.tooling.support.install.impl.InstallServlet.installBasedOnUploadedJar(InstallServlet.java:149) at org.apache.sling.tooling.support.install.impl.InstallServlet.doPost(InstallServlet.java:101) at javax.servlet.http.HttpServlet.service(HttpServlet.java:641) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:339) at org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:300) at org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:93) at org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:50) at org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:31) at org.apache.sling.launchpad.testservices.filters.TestFilter.doFilter(TestFilter.java:47) at org.apache.sling.launchpad.testservices.filters.HttpServiceExtFilter.doFilter(HttpServiceExtFilter.java:27) at org.apache.felix.http.base.internal.handler.FilterHandler.doHandle(FilterHandler.java:108) at org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:80) at org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:46) at org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:31) at
[jira] [Issue Comment Deleted] (SLING-4405) Unable to install bundle for the first time
[ https://issues.apache.org/jira/browse/SLING-4405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Satya Deep Maheshwari updated SLING-4405: - Comment: was deleted (was: Yes uploading from local directory works.) Unable to install bundle for the first time --- Key: SLING-4405 URL: https://issues.apache.org/jira/browse/SLING-4405 Project: Sling Issue Type: Bug Components: IDE Affects Versions: Tooling Support Install 1.0.0 Reporter: Satya Deep Maheshwari Assignee: Robert Munteanu Fix For: Tooling Support Install 1.0.2 I am experimenting with sling IDE tooling. I am facing a problem wherein I am unable to deploy the bundle for the very first time using it. Once I have uploaded the bundle once using some other means, I am subsequently able to upload successfully using the ide tooling. On debugging this a bit, I see that the on installing the bundle for the very first time, the felix framework attempts to search for the bundle in a non-existent directory which fails with a FileNotFound exception. I compared this with the bundle install done from the felix web console. It looks like IDE tooling uses the InstallServlet mechanism while the web console does not. The InstallServlet tries to determine the location of this bundle if it already exists and if it does not, it sets it to null which later causes the above mentioned problem. Below is the exception trace: 11.02.2015 14:59:49.172 *ERROR* [qtp1941320881-42] ERROR: Error getting location from bundle archive. (java.io.FileNotFoundException: /home/satyadeep/code/sling/sling/felix/bundle181/bundle.location (No such file or directory)) java.io.FileNotFoundException: /home/satyadeep/code/sling/sling/felix/bundle181/bundle.location (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:146) at org.apache.felix.framework.util.SecureAction.getFileInputStream(SecureAction.java:453) at org.apache.felix.framework.cache.BundleArchive.readLocation(BundleArchive.java:1107) at org.apache.felix.framework.cache.BundleArchive.getLocation(BundleArchive.java:256) at org.apache.felix.framework.BundleImpl._getLocation(BundleImpl.java:621) at org.apache.felix.framework.BundleProtectionDomain$RevisionAsJarURL.create(BundleProtectionDomain.java:335) at org.apache.felix.framework.BundleProtectionDomain$RevisionAsJarURL.access$200(BundleProtectionDomain.java:234) at org.apache.felix.framework.BundleProtectionDomain.init(BundleProtectionDomain.java:385) at org.apache.felix.framework.Felix.setBundleProtectionDomain(Felix.java:938) at org.apache.felix.framework.BundleImpl.addRevision(BundleImpl.java:1219) at org.apache.felix.framework.BundleImpl.init(BundleImpl.java:114) at org.apache.felix.framework.Felix.installBundle(Felix.java:2976) at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:169) at org.apache.sling.tooling.support.install.impl.InstallServlet.installOrUpdateBundle(InstallServlet.java:242) at org.apache.sling.tooling.support.install.impl.InstallServlet.installBasedOnUploadedJar(InstallServlet.java:149) at org.apache.sling.tooling.support.install.impl.InstallServlet.doPost(InstallServlet.java:101) at javax.servlet.http.HttpServlet.service(HttpServlet.java:641) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:339) at org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:300) at org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:93) at org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:50) at org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:31) at org.apache.sling.launchpad.testservices.filters.TestFilter.doFilter(TestFilter.java:47) at org.apache.sling.launchpad.testservices.filters.HttpServiceExtFilter.doFilter(HttpServiceExtFilter.java:27) at org.apache.felix.http.base.internal.handler.FilterHandler.doHandle(FilterHandler.java:108) at org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:80) at org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:46) at org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:31) at
