[jira] [Commented] (SLING-5582) DAM Updates fail due to race conditions with Workflows in AEM

[Andreas Schaefer (JIRA)]

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

Andreas Schaefer commented on SLING-5582:
-

I finally you get Eclipse going and I think the issue is that Eclipse works on 
changes. The IntelliJ plugin does something similar but it also has a feature 
to force the push to the server and there is where I see the issue cropping up. 

> DAM Updates fail due to race conditions with Workflows in AEM
> -
>
> Key: SLING-5582
> URL: https://issues.apache.org/jira/browse/SLING-5582
> Project: Sling
>  Issue Type: Bug
>  Components: IDE
>Affects Versions: Sling Eclipse IDE 1.0.10
>Reporter: Andreas Schaefer
> Fix For: Sling Eclipse IDE 1.1.2
>
>
> In my IntelliJ plugin an update of a DAM entry I sometimes run into an 
> exception while updating rendition files. This seems to be caused by the DAM 
> Workflows inside AEM which is triggered as soon as the original file is 
> updated. This is probably due to the fact that the "impl-vlt" code is 
> committing a change after each and every command and so the workflow is 
> triggered right away causing problems with the updates of the rendition files.
> I would think this is not just an issue of DAM assets but in general an issue 
> with any node that can trigger a workflow.
> From my point of view the plugin should be able to control the commits so 
> that a logical group like a DAM asset can be update in single step.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Random Failure to Deploy a File using AddOrUpdateNodeCommand

[Andreas Schaefer Sr.]

I tried to do some testing in Eclipse but I cannot connect. Always get the 
exception
Connection Refused.

No repository found at http://localhost:4052/
http://localhost:4052/server/-/jcr:root : java.net.ConnectException: Connection 
refused
http://localhost:4052/crx/-/jcr:root : java.net.ConnectException: Connection 
refused
No repository found at http://localhost:4052/
http://localhost:4052/server/-/jcr:root : java.net.ConnectException: Connection 
refused
http://localhost:4052/crx/-/jcr:root : java.net.ConnectException: Connection 
refused

Any idea what I am doing wrong?

- Andy

> On Mar 3, 2016, at 7:57 AM, Robert Munteanu  wrote:
> 
> On Thu, 2016-03-03 at 06:57 -0800, Andreas Schaefer Sr. wrote:
>> Hi Robert
>> 
>> Not sure why but I think this is a timing issue as a 100ms delay does
>> prevent it for me.
>> 
>> Ruben was suggesting to change the order of the updates where the
>> /renditions/original is added last (after the other renditions) but I
>> think that is just masking the problem once more.
> 
> I would not go there :-) First of all, this should be agnostic to any
> workflows or similar components running in a Sling instance.
> 
> Second of all, reordering updates can be tricky - I've had bugs due to
> that.
> 
>> 
>> I think this is a commit issue where IMPL-VLT is committing the
>> change after each file and not after updating the entire batch. I
>> would rather suggest to let the plugin control the commits so that
>> the changes to the renditions are only visible to the workflow when
>> all files including the renditions are updated.
> 
> Yes, that's a possible way out.
> 
>> I created the ticket:
>> 
>> https://issues.apache.org/jira/browse/SLING-5582
>> 
>> Let me know if you need more info in the ticket.
> 
> Ack, let's continue the conversation other there.
> 
> Thanks,
> 
> Robert
> 
>> 
>> Cheers - Andy
>> 
>>> 
>>> On Mar 3, 2016, at 2:14 AM, Robert Munteanu 
>>> wrote:
>>> 
>>> On Wed, 2016-03-02 at 17:05 -0800, Andreas Schaefer Sr. wrote:
 
 I went ahead and took out any changed resource that contains a
 path
 with /renditions/ but not /renditions/original
 
 That solves the issue if a workflow is present and active but, of
 course, if the workflow is not enabled then there will be no
 renditions. We could make it configurable to ignore renditions.
 
 That said I am wondering why this wasn’t discovered earlier. I am
 pretty sure if AEM has more latency or is executing slower it
 will
 not surface as delaying it did the trick.
>>> I do test some projects which should trigger these issues but I
>>> don't
>>> see them at all. Not sure why ...
>>> 
>>> Now that we understand the root cause, the next step for a fix is
>>> to
>>> get a test that fails. Feel free to add create a Jira issue to we
>>> can
>>> track this better.
>>> 
>>> Thanks,
>>> 
>>> Robert
>>> 
 
 
 - Andy
 
> 
> 
> 
> On Mar 2, 2016, at 4:09 PM, Andreas Schaefer Sr.  com>
> wrote:
> 
> Hi Robert
> 
> Yes, the Workflow are the most likely culprit as I did not
> encounter a problem when the Workflow were disabled but as soon
> as
> I switched them back on the error was back.
> 
> So I am wondering if the /renditions folder should be
> replicated at
> all.
> 
> BTW the error occurs even if the renditions were in place
> inside
> AEM. So both the Create / Update Node workflows will cause this
> issue.
> 
> Cheers - Andy Schaefer
> 
>> 
>> 
>> On Mar 2, 2016, at 3:16 AM, Robert Munteanu > rg>
>> wrote:
>> 
>> On Mon, 2016-02-29 at 16:02 -0800, Andreas Schaefer Sr.
>> wrote:
>>> 
>>> 
>>> Sorry for the late reply but I got bogged down by a
>>> customer
>>> going
>>> live.
>>> 
>>> Here is the stack trace:
>>> 
>>> Caused by:
>>> org.apache.sling.ide.transport.RepositoryException:
>>> javax.jcr.ItemExistsException: Cannot add child node
>>> 'cq5dam.web.1280.1280.jpeg' to
>>> /content/dam/aembase/asset.jpg/jcr:content/renditions:
>>> colliding with
>>> same-named existing node.
>>> 
>> Thanks for the stack trace. My current theory is the
>> following:
>> 
>> - your project holds locally assets and their generated
>> renditions
>> - the asset generating the error does not exist remotely (
>> and by
>> extension neither do its renditions )
>> - the asset is uploaded first and then the renditions start
>> being
>> generated ( via AEM workflows )
>> - at the same time, the plugin tries to upload the renditions
>> 
>> Can you try disabling the DAM workflows that generate the
>> renditions
>> and see if this occurs?
>> 
>> If that's the real reason, we can probably find a way around
>> it.
>> 
>> Thanks,

[jira] [Comment Edited] (SLING-5582) DAM Updates fail due to race conditions with Workflows in AEM

[Andreas Schaefer (JIRA)]

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

Andreas Schaefer edited comment on SLING-5582 at 3/3/16 6:52 PM:
-

I cannot tell if it is working with Eclipse as I have no idea on how to make it 
work. I cannot upgrade to 1.0.10 and so I am stuck with 1.0.4 which is probably 
outdated and the project I am using to test is not accepted (missing jcr_root 
folder).

The session.save() call is made in the JcrCommand.execute() method at the end 
(see my code snippet above).

I don't know how to create a unit test as I don't understand what actually is 
going wrong (does the workflow delete old renditions and recreate them?). My 
guess is after that code inside the AddOrUpdateNodeCommand:
{code:java}
private void update(ResourceProxy resource, Session session) throws 
RepositoryException, IOException {

String path = resource.getPath();
boolean nodeExists = session.nodeExists(path);

Node node;
if(nodeExists) {
node = session.getNode(path);
getLogger().trace("Found existing node at {0} with primaryType 
{1}", path, node.getPrimaryNodeType().getName());
} else {
node = createNode(resource, session);
getLogger().trace("Created node at {0} with primaryType {1}", path, 
node.getPrimaryNodeType().getName());
}
{code}
the workflow is deleting the old node and creates a new one and commits that 
before our command is through that is why we have an Item Already Exists 
exception. 

You might be able to force the failure on your end by adding a delay 
(Thread.sleep()) after that.


was (Author: schaefa):
I cannot tell if it is working with Eclipse as I have no idea on how to make it 
work. I cannot upgrade to 1.0.10 and so I am stuck with 1.0.4 which is probably 
outdated and the project I am using to test is not accepted (missing jcr_root 
folder).

The session.save() call is made in the JcrCommand.execute() method at the end 
(see my code snippet above).

I don't know how to create a unit test as I don't understand what actually is 
going wrong (does the workflow delete old renditions and recreate them?). My 
guess is after that code inside the AddOrUpdateNodeCommand:
private void update(ResourceProxy resource, Session session) throws 
RepositoryException, IOException {

String path = resource.getPath();
boolean nodeExists = session.nodeExists(path);

Node node;
if(nodeExists) {
node = session.getNode(path);
getLogger().trace("Found existing node at {0} with primaryType 
{1}", path, node.getPrimaryNodeType().getName());
} else {
node = createNode(resource, session);
getLogger().trace("Created node at {0} with primaryType {1}", path, 
node.getPrimaryNodeType().getName());
}

the workflow is deleting the old node and creates a new one and commits that 
before our command is through that is why we have an Item Already Exists 
exception. 

You might be able to force the failure on your end by adding a delay 
(Thread.sleep()) after that.

> DAM Updates fail due to race conditions with Workflows in AEM
> -
>
> Key: SLING-5582
> URL: https://issues.apache.org/jira/browse/SLING-5582
> Project: Sling
>  Issue Type: Bug
>  Components: IDE
>Affects Versions: Sling Eclipse IDE 1.0.10
>Reporter: Andreas Schaefer
> Fix For: Sling Eclipse IDE 1.1.2
>
>
> In my IntelliJ plugin an update of a DAM entry I sometimes run into an 
> exception while updating rendition files. This seems to be caused by the DAM 
> Workflows inside AEM which is triggered as soon as the original file is 
> updated. This is probably due to the fact that the "impl-vlt" code is 
> committing a change after each and every command and so the workflow is 
> triggered right away causing problems with the updates of the rendition files.
> I would think this is not just an issue of DAM assets but in general an issue 
> with any node that can trigger a workflow.
> From my point of view the plugin should be able to control the commits so 
> that a logical group like a DAM asset can be update in single step.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5582) DAM Updates fail due to race conditions with Workflows in AEM

[Andreas Schaefer (JIRA)]

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

Andreas Schaefer commented on SLING-5582:
-

I cannot tell if it is working with Eclipse as I have no idea on how to make it 
work. I cannot upgrade to 1.0.10 and so I am stuck with 1.0.4 which is probably 
outdated and the project I am using to test is not accepted (missing jcr_root 
folder).

The session.save() call is made in the JcrCommand.execute() method at the end 
(see my code snippet above).

I don't know how to create a unit test as I don't understand what actually is 
going wrong (does the workflow delete old renditions and recreate them?). My 
guess is after that code inside the AddOrUpdateNodeCommand:
private void update(ResourceProxy resource, Session session) throws 
RepositoryException, IOException {

String path = resource.getPath();
boolean nodeExists = session.nodeExists(path);

Node node;
if(nodeExists) {
node = session.getNode(path);
getLogger().trace("Found existing node at {0} with primaryType 
{1}", path, node.getPrimaryNodeType().getName());
} else {
node = createNode(resource, session);
getLogger().trace("Created node at {0} with primaryType {1}", path, 
node.getPrimaryNodeType().getName());
}

the workflow is deleting the old node and creates a new one and commits that 
before our command is through that is why we have an Item Already Exists 
exception. 

You might be able to force the failure on your end by adding a delay 
(Thread.sleep()) after that.

> DAM Updates fail due to race conditions with Workflows in AEM
> -
>
> Key: SLING-5582
> URL: https://issues.apache.org/jira/browse/SLING-5582
> Project: Sling
>  Issue Type: Bug
>  Components: IDE
>Affects Versions: Sling Eclipse IDE 1.0.10
>Reporter: Andreas Schaefer
> Fix For: Sling Eclipse IDE 1.1.2
>
>
> In my IntelliJ plugin an update of a DAM entry I sometimes run into an 
> exception while updating rendition files. This seems to be caused by the DAM 
> Workflows inside AEM which is triggered as soon as the original file is 
> updated. This is probably due to the fact that the "impl-vlt" code is 
> committing a change after each and every command and so the workflow is 
> triggered right away causing problems with the updates of the rendition files.
> I would think this is not just an issue of DAM assets but in general an issue 
> with any node that can trigger a workflow.
> From my point of view the plugin should be able to control the commits so 
> that a logical group like a DAM asset can be update in single step.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Random Failure to Deploy a File using AddOrUpdateNodeCommand

[Robert Munteanu]

On Thu, 2016-03-03 at 06:57 -0800, Andreas Schaefer Sr. wrote:
> Hi Robert
> 
> Not sure why but I think this is a timing issue as a 100ms delay does
> prevent it for me.
> 
> Ruben was suggesting to change the order of the updates where the
> /renditions/original is added last (after the other renditions) but I
> think that is just masking the problem once more.

I would not go there :-) First of all, this should be agnostic to any
workflows or similar components running in a Sling instance.

Second of all, reordering updates can be tricky - I've had bugs due to
that.

> 
> I think this is a commit issue where IMPL-VLT is committing the
> change after each file and not after updating the entire batch. I
> would rather suggest to let the plugin control the commits so that
> the changes to the renditions are only visible to the workflow when
> all files including the renditions are updated.

Yes, that's a possible way out.

> I created the ticket:
> 
> https://issues.apache.org/jira/browse/SLING-5582
> 
> Let me know if you need more info in the ticket.

Ack, let's continue the conversation other there.

Thanks,

Robert

> 
> Cheers - Andy
> 
> > 
> > On Mar 3, 2016, at 2:14 AM, Robert Munteanu 
> > wrote:
> > 
> > On Wed, 2016-03-02 at 17:05 -0800, Andreas Schaefer Sr. wrote:
> > > 
> > > I went ahead and took out any changed resource that contains a
> > > path
> > > with /renditions/ but not /renditions/original
> > > 
> > > That solves the issue if a workflow is present and active but, of
> > > course, if the workflow is not enabled then there will be no
> > > renditions. We could make it configurable to ignore renditions.
> > > 
> > > That said I am wondering why this wasn’t discovered earlier. I am
> > > pretty sure if AEM has more latency or is executing slower it
> > > will
> > > not surface as delaying it did the trick.
> > I do test some projects which should trigger these issues but I
> > don't
> > see them at all. Not sure why ...
> > 
> > Now that we understand the root cause, the next step for a fix is
> > to
> > get a test that fails. Feel free to add create a Jira issue to we
> > can
> > track this better.
> > 
> > Thanks,
> > 
> > Robert
> > 
> > > 
> > > 
> > > - Andy
> > > 
> > > > 
> > > > 
> > > > 
> > > > On Mar 2, 2016, at 4:09 PM, Andreas Schaefer Sr.  > > > com>
> > > > wrote:
> > > > 
> > > > Hi Robert
> > > > 
> > > > Yes, the Workflow are the most likely culprit as I did not
> > > > encounter a problem when the Workflow were disabled but as soon
> > > > as
> > > > I switched them back on the error was back.
> > > > 
> > > > So I am wondering if the /renditions folder should be
> > > > replicated at
> > > > all.
> > > > 
> > > > BTW the error occurs even if the renditions were in place
> > > > inside
> > > > AEM. So both the Create / Update Node workflows will cause this
> > > > issue.
> > > > 
> > > > Cheers - Andy Schaefer
> > > > 
> > > > > 
> > > > > 
> > > > > On Mar 2, 2016, at 3:16 AM, Robert Munteanu  > > > > rg>
> > > > > wrote:
> > > > > 
> > > > > On Mon, 2016-02-29 at 16:02 -0800, Andreas Schaefer Sr.
> > > > > wrote:
> > > > > > 
> > > > > > 
> > > > > > Sorry for the late reply but I got bogged down by a
> > > > > > customer
> > > > > > going
> > > > > > live.
> > > > > > 
> > > > > > Here is the stack trace:
> > > > > > 
> > > > > > Caused by:
> > > > > > org.apache.sling.ide.transport.RepositoryException:
> > > > > > javax.jcr.ItemExistsException: Cannot add child node
> > > > > > 'cq5dam.web.1280.1280.jpeg' to
> > > > > > /content/dam/aembase/asset.jpg/jcr:content/renditions:
> > > > > > colliding with
> > > > > > same-named existing node.
> > > > > > 
> > > > > Thanks for the stack trace. My current theory is the
> > > > > following:
> > > > > 
> > > > > - your project holds locally assets and their generated
> > > > > renditions
> > > > > - the asset generating the error does not exist remotely (
> > > > > and by
> > > > > extension neither do its renditions )
> > > > > - the asset is uploaded first and then the renditions start
> > > > > being
> > > > > generated ( via AEM workflows )
> > > > > - at the same time, the plugin tries to upload the renditions
> > > > > 
> > > > > Can you try disabling the DAM workflows that generate the
> > > > > renditions
> > > > > and see if this occurs?
> > > > > 
> > > > > If that's the real reason, we can probably find a way around
> > > > > it.
> > > > > 
> > > > > Thanks,
> > > > > 
> > > > > Robert
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > - Andy
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On Feb 18, 2016, at 12:15 AM, Robert Munteanu  > > > > > > ache
> > > > > > > .org>
> > > > > > > wrote:
> > > > > > > 
> > > > > > > Hi Andy,
> > > > > > > 
> > > > > > > On Wed, 2016-02-17 at 19:41 -0500, Andreas Schaefer Sr.
> > > > > > > wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Hi
> > > 

[jira] [Updated] (SLING-5582) DAM Updates fail due to race conditions with Workflows in AEM

[Robert Munteanu (JIRA)]

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

Robert Munteanu updated SLING-5582:
---
Fix Version/s: Sling Eclipse IDE 1.1.2

> DAM Updates fail due to race conditions with Workflows in AEM
> -
>
> Key: SLING-5582
> URL: https://issues.apache.org/jira/browse/SLING-5582
> Project: Sling
>  Issue Type: Bug
>  Components: IDE
>Affects Versions: Sling Eclipse IDE 1.0.10
>Reporter: Andreas Schaefer
> Fix For: Sling Eclipse IDE 1.1.2
>
>
> In my IntelliJ plugin an update of a DAM entry I sometimes run into an 
> exception while updating rendition files. This seems to be caused by the DAM 
> Workflows inside AEM which is triggered as soon as the original file is 
> updated. This is probably due to the fact that the "impl-vlt" code is 
> committing a change after each and every command and so the workflow is 
> triggered right away causing problems with the updates of the rendition files.
> I would think this is not just an issue of DAM assets but in general an issue 
> with any node that can trigger a workflow.
> From my point of view the plugin should be able to control the commits so 
> that a logical group like a DAM asset can be update in single step.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (SLING-5582) DAM Updates fail due to race conditions with Workflows in AEM

[Robert Munteanu (JIRA)]

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

Robert Munteanu edited comment on SLING-5582 at 3/3/16 3:53 PM:


This is the stacktrace of the exception:
{noformat}
Caused by: org.apache.sling.ide.io.ConnectorException: 
/content/dam/aembase/asset.jpg/jcr:content/renditions/cq5dam.web.1280.1280.jpeg
at 
com.headwire.aem.tooling.intellij.communication.AbstractDeploymentManager.execute(AbstractDeploymentManager.java:347)
at 
com.headwire.aem.tooling.intellij.communication.AbstractDeploymentManager.publishModule(AbstractDeploymentManager.java:137)
... 19 more
Caused by: org.apache.sling.ide.transport.RepositoryException: 
javax.jcr.ItemExistsException: Cannot add child node 
'cq5dam.web.1280.1280.jpeg' to 
/content/dam/aembase/asset.jpg/jcr:content/renditions: colliding with 
same-named existing node.
at org.apache.sling.ide.impl.vlt.JcrResult.failure(JcrResult.java:33)
at org.apache.sling.ide.impl.vlt.JcrCommand.execute(JcrCommand.java:80)
at 
org.apache.sling.ide.transport.TracingCommand.execute(TracingCommand.java:45)
at 
com.headwire.aem.tooling.intellij.communication.AbstractDeploymentManager.execute(AbstractDeploymentManager.java:336)
... 20 more
{noformat}

It is caused by the session.save() method call in JcrCommand:

{code:java}
@Override
public Result execute() {

Session session = null;
try {
session = repository.login(credentials);

T result = execute0(session);

//try {
//Thread.sleep(100);
//} catch(InterruptedException e) {
//}
session.save();

return JcrResult.success(result);
} catch (LoginException e) {
return JcrResult.failure(e);
} catch (RepositoryException e) {
return JcrResult.failure(e);
} catch (IOException e) {
return JcrResult.failure(e);
} finally {
if (session != null)
session.logout();
}
}
{code}

In my environment adding the delay (commented out above) does solve it most of 
the time but that's still a bandaid. If the session is provided to the 
JcrCommand and the save() is called when the plugin has done a logical group 
(all files inside a DAM asset etc) the problem should not arise anymore.


was (Author: schaefa):
This is the stacktrace of the exception:

Caused by: org.apache.sling.ide.io.ConnectorException: 
/content/dam/aembase/asset.jpg/jcr:content/renditions/cq5dam.web.1280.1280.jpeg
at 
com.headwire.aem.tooling.intellij.communication.AbstractDeploymentManager.execute(AbstractDeploymentManager.java:347)
at 
com.headwire.aem.tooling.intellij.communication.AbstractDeploymentManager.publishModule(AbstractDeploymentManager.java:137)
... 19 more
Caused by: org.apache.sling.ide.transport.RepositoryException: 
javax.jcr.ItemExistsException: Cannot add child node 
'cq5dam.web.1280.1280.jpeg' to 
/content/dam/aembase/asset.jpg/jcr:content/renditions: colliding with 
same-named existing node.
at org.apache.sling.ide.impl.vlt.JcrResult.failure(JcrResult.java:33)
at org.apache.sling.ide.impl.vlt.JcrCommand.execute(JcrCommand.java:80)
at 
org.apache.sling.ide.transport.TracingCommand.execute(TracingCommand.java:45)
at 
com.headwire.aem.tooling.intellij.communication.AbstractDeploymentManager.execute(AbstractDeploymentManager.java:336)
... 20 more

It is caused by the session.save() method call in JcrCommand:

@Override
public Result execute() {

Session session = null;
try {
session = repository.login(credentials);

T result = execute0(session);

//try {
//Thread.sleep(100);
//} catch(InterruptedException e) {
//}
session.save();

return JcrResult.success(result);
} catch (LoginException e) {
return JcrResult.failure(e);
} catch (RepositoryException e) {
return JcrResult.failure(e);
} catch (IOException e) {
return JcrResult.failure(e);
} finally {
if (session != null)
session.logout();
}
}

In my environment adding the delay (commented out above) does solve it most of 
the time but that's still a bandaid. If the session is provided to the 
JcrCommand and the save() is called when the plugin has done a logical group 
(all files inside a DAM asset etc) the problem should not arise anymore.

> DAM Updates fail due to race conditions with Workflows in AEM
> -
>
> Key: SLING-5582
> URL: https://issues.apache.org/jira/browse/SLING-5582
>

[jira] [Commented] (SLING-5582) DAM Updates fail due to race conditions with Workflows in AEM

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-5582:


Thanks for the report. A couple of comments

* I see from the stacktrace that this is not the default Eclipse plugin, but 
running in IntelliJ. Does this happen with Eclipse as well?
* I looked at the code in the {{AddOrUpdateNodeCommand}} and there's only a 
single {{Session#save}} call, when the node primary type is changed . Can you 
confirm that in your scenario {{Session#save}} is invoked in addition to the 
final one from {{JcrCommand#execute}}?
* I would still need a unit test 'proving' this problem as I can't reproduce it 
and the content sync code is complicated enough for a test to be the only guard 
against regressions

> DAM Updates fail due to race conditions with Workflows in AEM
> -
>
> Key: SLING-5582
> URL: https://issues.apache.org/jira/browse/SLING-5582
> Project: Sling
>  Issue Type: Bug
>  Components: IDE
>Affects Versions: Sling Eclipse IDE 1.0.10
>Reporter: Andreas Schaefer
> Fix For: Sling Eclipse IDE 1.1.2
>
>
> In my IntelliJ plugin an update of a DAM entry I sometimes run into an 
> exception while updating rendition files. This seems to be caused by the DAM 
> Workflows inside AEM which is triggered as soon as the original file is 
> updated. This is probably due to the fact that the "impl-vlt" code is 
> committing a change after each and every command and so the workflow is 
> triggered right away causing problems with the updates of the rendition files.
> I would think this is not just an issue of DAM assets but in general an issue 
> with any node that can trigger a workflow.
> From my point of view the plugin should be able to control the commits so 
> that a logical group like a DAM asset can be update in single step.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-5576) Optimize queue items listing for big number of items by using iterators

[Marius Petria (JIRA)]

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

Marius Petria resolved SLING-5576.
--
Resolution: Fixed

Committed revision 1733486.


> Optimize queue items listing for big number of items by using iterators
> ---
>
> Key: SLING-5576
> URL: https://issues.apache.org/jira/browse/SLING-5576
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
>
> We should an iterator when retrieving queue items as it can happen to have 
> tens of thousands of items in the queue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-5583) Add defaults to server creation page in the project creation wizard

[Robert Munteanu (JIRA)]

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

Robert Munteanu resolved SLING-5583.

Resolution: Fixed

> Add defaults to server creation page in the project creation wizard
> ---
>
> Key: SLING-5583
> URL: https://issues.apache.org/jira/browse/SLING-5583
> Project: Sling
>  Issue Type: Improvement
>  Components: IDE
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Minor
> Fix For: Sling Eclipse IDE 1.1.0
>
>
> When creating a project the final page allows the user to create a new server 
> on the fly. However, all the inputs are empty. We should default to a 
> well-known set of values - port 8080, authenticate using admin/admin, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5583) Add defaults to server creation page in the project creation wizard

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-5583:


- [r1733483|https://svn.apache.org/r1733483] - added 
DefaultSlingLaunchpadConfiguration and used it in the wizard
- [r1733484|https://svn.apache.org/r1733484] - replaced hardcoded values with 
defaults from the DefaultSlingLaunchpadConfiguration

> Add defaults to server creation page in the project creation wizard
> ---
>
> Key: SLING-5583
> URL: https://issues.apache.org/jira/browse/SLING-5583
> Project: Sling
>  Issue Type: Improvement
>  Components: IDE
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Minor
> Fix For: Sling Eclipse IDE 1.1.0
>
>
> When creating a project the final page allows the user to create a new server 
> on the fly. However, all the inputs are empty. We should default to a 
> well-known set of values - port 8080, authenticate using admin/admin, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5582) DAM Updates fail due to race conditions with Workflows in AEM

[Andreas Schaefer (JIRA)]

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

Andreas Schaefer commented on SLING-5582:
-

This is the stacktrace of the exception:

Caused by: org.apache.sling.ide.io.ConnectorException: 
/content/dam/aembase/asset.jpg/jcr:content/renditions/cq5dam.web.1280.1280.jpeg
at 
com.headwire.aem.tooling.intellij.communication.AbstractDeploymentManager.execute(AbstractDeploymentManager.java:347)
at 
com.headwire.aem.tooling.intellij.communication.AbstractDeploymentManager.publishModule(AbstractDeploymentManager.java:137)
... 19 more
Caused by: org.apache.sling.ide.transport.RepositoryException: 
javax.jcr.ItemExistsException: Cannot add child node 
'cq5dam.web.1280.1280.jpeg' to 
/content/dam/aembase/asset.jpg/jcr:content/renditions: colliding with 
same-named existing node.
at org.apache.sling.ide.impl.vlt.JcrResult.failure(JcrResult.java:33)
at org.apache.sling.ide.impl.vlt.JcrCommand.execute(JcrCommand.java:80)
at 
org.apache.sling.ide.transport.TracingCommand.execute(TracingCommand.java:45)
at 
com.headwire.aem.tooling.intellij.communication.AbstractDeploymentManager.execute(AbstractDeploymentManager.java:336)
... 20 more

It is caused by the session.save() method call in JcrCommand:

@Override
public Result execute() {

Session session = null;
try {
session = repository.login(credentials);

T result = execute0(session);

//try {
//Thread.sleep(100);
//} catch(InterruptedException e) {
//}
session.save();

return JcrResult.success(result);
} catch (LoginException e) {
return JcrResult.failure(e);
} catch (RepositoryException e) {
return JcrResult.failure(e);
} catch (IOException e) {
return JcrResult.failure(e);
} finally {
if (session != null)
session.logout();
}
}

In my environment adding the delay (commented out above) does solve it most of 
the time but that's still a bandaid. If the session is provided to the 
JcrCommand and the save() is called when the plugin has done a logical group 
(all files inside a DAM asset etc) the problem should not arise anymore.

> DAM Updates fail due to race conditions with Workflows in AEM
> -
>
> Key: SLING-5582
> URL: https://issues.apache.org/jira/browse/SLING-5582
> Project: Sling
>  Issue Type: Bug
>  Components: IDE
>Affects Versions: Sling Eclipse IDE 1.0.10
>Reporter: Andreas Schaefer
>
> In my IntelliJ plugin an update of a DAM entry I sometimes run into an 
> exception while updating rendition files. This seems to be caused by the DAM 
> Workflows inside AEM which is triggered as soon as the original file is 
> updated. This is probably due to the fact that the "impl-vlt" code is 
> committing a change after each and every command and so the workflow is 
> triggered right away causing problems with the updates of the rendition files.
> I would think this is not just an issue of DAM assets but in general an issue 
> with any node that can trigger a workflow.
> From my point of view the plugin should be able to control the commits so 
> that a logical group like a DAM asset can be update in single step.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5583) Add defaults to server creation page in the project creation wizard

[Robert Munteanu (JIRA)]

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

Robert Munteanu updated SLING-5583:
---
Summary: Add defaults to server creation page in the project creation 
wizard  (was: Add default to server creation page in the project creation 
wizard)

> Add defaults to server creation page in the project creation wizard
> ---
>
> Key: SLING-5583
> URL: https://issues.apache.org/jira/browse/SLING-5583
> Project: Sling
>  Issue Type: Improvement
>  Components: IDE
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Minor
> Fix For: Sling Eclipse IDE 1.1.0
>
>
> When creating a project the final page allows the user to create a new server 
> on the fly. However, all the inputs are empty. We should default to a 
> well-known set of values - port 8080, authenticate using admin/admin, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-5583) Add default to server creation page in the project creation wizard

[Robert Munteanu (JIRA)]

Robert Munteanu created SLING-5583:
--

 Summary: Add default to server creation page in the project 
creation wizard
 Key: SLING-5583
 URL: https://issues.apache.org/jira/browse/SLING-5583
 Project: Sling
  Issue Type: Improvement
  Components: IDE
Reporter: Robert Munteanu
Assignee: Robert Munteanu
Priority: Minor
 Fix For: Sling Eclipse IDE 1.1.0


When creating a project the final page allows the user to create a new server 
on the fly. However, all the inputs are empty. We should default to a 
well-known set of values - port 8080, authenticate using admin/admin, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Random Failure to Deploy a File using AddOrUpdateNodeCommand

[Andreas Schaefer Sr.]

Hi Robert

Not sure why but I think this is a timing issue as a 100ms delay does prevent 
it for me.

Ruben was suggesting to change the order of the updates where the 
/renditions/original is added last (after the other renditions) but I think 
that is just masking the problem once more.

I think this is a commit issue where IMPL-VLT is committing the change after 
each file and not after updating the entire batch. I would rather suggest to 
let the plugin control the commits so that the changes to the renditions are 
only visible to the workflow when all files including the renditions are 
updated.

I created the ticket:

https://issues.apache.org/jira/browse/SLING-5582

Let me know if you need more info in the ticket.

Cheers - Andy

> On Mar 3, 2016, at 2:14 AM, Robert Munteanu  wrote:
> 
> On Wed, 2016-03-02 at 17:05 -0800, Andreas Schaefer Sr. wrote:
>> I went ahead and took out any changed resource that contains a path
>> with /renditions/ but not /renditions/original
>> 
>> That solves the issue if a workflow is present and active but, of
>> course, if the workflow is not enabled then there will be no
>> renditions. We could make it configurable to ignore renditions.
>> 
>> That said I am wondering why this wasn’t discovered earlier. I am
>> pretty sure if AEM has more latency or is executing slower it will
>> not surface as delaying it did the trick.
> 
> I do test some projects which should trigger these issues but I don't
> see them at all. Not sure why ...
> 
> Now that we understand the root cause, the next step for a fix is to
> get a test that fails. Feel free to add create a Jira issue to we can
> track this better.
> 
> Thanks,
> 
> Robert
> 
>> 
>> - Andy
>> 
>>> 
>>> 
>>> On Mar 2, 2016, at 4:09 PM, Andreas Schaefer Sr. 
>>> wrote:
>>> 
>>> Hi Robert
>>> 
>>> Yes, the Workflow are the most likely culprit as I did not
>>> encounter a problem when the Workflow were disabled but as soon as
>>> I switched them back on the error was back.
>>> 
>>> So I am wondering if the /renditions folder should be replicated at
>>> all.
>>> 
>>> BTW the error occurs even if the renditions were in place inside
>>> AEM. So both the Create / Update Node workflows will cause this
>>> issue.
>>> 
>>> Cheers - Andy Schaefer
>>> 
 
 On Mar 2, 2016, at 3:16 AM, Robert Munteanu 
 wrote:
 
 On Mon, 2016-02-29 at 16:02 -0800, Andreas Schaefer Sr. wrote:
> 
> Sorry for the late reply but I got bogged down by a customer
> going
> live.
> 
> Here is the stack trace:
> 
> Caused by: org.apache.sling.ide.transport.RepositoryException:
> javax.jcr.ItemExistsException: Cannot add child node
> 'cq5dam.web.1280.1280.jpeg' to
> /content/dam/aembase/asset.jpg/jcr:content/renditions:
> colliding with
> same-named existing node.
> 
 Thanks for the stack trace. My current theory is the following:
 
 - your project holds locally assets and their generated
 renditions
 - the asset generating the error does not exist remotely ( and by
 extension neither do its renditions )
 - the asset is uploaded first and then the renditions start being
 generated ( via AEM workflows )
 - at the same time, the plugin tries to upload the renditions
 
 Can you try disabling the DAM workflows that generate the
 renditions
 and see if this occurs?
 
 If that's the real reason, we can probably find a way around it.
 
 Thanks,
 
 Robert
 
> 
> 
> - Andy
> 
>> 
>> 
>> On Feb 18, 2016, at 12:15 AM, Robert Munteanu > .org>
>> wrote:
>> 
>> Hi Andy,
>> 
>> On Wed, 2016-02-17 at 19:41 -0500, Andreas Schaefer Sr.
>> wrote:
>>> 
>>> 
>>> Hi
>>> 
>>> During the development of the IntelliJ plugin I ran into
>>> some
>>> random
>>> failures to deploy.
>>> Looking deeper I save that the failure is happening when
>>> session.save() is called and
>>> to my surprise a slight delay (Thread.sleep(100)) does fix
>>> it on
>>> my
>>> Mac.
>>> 
>>> The code is in JcrCommand inside the impl-vlt module. This
>>> is the
>>> change that make it
>>> work for me:
>>> 
>>> @Override
>>> public Result execute() {
>>> 
>>>Session session = null;
>>>try {
>>>session = repository.login(credentials);
>>> 
>>>T result = execute0(session);
>>> 
>>>try {
>>>Thread.sleep(100);
>>>} catch(InterruptedException e) {
>>>}
>>>session.save();
>>> 
>>>return JcrResult.success(result);
>>> The exception I see is a ItemExistsException and was thrown
>>> for a
>>> folder and rendition file in the DAM.
>> Can you add a stack trace? Does this only happen for DAM
>> assets +
>> 

[jira] [Created] (SLING-5582) DAM Updates fail due to race conditions with Workflows in AEM

[Andreas Schaefer (JIRA)]

Andreas Schaefer created SLING-5582:
---

 Summary: DAM Updates fail due to race conditions with Workflows in 
AEM
 Key: SLING-5582
 URL: https://issues.apache.org/jira/browse/SLING-5582
 Project: Sling
  Issue Type: Bug
  Components: IDE
Affects Versions: Sling Eclipse IDE 1.0.10
Reporter: Andreas Schaefer


In my IntelliJ plugin an update of a DAM entry I sometimes run into an 
exception while updating rendition files. This seems to be caused by the DAM 
Workflows inside AEM which is triggered as soon as the original file is 
updated. This is probably due to the fact that the "impl-vlt" code is 
committing a change after each and every command and so the workflow is 
triggered right away causing problems with the updates of the rendition files.

I would think this is not just an issue of DAM assets but in general an issue 
with any node that can trigger a workflow.

>From my point of view the plugin should be able to control the commits so that 
>a logical group like a DAM asset can be update in single step.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-3100) Provide a m2e project configurator for packaging "content-package"

[Robert Munteanu (JIRA)]

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

Robert Munteanu resolved SLING-3100.

Resolution: Fixed

> Provide a m2e project configurator for packaging "content-package"
> --
>
> Key: SLING-3100
> URL: https://issues.apache.org/jira/browse/SLING-3100
> Project: Sling
>  Issue Type: New Feature
>  Components: IDE
>Affects Versions: Sling Eclipse IDE 1.0.0
>Reporter: Konrad Windszus
>Assignee: Robert Munteanu
> Fix For: Sling Eclipse IDE 1.1.0
>
> Attachments: 0001-WIP-do-not-push.patch, 
> SLING-3100-m2e-integration.patch
>
>
> To set up the appropriate project configuration just from the POM an 
> according m2e project configurator is needed 
> (http://wiki.eclipse.org/M2E_plugin_execution_not_covered#delegate_to_a_project_configurator_.28recommended.29)
> The m2e-war-plugin comes with a project configurator which works also for 
> content-packages pretty well but it is currently hard to reuse for any other 
> packaging than "war" (due to the delegate pattern being used internally, 
> compare with https://bugs.eclipse.org/bugs/show_bug.cgi?id=412213). Only if 
> the project is having the dynamic web project facet the following features in 
> Eclipse are supported:
> - JSP include directives (considered for validation and supports ctrl+click 
> to open linked file)
> - Tag Library Support ( 
> http://wiki.eclipse.org/WTP_FAQ#Why_isn.27t_the_JSP_editor.2Fvalidator_finding_my_custom_tag_libraries.3F
>  )
> - probably other features as well.
> Apart from that a feature like overlays should be supported ( 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=384154 ), as often 
> content-package projects are referencing JSPs from other projects, and the 
> IDE needs to know those, to complete the validation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5581) Transport doesn't throw an exception if a 400+ status is returned

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili updated SLING-5581:
---
Summary: Transport doesn't throw an exception if a 400+ status is returned  
(was: Transport doesn't throw an exception if a 4+ status is returned)

> Transport doesn't throw an exception if a 400+ status is returned
> -
>
> Key: SLING-5581
> URL: https://issues.apache.org/jira/browse/SLING-5581
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution
>Affects Versions: Content Distribution Core 0.1.12
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>Priority: Critical
> Fix For: Content Distribution Core 0.1.14
>
>
> {{SimpleHttpDistributionTransport}} HTTP call uses
> {code}
> Response response = executor.execute(req);
> response.discardContent();
> {code}
> but the second line doesn't throw an Exception if e.g. the HTTP status is 
> 500, while it used to do it when the code was:
> {code}
> Response response = executor.execute(req);
> response.returnContent();
> {code}
> Therefore this may result in lost packages if an error occurs on the 
> receiving side.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-3100) Provide a m2e project configurator for packaging "content-package"

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-3100:


Fixed eclipse-m2e-core/build.properties in 
[r1733466|https://svn.apache.org/r1733466]

> Provide a m2e project configurator for packaging "content-package"
> --
>
> Key: SLING-3100
> URL: https://issues.apache.org/jira/browse/SLING-3100
> Project: Sling
>  Issue Type: New Feature
>  Components: IDE
>Affects Versions: Sling Eclipse IDE 1.0.0
>Reporter: Konrad Windszus
>Assignee: Robert Munteanu
> Fix For: Sling Eclipse IDE 1.1.0
>
> Attachments: 0001-WIP-do-not-push.patch, 
> SLING-3100-m2e-integration.patch
>
>
> To set up the appropriate project configuration just from the POM an 
> according m2e project configurator is needed 
> (http://wiki.eclipse.org/M2E_plugin_execution_not_covered#delegate_to_a_project_configurator_.28recommended.29)
> The m2e-war-plugin comes with a project configurator which works also for 
> content-packages pretty well but it is currently hard to reuse for any other 
> packaging than "war" (due to the delegate pattern being used internally, 
> compare with https://bugs.eclipse.org/bugs/show_bug.cgi?id=412213). Only if 
> the project is having the dynamic web project facet the following features in 
> Eclipse are supported:
> - JSP include directives (considered for validation and supports ctrl+click 
> to open linked file)
> - Tag Library Support ( 
> http://wiki.eclipse.org/WTP_FAQ#Why_isn.27t_the_JSP_editor.2Fvalidator_finding_my_custom_tag_libraries.3F
>  )
> - probably other features as well.
> Apart from that a feature like overlays should be supported ( 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=384154 ), as often 
> content-package projects are referencing JSPs from other projects, and the 
> IDE needs to know those, to complete the validation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-5581) Transport doesn't throw an exception if a 4+ status is returned

[Tommaso Teofili (JIRA)]

Tommaso Teofili created SLING-5581:
--

 Summary: Transport doesn't throw an exception if a 4+ status is 
returned
 Key: SLING-5581
 URL: https://issues.apache.org/jira/browse/SLING-5581
 Project: Sling
  Issue Type: Bug
  Components: Distribution
Affects Versions: Content Distribution Core 0.1.12
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
Priority: Critical
 Fix For: Content Distribution Core 0.1.14


{{SimpleHttpDistributionTransport}} HTTP call uses

{code}
Response response = executor.execute(req);
response.discardContent();
{code}

but the second line doesn't throw an Exception if e.g. the HTTP status is 500, 
while it used to do it when the code was:
{code}
Response response = executor.execute(req);
response.returnContent();
{code}

Therefore this may result in lost packages if an error occurs on the receiving 
side.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-3100) Provide a m2e project configurator for packaging "content-package"

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-3100:


Patch applied in [r1733463|https://svn.apache.org/r1733463] with the changes 
that we discussed, thanks [~henzlerg] for the submission!

> Provide a m2e project configurator for packaging "content-package"
> --
>
> Key: SLING-3100
> URL: https://issues.apache.org/jira/browse/SLING-3100
> Project: Sling
>  Issue Type: New Feature
>  Components: IDE
>Affects Versions: Sling Eclipse IDE 1.0.0
>Reporter: Konrad Windszus
>Assignee: Robert Munteanu
> Fix For: Sling Eclipse IDE 1.1.0
>
> Attachments: 0001-WIP-do-not-push.patch, 
> SLING-3100-m2e-integration.patch
>
>
> To set up the appropriate project configuration just from the POM an 
> according m2e project configurator is needed 
> (http://wiki.eclipse.org/M2E_plugin_execution_not_covered#delegate_to_a_project_configurator_.28recommended.29)
> The m2e-war-plugin comes with a project configurator which works also for 
> content-packages pretty well but it is currently hard to reuse for any other 
> packaging than "war" (due to the delegate pattern being used internally, 
> compare with https://bugs.eclipse.org/bugs/show_bug.cgi?id=412213). Only if 
> the project is having the dynamic web project facet the following features in 
> Eclipse are supported:
> - JSP include directives (considered for validation and supports ctrl+click 
> to open linked file)
> - Tag Library Support ( 
> http://wiki.eclipse.org/WTP_FAQ#Why_isn.27t_the_JSP_editor.2Fvalidator_finding_my_custom_tag_libraries.3F
>  )
> - probably other features as well.
> Apart from that a feature like overlays should be supported ( 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=384154 ), as often 
> content-package projects are referencing JSPs from other projects, and the 
> IDE needs to know those, to complete the validation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

RE: [VOTE] release Health Checks Core 1.2.4 and Health Checks Annotations 1.0.4

[Stefan Seifert]

+1

Re: Random Failure to Deploy a File using AddOrUpdateNodeCommand

[Robert Munteanu]

On Wed, 2016-03-02 at 17:05 -0800, Andreas Schaefer Sr. wrote:
> I went ahead and took out any changed resource that contains a path
> with /renditions/ but not /renditions/original
> 
> That solves the issue if a workflow is present and active but, of
> course, if the workflow is not enabled then there will be no
> renditions. We could make it configurable to ignore renditions.
> 
> That said I am wondering why this wasn’t discovered earlier. I am
> pretty sure if AEM has more latency or is executing slower it will
> not surface as delaying it did the trick.

I do test some projects which should trigger these issues but I don't
see them at all. Not sure why ...

Now that we understand the root cause, the next step for a fix is to
get a test that fails. Feel free to add create a Jira issue to we can
track this better.

Thanks,

Robert

> 
> - Andy
> 
> > 
> > 
> > On Mar 2, 2016, at 4:09 PM, Andreas Schaefer Sr. 
> > wrote:
> > 
> > Hi Robert
> > 
> > Yes, the Workflow are the most likely culprit as I did not
> > encounter a problem when the Workflow were disabled but as soon as
> > I switched them back on the error was back.
> > 
> > So I am wondering if the /renditions folder should be replicated at
> > all.
> > 
> > BTW the error occurs even if the renditions were in place inside
> > AEM. So both the Create / Update Node workflows will cause this
> > issue.
> > 
> > Cheers - Andy Schaefer
> > 
> > > 
> > > On Mar 2, 2016, at 3:16 AM, Robert Munteanu 
> > > wrote:
> > > 
> > > On Mon, 2016-02-29 at 16:02 -0800, Andreas Schaefer Sr. wrote:
> > > > 
> > > > Sorry for the late reply but I got bogged down by a customer
> > > > going
> > > > live.
> > > > 
> > > > Here is the stack trace:
> > > > 
> > > > Caused by: org.apache.sling.ide.transport.RepositoryException:
> > > > javax.jcr.ItemExistsException: Cannot add child node
> > > > 'cq5dam.web.1280.1280.jpeg' to
> > > > /content/dam/aembase/asset.jpg/jcr:content/renditions:
> > > > colliding with
> > > > same-named existing node.
> > > > 
> > > Thanks for the stack trace. My current theory is the following:
> > > 
> > > - your project holds locally assets and their generated
> > > renditions
> > > - the asset generating the error does not exist remotely ( and by
> > > extension neither do its renditions )
> > > - the asset is uploaded first and then the renditions start being
> > > generated ( via AEM workflows )
> > > - at the same time, the plugin tries to upload the renditions
> > > 
> > > Can you try disabling the DAM workflows that generate the
> > > renditions
> > > and see if this occurs?
> > > 
> > > If that's the real reason, we can probably find a way around it.
> > > 
> > > Thanks,
> > > 
> > > Robert
> > > 
> > > > 
> > > > 
> > > > - Andy
> > > > 
> > > > > 
> > > > > 
> > > > > On Feb 18, 2016, at 12:15 AM, Robert Munteanu  > > > > .org>
> > > > > wrote:
> > > > > 
> > > > > Hi Andy,
> > > > > 
> > > > > On Wed, 2016-02-17 at 19:41 -0500, Andreas Schaefer Sr.
> > > > > wrote:
> > > > > > 
> > > > > > 
> > > > > > Hi
> > > > > > 
> > > > > > During the development of the IntelliJ plugin I ran into
> > > > > > some
> > > > > > random
> > > > > > failures to deploy.
> > > > > > Looking deeper I save that the failure is happening when
> > > > > > session.save() is called and
> > > > > > to my surprise a slight delay (Thread.sleep(100)) does fix
> > > > > > it on
> > > > > > my
> > > > > > Mac.
> > > > > > 
> > > > > > The code is in JcrCommand inside the impl-vlt module. This
> > > > > > is the
> > > > > > change that make it
> > > > > > work for me:
> > > > > > 
> > > > > > @Override
> > > > > > public Result execute() {
> > > > > > 
> > > > > >    Session session = null;
> > > > > >    try {
> > > > > >    session = repository.login(credentials);
> > > > > > 
> > > > > >    T result = execute0(session);
> > > > > > 
> > > > > >    try {
> > > > > >    Thread.sleep(100);
> > > > > >    } catch(InterruptedException e) {
> > > > > >    }
> > > > > >    session.save();
> > > > > > 
> > > > > >    return JcrResult.success(result);
> > > > > > The exception I see is a ItemExistsException and was thrown
> > > > > > for a
> > > > > > folder and rendition file in the DAM.
> > > > > Can you add a stack trace? Does this only happen for DAM
> > > > > assets +
> > > > > renditions?
> > > > > 
> > > > > Robert

Re: [VOTE] release Health Checks Core 1.2.4 and Health Checks Annotations 1.0.4

[Bertrand Delacretaz]

On Thu, Mar 3, 2016 at 9:43 AM, Stefan Egli  wrote:
> ...(assuming this includes 1 fixed issue for
> https://issues.apache.org/jira/browse/SLING/fixforversion/12329468) ..

Yes it does, good catch, thanks!
-Bertrand

Re: [VOTE] release Health Checks Core 1.2.4 and Health Checks Annotations 1.0.4

[Stefan Egli]

+1

(assuming this includes 1 fixed issue for
https://issues.apache.org/jira/browse/SLING/fixforversion/12329468)

Cheers,
Stefan

On 02/03/16 15:43, "Bertrand Delacretaz"  wrote:

>Hi,
>
>We solved 6 issues in this release:
>  https://issues.apache.org/jira/browse/SLING/fixforversion/12332272
>
>Staging repository:
>  https://repository.apache.org/content/repositories/orgapachesling-1437
>
>You can use this UNIX script to download the release and verify the
>signatures:
>http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
>Usage:
>sh check_staged_release.sh 1437 /tmp/sling-staging
>
>Please vote to approve this release:
>
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
>
>This majority vote is open for at least 72 hours.
>
>Here's my +1
>
>-Bertrand