[JBoss JIRA] (DROOLS-5107) A rule always fires with executable model for a constraint which has extra parentheses
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5107?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi updated DROOLS-5107:
--------------------------------------
Description:
When you have a constraint with extra parentheses,
{noformat}
$p : Person((age > 30))
{noformat}
executable-model generates a pattern without a constraint expr method so it always fires.
{code:java}
public static org.drools.model.Rule rule_R() {
final org.drools.model.Variable<org.drools.modelcompiler.domain.Person> var_$p = D.declarationOf(org.drools.modelcompiler.domain.Person.class, DomainClassesMetadataFBDA1ED637C8B60C741C0BDB502EB8F0.org_drools_modelcompiler_domain_Person_Metadata_INSTANCE, "$p");
org.drools.model.Rule rule = D.rule("R").build(D.pattern(var_$p),
D.execute(() -> {
{
}
}));
return rule;
}
{code}
was:
When you have a constraint with extra parentheses,
{noformat}
$p : Person((age > 30))
{noformat}
executable-model generates pattern without constraint expr method so it always fires.
{code:java}
public static org.drools.model.Rule rule_R() {
final org.drools.model.Variable<org.drools.modelcompiler.domain.Person> var_$p = D.declarationOf(org.drools.modelcompiler.domain.Person.class, DomainClassesMetadataFBDA1ED637C8B60C741C0BDB502EB8F0.org_drools_modelcompiler_domain_Person_Metadata_INSTANCE, "$p");
org.drools.model.Rule rule = D.rule("R").build(D.pattern(var_$p),
D.execute(() -> {
{
}
}));
return rule;
}
{code}
> A rule always fires with executable model for a constraint which has extra parentheses
> --------------------------------------------------------------------------------------
>
> Key: DROOLS-5107
> URL: https://issues.redhat.com/browse/DROOLS-5107
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.33.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Luca Molteni
> Priority: Major
>
> When you have a constraint with extra parentheses,
> {noformat}
> $p : Person((age > 30))
> {noformat}
> executable-model generates a pattern without a constraint expr method so it always fires.
> {code:java}
> public static org.drools.model.Rule rule_R() {
> final org.drools.model.Variable<org.drools.modelcompiler.domain.Person> var_$p = D.declarationOf(org.drools.modelcompiler.domain.Person.class, DomainClassesMetadataFBDA1ED637C8B60C741C0BDB502EB8F0.org_drools_modelcompiler_domain_Person_Metadata_INSTANCE, "$p");
> org.drools.model.Rule rule = D.rule("R").build(D.pattern(var_$p),
> D.execute(() -> {
> {
> }
> }));
> return rule;
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13152) WFLYEJB0094: EJB 3.1 FR 5.4.2 MessageDrivenBean does not implement 1 interface nor specifies message listener interface
by Rhuan Rocha (Jira)
[ https://issues.redhat.com/browse/WFLY-13152?page=com.atlassian.jira.plugi... ]
Rhuan Rocha edited comment on WFLY-13152 at 2/25/20 11:38 AM:
--------------------------------------------------------------
[~cfang] About the WAR, I have packaged the application via Maven and I have used the external jar in both.
{color:#403294}MessageDrivenComponentDescriptionFactory does check for the interface implemented by the super class of the bean class, but when the super class is not in the current module, the ClassInfo is not found in the current CompositeIndex:{color}
I agreed. I have made tests in my local environment and I have noted it has many CompositeIndex instance and looks like it creates one instance per module. When the code search by interface information it is searching in a wrong instance. I have seen one of these instance has the correct information. I could not find the local in code that it select the CompositeIndex instance.
was (Author: rhn-support-rhsilva):
[~cfang] About the WAR, I have packaged the application via Maven and I have used the external jar in both.
{color:#DE350B}MessageDrivenComponentDescriptionFactory does check for the interface implemented by the super class of the bean class, but when the super class is not in the current module, the ClassInfo is not found in the current CompositeIndex:{color}
I agreed. I have made tests in my local environment and I have noted it has many CompositeIndex instance and looks like it creates one instance per module. When the code search by interface information it is searching in a wrong instance. I have seen one of these instance has the correct information. I could not find the local in code that it select the CompositeIndex instance.
> WFLYEJB0094: EJB 3.1 FR 5.4.2 MessageDrivenBean does not implement 1 interface nor specifies message listener interface
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13152
> URL: https://issues.redhat.com/browse/WFLY-13152
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 17.0.1.Final
> Reporter: Rhuan Rocha
> Assignee: Cheng Fang
> Priority: Major
> Attachments: lib.zip, samplemdbear.zip
>
>
> The MDB does not works when it extends a superclass that comes from an external JAR and this super class implements the MessageListener. It generates this exception:
> {code:java}
> WFLYEJB0094: EJB 3.1 FR 5.4.2 MessageDrivenBean com.exemple.MyMDB does not implement 1 interface nor specifies message listener interface
> {code}
> These are what I have noted:
> * It only happens in a EAR project. In a WAR project it works fine.
> * It only happens when the abstract class come from an external JAR
> * If the sub class implements directly the MessageListener or if the messageListenerInterface is defined in the annotation it works fine.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13152) WFLYEJB0094: EJB 3.1 FR 5.4.2 MessageDrivenBean does not implement 1 interface nor specifies message listener interface
by Rhuan Rocha (Jira)
[ https://issues.redhat.com/browse/WFLY-13152?page=com.atlassian.jira.plugi... ]
Rhuan Rocha commented on WFLY-13152:
------------------------------------
[~cfang] About the WAR, I have packaged the application via Maven and I have used the external jar in both.
{color:#DE350B}MessageDrivenComponentDescriptionFactory does check for the interface implemented by the super class of the bean class, but when the super class is not in the current module, the ClassInfo is not found in the current CompositeIndex:{color}
I agreed. I have made tests in my local environment and I have noted it has many CompositeIndex instance and looks like it creates one instance per module. When the code search by interface information it is searching in a wrong instance. I have seen one of these instance has the correct information. I could not find the local in code that it select the CompositeIndex instance.
> WFLYEJB0094: EJB 3.1 FR 5.4.2 MessageDrivenBean does not implement 1 interface nor specifies message listener interface
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13152
> URL: https://issues.redhat.com/browse/WFLY-13152
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 17.0.1.Final
> Reporter: Rhuan Rocha
> Assignee: Cheng Fang
> Priority: Major
> Attachments: lib.zip, samplemdbear.zip
>
>
> The MDB does not works when it extends a superclass that comes from an external JAR and this super class implements the MessageListener. It generates this exception:
> {code:java}
> WFLYEJB0094: EJB 3.1 FR 5.4.2 MessageDrivenBean com.exemple.MyMDB does not implement 1 interface nor specifies message listener interface
> {code}
> These are what I have noted:
> * It only happens in a EAR project. In a WAR project it works fine.
> * It only happens when the abstract class come from an external JAR
> * If the sub class implements directly the MessageListener or if the messageListenerInterface is defined in the annotation it works fine.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13127) NPE in OpenApiAnnotationScanner when OpenTracing TCK war is deployed
by Ken Finnigan (Jira)
[ https://issues.redhat.com/browse/WFLY-13127?page=com.atlassian.jira.plugi... ]
Ken Finnigan commented on WFLY-13127:
-------------------------------------
[~pferraro] it's available -> https://repo1.maven.org/maven2/io/smallrye/smallrye-open-api/1.1.21/
> NPE in OpenApiAnnotationScanner when OpenTracing TCK war is deployed
> --------------------------------------------------------------------
>
> Key: WFLY-13127
> URL: https://issues.redhat.com/browse/WFLY-13127
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenAPI, MP OpenTracing
> Affects Versions: 19.0.0.Beta2
> Reporter: Brian Stansberry
> Assignee: Paul Ferraro
> Priority: Blocker
> Fix For: 19.0.0.Beta3, 20.0.0.Beta1
>
>
> I tried running the microprofile-tck/opentracing tests against a config that included the OpenAPI subsystem. It failed with an NPE:
> {code}
> 2020-02-18 16:36:53,302 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0001: Content added at location /Users/bstansberry/dev/wildfly/wildfly/testsuite/integration/microprofile-tck/opentracing/target/wildfly/standalone/data/content/85/48e223eb8bfcd73f66458e14a0bbc425998a70/content
> 2020-02-18 16:36:53,313 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0027: Starting deployment of "opentracing.war" (runtime-name: "opentracing.war")
> 2020-02-18 16:36:54,020 INFO [org.jboss.weld.deployer] (MSC service thread 1-7) WFLYWELD0003: Processing weld deployment opentracing.war
> 2020-02-18 16:36:54,114 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-7) HV000001: Hibernate Validator 6.0.18.Final
> 2020-02-18 16:36:54,330 INFO [org.jboss.weld.Version] (MSC service thread 1-8) WELD-000900: 3.1.3 (Final)
> 2020-02-18 16:36:54,576 INFO [io.smallrye.metrics] (MSC service thread 1-5) MicroProfile: Metrics activated (SmallRye Metrics version: 2.4.0)
> 2020-02-18 16:36:54,992 WARN [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0101: Duplicate servlet mapping /rest/* found
> 2020-02-18 16:36:55,173 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service org.wildfly.undertow.host.default-server.default-host./openapi: org.jboss.msc.service.StartException in service org.wildfly.undertow.host.default-server.default-host./openapi: java.lang.NullPointerException
> at org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:66)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.createResponseFromJaxRsMethod(OpenApiAnnotationScanner.java:934)
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.processJaxRsMethod(OpenApiAnnotationScanner.java:688)
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.lambda$processJaxRsResourceClass$0(OpenApiAnnotationScanner.java:422)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1556)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.processJaxRsResourceClass(OpenApiAnnotationScanner.java:420)
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.scan(OpenApiAnnotationScanner.java:221)
> at io.smallrye.openapi.runtime.OpenApiProcessor.modelFromAnnotations(OpenApiProcessor.java:72)
> at org.wildfly.extension.microprofile.openapi.deployment.OpenAPIModelServiceConfigurator.get(OpenAPIModelServiceConfigurator.java:173)
> at org.wildfly.extension.microprofile.openapi.deployment.OpenAPIModelServiceConfigurator.get(OpenAPIModelServiceConfigurator.java:94)
> at org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:63)
> ... 8 more
> {code}
> I hit this when working on WFLY-13099. I was using a standalone.xml variant equivalent to what Galleon would generate using the cloud-server, h2-default-datasource, microprofile-fault-tolerance, microprofile-jwt and microprofile-openapi layers. It wasn't a slimmed server though.
> OpenApiAnnotationScanner L934 seems to assume 'schema' will not be null. But the 'SchemaFactory.typeToSchema' method seems like it's written such that returning null is a possibility; e.g. L362 in the final 'else' block is doing a null check on the 'schema' var whose value is ultimately returned. (I don't see how else the NPE would happen other than SchemaFactory.typeToSchema returning null.)
>
> I put Critical severity on this because I don't know anything about opentracing.war; i.e. whether it's written in a way that would be a real corner case for OpenAPI. I'm being conservative and assigning a high priority.
> [~ehugonnet] FYI.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (JGRP-2455) Fibers use ForkJoinPool by default
by Bela Ban (Jira)
Bela Ban created JGRP-2455:
------------------------------
Summary: Fibers use ForkJoinPool by default
Key: JGRP-2455
URL: https://issues.redhat.com/browse/JGRP-2455
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 5.0, 4.2.1
Fibers are currently created with {{Thread.builder().virtual().task(t).name(name).build()}}
This uses the ForkJoinPool. See if changing this to thread_pool help; this pool is configurable via XML.
Run perftest to see if handling messages and scheduling threads on the same pool cause a perf degradation.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5106) Local/Internal Maven Repos can not be accessed
by Alexandre Bakos (Jira)
[ https://issues.redhat.com/browse/DROOLS-5106?page=com.atlassian.jira.plug... ]
Alexandre Bakos commented on DROOLS-5106:
-----------------------------------------
thank you for the report, but we need a better description of the environment setup and steps to reproduce.
> Local/Internal Maven Repos can not be accessed
> ----------------------------------------------
>
> Key: DROOLS-5106
> URL: https://issues.redhat.com/browse/DROOLS-5106
> Project: Drools
> Issue Type: Bug
> Components: Artifact Repository
> Affects Versions: 7.33.0.Final
> Reporter: Steve Davidson
> Assignee: Alexandre Bakos
> Priority: Major
> Labels: Drools, drools-compiler, maven
>
> Attempting to use an internal Nexus Repository, unable to load Drools KIE Modules using Maven. This works with 7.29.Final. Changing to 7.33.Final fails with the following stack trace;
> {code:java}
> WARNING: Environment variable M2_HOME is not set
> Feb 24, 2020 5:12:30 PM org.kie.server.services.impl.KieServerImpl createContainer
> SEVERE: Error creating container 'JUnit Test: kie-server' for module 'com.j2eeguys.demo:KieIssueDemo:0.1.0-SNAPSHOT'
> java.lang.RuntimeException: Cannot find KieModule: com.j2eeguys.demo:KieIssueDemo:0.1.0-SNAPSHOT
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:186)
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:176)
> at org.kie.server.services.impl.KieServerImpl.createContainer(KieServerImpl.java:281)
> at org.kie.server.remote.rest.common.resource.KieServerRestImpl.createContainer(KieServerRestImpl.java:157)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140)
> at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399)
> at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:310)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:443)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:233)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:139)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358)
> at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:142)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:219)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at org.eclipse.jetty.servlet.ServletHolder$NotAsyncServlet.service(ServletHolder.java:1401)
> at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:760)
> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1617)
> at org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter.doFilter(WebSocketUpgradeFilter.java:226)
> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1604)
> at org.kie.server.services.impl.security.web.CaptureHttpRequestFilter.doFilter(CaptureHttpRequestFilter.java:42)
> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:501)
> at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1592)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1296)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1562)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1211)
> at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:386)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:562)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:378)
> at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:270)
> at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
> at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:388)
> at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806)
> at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months