[jira] [Resolved] (SLING-5217) Verify if login failures to resource providers are handled correctly
[ https://issues.apache.org/jira/browse/SLING-5217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu resolved SLING-5217. Resolution: Fixed Assignee: Robert Munteanu The code looks good to me and I've verified the behaviour using a MongoDB provider with the patches from SLING-5437. Considering fixed. > Verify if login failures to resource providers are handled correctly > > > Key: SLING-5217 > URL: https://issues.apache.org/jira/browse/SLING-5217 > Project: Sling > Issue Type: Sub-task > Components: ResourceResolver >Reporter: Carsten Ziegeler >Assignee: Robert Munteanu > Fix For: Resource Resolver 1.3.0 > > > If a resource provider is marked as required auth, then the login is > performed on creation of the resource resolver impl - if it fails, not RR is > created. This is correct. > For providers marked as lazy auth, if login fails they are not tried again > and they are treated as if auth was successful, but all get methods return > null and all set methods either throw or do nothing. I haven't verified this > in all places yet. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-5437) The NoSQL providers should throw LoginException if the connection to the NoSQL database can't be established
Robert Munteanu created SLING-5437: -- Summary: The NoSQL providers should throw LoginException if the connection to the NoSQL database can't be established Key: SLING-5437 URL: https://issues.apache.org/jira/browse/SLING-5437 Project: Sling Issue Type: New Feature Components: NoSQL Affects Versions: NoSQL MongoDB Resource Provider 1.0.0, NoSQL Couchbase Resource Provider 1.0.0, NoSQL Generic Resource Provider 1.0.0 Reporter: Robert Munteanu Assignee: Robert Munteanu Fix For: NoSQL Generic Resource Provider 1.0.2, NoSQL Couchbase Client 1.0.2, NoSQL MongoDB Resource Provider 1.0.2 While trying to find a proper test for SLING-5217, I noticed that the NoSQL providers don't check the connection when the ResourceProvider is instantiated. Therefore the ResourceProvider is always considered valid and when access is attempted exceptions are thrown. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-5437) The NoSQL providers should throw LoginException if the connection to the NoSQL database can't be established
[ https://issues.apache.org/jira/browse/SLING-5437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-5437: --- Attachment: 0001-SLING-5437-The-NoSQL-providers-should-throw-LoginExc.patch Added a rough patch which works for MongoDB ( couchbase is a no-op since I did not have the time to test it ). I'm not very eager to commit it without review since it bumps the API of `org.apache.sling.nosql.generic.adapter` to 2.0.0 . [~sseif...@pro-vision.de] - thoughts? > The NoSQL providers should throw LoginException if the connection to the > NoSQL database can't be established > > > Key: SLING-5437 > URL: https://issues.apache.org/jira/browse/SLING-5437 > Project: Sling > Issue Type: New Feature > Components: NoSQL >Affects Versions: NoSQL Generic Resource Provider 1.0.0, NoSQL Couchbase > Resource Provider 1.0.0, NoSQL MongoDB Resource Provider 1.0.0 >Reporter: Robert Munteanu >Assignee: Robert Munteanu > Fix For: NoSQL Generic Resource Provider 1.0.2, NoSQL Couchbase > Client 1.0.2, NoSQL MongoDB Resource Provider 1.0.2 > > Attachments: > 0001-SLING-5437-The-NoSQL-providers-should-throw-LoginExc.patch > > > While trying to find a proper test for SLING-5217, I noticed that the NoSQL > providers don't check the connection when the ResourceProvider is > instantiated. Therefore the ResourceProvider is always considered valid and > when access is attempted exceptions are thrown. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5205) Check for potential memory leaks
[ https://issues.apache.org/jira/browse/SLING-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15105445#comment-15105445 ] Robert Munteanu commented on SLING-5205: After changing the OSGi config of the MongoDB provider, the old duplicate is still retained. I've validated this with two heap dumps ( see [^duplicate-mongodb-resource-provider.png] ). > Check for potential memory leaks > > > Key: SLING-5205 > URL: https://issues.apache.org/jira/browse/SLING-5205 > Project: Sling > Issue Type: Sub-task > Components: ResourceResolver >Reporter: Carsten Ziegeler > Fix For: Resource Resolver 1.3.0 > > Attachments: duplicate-mongodb-resource-provider.png > > > With long running resource resolvers and provider dynamically being > registered, we need to check that we don't hold too strong references on the > providers -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-5205) Check for potential memory leaks
[ https://issues.apache.org/jira/browse/SLING-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-5205: --- Attachment: duplicate-mongodb-resource-provider.png > Check for potential memory leaks > > > Key: SLING-5205 > URL: https://issues.apache.org/jira/browse/SLING-5205 > Project: Sling > Issue Type: Sub-task > Components: ResourceResolver >Reporter: Carsten Ziegeler > Fix For: Resource Resolver 1.3.0 > > Attachments: duplicate-mongodb-resource-provider.png > > > With long running resource resolvers and provider dynamically being > registered, we need to check that we don't hold too strong references on the > providers -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-5205) Check for potential memory leaks
[ https://issues.apache.org/jira/browse/SLING-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-5205: --- Assignee: Robert Munteanu > Check for potential memory leaks > > > Key: SLING-5205 > URL: https://issues.apache.org/jira/browse/SLING-5205 > Project: Sling > Issue Type: Sub-task > Components: ResourceResolver >Reporter: Carsten Ziegeler >Assignee: Robert Munteanu > Fix For: Resource Resolver 1.3.0 > > Attachments: duplicate-mongodb-resource-provider.png > > > With long running resource resolvers and provider dynamically being > registered, we need to check that we don't hold too strong references on the > providers -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SLING-5205) Check for potential memory leaks
[ https://issues.apache.org/jira/browse/SLING-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15105445#comment-15105445 ] Robert Munteanu edited comment on SLING-5205 at 1/18/16 3:41 PM: - After changing the OSGi config of the MongoDB provider, the old provider is still retained. I've validated this with two heap dumps ( see [^duplicate-mongodb-resource-provider.png] ). was (Author: rombert): After changing the OSGi config of the MongoDB provider, the old duplicate is still retained. I've validated this with two heap dumps ( see [^duplicate-mongodb-resource-provider.png] ). > Check for potential memory leaks > > > Key: SLING-5205 > URL: https://issues.apache.org/jira/browse/SLING-5205 > Project: Sling > Issue Type: Sub-task > Components: ResourceResolver >Reporter: Carsten Ziegeler > Fix For: Resource Resolver 1.3.0 > > Attachments: duplicate-mongodb-resource-provider.png > > > With long running resource resolvers and provider dynamically being > registered, we need to check that we don't hold too strong references on the > providers -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5414) Make the contents of the provisioning model available at runtime
[ https://issues.apache.org/jira/browse/SLING-5414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15105105#comment-15105105 ] Bertrand Delacretaz commented on SLING-5414: I've tried an approach where the slingstart maven plugin generates a bundle with a "modelfragment" classifier, used by a provisioning model provider bundle to supply the model at runtime. It works but creates a "chicken and egg" dependency on the modelfragment bundle in launchpad/builder. I have saved that variant at https://github.com/bdelacretaz/sling/tree/SLING-5414-wontwork but will need to change the strategy in the slingstart plugin - having that optionally inject the modelfragment bundle in the provisioning model, without having a dependency on it, should work. > Make the contents of the provisioning model available at runtime > > > Key: SLING-5414 > URL: https://issues.apache.org/jira/browse/SLING-5414 > Project: Sling > Issue Type: New Feature > Components: Maven Plugins and Archetypes >Affects Versions: Slingstart Maven Plugin 1.4.0 >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz >Priority: Minor > Fix For: Slingstart Maven Plugin 1.4.2 > > Attachments: SLING-5414.patch > > > For SLING-5355 we need to make additional sections from the provisioning > model available at runtime, so that ACLs can be set at startup, and also to > be able to reuse their definitions later for auditing/verification purposes. > A simple way to do that is to copy those sections in the sling_bootstrap.txt > file. I have created a patch that does that, will attach it here for review. > _edit: as discussed below, we'll make the full text of the model available at > runtime_ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-3891) Document Sling Content Distribution
[ https://issues.apache.org/jira/browse/SLING-3891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15105075#comment-15105075 ] Konrad Windszus commented on SLING-3891: [~teofili] At first glance I couldn't find any documentation on the website. Could you add a link in http://sling.staging.apache.org/documentation/bundles.html in the section content? > Document Sling Content Distribution > --- > > Key: SLING-3891 > URL: https://issues.apache.org/jira/browse/SLING-3891 > Project: Sling > Issue Type: Task > Components: Distribution, Documentation >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > > Sling replication should be documented (APIs, endpoints, commands, etc.) to > ease usage and adoption. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-5358) Description for OSGi configuration of org.apache.sling.servlets.resolver.SlingServletResolver servletresolver.servletRoot is wrong
[
https://issues.apache.org/jira/browse/SLING-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SLING-5358:
---
Fix Version/s: Servlets Resolver 2.3.10
> Description for OSGi configuration of
> org.apache.sling.servlets.resolver.SlingServletResolver
> servletresolver.servletRoot is wrong
> --
>
> Key: SLING-5358
> URL: https://issues.apache.org/jira/browse/SLING-5358
> Project: Sling
> Issue Type: Bug
> Components: Servlets
>Affects Versions: Servlets Resolver 2.3.8
>Reporter: Konrad Windszus
>Priority: Minor
> Fix For: Servlets Resolver 2.3.10
>
>
> The description of that property of the OSGi configuration says:
> {quote}
> The default root path assumed when registering a Servlet whose Servlet
> registration properties define a relative path. The default value is "/apps".
> This path should be part of the search path configured in the Resource
> Resolver Factory otherwise a thus registered servlet may not be found.
> {quote}
> https://github.com/apache/sling/blob/trunk/bundles/servlets/resolver/src/main/resources/OSGI-INF/metatype/metatype.properties#L36
> The default value is actually 0 not "/apps"
> (https://github.com/apache/sling/blob/trunk/bundles/servlets/resolver/src/main/java/org/apache/sling/servlets/resolver/internal/SlingServletResolver.java#L137).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-5358) Description for OSGi configuration of org.apache.sling.servlets.resolver.SlingServletResolver servletresolver.servletRoot is wrong
[
https://issues.apache.org/jira/browse/SLING-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SLING-5358:
---
Affects Version/s: (was: Servlets Resolver 2.3.10)
Servlets Resolver 2.3.8
> Description for OSGi configuration of
> org.apache.sling.servlets.resolver.SlingServletResolver
> servletresolver.servletRoot is wrong
> --
>
> Key: SLING-5358
> URL: https://issues.apache.org/jira/browse/SLING-5358
> Project: Sling
> Issue Type: Bug
> Components: Servlets
>Affects Versions: Servlets Resolver 2.3.8
>Reporter: Konrad Windszus
>Priority: Minor
> Fix For: Servlets Resolver 2.3.10
>
>
> The description of that property of the OSGi configuration says:
> {quote}
> The default root path assumed when registering a Servlet whose Servlet
> registration properties define a relative path. The default value is "/apps".
> This path should be part of the search path configured in the Resource
> Resolver Factory otherwise a thus registered servlet may not be found.
> {quote}
> https://github.com/apache/sling/blob/trunk/bundles/servlets/resolver/src/main/resources/OSGI-INF/metatype/metatype.properties#L36
> The default value is actually 0 not "/apps"
> (https://github.com/apache/sling/blob/trunk/bundles/servlets/resolver/src/main/java/org/apache/sling/servlets/resolver/internal/SlingServletResolver.java#L137).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-3891) Document Sling Content Distribution
[ https://issues.apache.org/jira/browse/SLING-3891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved SLING-3891. Resolution: Fixed > Document Sling Content Distribution > --- > > Key: SLING-3891 > URL: https://issues.apache.org/jira/browse/SLING-3891 > Project: Sling > Issue Type: Task > Components: Distribution, Documentation >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > > Sling replication should be documented (APIs, endpoints, commands, etc.) to > ease usage and adoption. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-5358) Description for OSGi configuration of org.apache.sling.servlets.resolver.SlingServletResolver servletresolver.servletRoot is wrong
[
https://issues.apache.org/jira/browse/SLING-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved SLING-5358.
Resolution: Fixed
Fixed in [r1725219|http://svn.apache.org/r1725219].
> Description for OSGi configuration of
> org.apache.sling.servlets.resolver.SlingServletResolver
> servletresolver.servletRoot is wrong
> --
>
> Key: SLING-5358
> URL: https://issues.apache.org/jira/browse/SLING-5358
> Project: Sling
> Issue Type: Bug
> Components: Servlets
>Affects Versions: Servlets Resolver 2.3.8
>Reporter: Konrad Windszus
>Priority: Minor
> Fix For: Servlets Resolver 2.3.10
>
>
> The description of that property of the OSGi configuration says:
> {quote}
> The default root path assumed when registering a Servlet whose Servlet
> registration properties define a relative path. The default value is "/apps".
> This path should be part of the search path configured in the Resource
> Resolver Factory otherwise a thus registered servlet may not be found.
> {quote}
> https://github.com/apache/sling/blob/trunk/bundles/servlets/resolver/src/main/resources/OSGI-INF/metatype/metatype.properties#L36
> The default value is actually 0 not "/apps"
> (https://github.com/apache/sling/blob/trunk/bundles/servlets/resolver/src/main/java/org/apache/sling/servlets/resolver/internal/SlingServletResolver.java#L137).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4183) Jcr Installer Provider only supports storing array values for OSGi Component Properties (for sling:OsgiConfig resources) but not java.util.Vector
[
https://issues.apache.org/jira/browse/SLING-4183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SLING-4183:
---
Summary: Jcr Installer Provider only supports storing array values for OSGi
Component Properties (for sling:OsgiConfig resources) but not java.util.Vector
(was: Jcr Installer Provider only supports storing array values for OSGi
Component Properties but not java.util.Vector)
> Jcr Installer Provider only supports storing array values for OSGi Component
> Properties (for sling:OsgiConfig resources) but not java.util.Vector
> -
>
> Key: SLING-4183
> URL: https://issues.apache.org/jira/browse/SLING-4183
> Project: Sling
> Issue Type: Improvement
> Components: Installer
>Affects Versions: JCR Installer 3.1.8
>Reporter: Konrad Windszus
>
> The OSGi Compendium 4.3.0, $105.14.3.13 defines two storage formats for
> multivalue entries: one is vector and the other one is array.
> As long as a configuration is maintained via the Felix Webconsole, it will
> stick to the data format being given in the metatype manifest (through the
> cardinality attribute).
> If the JCR Installer is used to deploy the OSGi configuration it will always
> use array, in case the property is a multivalue property in the JCR
> (https://github.com/apache/sling/blob/trunk/installer/providers/jcr/src/main/java/org/apache/sling/installer/provider/jcr/impl/ConfigNodeConverter.java#L99)
> In the best case the JCR Installer should evaluate the metatype manifest as
> well. Or it should support {{Vector}}s through some special prefix on a
> multivalue property name.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
SLING-5127 - ResourceProviderInfo.authType values clarification
Hi,
I was looking at
SLING-5217: Verify if login failures to resource providers are
handled correctly
and I tried to follow the logic behind the AuthType enum:
public enum AuthType { no, lazy, required }
The 'lazy' and 'required' values don't really 'partition' the providers
well IMO, e.g. you can think of a resource provider that is required
and should be lazily authenticated against.
I would suggest the following change
public enum AuthType { none, lazy, eager }
Thoughts?
Robert
[jira] [Resolved] (SLING-3553) Run FindBugs (and fix accordingly) on Sling Replication code
[ https://issues.apache.org/jira/browse/SLING-3553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved SLING-3553. Resolution: Fixed Fix Version/s: Content Distribution Core 0.1.14 > Run FindBugs (and fix accordingly) on Sling Replication code > > > Key: SLING-3553 > URL: https://issues.apache.org/jira/browse/SLING-3553 > Project: Sling > Issue Type: Improvement > Components: Distribution >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili >Priority: Trivial > Fix For: Content Distribution Core 0.1.14 > > > Sling Replication code has grown over time and I'd like to a) fix current > problems as reported by FindBugs b) add a reporting entry to the pom.xml in > order to be continuously able to check eventual problems. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-5436) Do not move distribution packages to error queues after connection problems
Marius Petria created SLING-5436: Summary: Do not move distribution packages to error queues after connection problems Key: SLING-5436 URL: https://issues.apache.org/jira/browse/SLING-5436 Project: Sling Issue Type: Bug Components: Distribution Reporter: Marius Petria Assignee: Marius Petria Fix For: Content Distribution Core 0.1.14 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-5439) HttpEntity in SimpleHttpTransport should be consumed / discarded
Tommaso Teofili created SLING-5439:
--
Summary: HttpEntity in SimpleHttpTransport should be consumed /
discarded
Key: SLING-5439
URL: https://issues.apache.org/jira/browse/SLING-5439
Project: Sling
Issue Type: Improvement
Components: Distribution
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
Fix For: Content Distribution Core 0.1.14
{{SimpleHttpDistributionTransport#deliverPackage}} returns Http {{Content}} but
doesn't use it. While it seems it's not possible to just let it go (as that
would leak as an unconsumed resource) such content should be discarded.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-5436) Do not move distribution packages to error queues after connection problems
[ https://issues.apache.org/jira/browse/SLING-5436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marius Petria resolved SLING-5436. -- Resolution: Fixed > Do not move distribution packages to error queues after connection problems > --- > > Key: SLING-5436 > URL: https://issues.apache.org/jira/browse/SLING-5436 > Project: Sling > Issue Type: Bug > Components: Distribution >Reporter: Marius Petria >Assignee: Marius Petria > Fix For: Content Distribution Core 0.1.14 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-5438) Avoid reopening the JcrPackage during installation
Tommaso Teofili created SLING-5438:
--
Summary: Avoid reopening the JcrPackage during installation
Key: SLING-5438
URL: https://issues.apache.org/jira/browse/SLING-5438
Project: Sling
Issue Type: Improvement
Components: Distribution
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
Fix For: Content Distribution Core 0.1.14
During {{JcrVaultDistributionPackageBuilder#installPackageInternal}} the
{{JcrPackage}} contained in the {{DistributionPackage}} is re opened using its
id. That is avoidable as the {{JcrPackage}} is already available inside the
{{DistributionPackage}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-5438) Avoid reopening the JcrPackage during installation
[
https://issues.apache.org/jira/browse/SLING-5438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili resolved SLING-5438.
Resolution: Fixed
fixed in r1725302
> Avoid reopening the JcrPackage during installation
> --
>
> Key: SLING-5438
> URL: https://issues.apache.org/jira/browse/SLING-5438
> Project: Sling
> Issue Type: Improvement
> Components: Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution Core 0.1.14
>
>
> During {{JcrVaultDistributionPackageBuilder#installPackageInternal}} the
> {{JcrPackage}} contained in the {{DistributionPackage}} is re opened using
> its id. That is avoidable as the {{JcrPackage}} is already available inside
> the {{DistributionPackage}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5205) Check for potential memory leaks
[ https://issues.apache.org/jira/browse/SLING-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15105720#comment-15105720 ] Robert Munteanu commented on SLING-5205: For the sake of being complete, here's a screenshot of the path to the GC root for the leaking resource provider [^shortest-path.png] > Check for potential memory leaks > > > Key: SLING-5205 > URL: https://issues.apache.org/jira/browse/SLING-5205 > Project: Sling > Issue Type: Sub-task > Components: ResourceResolver >Reporter: Carsten Ziegeler >Assignee: Robert Munteanu > Fix For: Resource Resolver 1.3.0 > > Attachments: duplicate-mongodb-resource-provider.png, > shortest-path.png > > > With long running resource resolvers and provider dynamically being > registered, we need to check that we don't hold too strong references on the > providers -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-5205) Check for potential memory leaks
[ https://issues.apache.org/jira/browse/SLING-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-5205: --- Attachment: shortest-path.png > Check for potential memory leaks > > > Key: SLING-5205 > URL: https://issues.apache.org/jira/browse/SLING-5205 > Project: Sling > Issue Type: Sub-task > Components: ResourceResolver >Reporter: Carsten Ziegeler >Assignee: Robert Munteanu > Fix For: Resource Resolver 1.3.0 > > Attachments: duplicate-mongodb-resource-provider.png, > shortest-path.png > > > With long running resource resolvers and provider dynamically being > registered, we need to check that we don't hold too strong references on the > providers -- This message was sent by Atlassian JIRA (v6.3.4#6332)
