[JBoss JIRA] (WFWIP-71) Allow for configuration of Converter SPI implementations via management in microprofile-config-smallrye subsystem
by Michal Jurc (JIRA)
Michal Jurc created WFWIP-71:
--------------------------------
Summary: Allow for configuration of Converter SPI implementations via management in microprofile-config-smallrye subsystem
Key: WFWIP-71
URL: https://issues.jboss.org/browse/WFWIP-71
Project: WildFly WIP
Issue Type: Enhancement
Components: MP Config
Reporter: Michal Jurc
Assignee: Jeff Mesnil
MicroProfile configuration specifies three SPIs:
* {{org.eclipse.microprofile.config.spi.ConfigSource}}
* {{org.eclipse.microprofile.config.spi.ConfigSourceProvider}}
* {{org.eclipse.microprofile.config.spi.Converter}}
{{ConfigSource}} and {{ConfigSourceProvider}} services both can be exposed by WildFly management. We recommend providing the same capability for {{Converter}} services.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-70) smallrye-config: Allow configuration of per-deployment DirConfigSource
by Michal Jurc (JIRA)
Michal Jurc created WFWIP-70:
--------------------------------
Summary: smallrye-config: Allow configuration of per-deployment DirConfigSource
Key: WFWIP-70
URL: https://issues.jboss.org/browse/WFWIP-70
Project: WildFly WIP
Issue Type: Enhancement
Components: MP Config
Reporter: Michal Jurc
Assignee: Jeff Mesnil
With the current integration of {{smallrye-config}} with WildFly, it is possible to add a {{config-source}} management element that will hold a location of property directory. In cloud environments, it would be handier to allow this configuration to be committed from deployment itself.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10729) Standalone JMS client is failing with: java.lang.ClassNotFoundException: javax.json.JsonValue with jboss-client.jar
by Martin Styk (JIRA)
[ https://issues.jboss.org/browse/WFLY-10729?page=com.atlassian.jira.plugin... ]
Martin Styk updated WFLY-10729:
-------------------------------
Fix Version/s: 13.0.0.Final
(was: 14.0.0.CR1)
> Standalone JMS client is failing with: java.lang.ClassNotFoundException: javax.json.JsonValue with jboss-client.jar
> -------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10729
> URL: https://issues.jboss.org/browse/WFLY-10729
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 13.0.0.Final
> Reporter: Martin Styk
> Assignee: Jeff Mesnil
> Priority: Blocker
> Fix For: 13.0.0.Final
>
>
> If standalone JMS client is using only jboss-client.jar on classpath then during look up of connection factory fails with:
> {code}
> java.lang.NoClassDefFoundError: javax/json/JsonValue
> at org.apache.activemq.artemis.uri.schema.connector.TCPTransportConfigurationSchema.getTransportConfigurations(TCPTransportConfigurationSchema.java:68)
> at org.apache.activemq.artemis.uri.schema.serverLocator.TCPServerLocatorSchema.internalNewObject(TCPServerLocatorSchema.java:44)
> at org.apache.activemq.artemis.uri.schema.serverLocator.TCPServerLocatorSchema.internalNewObject(TCPServerLocatorSchema.java:33)
> at org.apache.activemq.artemis.utils.uri.URISchema.newObject(URISchema.java:86)
> at org.apache.activemq.artemis.utils.uri.URISchema.newObject(URISchema.java:30)
> at org.apache.activemq.artemis.utils.uri.URIFactory.newObject(URIFactory.java:59)
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.newLocator(ServerLocatorImpl.java:411)
> at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.<init>(ActiveMQConnectionFactory.java:209)
> at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.<init>(ActiveMQConnectionFactory.java:202)
> at org.apache.activemq.artemis.jms.client.ActiveMQJMSConnectionFactory.<init>(ActiveMQJMSConnectionFactory.java:34)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at org.jboss.marshalling.reflect.SerializableClass.invokeConstructor(SerializableClass.java:340)
> at org.jboss.marshalling.reflect.SerializableClass.callNoArgConstructor(SerializableClass.java:292)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1408)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:205)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> at org.wildfly.naming.client.remote.RemoteClientTransport.lookup(RemoteClientTransport.java:243)
> at org.wildfly.naming.client.remote.RemoteContext.lambda$lookupNative$0(RemoteContext.java:190)
> at org.wildfly.naming.client.NamingProvider.performExceptionAction(NamingProvider.java:222)
> at org.wildfly.naming.client.remote.RemoteContext.performWithRetry(RemoteContext.java:100)
> at org.wildfly.naming.client.remote.RemoteContext.lookupNative(RemoteContext.java:188)
> at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:74)
> at org.wildfly.naming.client.store.RelativeFederatingContext.lookupNative(RelativeFederatingContext.java:58)
> at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:74)
> at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:60)
> at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:66)
> at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:144)
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> at org.jboss.qa.artemis.test.client.ProducerJms11.sendMessages(ProducerJms11.java:27)
> at org.jboss.qa.artemis.test.client.Producer.run(Producer.java:35)
> at org.jboss.qa.artemis.test.client.Producer.sendAllSync(Producer.java:26)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10729) Standalone JMS client is failing with: java.lang.ClassNotFoundException: javax.json.JsonValue with jboss-client.jar
by Martin Styk (JIRA)
Martin Styk created WFLY-10729:
----------------------------------
Summary: Standalone JMS client is failing with: java.lang.ClassNotFoundException: javax.json.JsonValue with jboss-client.jar
Key: WFLY-10729
URL: https://issues.jboss.org/browse/WFLY-10729
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 13.0.0.Final
Reporter: Martin Styk
Assignee: Jeff Mesnil
Priority: Blocker
Fix For: 14.0.0.CR1
If standalone JMS client is using only jboss-client.jar on classpath then during look up of connection factory fails with:
{code}
java.lang.NoClassDefFoundError: javax/json/JsonValue
at org.apache.activemq.artemis.uri.schema.connector.TCPTransportConfigurationSchema.getTransportConfigurations(TCPTransportConfigurationSchema.java:68)
at org.apache.activemq.artemis.uri.schema.serverLocator.TCPServerLocatorSchema.internalNewObject(TCPServerLocatorSchema.java:44)
at org.apache.activemq.artemis.uri.schema.serverLocator.TCPServerLocatorSchema.internalNewObject(TCPServerLocatorSchema.java:33)
at org.apache.activemq.artemis.utils.uri.URISchema.newObject(URISchema.java:86)
at org.apache.activemq.artemis.utils.uri.URISchema.newObject(URISchema.java:30)
at org.apache.activemq.artemis.utils.uri.URIFactory.newObject(URIFactory.java:59)
at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.newLocator(ServerLocatorImpl.java:411)
at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.<init>(ActiveMQConnectionFactory.java:209)
at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.<init>(ActiveMQConnectionFactory.java:202)
at org.apache.activemq.artemis.jms.client.ActiveMQJMSConnectionFactory.<init>(ActiveMQJMSConnectionFactory.java:34)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.jboss.marshalling.reflect.SerializableClass.invokeConstructor(SerializableClass.java:340)
at org.jboss.marshalling.reflect.SerializableClass.callNoArgConstructor(SerializableClass.java:292)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1408)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:205)
at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
at org.wildfly.naming.client.remote.RemoteClientTransport.lookup(RemoteClientTransport.java:243)
at org.wildfly.naming.client.remote.RemoteContext.lambda$lookupNative$0(RemoteContext.java:190)
at org.wildfly.naming.client.NamingProvider.performExceptionAction(NamingProvider.java:222)
at org.wildfly.naming.client.remote.RemoteContext.performWithRetry(RemoteContext.java:100)
at org.wildfly.naming.client.remote.RemoteContext.lookupNative(RemoteContext.java:188)
at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:74)
at org.wildfly.naming.client.store.RelativeFederatingContext.lookupNative(RelativeFederatingContext.java:58)
at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:74)
at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:60)
at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:66)
at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:144)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at org.jboss.qa.artemis.test.client.ProducerJms11.sendMessages(ProducerJms11.java:27)
at org.jboss.qa.artemis.test.client.Producer.run(Producer.java:35)
at org.jboss.qa.artemis.test.client.Producer.sendAllSync(Producer.java:26)
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-1825) [Guided Decision Table] Ability to change HIT policy in a decision table anytime
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1825?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-1825:
--------------------------------
Sprint: 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02, 2018 Week 03-04, 2018 Week 05-06, 2018 Week 07-08, 2018 Week 09-10, 2018 Week 11-12, 2018 Week 13-14, 2018 Week 15-16, 2018 Week 17-18, 2018 Week 19-22, 2018 Week 23-24, 2018 Week 25-26, 2018 Week 27-29 (was: 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02, 2018 Week 03-04, 2018 Week 05-06, 2018 Week 07-08, 2018 Week 09-10, 2018 Week 11-12, 2018 Week 13-14, 2018 Week 15-16, 2018 Week 17-18, 2018 Week 19-22, 2018 Week 23-24, 2018 Week 25-26, 2018 Week 27-29, 2018 Week 30-32)
> [Guided Decision Table] Ability to change HIT policy in a decision table anytime
> --------------------------------------------------------------------------------
>
> Key: DROOLS-1825
> URL: https://issues.jboss.org/browse/DROOLS-1825
> Project: Drools
> Issue Type: Enhancement
> Components: Guided Decision Table Editor
> Affects Versions: 7.1.0.Beta2
> Reporter: Ivo Bek
> Assignee: Toni Rikkola
> Priority: Critical
> Labels: UX, UXTeam, drools-tools
> Attachments: DROOLS-1825 (Parent Rule).png, DecisionTable1.png, DecisionTable2.png, GDTAnalysis(a)2x.png, GDTColumns(a)2x.png
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> Today, it's possible to set 1 of 5 HIT policies when we create a new guided decision table. However, the user might not know which HIT policy he/she should use at this early beginning. Therefore, it should be possible to set the policy to None when we create a new guided decision table and set the HIT policy later after we add columns and rows, fill in some data and see and decide based on the created table how the rules should behave using the HIT policy.
> Thus, it should be possible to change HIT policy in a decision table anytime.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10199) Using jboss-modules loading outside WildFly 12 is broken
by Martin Perina (JIRA)
[ https://issues.jboss.org/browse/WFLY-10199?page=com.atlassian.jira.plugin... ]
Martin Perina commented on WFLY-10199:
--------------------------------------
We have moved oVirt to WildFly 13, the issue is fixed there.
Thanks a lot!
> Using jboss-modules loading outside WildFly 12 is broken
> --------------------------------------------------------
>
> Key: WFLY-10199
> URL: https://issues.jboss.org/browse/WFLY-10199
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 12.0.0.Final
> Reporter: Martin Perina
> Assignee: David Lloyd
>
> oVirt is using jboss-modules not only for dependencies inside WildFly, but also when executing command line tools outside WildFly process. We are using following method which worked fine from JBoss 7 to WildFly11:
> {code}
> export JAVA_MODULEPATH="<PATH TO OUR MODULES>"
> exec "${JAVA_HOME}/bin/java" \
> -jar "${JBOSS_HOME}/jboss-modules.jar" \
> -dependencies org.ovirt.engine.core.tools \
> -class org.ovirt.engine.core.cryptotool.Main \
> "$@"
> {code}
> where "org.ovirt.engine.core.tools" is one of our existing module and in class we have standard Java class with main() method executing logic of specific command line tool.
> When I try to execute this code with WildFly 12.0.0.FINAL I receive following exception:
> {code}
> Exception in thread "main" java.lang.NullPointerException
> at java.util.Hashtable.put(Hashtable.java:460)
> at java.util.Properties.setProperty(Properties.java:166)
> at java.lang.System.setProperty(System.java:796)
> at org.jboss.modules.PropertyWriteAction.run(PropertyWriteAction.java:40)
> at org.jboss.modules.PropertyWriteAction.run(PropertyWriteAction.java:28)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.modules.Main.main(Main.java:390)
> {code}
> When I tried to replace jboss-modules.jar provided by WildFly 12.0.0.FINAL with manuall build using latest code in 1.7 branch (commit a52a323c5c3d71cf9597f06951155e4639cbb707) I receive different error:
> {code}
> org.jboss.modules.ModuleNotFoundException: org.ovirt.engine.core.tools
> at org.jboss.modules.Module.addPaths(Module.java:1221)
> at org.jboss.modules.Module.link(Module.java:1577)
> at org.jboss.modules.Module.relinkIfNecessary(Module.java:1605)
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:296)
> at org.jboss.modules.Main.main(Main.java:426)
> {code}
> I haven't found any documentation describing such incompatible between 1.6 and 1.7, so is there any way how to have above execution compatible with both jboss-modules versions?
> Thanks
> Martin
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-1825) [Guided Decision Table] Ability to change HIT policy in a decision table anytime
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1825?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-1825:
--------------------------------
Labels: UX UXTeam drools-tools (was: UX UXTeam)
> [Guided Decision Table] Ability to change HIT policy in a decision table anytime
> --------------------------------------------------------------------------------
>
> Key: DROOLS-1825
> URL: https://issues.jboss.org/browse/DROOLS-1825
> Project: Drools
> Issue Type: Enhancement
> Components: Guided Decision Table Editor
> Affects Versions: 7.1.0.Beta2
> Reporter: Ivo Bek
> Assignee: Toni Rikkola
> Priority: Critical
> Labels: UX, UXTeam, drools-tools
> Attachments: DROOLS-1825 (Parent Rule).png, DecisionTable1.png, DecisionTable2.png, GDTAnalysis(a)2x.png, GDTColumns(a)2x.png
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> Today, it's possible to set 1 of 5 HIT policies when we create a new guided decision table. However, the user might not know which HIT policy he/she should use at this early beginning. Therefore, it should be possible to set the policy to None when we create a new guided decision table and set the HIT policy later after we add columns and rows, fill in some data and see and decide based on the created table how the rules should behave using the HIT policy.
> Thus, it should be possible to change HIT policy in a decision table anytime.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10728) RESTEASY008200: JSON Binding deserialization error for valid JSON
by Guido Schmidt (JIRA)
Guido Schmidt created WFLY-10728:
------------------------------------
Summary: RESTEASY008200: JSON Binding deserialization error for valid JSON
Key: WFLY-10728
URL: https://issues.jboss.org/browse/WFLY-10728
Project: WildFly
Issue Type: Bug
Affects Versions: 13.0.0.Final
Environment: JDK-10.0.1
Reporter: Guido Schmidt
Assignee: Jason Greene
Attachments: User.java, UserQueryForm.java, UsersApi.java
I found the following regression issue running the code inside an ejb jar:
In the context of a search for a user for a user via the Wordpress REST API, I get e.g. following String:
{{[{
"id": 15,
"username": "wpx1",
"name": "Word Press1",
"first_name": "Word",
"last_name": "Press1",
"email": "wpx1(a)pb.com",
"url": "",
"description": "",
"link": "http:\/\/www.pbpiazza.com\/dayc\/archives\/author\/wpx1",
"locale": "en_US",
"nickname": "wpx1",
"slug": "wpx1",
"roles": ["contributor"],
"registered_date": "2018-07-23T08:59:13+00:00",
"capabilities": {
"edit_posts": true,
"read": true,
"level_1": true,
"level_0": true,
"delete_posts": true,
"manage_bookings": true,
"upload_event_images": true,
"delete_events": true,
"edit_events": true,
"read_private_events": true,
"delete_recurring_events": true,
"edit_recurring_events": true,
"edit_locations": true,
"read_private_locations": true,
"read_others_locations": true,
"contributor": true
},
"extra_capabilities": {
"contributor": true
},
"avatar_urls": {
"24": "http:\/\/1.gravatar.com\/avatar\/a4d79ad5a72a13f7d7739c9a3dd9a17b?s=24&d=mm&r=g",
"48": "http:\/\/1.gravatar.com\/avatar\/a4d79ad5a72a13f7d7739c9a3dd9a17b?s=48&d=mm&r=g",
"96": "http:\/\/1.gravatar.com\/avatar\/a4d79ad5a72a13f7d7739c9a3dd9a17b?s=96&d=mm&r=g"
},
"meta": [],
"_links": {
"self": [{
"href": "http:\/\/www.pbpiazza.com\/dayc\/wp-json\/wp\/v2\/users\/15"
}
],
"collection": [{
"href": "http:\/\/www.pbpiazza.com\/dayc\/wp-json\/wp\/v2\/users"
}
]
}
}
]}}
This is achieved by a call of the UsersApi method listUsersAsString:
ResteasyWebTarget target = (ResteasyWebTarget)restEasy.target(uri);
target.proxy(UsersApi.class);
The call rendering the result into a List<User> fails with error message in the subject.
The result is perfectly fine running Wildfly 11.Plain test cases with Wildfly 13 libraries is also fine. It seems to be a runtime configuration issue of RESTEasy in WIldfly 13.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10199) Using jboss-modules loading outside WildFly 12 is broken
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-10199?page=com.atlassian.jira.plugin... ]
David Lloyd resolved WFLY-10199.
--------------------------------
Resolution: Done
Fixed in JBoss Modules.
> Using jboss-modules loading outside WildFly 12 is broken
> --------------------------------------------------------
>
> Key: WFLY-10199
> URL: https://issues.jboss.org/browse/WFLY-10199
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 12.0.0.Final
> Reporter: Martin Perina
> Assignee: David Lloyd
>
> oVirt is using jboss-modules not only for dependencies inside WildFly, but also when executing command line tools outside WildFly process. We are using following method which worked fine from JBoss 7 to WildFly11:
> {code}
> export JAVA_MODULEPATH="<PATH TO OUR MODULES>"
> exec "${JAVA_HOME}/bin/java" \
> -jar "${JBOSS_HOME}/jboss-modules.jar" \
> -dependencies org.ovirt.engine.core.tools \
> -class org.ovirt.engine.core.cryptotool.Main \
> "$@"
> {code}
> where "org.ovirt.engine.core.tools" is one of our existing module and in class we have standard Java class with main() method executing logic of specific command line tool.
> When I try to execute this code with WildFly 12.0.0.FINAL I receive following exception:
> {code}
> Exception in thread "main" java.lang.NullPointerException
> at java.util.Hashtable.put(Hashtable.java:460)
> at java.util.Properties.setProperty(Properties.java:166)
> at java.lang.System.setProperty(System.java:796)
> at org.jboss.modules.PropertyWriteAction.run(PropertyWriteAction.java:40)
> at org.jboss.modules.PropertyWriteAction.run(PropertyWriteAction.java:28)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.modules.Main.main(Main.java:390)
> {code}
> When I tried to replace jboss-modules.jar provided by WildFly 12.0.0.FINAL with manuall build using latest code in 1.7 branch (commit a52a323c5c3d71cf9597f06951155e4639cbb707) I receive different error:
> {code}
> org.jboss.modules.ModuleNotFoundException: org.ovirt.engine.core.tools
> at org.jboss.modules.Module.addPaths(Module.java:1221)
> at org.jboss.modules.Module.link(Module.java:1577)
> at org.jboss.modules.Module.relinkIfNecessary(Module.java:1605)
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:296)
> at org.jboss.modules.Main.main(Main.java:426)
> {code}
> I haven't found any documentation describing such incompatible between 1.6 and 1.7, so is there any way how to have above execution compatible with both jboss-modules versions?
> Thanks
> Martin
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months