[jira] [Commented] (JEXL-255) Ability to continue interrupted scripts
[
https://issues.apache.org/jira/browse/JEXL-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381642#comment-16381642
]
Dmitri Blinov commented on JEXL-255:
As far as I can understand, the problem comes from
{{InterpreterBase.cancelled}} member that is set to {{true}} once
{{InterrupedException}} is caught by iterpreter and left with it even when
{{JexlException.Cancel}} has been thrown.
I think we can implement the same pattern as in java with
{{Thread.interruped()}} / {{InterruptedException}}. The idea is to clear
interruption status once the {{JexlException.Cancel}} exception is about to be
thrown, so that we would have either the exception or the interruption status
set. Once the exception is thrown and interruption status is cleared, the
annotation may catch {{JexlException.Cancel}} and decide what to do with it, if
the situation could be handled locally, or re-raise otherwise...
> Ability to continue interrupted scripts
> ---
>
> Key: JEXL-255
> URL: https://issues.apache.org/jira/browse/JEXL-255
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Major
>
> I'm trying to implement the {{@timeout}} annotation that should work like the
> following
> {code:java}
> @timeout(15000) { return longrunningcall(); }
> {code}
> The idea is to protect part of the script code from being executed
> indefinitely or more than allowed by business rules. The script should
> continue its evaluation after the {{@timeout}} annotation regardless of
> whether the timeout has taken place or not.
> There is a straightforward implementation that starts guarding thread which
> should invoke {{Thread.interrupt()}} for the thread executing the script. The
> {{InterruptedException | JexlException.Cancel}} is then caught and swallowed
> inside the {{processAnnotation()}} method, and if the guard thread has fired,
> which means the timeout occured, the {{null}} value is returned.
> I expected the script to continue its evaluation after the exception is
> processed inside {{processAnnotation()}} code, but the script nevertheless
> throwed {{JexlException.Cancel}} as a result. The suggestion is to allow
> script to continue its evaluation once {{InterruptedException}} or
> {{JexlException.Cancel}} is processed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (COMMONSSITE-104) Commons Release Plugin: generated signature files don't reflect actual signatures.
[
https://issues.apache.org/jira/browse/COMMONSSITE-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Tompkins resolved COMMONSSITE-104.
--
Resolution: Fixed
Commit: {{8af3b4c0a269db99c09313c076b154de7a09b184}}
> Commons Release Plugin: generated signature files don't reflect actual
> signatures.
> --
>
> Key: COMMONSSITE-104
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-104
> Project: Commons All
> Issue Type: Bug
> Components: Commons Release Plugin
>Affects Versions: 1.0
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Major
> Fix For: 1.1
>
>
> When attempting to release using the plugin my generated signatures appear as
> the following:
> {code}
> [INFO] --- commons-release-plugin:1.0:detach-distributions
> (detatch-distributions) @ commons-release-plugin ---
> [INFO] Detatching Assemblies
> [INFO] Copying detatched artifacts to working directory.
> [INFO] Copying: commons-release-plugin-1.1-bin.tar.gz
> [INFO] Copying: commons-release-plugin-1.1-bin.zip
> [INFO] Copying: commons-release-plugin-1.1-src.tar.gz
> [INFO] Copying: commons-release-plugin-1.1-src.zip
> [INFO] Copying: commons-release-plugin-1.1-bin.tar.gz.asc
> [INFO] Copying: commons-release-plugin-1.1-bin.zip.asc
> [INFO] Copying: commons-release-plugin-1.1-src.tar.gz.asc
> [INFO] Copying: commons-release-plugin-1.1-src.zip.asc
> [INFO]
> [INFO] commons-release-plugin-1.1-bin.tar.gz md5:
> 3df58049938e2e9f3adce23e3ccb1aa3
> [INFO] commons-release-plugin-1.1-bin.tar.gz sha1:
> da39a3ee5e6b4b0d3255bfef95601890afd80709
> [INFO] commons-release-plugin-1.1-bin.zip md5:
> b416b98fec2b7d3318507ad552489e7f
> [INFO] commons-release-plugin-1.1-bin.zip sha1:
> da39a3ee5e6b4b0d3255bfef95601890afd80709
> [INFO] commons-release-plugin-1.1-src.tar.gz md5:
> a8986a15f001778428d8128a0066fd5f
> [INFO] commons-release-plugin-1.1-src.tar.gz sha1:
> da39a3ee5e6b4b0d3255bfef95601890afd80709
> [INFO] commons-release-plugin-1.1-src.zip md5:
> dcb7881c8fec2451edf9dc92c563270e
> [INFO] commons-release-plugin-1.1-src.zip sha1:
> da39a3ee5e6b4b0d3255bfef95601890afd80709
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (COMMONSSITE-104) Commons Release Plugin: generated signature files don't reflect actual signatures.
Rob Tompkins created COMMONSSITE-104:
Summary: Commons Release Plugin: generated signature files don't
reflect actual signatures.
Key: COMMONSSITE-104
URL: https://issues.apache.org/jira/browse/COMMONSSITE-104
Project: Commons All
Issue Type: Bug
Components: Commons Release Plugin
Affects Versions: 1.0
Reporter: Rob Tompkins
Assignee: Rob Tompkins
Fix For: 1.1
When attempting to release using the plugin my generated signatures appear as
the following:
{code}
[INFO] --- commons-release-plugin:1.0:detach-distributions
(detatch-distributions) @ commons-release-plugin ---
[INFO] Detatching Assemblies
[INFO] Copying detatched artifacts to working directory.
[INFO] Copying: commons-release-plugin-1.1-bin.tar.gz
[INFO] Copying: commons-release-plugin-1.1-bin.zip
[INFO] Copying: commons-release-plugin-1.1-src.tar.gz
[INFO] Copying: commons-release-plugin-1.1-src.zip
[INFO] Copying: commons-release-plugin-1.1-bin.tar.gz.asc
[INFO] Copying: commons-release-plugin-1.1-bin.zip.asc
[INFO] Copying: commons-release-plugin-1.1-src.tar.gz.asc
[INFO] Copying: commons-release-plugin-1.1-src.zip.asc
[INFO]
[INFO] commons-release-plugin-1.1-bin.tar.gz md5:
3df58049938e2e9f3adce23e3ccb1aa3
[INFO] commons-release-plugin-1.1-bin.tar.gz sha1:
da39a3ee5e6b4b0d3255bfef95601890afd80709
[INFO] commons-release-plugin-1.1-bin.zip md5: b416b98fec2b7d3318507ad552489e7f
[INFO] commons-release-plugin-1.1-bin.zip sha1:
da39a3ee5e6b4b0d3255bfef95601890afd80709
[INFO] commons-release-plugin-1.1-src.tar.gz md5:
a8986a15f001778428d8128a0066fd5f
[INFO] commons-release-plugin-1.1-src.tar.gz sha1:
da39a3ee5e6b4b0d3255bfef95601890afd80709
[INFO] commons-release-plugin-1.1-src.zip md5: dcb7881c8fec2451edf9dc92c563270e
[INFO] commons-release-plugin-1.1-src.zip sha1:
da39a3ee5e6b4b0d3255bfef95601890afd80709
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380261#comment-16380261 ] Otto Fowler commented on LANG-1373: --- I sent a mail to the list. Please comment. I'm winging it here ;) > Stopwatch based capability for nested, named, timings in a call stack > - > > Key: LANG-1373 > URL: https://issues.apache.org/jira/browse/LANG-1373 > Project: Commons Lang > Issue Type: New Feature > Components: lang.time.* >Reporter: Otto Fowler >Assignee: Otto Fowler >Priority: Major > Labels: commons-lang, > Attachments: LANG-1373.patch > > > While working on adding some timing functionality to a Metron feature, I came > across the > Stopwatch class, but found that it didn’t suite my needs. > What I wanted to do was to create a timing from a top level function in our > Stellar dsl, and have have a group of related timings, such that the end > result was the overall time of the call, and nested timings of other calls > executed during the dsl execution of that function. These timings would all > be named, and have a path for identification and include timing the language > compiler/execution as well as the function execution itself. It would be > helpful if they were tagged in some way as well, such that the consumer could > filter during visitation. > So I have written StackWatch to provide this functionality, and submitted it > in a Metron PR. > From the PR description: > StackWatch > A set of utility classes under the new package stellar.common.timing have > been added. These provide the StackWatch functionality. > StackWatch provides an abstraction over the Apache Commons StopWatch class > that allows callers to create multiple named and possibly nested timing > operations. > <…> > This class may be more generally useful to this and other projects, but I am > not sure where it would live since we wouldn’t want it in common. > StackWatch uses a combination of Deque and a custom Tree implementation to > create, start and end timing operations. > A Visitor pattern is also implemented to allow for retrieving the results > after the completion of the operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (VFS-654) File system events API
[ https://issues.apache.org/jira/browse/VFS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380228#comment-16380228 ] Otto Fowler commented on VFS-654: - WatchEvent is very cool. The Java ( 7+) system is very similar to VFS, in that there is a provider spi for supporting file systems. I am not sure what providers are installed on what operating systems. On my mac, I only have the OSX and ZIP installed. So, to support WatchEvent for any local filesystem would seem to be possible. For other filesystems that VFS supports, it would depend on what providers where loaded, therefore these would become dependencies. INotify for hdfs could be implemented on it's own as well. Thoughts [~b.eckenfels]? > File system events API > -- > > Key: VFS-654 > URL: https://issues.apache.org/jira/browse/VFS-654 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Boris Petrov >Priority: Major > > Currently the DefaultFileMonitor walks the whole file system and notifies > when something changes. For large file systems and (near) real-time > requirements this is _extremely_ inefficient. Some file systems have an > events API which could be exposed (like *inotify*). Has any work towards that > ever been done? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (VFS-654) File system events API
[ https://issues.apache.org/jira/browse/VFS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380128#comment-16380128 ] Bernd Eckenfels commented on VFS-654: - Yes as a minimum support for java.nio.WatchEvent should be implemented. This would work with Linux inotify as well as Windows (SMB and NTFS changejournal) (however not in all cases reliably) https://docs.oracle.com/javase/tutorial/essential/io/notification.html > File system events API > -- > > Key: VFS-654 > URL: https://issues.apache.org/jira/browse/VFS-654 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Boris Petrov >Priority: Major > > Currently the DefaultFileMonitor walks the whole file system and notifies > when something changes. For large file systems and (near) real-time > requirements this is _extremely_ inefficient. Some file systems have an > events API which could be exposed (like *inotify*). Has any work towards that > ever been done? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (POOL-337) EvictionTimer does not remove cancelled tasks from the executor, leading to an IllegalStateException when the evictor attempts to evict
[
https://issues.apache.org/jira/browse/POOL-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380111#comment-16380111
]
Christophe DENEUX commented on POOL-337:
Hi Reinald Verheij,
I have the same problem, consequences are memory leaks in my use-cases.
Have you plan to create pull request about your patch ? Can I create one ?
> EvictionTimer does not remove cancelled tasks from the executor, leading to
> an IllegalStateException when the evictor attempts to evict
> ---
>
> Key: POOL-337
> URL: https://issues.apache.org/jira/browse/POOL-337
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Reinald Verheij
>Priority: Major
> Attachments: EvictionTimer.java,
> EvictionTimer.java.original-from-2.5.0.java
>
>
> EvictionTimer does not remove cancelled tasks from the executor, leading to
> an IllegalStateException when the evictor attempts to evict.
>
> EvictionTimer::schedule() adds eviction tasks to the executor, but the cancel
> does not remove it. This is asymmetric and leads to the following exception:
> {noformat}
> java.lang.IllegalStateException: Pool not open
> at
> org.apache.commons.pool2.impl.BaseGenericObjectPool.assertOpen(BaseGenericObjectPool.java:713)
> at
> org.apache.commons.pool2.impl.GenericObjectPool.evict(GenericObjectPool.java:721)
> at
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor.run(BaseGenericObjectPool.java:1077)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748){noformat}
> I think the cancel would need to remember the future which returned from
> {{executor::scheduleWithFixedDelay()}} in {{schedule()}} and then do
> something like this (see [^EvictionTimer.java] compared to original
> [^EvictionTimer.java.original-from-2.5.0.java] )
> {code:java}
> if (futures.containsKey(task)) {
> futures.remove(task).cancel(false);
> executor.purge();
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (VFS-654) File system events API
[ https://issues.apache.org/jira/browse/VFS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380108#comment-16380108 ] Boris Petrov edited comment on VFS-654 at 2/28/18 10:32 AM: Thank you for the quick response. I spent a significant amount of time researching this. [Samba 3 has support for notifications since version 3.0.25|https://wiki.samba.org/index.php/Samba_3.0_Features_added/changed]. Of course, local file systems have the *inotify* functionality (that's on Linux, I'm pretty sure there is something on Windows). Maybe these are the only two available. Samba 3 support is along the way in [smbj|https://github.com/hierynomus/smbj] and there is a [pull request|https://github.com/apache/commons-vfs/pull/26] for VFS for that library (which I hope you'll merge soon). I guess they will add notifications support once *smbj* has them and you expose some API in VFS. As for other file systems - I really don't know. NFS seems to have such support (at least I read that it can be used with *inotify* so there obviously is something). NFS is supported by [this library|https://github.com/danniss/common-vfs2-nfs]. WebDAV also seems to be able to trigger some kind of notifications but I am not sure. I'll have to research more. In any case - such an API by VFS is definitely a nice thing to have and then it's up to the driver to implement it if possible. was (Author: boris-petrov): Thank you for the quick response. I spent a significant amount of time researching this. [Samba 3 has support for notifications since version 3.0.25|https://wiki.samba.org/index.php/Samba_3.0_Features_added/changed]. Of course, local file systems have the *inotify* functionality (that's on Linux, I'm pretty sure there is something on Windows). Maybe these are the only two available. Samba 3 support is along the way in [smbj|https://github.com/hierynomus/smbj] and there is a [pull request|https://github.com/apache/commons-vfs/pull/26] for VFS for that library (which I hope you'll merge soon). I guess they will add notifications support once *smbj* has them and you expose some API in VFS. As for other file systems - I really don't know. NFS seems to have such support (at least I read that it can be used with *inotify* so there obviously is something. NFS is supported by [this library|https://github.com/danniss/common-vfs2-nfs]. WebDAV also seems to be able to trigger some kind of notifications but I am not sure. I'll have to research more. In any case - such an API by VFS is definitely a nice thing to have and then it's up to the driver to implement it if possible. > File system events API > -- > > Key: VFS-654 > URL: https://issues.apache.org/jira/browse/VFS-654 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Boris Petrov >Priority: Major > > Currently the DefaultFileMonitor walks the whole file system and notifies > when something changes. For large file systems and (near) real-time > requirements this is _extremely_ inefficient. Some file systems have an > events API which could be exposed (like *inotify*). Has any work towards that > ever been done? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (VFS-654) File system events API
[ https://issues.apache.org/jira/browse/VFS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380108#comment-16380108 ] Boris Petrov edited comment on VFS-654 at 2/28/18 10:32 AM: Thank you for the quick response. I spent a significant amount of time researching this. [Samba 3 has support for notifications since version 3.0.25|https://wiki.samba.org/index.php/Samba_3.0_Features_added/changed]. Of course, local file systems have the *inotify* functionality (that's on Linux, I'm pretty sure there is something on Windows). Maybe these are the only two available. Samba 3 support is along the way in [smbj|https://github.com/hierynomus/smbj] and there is a [pull request|https://github.com/apache/commons-vfs/pull/26] for VFS for that library (which I hope you'll merge soon). I guess they will add notifications support once *smbj* has them and you expose some API in VFS. As for other file systems - I really don't know. NFS seems to have such support (at least I read that it can be used with *inotify* so there obviously is something. NFS is supported by [this library|https://github.com/danniss/common-vfs2-nfs]. WebDAV also seems to be able to trigger some kind of notifications but I am not sure. I'll have to research more. In any case - such an API by VFS is definitely a nice thing to have and then it's up to the driver to implement it if possible. was (Author: boris-petrov): Thank you for the quick response. I spent a significant amount of time researching this. [Samba 3 has support for notifications since version 3.0.25.|https://wiki.samba.org/index.php/Samba_3.0_Features_added/changed]. Of course, local file systems have the *inotify* functionality (that's on Linux, I'm pretty sure there is something on Windows). Maybe these are the only two available. Samba 3 support is along the way in [smbj|https://github.com/hierynomus/smbj] and there is a [pull request|https://github.com/apache/commons-vfs/pull/26] for VFS for that library (which I hope you'll merge soon). I guess they will add notifications support once *smbj* has them and you expose some API in VFS. As for other file systems - I really don't know. NFS seems to have such support (at least I read that it can be used with *inotify* so there obviously is something. NFS is supported by [this library|https://github.com/danniss/common-vfs2-nfs]. WebDAV also seems to be able to trigger some kind of notifications but I am not sure. I'll have to research more. In any case - such an API by VFS is definitely a nice thing to have and then it's up to the driver to implement it if possible. > File system events API > -- > > Key: VFS-654 > URL: https://issues.apache.org/jira/browse/VFS-654 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Boris Petrov >Priority: Major > > Currently the DefaultFileMonitor walks the whole file system and notifies > when something changes. For large file systems and (near) real-time > requirements this is _extremely_ inefficient. Some file systems have an > events API which could be exposed (like *inotify*). Has any work towards that > ever been done? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (VFS-654) File system events API
[ https://issues.apache.org/jira/browse/VFS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380108#comment-16380108 ] Boris Petrov commented on VFS-654: -- Thank you for the quick response. I spent a significant amount of time researching this. [Samba 3 has support for notifications since version 3.0.25.|https://wiki.samba.org/index.php/Samba_3.0_Features_added/changed]. Of course, local file systems have the *inotify* functionality (that's on Linux, I'm pretty sure there is something on Windows). Maybe these are the only two available. Samba 3 support is along the way in [smbj|https://github.com/hierynomus/smbj] and there is a [pull request|https://github.com/apache/commons-vfs/pull/26] for VFS for that library (which I hope you'll merge soon). I guess they will add notifications support once *smbj* has them and you expose some API in VFS. As for other file systems - I really don't know. NFS seems to have such support (at least I read that it can be used with *inotify* so there obviously is something. NFS is supported by [this library|https://github.com/danniss/common-vfs2-nfs]. WebDAV also seems to be able to trigger some kind of notifications but I am not sure. I'll have to research more. In any case - such an API by VFS is definitely a nice thing to have and then it's up to the driver to implement it if possible. > File system events API > -- > > Key: VFS-654 > URL: https://issues.apache.org/jira/browse/VFS-654 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Boris Petrov >Priority: Major > > Currently the DefaultFileMonitor walks the whole file system and notifies > when something changes. For large file systems and (near) real-time > requirements this is _extremely_ inefficient. Some file systems have an > events API which could be exposed (like *inotify*). Has any work towards that > ever been done? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (EMAIL-174) Upgrade from javax.mail-1.5.6 to 1.6.0
[ https://issues.apache.org/jira/browse/EMAIL-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann reopened EMAIL-174: --- Noticed too late: Javax.mail 1.6.1 is Java 7, but we're still on Java 6. Revert? > Upgrade from javax.mail-1.5.6 to 1.6.0 > -- > > Key: EMAIL-174 > URL: https://issues.apache.org/jira/browse/EMAIL-174 > Project: Commons Email > Issue Type: Bug >Reporter: Mark Woon >Assignee: Jochen Wiedmann >Priority: Minor > Fix For: 1.6 > > > Upgrade from javax.mail-1.5.6 to 1.6.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (EMAIL-174) Upgrade from javax.mail-1.5.6 to 1.6.0
[ https://issues.apache.org/jira/browse/EMAIL-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved EMAIL-174. --- Resolution: Fixed Assignee: Jochen Wiedmann Fix Version/s: 1.6 Applied with revision 1825540. > Upgrade from javax.mail-1.5.6 to 1.6.0 > -- > > Key: EMAIL-174 > URL: https://issues.apache.org/jira/browse/EMAIL-174 > Project: Commons Email > Issue Type: Bug >Reporter: Mark Woon >Assignee: Jochen Wiedmann >Priority: Minor > Fix For: 1.6 > > > Upgrade from javax.mail-1.5.6 to 1.6.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (EMAIL-174) Upgrade from javax.mail-1.5.6 to 1.6.0
[ https://issues.apache.org/jira/browse/EMAIL-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380007#comment-16380007 ] Vegard Stuen commented on EMAIL-174: Pull request submitted: https://github.com/apache/commons-email/pull/4 > Upgrade from javax.mail-1.5.6 to 1.6.0 > -- > > Key: EMAIL-174 > URL: https://issues.apache.org/jira/browse/EMAIL-174 > Project: Commons Email > Issue Type: Bug >Reporter: Mark Woon >Priority: Minor > > Upgrade from javax.mail-1.5.6 to 1.6.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
