[JBoss JIRA] (LOGMGR-144) Allow the # symbol to be used for expressions in a PatternFormatter
by James Perkins (JIRA)
James Perkins created LOGMGR-144:
------------------------------------
Summary: Allow the # symbol to be used for expressions in a PatternFormatter
Key: LOGMGR-144
URL: https://issues.jboss.org/browse/LOGMGR-144
Project: JBoss Log Manager
Issue Type: Feature Request
Reporter: James Perkins
Assignee: James Perkins
Currently in the format pattern when you want to define an expression the format pattern is {code}
%${system.property.key:default-value}
{code}
This can cause problems other applications that parse the same type of expression format like WildFly. Adding an option like the following will allow a workaround for this issue.
{code{
%#{system.property.key:default:value}
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFCORE-1975) EmbeddedProcessFactory does not accept module pathes with multiple directories
by István Tóth (JIRA)
István Tóth created WFCORE-1975:
-----------------------------------
Summary: EmbeddedProcessFactory does not accept module pathes with multiple directories
Key: WFCORE-1975
URL: https://issues.jboss.org/browse/WFCORE-1975
Project: WildFly Core
Issue Type: Bug
Components: Server
Affects Versions: 3.0.0.Alpha12
Reporter: István Tóth
Assignee: Jason Greene
The {{modulePath}} parameters passed to the {{org.wildfly.core.embedded.EmbeddedProcessFactory}} methods are are rejected if they they are actual paths with multiple directories. Only single directory names are accepted.
This is inconsistent with the normal operation of the server, with the naming of the parameter, as well as with the semantics of the {{module.path}} system property that it ultimately sets.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (DROOLS-1143) Guice error resolving implementation for RepositorySystem in shaded jar for kie-ci 6.3.0.Final with spark streaming (1.6.1)
by Jess Evans (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1143?page=com.atlassian.jira.plugi... ]
Jess Evans commented on DROOLS-1143:
------------------------------------
Thanks for responding. You did this to override some newer maven library that Spark was using i.e. Drools isn't compatible with later versions of maven? Or was this purely some class loader hierarchy quirk?
> Guice error resolving implementation for RepositorySystem in shaded jar for kie-ci 6.3.0.Final with spark streaming (1.6.1)
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1143
> URL: https://issues.jboss.org/browse/DROOLS-1143
> Project: Drools
> Issue Type: Bug
> Reporter: Lucie Zhao
> Assignee: Mario Fusco
>
> I'm working on a project where I'm trying to integrate drools with spark streaming. I've seen this error on DROOLS-723 where it's reported to have been fixed in 6.2.0.Final but I'm using 6.3.0.Final and it's not working for me. I am able to run a quick test in my eclipse work space without the spark piece and it is working for me.
> here's the stack trace:
> {code}
> 016-04-27 10:22:32,360 WARN [streaming-job-executor-0] Sisu (Logs.java:warn(394)) - Error injecting: org.apache.maven.execution.DefaultMavenExecutionRequestPopulator
> com.google.inject.ProvisionException: Guice provision errors:
> 1) No implementation for org.apache.maven.repository.RepositorySystem was bound.
> while locating org.apache.maven.execution.DefaultMavenExecutionRequestPopulator
> 1 error
> at com.google.inject.internal.InjectorImpl$3.get(InjectorImpl.java:974)
> at com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1000)
> at org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
> at com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:84)
> at com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:52)
> at com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:70)
> at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:100)
> at org.eclipse.sisu.plexus.PlexusLifecycleManager.onProvision(PlexusLifecycleManager.java:133)
> at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:108)
> at com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:55)
> at com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
> at com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:45)
> at com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
> at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1018)
> at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
> at com.google.inject.Scopes$1$1.get(Scopes.java:59)
> at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
> at com.google.inject.internal.InjectorImpl$3$1.call(InjectorImpl.java:965)
> at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1011)
> at com.google.inject.internal.InjectorImpl$3.get(InjectorImpl.java:961)
> at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:82)
> at org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:260)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:252)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:246)
> at org.kie.scanner.embedder.PlexusComponentProvider.lookup(PlexusComponentProvider.java:42)
> at org.kie.scanner.embedder.MavenEmbedder.buildMavenExecutionRequest(MavenEmbedder.java:111)
> at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:84)
> at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:75)
> at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:69)
> at org.kie.scanner.embedder.MavenProjectLoader.parseMavenPom(MavenProjectLoader.java:55)
> at org.kie.scanner.embedder.MavenProjectLoader.parseMavenPom(MavenProjectLoader.java:49)
> at org.kie.scanner.ArtifactResolver.getResolverFor(ArtifactResolver.java:127)
> at org.kie.scanner.ArtifactResolver.getResolverFor(ArtifactResolver.java:90)
> at org.kie.scanner.KieRepositoryScannerImpl.setKieContainer(KieRepositoryScannerImpl.java:88)
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieScanner(KieServicesImpl.java:139)
> at com.emc.ctooil.spark.SparkKafkaDroolsConsumer$4.call(SparkKafkaDroolsConsumer.java:239)
> at com.emc.ctooil.spark.SparkKafkaDroolsConsumer$4.call(SparkKafkaDroolsConsumer.java:1)
> at org.apache.spark.streaming.api.java.JavaDStreamLike$$anonfun$foreachRDD$3.apply(JavaDStreamLike.scala:335)
> at org.apache.spark.streaming.api.java.JavaDStreamLike$$anonfun$foreachRDD$3.apply(JavaDStreamLike.scala:335)
> at org.apache.spark.streaming.dstream.DStream$$anonfun$foreachRDD$1$$anonfun$apply$mcV$sp$3.apply(DStream.scala:661)
> at org.apache.spark.streaming.dstream.DStream$$anonfun$foreachRDD$1$$anonfun$apply$mcV$sp$3.apply(DStream.scala:661)
> at org.apache.spark.streaming.dstream.ForEachDStream$$anonfun$1$$anonfun$apply$mcV$sp$1.apply$mcV$sp(ForEachDStream.scala:50)
> at org.apache.spark.streaming.dstream.ForEachDStream$$anonfun$1$$anonfun$apply$mcV$sp$1.apply(ForEachDStream.scala:50)
> at org.apache.spark.streaming.dstream.ForEachDStream$$anonfun$1$$anonfun$apply$mcV$sp$1.apply(ForEachDStream.scala:50)
> at org.apache.spark.streaming.dstream.DStream.createRDDWithLocalProperties(DStream.scala:426)
> at org.apache.spark.streaming.dstream.ForEachDStream$$anonfun$1.apply$mcV$sp(ForEachDStream.scala:49)
> at org.apache.spark.streaming.dstream.ForEachDStream$$anonfun$1.apply(ForEachDStream.scala:49)
> at org.apache.spark.streaming.dstream.ForEachDStream$$anonfun$1.apply(ForEachDStream.scala:49)
> at scala.util.Try$.apply(Try.scala:161)
> at org.apache.spark.streaming.scheduler.Job.run(Job.scala:39)
> at org.apache.spark.streaming.scheduler.JobScheduler$JobHandler$$anonfun$run$1.apply$mcV$sp(JobScheduler.scala:224)
> at org.apache.spark.streaming.scheduler.JobScheduler$JobHandler$$anonfun$run$1.apply(JobScheduler.scala:224)
> at org.apache.spark.streaming.scheduler.JobScheduler$JobHandler$$anonfun$run$1.apply(JobScheduler.scala:224)
> at scala.util.DynamicVariable.withValue(DynamicVariable.scala:57)
> at org.apache.spark.streaming.scheduler.JobScheduler$JobHandler.run(JobScheduler.scala:223)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> java.lang.RuntimeException: org.kie.scanner.embedder.MavenEmbedderException: com.google.inject.ProvisionException: Guice provision errors:
> 1) No implementation for org.apache.maven.repository.RepositorySystem was bound.
> while locating org.apache.maven.execution.DefaultMavenExecutionRequestPopulator
> at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]]
> at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]]
> while locating org.apache.maven.execution.MavenExecutionRequestPopulator
> 1 error
> role: org.apache.maven.execution.MavenExecutionRequestPopulator
> roleHint:
> at org.kie.scanner.embedder.MavenProjectLoader.parseMavenPom(MavenProjectLoader.java:57)
> at org.kie.scanner.embedder.MavenProjectLoader.parseMavenPom(MavenProjectLoader.java:49)
> at org.kie.scanner.ArtifactResolver.getResolverFor(ArtifactResolver.java:127)
> at org.kie.scanner.ArtifactResolver.getResolverFor(ArtifactResolver.java:90)
> at org.kie.scanner.KieRepositoryScannerImpl.setKieContainer(KieRepositoryScannerImpl.java:88)
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieScanner(KieServicesImpl.java:139)
> at com.emc.ctooil.spark.SparkKafkaDroolsConsumer$4.call(SparkKafkaDroolsConsumer.java:239)
> at com.emc.ctooil.spark.SparkKafkaDroolsConsumer$4.call(SparkKafkaDroolsConsumer.java:1)
> at org.apache.spark.streaming.api.java.JavaDStreamLike$$anonfun$foreachRDD$3.apply(JavaDStreamLike.scala:335)
> at org.apache.spark.streaming.api.java.JavaDStreamLike$$anonfun$foreachRDD$3.apply(JavaDStreamLike.scala:335)
> at org.apache.spark.streaming.dstream.DStream$$anonfun$foreachRDD$1$$anonfun$apply$mcV$sp$3.apply(DStream.scala:661)
> at org.apache.spark.streaming.dstream.DStream$$anonfun$foreachRDD$1$$anonfun$apply$mcV$sp$3.apply(DStream.scala:661)
> at org.apache.spark.streaming.dstream.ForEachDStream$$anonfun$1$$anonfun$apply$mcV$sp$1.apply$mcV$sp(ForEachDStream.scala:50)
> at org.apache.spark.streaming.dstream.ForEachDStream$$anonfun$1$$anonfun$apply$mcV$sp$1.apply(ForEachDStream.scala:50)
> at org.apache.spark.streaming.dstream.ForEachDStream$$anonfun$1$$anonfun$apply$mcV$sp$1.apply(ForEachDStream.scala:50)
> at org.apache.spark.streaming.dstream.DStream.createRDDWithLocalProperties(DStream.scala:426)
> at org.apache.spark.streaming.dstream.ForEachDStream$$anonfun$1.apply$mcV$sp(ForEachDStream.scala:49)
> at org.apache.spark.streaming.dstream.ForEachDStream$$anonfun$1.apply(ForEachDStream.scala:49)
> at org.apache.spark.streaming.dstream.ForEachDStream$$anonfun$1.apply(ForEachDStream.scala:49)
> at scala.util.Try$.apply(Try.scala:161)
> at org.apache.spark.streaming.scheduler.Job.run(Job.scala:39)^C
> at org.apache.spark.streaming.scheduler.JobScheduler$JobHandler$$anonfun$run$1.apply$mcV$sp(JobScheduler.scala:224)
> at org.apache.spark.streaming.scheduler.JobScheduler$JobHandler$$anonfun$run$1.apply(JobScheduler.scala:224)
> at org.apache.spark.streaming.scheduler.JobScheduler$JobHandler$$anonfun$run$1.apply(JobScheduler.scala:224)
> at scala.util.DynamicVariable.withValue(DynamicVariable.scala:57)
> at org.apache.spark.streaming.scheduler.JobScheduler$JobHandler.run(JobScheduler.scala:223)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.kie.scanner.embedder.MavenEmbedderException: com.google.inject.ProvisionException: Guice provision errors:
> 1) No implementation for org.apache.maven.repository.RepositorySystem was bound.
> while locating org.apache.maven.execution.DefaultMavenExecutionRequestPopulator
> at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]]
> at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]]
> while locating org.apache.maven.execution.MavenExecutionRequestPopulator
> 1 error
> role: org.apache.maven.execution.MavenExecutionRequestPopulator
> roleHint:
> at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:94)
> at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:75)
> at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:69)
> at org.kie.scanner.embedder.MavenProjectLoader.parseMavenPom(MavenProjectLoader.java:55)
> ... 28 more
> Caused by: org.codehaus.plexus.component.repository.exception.ComponentLookupException: com.google.inject.ProvisionException: Guice provision errors:
> 1) No implementation for org.apache.maven.repository.RepositorySystem was bound.
> while locating org.apache.maven.execution.DefaultMavenExecutionRequestPopulator
> at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]]
> at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]]
> while locating org.apache.maven.execution.MavenExecutionRequestPopulator
> 1 error
> role: org.apache.maven.execution.MavenExecutionRequestPopulator
> roleHint:
> at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:264)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:252)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:246)
> at org.kie.scanner.embedder.PlexusComponentProvider.lookup(PlexusComponentProvider.java:42)
> at org.kie.scanner.embedder.MavenEmbedder.buildMavenExecutionRequest(MavenEmbedder.java:111)
> at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:84)
> ... 31 more
> Caused by: com.google.inject.ProvisionException: Guice provision errors:
> 1) No implementation for org.apache.maven.repository.RepositorySystem was bound.
> while locating org.apache.maven.execution.DefaultMavenExecutionRequestPopulator
> at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]]
> at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]]
> while locating org.apache.maven.execution.MavenExecutionRequestPopulator
> 1 error
> at com.google.inject.internal.InjectorImpl$3.get(InjectorImpl.java:974)
> at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:82)
> at org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:260)
> ... 36 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7564) EJB Attachment protocol mismatch
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-7564?page=com.atlassian.jira.plugin.... ]
David Lloyd updated WFLY-7564:
------------------------------
Component/s: EJB
Description:
In both EJB client and server code, on method invocations where context data is sent, the sender writes the attachment count as a packed integer but the reader consumes it as an unsigned byte. This is not good.
The fix:
* In protocol 3 and higher, always read and write a packed integer
* In protocol 2 and lower, always read a packed integer but write a signed byte, failing if more than 127 attachments are present
Note that this is only temporary in the WFLY project as the server code should ultimately be moving to live in the ejb-client library.
was:
In both EJB client and server code, on method invocations where context data is sent, the sender writes the attachment count as a packed integer but the reader consumes it as an unsigned byte. This is not good.
The fix:
* In protocol 3 and higher, always read and write a packed integer
* In protocol 2 and lower, always read a packed integer but write a signed byte, failing if more than 127 attachments are present
Summary: EJB Attachment protocol mismatch (was: Attachment protocol mismatch)
> EJB Attachment protocol mismatch
> --------------------------------
>
> Key: WFLY-7564
> URL: https://issues.jboss.org/browse/WFLY-7564
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: David Lloyd
> Assignee: David Lloyd
> Priority: Blocker
> Fix For: 11.0.0.Alpha1
>
>
> In both EJB client and server code, on method invocations where context data is sent, the sender writes the attachment count as a packed integer but the reader consumes it as an unsigned byte. This is not good.
> The fix:
> * In protocol 3 and higher, always read and write a packed integer
> * In protocol 2 and lower, always read a packed integer but write a signed byte, failing if more than 127 attachments are present
> Note that this is only temporary in the WFLY project as the server code should ultimately be moving to live in the ejb-client library.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7564) Attachment protocol mismatch
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-7564?page=com.atlassian.jira.plugin.... ]
David Lloyd moved EJBCLIENT-174 to WFLY-7564:
---------------------------------------------
Project: WildFly (was: EJB Client Library (AS7+))
Key: WFLY-7564 (was: EJBCLIENT-174)
Affects Version/s: (was: 2.0.3.Final)
(was: 2.1.7.Final)
(was: 1.0.37.Final)
(was: 3.0.0.Beta3)
Fix Version/s: 11.0.0.Alpha1
(was: 2.0.4.Final)
(was: 4.0.0.Beta1)
(was: 1.0.38.Final)
(was: 2.1.8.Final)
(was: 3.0.0.Beta4)
> Attachment protocol mismatch
> ----------------------------
>
> Key: WFLY-7564
> URL: https://issues.jboss.org/browse/WFLY-7564
> Project: WildFly
> Issue Type: Bug
> Reporter: David Lloyd
> Assignee: David Lloyd
> Priority: Blocker
> Fix For: 11.0.0.Alpha1
>
>
> In both EJB client and server code, on method invocations where context data is sent, the sender writes the attachment count as a packed integer but the reader consumes it as an unsigned byte. This is not good.
> The fix:
> * In protocol 3 and higher, always read and write a packed integer
> * In protocol 2 and lower, always read a packed integer but write a signed byte, failing if more than 127 attachments are present
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-4988) Can't load job from another jar inside ear
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-4988?page=com.atlassian.jira.plugin.... ]
James Perkins commented on WFLY-4988:
-------------------------------------
The pull request allows job XML files in a JAR in a WAR's `lib` directory to be resolved. It also allows all modules of an `EAR` to see job XML files in libraries in it's `lib` directory. Also `EAR` modules will be able to see job XML files in dependent modules.
> Can't load job from another jar inside ear
> ------------------------------------------
>
> Key: WFLY-4988
> URL: https://issues.jboss.org/browse/WFLY-4988
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Reporter: Daniele Pirola
> Assignee: James Perkins
> Priority: Critical
>
> Prior to 1.1.0.Final I was able to load and start a batch job located in jar 1 from jar 2. Both jars were package inside an ear. Now with the latest introduction of spi resolver (JobXmlResolverService from wildfly 9) the service created for jar 2 have no jobXmlResolvers so the start method from JobOperator throws an javax.batch.operations.JobStartException: JBERET000601: Failed to get job xml file for job XXX.
> According to the spec:
> "archive loader If the implementation-specific mechanism does fails to resolve a Job XML reference, then the batch runtime implementation must resolve the reference with an archive loader. The implementation must provide an archive loader that resolves the reference by looking up the reference from the META-INF/batch-jobs directory." I think that the implementation have to try to load jobs also in META-INF/batch-jobs dir.
> Changes in the old behaviour was made due to Issue JBERET-144
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-4988) Can't load job from another jar inside ear
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-4988?page=com.atlassian.jira.plugin.... ]
James Perkins updated WFLY-4988:
--------------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/9376
> Can't load job from another jar inside ear
> ------------------------------------------
>
> Key: WFLY-4988
> URL: https://issues.jboss.org/browse/WFLY-4988
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Reporter: Daniele Pirola
> Assignee: James Perkins
> Priority: Critical
>
> Prior to 1.1.0.Final I was able to load and start a batch job located in jar 1 from jar 2. Both jars were package inside an ear. Now with the latest introduction of spi resolver (JobXmlResolverService from wildfly 9) the service created for jar 2 have no jobXmlResolvers so the start method from JobOperator throws an javax.batch.operations.JobStartException: JBERET000601: Failed to get job xml file for job XXX.
> According to the spec:
> "archive loader If the implementation-specific mechanism does fails to resolve a Job XML reference, then the batch runtime implementation must resolve the reference with an archive loader. The implementation must provide an archive loader that resolves the reference by looking up the reference from the META-INF/batch-jobs directory." I think that the implementation have to try to load jobs also in META-INF/batch-jobs dir.
> Changes in the old behaviour was made due to Issue JBERET-144
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months