[jira] [Updated] (SLING-7552) SlingPostServlet error handling still insufficient

[JIRA]

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

Jörg Hoh updated SLING-7552:

Labels: patch  (was: )

> SlingPostServlet error handling still insufficient
> --
>
> Key: SLING-7552
> URL: https://issues.apache.org/jira/browse/SLING-7552
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Affects Versions: Servlets Post 2.3.24
>Reporter: Jörg Hoh
>Priority: Major
>  Labels: patch
> Attachments: SLING-7552-patch.diff
>
>
> At the moment the default errorhandling of Sling [1] cannot be used for 
> errors caused and handled by the SlingPostServlet itself. It will always 
> return its own custom output without the chance of customizing it. Although 
> Antonio and Justing worked in SLING-2156 to improve this situation, it still 
> requires extra work (implementing a PostResponseWithErrorHandling). It would 
> be better if the output could be customized by the "standard error handling".
>  
> How to reproduce:
>  * create an error handling script in 
> /apps/sling/servlet/errorhandler/default.jsp which creates some random output.
>  * Validate this script config by doing a request which causes some exception 
> (do not use the SlingPostServlet here)
>  * Do a POST to the Sling instance which results in an exception (e.g. due to 
> insufficient permissions.
>  * The output of the second call is completely determined by the 
> SlingPostServlet, the default error handling does not kick in.
> Proposed solution:
> * The SlingPostServlet should not swallow the exception and handle it by 
> itself, but rather re-throw it, so the standard error handling is triggered.
>  
> [1] http://sling.apache.org/documentation/the-sling-engine/errorhandling.html



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

[jira] [Updated] (SLING-7581) Using data-sly-use with two classes with same name will generate uncompilable code

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-7581:
---
Component/s: Scripting

> Using data-sly-use with two classes with same name will generate uncompilable 
> code
> --
>
> Key: SLING-7581
> URL: https://issues.apache.org/jira/browse/SLING-7581
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting HTL Compiler 1.0.16
>Reporter: Santiago García Pimentel
>Priority: Major
>
> If you have an HTL file with two data-sly-use with classes with the same name 
> HTL will generate a java file which cannot be compiled.
> e.g.
> {code}
> data-sly-use.first="com.adobe.cq.wcm.core.components.models.Page"
> data-sly-use.second="com.client.project.Page"
> {code}
>  
> Will generate
> {code}
> import com.client.project.Page;
> import com.adobe.cq.wcm.core.components.models.Page;
>  ...
>  ...
>  _global_first= renderContext.call("use", Page.class.getName(), obj());
>  _global_second = renderContext.call("use", Page.class.getName(), obj());
> {code} 
> Causing a compilation error as Page is not fully qualified in the code and 
> therefore an ambiguous reference (due to the two imports of same class names)
> This seems to have been introduced by SLING-7205 .



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

[jira] [Updated] (SLING-7581) Using data-sly-use with two classes with same name will generate uncompilable code

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-7581:
---
Description: 
If you have an HTL file with two data-sly-use with classes with the same name 
HTL will generate a java file which cannot be compiled.

e.g.
{code}
data-sly-use.first="com.adobe.cq.wcm.core.components.models.Page"
data-sly-use.second="com.client.project.Page"
{code}
 
Will generate
{code}
import com.client.project.Page;
import com.adobe.cq.wcm.core.components.models.Page;
 ...
 ...
 _global_first= renderContext.call("use", Page.class.getName(), obj());
 _global_second = renderContext.call("use", Page.class.getName(), obj());

{code} 
Causing a compilation error as Page is not fully qualified in the code and 
therefore an ambiguous reference (due to the two imports of same class names)

This seems to have been introduced by SLING-7205 .

  was:
If you have an HTL file with two data-sly-use with classes with the same name 
HTL will generate a java file which cannot be compiled.

e.g.
{code}
data-sly-use.first="com.adobe.cq.wcm.core.components.models.Page"
data-sly-use.second="com.client.project.Page"
{code}
 
Will generate
{code}
import com.client.project.Page;
import com.adobe.cq.wcm.core.components.models.Page;
 ...
 ...
 _global_first= renderContext.call("use", Page.class.getName(), obj());
 _global_second = renderContext.call("use", Page.class.getName(), obj());

{code} 
Causing a compilation error.
 

The import com.adobe.cq.wcm.core.components.models.Page collides with another 
import statement.

This seems to have been introduced by SLING-7205 .


> Using data-sly-use with two classes with same name will generate uncompilable 
> code
> --
>
> Key: SLING-7581
> URL: https://issues.apache.org/jira/browse/SLING-7581
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Scripting HTL Compiler 1.0.16
>Reporter: Santiago García Pimentel
>Priority: Major
>
> If you have an HTL file with two data-sly-use with classes with the same name 
> HTL will generate a java file which cannot be compiled.
> e.g.
> {code}
> data-sly-use.first="com.adobe.cq.wcm.core.components.models.Page"
> data-sly-use.second="com.client.project.Page"
> {code}
>  
> Will generate
> {code}
> import com.client.project.Page;
> import com.adobe.cq.wcm.core.components.models.Page;
>  ...
>  ...
>  _global_first= renderContext.call("use", Page.class.getName(), obj());
>  _global_second = renderContext.call("use", Page.class.getName(), obj());
> {code} 
> Causing a compilation error as Page is not fully qualified in the code and 
> therefore an ambiguous reference (due to the two imports of same class names)
> This seems to have been introduced by SLING-7205 .



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

[jira] [Updated] (SLING-7581) Using data-sly-use with two classes with same name will generate uncompilable code

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-7581:
---
Description: 
If you have an HTL file with two data-sly-use with classes with the same name 
HTL will generate a java file which cannot be compiled.

e.g.
{code}
data-sly-use.first="com.adobe.cq.wcm.core.components.models.Page"
data-sly-use.second="com.client.project.Page"
{code}
 
Will generate
{code}
import com.client.project.Page;
import com.adobe.cq.wcm.core.components.models.Page;
 ...
 ...
 _global_first= renderContext.call("use", Page.class.getName(), obj());
 _global_second = renderContext.call("use", Page.class.getName(), obj());

{code} 
Causing a compilation error.
 

The import com.adobe.cq.wcm.core.components.models.Page collides with another 
import statement.

This seems to have been introduced by SLING-7205 .

  was:
If you have a sightly file with two data-sly-use with classes with the same 
name. Sightly will generate a java file which cannot be compiled.

 

e.g.

data-sly-use.first="com.adobe.cq.wcm.core.components.models.Page"
 data-sly-use.second="com.client.project.Page"

 

Will generate

 

import com.client.project.Page;
 import com.adobe.cq.wcm.core.components.models.Page;
 ...
 ...
 _global_first= renderContext.call("use", Page.class.getName(), obj());
 _global_second = renderContext.call("use", Page.class.getName(), obj());

 

Causing a compilation error.

 

The import com.adobe.cq.wcm.core.components.models.Page collides with another 
import statement.

This seems to have been introduced by SLING-7205 .


> Using data-sly-use with two classes with same name will generate uncompilable 
> code
> --
>
> Key: SLING-7581
> URL: https://issues.apache.org/jira/browse/SLING-7581
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Scripting HTL Compiler 1.0.16
>Reporter: Santiago García Pimentel
>Priority: Major
>
> If you have an HTL file with two data-sly-use with classes with the same name 
> HTL will generate a java file which cannot be compiled.
> e.g.
> {code}
> data-sly-use.first="com.adobe.cq.wcm.core.components.models.Page"
> data-sly-use.second="com.client.project.Page"
> {code}
>  
> Will generate
> {code}
> import com.client.project.Page;
> import com.adobe.cq.wcm.core.components.models.Page;
>  ...
>  ...
>  _global_first= renderContext.call("use", Page.class.getName(), obj());
>  _global_second = renderContext.call("use", Page.class.getName(), obj());
> {code} 
> Causing a compilation error.
>  
> The import com.adobe.cq.wcm.core.components.models.Page collides with another 
> import statement.
> This seems to have been introduced by SLING-7205 .



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

[jira] [Created] (SLING-7581) Using data-sly-use with two classes with same name will generate uncompilable code

[JIRA]

Santiago García Pimentel created SLING-7581:
---

 Summary: Using data-sly-use with two classes with same name will 
generate uncompilable code
 Key: SLING-7581
 URL: https://issues.apache.org/jira/browse/SLING-7581
 Project: Sling
  Issue Type: Bug
Affects Versions: Scripting HTL Compiler 1.0.16
Reporter: Santiago García Pimentel


If you have a sightly file with two data-sly-use with classes with the same 
name. Sightly will generate a java file which cannot be compiled.

 

e.g.

data-sly-use.first="com.adobe.cq.wcm.core.components.models.Page"
 data-sly-use.second="com.client.project.Page"

 

Will generate

 

import com.client.project.Page;
 import com.adobe.cq.wcm.core.components.models.Page;
 ...
 ...
 _global_first= renderContext.call("use", Page.class.getName(), obj());
 _global_second = renderContext.call("use", Page.class.getName(), obj());

 

Causing a compilation error.

 

The import com.adobe.cq.wcm.core.components.models.Page collides with another 
import statement.

This seems to have been introduced by SLING-7205 .



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

[jira] [Comment Edited] (SLING-7534) Release policy - stop providing MD5 signatures

[Robert Munteanu (JIRA)]

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

Robert Munteanu edited comment on SLING-7534 at 4/13/18 11:10 AM:
--

Since what matters is whatever is stored in dist.apache.org, we can start off 
by removing .md5 files and ensuring we have .sha1 files for everything.

_Edit_: see also https://checker.apache.org/projs/sling.html


was (Author: rombert):
Since what matters is whatever is stored in dist.apache.org, we can start off 
by removing .md5 files and ensuring we have .sha1 files for everything.

> Release policy - stop providing MD5 signatures
> --
>
> Key: SLING-7534
> URL: https://issues.apache.org/jira/browse/SLING-7534
> Project: Sling
>  Issue Type: Task
>  Components: Tooling
>Reporter: Robert Munteanu
>Priority: Major
>
> See http://www.apache.org/dev/release-distribution#sigs-and-sums , we SHOULD 
> no longer provide MD5 checksums for new releases.



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

[jira] [Commented] (SLING-7534) Release policy - stop providing MD5 signatures

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-7534:


Since what matters is whatever is stored in dist.apache.org, we can start off 
by removing .md5 files and ensuring we have .sha1 files for everything.

> Release policy - stop providing MD5 signatures
> --
>
> Key: SLING-7534
> URL: https://issues.apache.org/jira/browse/SLING-7534
> Project: Sling
>  Issue Type: Task
>  Components: Tooling
>Reporter: Robert Munteanu
>Priority: Major
>
> See http://www.apache.org/dev/release-distribution#sigs-and-sums , we SHOULD 
> no longer provide MD5 checksums for new releases.



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

[jira] [Created] (SLING-7580) Servlets GET: JsonRendererServlet: ResourceTraversor: New optional request parameter appendChildResourceTypes should be provided to have the childresourceTypes array for

[Avani Sarsani (JIRA)]

Avani Sarsani created SLING-7580:


 Summary: Servlets GET: JsonRendererServlet: ResourceTraversor: New 
optional request parameter appendChildResourceTypes should be provided to have 
the childresourceTypes array for each JsonObjectBuilder object in the response.
 Key: SLING-7580
 URL: https://issues.apache.org/jira/browse/SLING-7580
 Project: Sling
  Issue Type: Bug
  Components: Servlets
Affects Versions: Servlets Get 2.1.30
Reporter: Avani Sarsani


1) Provide a new optional request query parameter 
"appendChildResourceTypes".When appendChildResourceTypes is provided as 
true,ChildResourceTypes Attribute should be defined for all the 
JsonObjectBuilder Objects in the response containing its respective immediate 
children's resourceTypes array.
2) Provide a new optional request query parameter "filterResourceTypes".Filter 
the response to return only those JsonObjectBuilder objects whose resourceTypes 
are present in the array of the filterResourceTypes.



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

[jira] [Commented] (SLING-7552) SlingPostServlet error handling still insufficient

[JIRA]

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

Jörg Hoh commented on SLING-7552:
-

I attached a patch, which just removes the error handling inside the 
SlingPostServlet and the AbstractPostOperation classes and throws the exception 
instead.

I don't like that the fact, that SlingRequestProcessor does not do call 
{{handleError}} when handling an IOException, but rather re-throws it as well. 
So in an case of an exception the SlingPostSerlvet has to wrap the IOException 
into an RuntimeException to trigger the {{handleError}} method in the 
SlingRequestProcessor. Open for better ideas.

> SlingPostServlet error handling still insufficient
> --
>
> Key: SLING-7552
> URL: https://issues.apache.org/jira/browse/SLING-7552
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Affects Versions: Servlets Post 2.3.24
>Reporter: Jörg Hoh
>Priority: Major
> Attachments: SLING-7552-patch.diff
>
>
> At the moment the default errorhandling of Sling [1] cannot be used for 
> errors caused and handled by the SlingPostServlet itself. It will always 
> return its own custom output without the chance of customizing it. Although 
> Antonio and Justing worked in SLING-2156 to improve this situation, it still 
> requires extra work (implementing a PostResponseWithErrorHandling). It would 
> be better if the output could be customized by the "standard error handling".
>  
> How to reproduce:
>  * create an error handling script in 
> /apps/sling/servlet/errorhandler/default.jsp which creates some random output.
>  * Validate this script config by doing a request which causes some exception 
> (do not use the SlingPostServlet here)
>  * Do a POST to the Sling instance which results in an exception (e.g. due to 
> insufficient permissions.
>  * The output of the second call is completely determined by the 
> SlingPostServlet, the default error handling does not kick in.
> Proposed solution:
> * The SlingPostServlet should not swallow the exception and handle it by 
> itself, but rather re-throw it, so the standard error handling is triggered.
>  
> [1] http://sling.apache.org/documentation/the-sling-engine/errorhandling.html



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

[jira] [Comment Edited] (SLING-7534) Release policy - stop providing MD5 signatures

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz edited comment on SLING-7534 at 4/13/18 7:35 AM:
-

As per discussion at [1], it looks like it's indeed {{maven-deploy-plugin}} 
which generates the checksum files - although I don't see a mention of 
checksums in the docs at 
[http://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html] so I'm 
still a bit skeptical.

However in INFRA-14923 and  at [1] Brian Fox says that getting rid of {{.md5}} 
requires Nexus code changes.

I suggest that we wait for INFRA-14923 to be clarified, nothing's urgent.

[1] 
[https://lists.apache.org/thread.html/c50e4842dbbe13b8196a43fa76d6040f8971bc5e812b561d080c5776@%3Cusers.infra.apache.org%3E]


was (Author: bdelacretaz):
As per discussion at [1], it looks like it's indeed {{maven-deploy-plugin}} 
which generates the checksum files.

However in INFRA-14923 and  at [1] Brian Fox says that getting rid of {{.md5}} 
requires Nexus code changes.

I suggest that we wait for INFRA-14923 to be clarified, nothing's urgent.

[1] 
https://lists.apache.org/thread.html/c50e4842dbbe13b8196a43fa76d6040f8971bc5e812b561d080c5776@%3Cusers.infra.apache.org%3E

> Release policy - stop providing MD5 signatures
> --
>
> Key: SLING-7534
> URL: https://issues.apache.org/jira/browse/SLING-7534
> Project: Sling
>  Issue Type: Task
>  Components: Tooling
>Reporter: Robert Munteanu
>Priority: Major
>
> See http://www.apache.org/dev/release-distribution#sigs-and-sums , we SHOULD 
> no longer provide MD5 checksums for new releases.



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

[jira] [Updated] (SLING-7552) SlingPostServlet error handling still insufficient

[JIRA]

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

Jörg Hoh updated SLING-7552:

Attachment: SLING-7552-patch.diff

> SlingPostServlet error handling still insufficient
> --
>
> Key: SLING-7552
> URL: https://issues.apache.org/jira/browse/SLING-7552
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Affects Versions: Servlets Post 2.3.24
>Reporter: Jörg Hoh
>Priority: Major
> Attachments: SLING-7552-patch.diff
>
>
> At the moment the default errorhandling of Sling [1] cannot be used for 
> errors caused and handled by the SlingPostServlet itself. It will always 
> return its own custom output without the chance of customizing it. Although 
> Antonio and Justing worked in SLING-2156 to improve this situation, it still 
> requires extra work (implementing a PostResponseWithErrorHandling). It would 
> be better if the output could be customized by the "standard error handling".
>  
> How to reproduce:
>  * create an error handling script in 
> /apps/sling/servlet/errorhandler/default.jsp which creates some random output.
>  * Validate this script config by doing a request which causes some exception 
> (do not use the SlingPostServlet here)
>  * Do a POST to the Sling instance which results in an exception (e.g. due to 
> insufficient permissions.
>  * The output of the second call is completely determined by the 
> SlingPostServlet, the default error handling does not kick in.
> Proposed solution:
> * The SlingPostServlet should not swallow the exception and handle it by 
> itself, but rather re-throw it, so the standard error handling is triggered.
>  
> [1] http://sling.apache.org/documentation/the-sling-engine/errorhandling.html



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

[jira] [Commented] (SLING-7534) Release policy - stop providing MD5 signatures

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-7534:


As per discussion at [1], it looks like it's indeed {{maven-deploy-plugin}} 
which generates the checksum files.

However in INFRA-14923 and  at [1] Brian Fox says that getting rid of {{.md5}} 
requires Nexus code changes.

I suggest that we wait for INFRA-14923 to be clarified, nothing's urgent.

[1] 
https://lists.apache.org/thread.html/c50e4842dbbe13b8196a43fa76d6040f8971bc5e812b561d080c5776@%3Cusers.infra.apache.org%3E

> Release policy - stop providing MD5 signatures
> --
>
> Key: SLING-7534
> URL: https://issues.apache.org/jira/browse/SLING-7534
> Project: Sling
>  Issue Type: Task
>  Components: Tooling
>Reporter: Robert Munteanu
>Priority: Major
>
> See http://www.apache.org/dev/release-distribution#sigs-and-sums , we SHOULD 
> no longer provide MD5 checksums for new releases.



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

Re: [LAZY] Removing .md5 digest files in our releases folder

[Bertrand Delacretaz]

On Thu, Apr 12, 2018 at 5:51 PM, Konrad Windszus  wrote:
> ...We should just defer the actual deletion until we figured out how to 
> prevent MD5 generation for new releases in the first place...

Ok, makes sense, I've made a note in SLING-7534

-Bertrand

[jira] [Commented] (SLING-7534) Release policy - stop providing MD5 signatures

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-7534:


Once this is clarified we should also remove existing .md5 files under 
https://dist.apache.org/repos/dist/release/sling/

> Release policy - stop providing MD5 signatures
> --
>
> Key: SLING-7534
> URL: https://issues.apache.org/jira/browse/SLING-7534
> Project: Sling
>  Issue Type: Task
>  Components: Tooling
>Reporter: Robert Munteanu
>Priority: Major
>
> See http://www.apache.org/dev/release-distribution#sigs-and-sums , we SHOULD 
> no longer provide MD5 checksums for new releases.



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