[jira] [Updated] (WICKET-6551) LazyInitProxyFactory doesn't work correctly at Weblogic

2018-04-19 Thread Tomas Kloucek (JIRA)

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

Tomas Kloucek updated WICKET-6551:
--
Description: 
When weblogic serializes HTTP session then it's not an Wicket Application 
thread and Thread.currentThread().getClassLoader() can return different 
NOT-application classloader... which ends in LazyInitProxyFactory.readResolve() 
ClassNotFoundException crash...This ends in Wicket's WebSession being not saved 
into HTTP session which is fatal consequence

We have sucessfully tested following patch of LazyInitProxyFactory:

 

static class ProxyReplacement implements IClusterable
 {
 private static final long serialVersionUID = 1L;

private final IProxyTargetLocator locator;

private final String type;

/**
 * Constructor
 * 
 * @param type
 * @param locator
 */
 public ProxyReplacement(final String type, final IProxyTargetLocator locator) 
\{ this.type = type; this.locator = locator; }

private Object readResolve() throws ObjectStreamException
 {
 Class clazz = WicketObjects.resolveClass(type);
 if (clazz == null)
 {
 try

{ clazz = Class.forName(type, false, WicketObjects.class.getClassLoader()); 
System.out.println("Clazz resolved through application classloade"); }

catch (ClassNotFoundException e)

{ ClassNotFoundException cause = new ClassNotFoundException( "Could not resolve 
type [" + type + "] with the currently configured 
org.apache.wicket.application.IClassResolver"); throw new 
WicketRuntimeException(cause); }

}
 return LazyInitProxyFactory.createProxy(clazz, locator);
 }
 }

With this patched LazyInitProxyFactory class problem went away. Can you please 
accomodate this fix into Wicket 6.x line?

 

Forum link: 
http://apache-wicket.1842946.n4.nabble.com/Wicket-s-LazyInitProxyFactory-runs-incorrectly-at-WebLogic-td4680236.html

 

 

  was:
When weblogic serializes HTTP session then it's not an Wicket Application 
thread and Thread.currentThread().getClassLoader() can return different 
NOT-application classloader... which ends in LazyInitProxyFactory.readResolve() 
ClassNotFoundException crash...This ends in Wicket's WebSession being not saved 
into HTTP session which is fatal consequence

We have sucessfully tested following patch of LazyInitProxyFactory:

 

static class ProxyReplacement implements IClusterable
{
 private static final long serialVersionUID = 1L;

 private final IProxyTargetLocator locator;

 private final String type;

 /**
 * Constructor
 * 
 * @param type
 * @param locator
 */
 public ProxyReplacement(final String type, final IProxyTargetLocator locator)
 {
 this.type = type;
 this.locator = locator;
 }

 private Object readResolve() throws ObjectStreamException
 {
 Class clazz = WicketObjects.resolveClass(type);
 if (clazz == null)
 {
 try {
 clazz = Class.forName(type, false,
 WicketObjects.class.getClassLoader());
 System.out.println("Clazz resolved through application classloade");
 } catch (ClassNotFoundException e) {
 ClassNotFoundException cause = new ClassNotFoundException(
 "Could not resolve type [" + type +
 "] with the currently configured 
org.apache.wicket.application.IClassResolver");
 throw new WicketRuntimeException(cause);
 }
 }
 return LazyInitProxyFactory.createProxy(clazz, locator);
 }
}

With this patched LazyInitProxyFactory class problem went away. Can you please 
accomodate this fix into Wicket 6.x line?

 

 

 


> LazyInitProxyFactory doesn't work correctly at Weblogic
> ---
>
> Key: WICKET-6551
> URL: https://issues.apache.org/jira/browse/WICKET-6551
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket, wicket-spring
>Affects Versions: 6.21.0
>Reporter: Tomas Kloucek
>Priority: Critical
>
> When weblogic serializes HTTP session then it's not an Wicket Application 
> thread and Thread.currentThread().getClassLoader() can return different 
> NOT-application classloader... which ends in 
> LazyInitProxyFactory.readResolve() ClassNotFoundException crash...This ends 
> in Wicket's WebSession being not saved into HTTP session which is fatal 
> consequence
> We have sucessfully tested following patch of LazyInitProxyFactory:
>  
> static class ProxyReplacement implements IClusterable
>  {
>  private static final long serialVersionUID = 1L;
> private final IProxyTargetLocator locator;
> private final String type;
> /**
>  * Constructor
>  * 
>  * @param type
>  * @param locator
>  */
>  public ProxyReplacement(final String type, final IProxyTargetLocator 
> locator) \{ this.type = type; this.locator = locator; }
> private Object readResolve() throws ObjectStreamException
>  {
>  Class clazz = WicketObjects.resolveClass(type);
>  if (clazz == null)
>  {
>  try
> { clazz = Class.forName(type, false, WicketObjects.class.getClassLoader()); 
> System.out.println("Clazz resolved through appli

[jira] [Created] (WICKET-6551) LazyInitProxyFactory doesn't work correctly at Weblogic

2018-04-19 Thread Tomas Kloucek (JIRA)
Tomas Kloucek created WICKET-6551:
-

 Summary: LazyInitProxyFactory doesn't work correctly at Weblogic
 Key: WICKET-6551
 URL: https://issues.apache.org/jira/browse/WICKET-6551
 Project: Wicket
  Issue Type: Bug
  Components: wicket, wicket-spring
Affects Versions: 6.21.0
Reporter: Tomas Kloucek


When weblogic serializes HTTP session then it's not an Wicket Application 
thread and Thread.currentThread().getClassLoader() can return different 
NOT-application classloader... which ends in LazyInitProxyFactory.readResolve() 
ClassNotFoundException crash...This ends in Wicket's WebSession being not saved 
into HTTP session which is fatal consequence

We have sucessfully tested following patch of LazyInitProxyFactory:

 

static class ProxyReplacement implements IClusterable
{
 private static final long serialVersionUID = 1L;

 private final IProxyTargetLocator locator;

 private final String type;

 /**
 * Constructor
 * 
 * @param type
 * @param locator
 */
 public ProxyReplacement(final String type, final IProxyTargetLocator locator)
 {
 this.type = type;
 this.locator = locator;
 }

 private Object readResolve() throws ObjectStreamException
 {
 Class clazz = WicketObjects.resolveClass(type);
 if (clazz == null)
 {
 try {
 clazz = Class.forName(type, false,
 WicketObjects.class.getClassLoader());
 System.out.println("Clazz resolved through application classloade");
 } catch (ClassNotFoundException e) {
 ClassNotFoundException cause = new ClassNotFoundException(
 "Could not resolve type [" + type +
 "] with the currently configured 
org.apache.wicket.application.IClassResolver");
 throw new WicketRuntimeException(cause);
 }
 }
 return LazyInitProxyFactory.createProxy(clazz, locator);
 }
}

With this patched LazyInitProxyFactory class problem went away. Can you please 
accomodate this fix into Wicket 6.x line?

 

 

 



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


[jira] [Updated] (WICKET-6550) Unify all metadata capable objects.

2018-04-19 Thread Jezza (JIRA)

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

Jezza updated WICKET-6550:
--
Description: 
Application, Session, RequestCycle, and Component all have #setMetadata and 
#getMetadata methods, but lack some super object to unify them all.
These leads to annoying complex code if you wish to implement some extra 
functionality.

I propose that we unify them all with one interface.
I've attached a mock idea that would solve it, and I'll work on a prototype and 
submit a PR so anyone can take a look.

I'll add a comment here with the PR number.

  was:
Application, Session, RequestCycle, and Component all have #setMetadata and 
#getMetadata methods, but lack some super object to unify them all.
These leads to annoying complex code if you wish to implement some basic 
functionality.

Such as a computeIfAbsent, which needs to be implemented 4 times.

I propose that we unify them all with one interface.
I've attached a mock idea that would solve it, and I'll work on a prototype and 
submit a PR so anyone can take a look.

I'll add a comment here with the PR number.


> Unify all metadata capable objects.
> ---
>
> Key: WICKET-6550
> URL: https://issues.apache.org/jira/browse/WICKET-6550
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Reporter: Jezza
>Priority: Minor
> Attachments: Test.java, mock.txt
>
>
> Application, Session, RequestCycle, and Component all have #setMetadata and 
> #getMetadata methods, but lack some super object to unify them all.
> These leads to annoying complex code if you wish to implement some extra 
> functionality.
> I propose that we unify them all with one interface.
> I've attached a mock idea that would solve it, and I'll work on a prototype 
> and submit a PR so anyone can take a look.
> I'll add a comment here with the PR number.



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


[jira] [Commented] (WICKET-6550) Unify all metadata capable objects.

2018-04-19 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-6550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444750#comment-16444750
 ] 

ASF GitHub Bot commented on WICKET-6550:


Github user Jezza commented on a diff in the pull request:

https://github.com/apache/wicket/pull/276#discussion_r182876774
  
--- Diff: wicket-core/src/main/java/org/apache/wicket/Application.java ---
@@ -518,9 +519,13 @@ public void logResponseTarget(final IRequestHandler 
requestTarget)
 * @throws IllegalArgumentException
 * @see MetaDataKey
 */
-   public final synchronized  Application setMetaData(final 
MetaDataKey key, final Object object)
+   @Override
+   public final  Application setMetaData(final MetaDataKey key, 
final T object)
--- End diff --

I had to change the signature of this method.
Ideally, it should have been that way anyway.
Everything still compiles, which means we weren't putting values in keys 
that weren't expecting the value.

I fear that some users might be doing exactly that though, so this whole 
IMetadataContext might have to be put off for a bigger version.


> Unify all metadata capable objects.
> ---
>
> Key: WICKET-6550
> URL: https://issues.apache.org/jira/browse/WICKET-6550
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Reporter: Jezza
>Priority: Minor
> Attachments: Test.java, mock.txt
>
>
> Application, Session, RequestCycle, and Component all have #setMetadata and 
> #getMetadata methods, but lack some super object to unify them all.
> These leads to annoying complex code if you wish to implement some basic 
> functionality.
> Such as a computeIfAbsent, which needs to be implemented 4 times.
> I propose that we unify them all with one interface.
> I've attached a mock idea that would solve it, and I'll work on a prototype 
> and submit a PR so anyone can take a look.
> I'll add a comment here with the PR number.



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


[jira] [Commented] (WICKET-6550) Unify all metadata capable objects.

2018-04-19 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-6550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444748#comment-16444748
 ] 

ASF GitHub Bot commented on WICKET-6550:


Github user Jezza commented on a diff in the pull request:

https://github.com/apache/wicket/pull/276#discussion_r182876140
  
--- Diff: wicket-core/src/main/java/org/apache/wicket/IMetadataContext.java 
---
@@ -0,0 +1,10 @@
+package org.apache.wicket;
+
+/**
+ * @author Jezza
+ */
+public interface IMetadataContext {
--- End diff --

I don't like the names of the generics, nor the R parameter.
It was only added because the current implementation returns the object the 
method is enclosed in, so right now, it just conveys that type information.  
Ideally, I would want to remove it.

One solution would be just to return the IMetadataContext itself, but 
you wouldn't be able to do much with the return result, short of just setting 
more metadata.


> Unify all metadata capable objects.
> ---
>
> Key: WICKET-6550
> URL: https://issues.apache.org/jira/browse/WICKET-6550
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Reporter: Jezza
>Priority: Minor
> Attachments: Test.java, mock.txt
>
>
> Application, Session, RequestCycle, and Component all have #setMetadata and 
> #getMetadata methods, but lack some super object to unify them all.
> These leads to annoying complex code if you wish to implement some basic 
> functionality.
> Such as a computeIfAbsent, which needs to be implemented 4 times.
> I propose that we unify them all with one interface.
> I've attached a mock idea that would solve it, and I'll work on a prototype 
> and submit a PR so anyone can take a look.
> I'll add a comment here with the PR number.



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


[jira] [Comment Edited] (WICKET-6550) Unify all metadata capable objects.

2018-04-19 Thread Jezza (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-6550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444743#comment-16444743
 ] 

Jezza edited comment on WICKET-6550 at 4/19/18 8:31 PM:


In the commit message, I said it could be extended.

Something like this could be add to the interface, among others.

{code:java}

default  T computeMetadataIfAbsent(MetaDataKey key, Supplier 
supplier) {
T data = getMetaData(key);
if (data == null) {
data = supplier.get();
setMetaData(key, data);
}
return data;
}

{code}

 


was (Author: jezza):
In the commit message, I said it could be extended.

Something like this could be add to the interface, among others.

{code:java}

default  T computeMetadataIfAbsent(MetaDataKey key, Supplier 
supplier) {
  T data = getMetaData(key);
  if (data == null) {
data = supplier.get();
setMetaData(key, data);
  }
  return data;
}

{code}

 

> Unify all metadata capable objects.
> ---
>
> Key: WICKET-6550
> URL: https://issues.apache.org/jira/browse/WICKET-6550
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Reporter: Jezza
>Priority: Minor
> Attachments: Test.java, mock.txt
>
>
> Application, Session, RequestCycle, and Component all have #setMetadata and 
> #getMetadata methods, but lack some super object to unify them all.
> These leads to annoying complex code if you wish to implement some basic 
> functionality.
> Such as a computeIfAbsent, which needs to be implemented 4 times.
> I propose that we unify them all with one interface.
> I've attached a mock idea that would solve it, and I'll work on a prototype 
> and submit a PR so anyone can take a look.
> I'll add a comment here with the PR number.



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


[jira] [Commented] (WICKET-6550) Unify all metadata capable objects.

2018-04-19 Thread Jezza (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-6550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444746#comment-16444746
 ] 

Jezza commented on WICKET-6550:
---

Or if that isn't the direction we want to go in, the current state still lets 
us do something like:

{code:java}
public static  T computeIfAbsent(IMetadataContext context, 
MetaDataKey key, Supplier supplier) {
T data = context.getMetaData(key);
if (data == null) {
data = supplier.get();
context.setMetaData(key, data);
}
return data;
}
{code}

> Unify all metadata capable objects.
> ---
>
> Key: WICKET-6550
> URL: https://issues.apache.org/jira/browse/WICKET-6550
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Reporter: Jezza
>Priority: Minor
> Attachments: Test.java, mock.txt
>
>
> Application, Session, RequestCycle, and Component all have #setMetadata and 
> #getMetadata methods, but lack some super object to unify them all.
> These leads to annoying complex code if you wish to implement some basic 
> functionality.
> Such as a computeIfAbsent, which needs to be implemented 4 times.
> I propose that we unify them all with one interface.
> I've attached a mock idea that would solve it, and I'll work on a prototype 
> and submit a PR so anyone can take a look.
> I'll add a comment here with the PR number.



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


[jira] [Commented] (WICKET-6550) Unify all metadata capable objects.

2018-04-19 Thread Jezza (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-6550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444743#comment-16444743
 ] 

Jezza commented on WICKET-6550:
---

In the commit message, I said it could be extended.

Something like this could be add to the interface, among others.

{code:java}

default  T computeMetadataIfAbsent(MetaDataKey key, Supplier 
supplier) {
  T data = getMetaData(key);
  if (data == null) {
data = supplier.get();
setMetaData(key, data);
  }
  return data;
}

{code}

 

> Unify all metadata capable objects.
> ---
>
> Key: WICKET-6550
> URL: https://issues.apache.org/jira/browse/WICKET-6550
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Reporter: Jezza
>Priority: Minor
> Attachments: Test.java, mock.txt
>
>
> Application, Session, RequestCycle, and Component all have #setMetadata and 
> #getMetadata methods, but lack some super object to unify them all.
> These leads to annoying complex code if you wish to implement some basic 
> functionality.
> Such as a computeIfAbsent, which needs to be implemented 4 times.
> I propose that we unify them all with one interface.
> I've attached a mock idea that would solve it, and I'll work on a prototype 
> and submit a PR so anyone can take a look.
> I'll add a comment here with the PR number.



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


[jira] [Commented] (WICKET-6550) Unify all metadata capable objects.

2018-04-19 Thread Jezza (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-6550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444728#comment-16444728
 ] 

Jezza commented on WICKET-6550:
---

[https://github.com/apache/wicket/pull/276]

[^Test.java] shows what is now possible.


 

> Unify all metadata capable objects.
> ---
>
> Key: WICKET-6550
> URL: https://issues.apache.org/jira/browse/WICKET-6550
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Reporter: Jezza
>Priority: Minor
> Attachments: Test.java, mock.txt
>
>
> Application, Session, RequestCycle, and Component all have #setMetadata and 
> #getMetadata methods, but lack some super object to unify them all.
> These leads to annoying complex code if you wish to implement some basic 
> functionality.
> Such as a computeIfAbsent, which needs to be implemented 4 times.
> I propose that we unify them all with one interface.
> I've attached a mock idea that would solve it, and I'll work on a prototype 
> and submit a PR so anyone can take a look.
> I'll add a comment here with the PR number.



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


[jira] [Updated] (WICKET-6550) Unify all metadata capable objects.

2018-04-19 Thread Jezza (JIRA)

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

Jezza updated WICKET-6550:
--
Attachment: Test.java

> Unify all metadata capable objects.
> ---
>
> Key: WICKET-6550
> URL: https://issues.apache.org/jira/browse/WICKET-6550
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Reporter: Jezza
>Priority: Minor
> Attachments: Test.java, mock.txt
>
>
> Application, Session, RequestCycle, and Component all have #setMetadata and 
> #getMetadata methods, but lack some super object to unify them all.
> These leads to annoying complex code if you wish to implement some basic 
> functionality.
> Such as a computeIfAbsent, which needs to be implemented 4 times.
> I propose that we unify them all with one interface.
> I've attached a mock idea that would solve it, and I'll work on a prototype 
> and submit a PR so anyone can take a look.
> I'll add a comment here with the PR number.



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


[jira] [Commented] (WICKET-6550) Unify all metadata capable objects.

2018-04-19 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-6550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444727#comment-16444727
 ] 

ASF GitHub Bot commented on WICKET-6550:


GitHub user Jezza opened a pull request:

https://github.com/apache/wicket/pull/276

WICKET-6550 : Unify all metadata capable objects.

Introduce a IMetadataContext that contains the current metadata
 implementation.
This should allow more generic code to be written for all of the objects
 currently capable of storing and handling metadata.
Ideally, this could be expanded with useful default methods.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Jezza/wicket WICKET-6550

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/wicket/pull/276.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #276


commit e92bffdf596bdf96d88de3bb2fe64616a390719b
Author: Jezza 
Date:   2018-04-19T20:16:47Z

WICKET-6550 : Unify all metadata capable objects.

Introduce a IMetadataContext that contains the current metadata
 implementation.
This should allow more generic code to be written for all of the objects
 currently capable of storing and handling metadata.
Ideally, this could be expanded with useful default methods.




> Unify all metadata capable objects.
> ---
>
> Key: WICKET-6550
> URL: https://issues.apache.org/jira/browse/WICKET-6550
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Reporter: Jezza
>Priority: Minor
> Attachments: mock.txt
>
>
> Application, Session, RequestCycle, and Component all have #setMetadata and 
> #getMetadata methods, but lack some super object to unify them all.
> These leads to annoying complex code if you wish to implement some basic 
> functionality.
> Such as a computeIfAbsent, which needs to be implemented 4 times.
> I propose that we unify them all with one interface.
> I've attached a mock idea that would solve it, and I'll work on a prototype 
> and submit a PR so anyone can take a look.
> I'll add a comment here with the PR number.



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


[jira] [Updated] (WICKET-6550) Unify all metadata capable objects.

2018-04-19 Thread Jezza (JIRA)

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

Jezza updated WICKET-6550:
--
Attachment: mock.txt

> Unify all metadata capable objects.
> ---
>
> Key: WICKET-6550
> URL: https://issues.apache.org/jira/browse/WICKET-6550
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Reporter: Jezza
>Priority: Minor
> Attachments: mock.txt
>
>
> Application, Session, RequestCycle, and Component all have #setMetadata and 
> #getMetadata methods, but lack some super object to unify them all.
> These leads to annoying complex code if you wish to implement some basic 
> functionality.
> Such as a computeIfAbsent, which needs to be implemented 4 times.
> I propose that we unify them all with one interface.
> I've attached a mock idea that would solve it, and I'll work on a prototype 
> and submit a PR so anyone can take a look.
> I'll add a comment here with the PR number.



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


[jira] [Created] (WICKET-6550) Unify all metadata capable objects.

2018-04-19 Thread Jezza (JIRA)
Jezza created WICKET-6550:
-

 Summary: Unify all metadata capable objects.
 Key: WICKET-6550
 URL: https://issues.apache.org/jira/browse/WICKET-6550
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Reporter: Jezza
 Attachments: mock.txt

Application, Session, RequestCycle, and Component all have #setMetadata and 
#getMetadata methods, but lack some super object to unify them all.
These leads to annoying complex code if you wish to implement some basic 
functionality.

Such as a computeIfAbsent, which needs to be implemented 4 times.

I propose that we unify them all with one interface.
I've attached a mock idea that would solve it, and I'll work on a prototype and 
submit a PR so anyone can take a look.

I'll add a comment here with the PR number.



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