[JBoss JIRA] (DROOLS-1553) Write documentation for the DMN and FEEL components
by Kris Verlaenen (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1553?page=com.atlassian.jira.plugi... ]
Kris Verlaenen updated DROOLS-1553:
-----------------------------------
Sprint: 2017 Week 22-23, 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33, 2017 Week 34-35, 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46 (was: 2017 Week 22-23, 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33, 2017 Week 34-35, 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44)
> Write documentation for the DMN and FEEL components
> ---------------------------------------------------
>
> Key: DROOLS-1553
> URL: https://issues.jboss.org/browse/DROOLS-1553
> Project: Drools
> Issue Type: Task
> Components: dmn engine
> Affects Versions: 7.0.0.CR3
> Reporter: Edson Tirelli
> Assignee: Edson Tirelli
> Fix For: 7.5.0.Final
>
>
> Write the documentation for both FEEL and DMN engines.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (DROOLS-1597) Implement profile for integration with Signavio's DMN modeler
by Kris Verlaenen (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1597?page=com.atlassian.jira.plugi... ]
Kris Verlaenen updated DROOLS-1597:
-----------------------------------
Sprint: 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33, 2017 Week 34-35, 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46 (was: 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33, 2017 Week 34-35, 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44)
> Implement profile for integration with Signavio's DMN modeler
> -------------------------------------------------------------
>
> Key: DROOLS-1597
> URL: https://issues.jboss.org/browse/DROOLS-1597
> Project: Drools
> Issue Type: Enhancement
> Components: dmn engine
> Affects Versions: 7.1.0.Beta2
> Reporter: Edson Tirelli
> Assignee: Edson Tirelli
> Fix For: 7.5.0.Final
>
>
> Signavio implements a number of extensions to the DMN standard. As they are a Red Hat partner, we will need to implement a profile in the runtime engine that enables and supports those extensions.
> A short list of extensions is as follows. Details will be added to individual tickets:
> * Support additional FEEL functions and alternate names for existing functions
> * Support the Multi Instance Decision node
> * Support character '?' for interpolation of values in a DT cell
> * Support constraints on List inputs in DT cells
> * Support model composition through BKMs
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (DROOLS-1946) DMN Editor
by Kris Verlaenen (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1946?page=com.atlassian.jira.plugi... ]
Kris Verlaenen updated DROOLS-1946:
-----------------------------------
Sprint: 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33, 2017 Week 34-35, 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46 (was: 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33, 2017 Week 34-35, 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44)
> DMN Editor
> ----------
>
> Key: DROOLS-1946
> URL: https://issues.jboss.org/browse/DROOLS-1946
> Project: Drools
> Issue Type: Feature Request
> Components: DMN Editor
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Fix For: 7.5.0.Final
>
>
> Place holder for all DMN Editor related activities
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (DROOLS-2103) [Test Scenario] Test Numerical Types
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2103?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2103:
--------------------------------
Description: Prepare Some simple test scenario that will use numerical types like BigDecimal, BigInteger (was: Prepare Some simple test scenario that will use numerical types like BigDecimal, BigInteger, Double, Float.)
> [Test Scenario] Test Numerical Types
> ------------------------------------
>
> Key: DROOLS-2103
> URL: https://issues.jboss.org/browse/DROOLS-2103
> Project: Drools
> Issue Type: Task
> Components: Test Scenarios Editor
> Affects Versions: 7.5.0.Final
> Reporter: Jozef Marko
> Assignee: Jozef Marko
> Fix For: 7.5.0.Final
>
>
> Prepare Some simple test scenario that will use numerical types like BigDecimal, BigInteger
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (SECURITY-983) NameNotFoundException due to policyRegistration -- service jboss.naming.context.java.policyRegistration
by Teresa Miyar (JIRA)
[ https://issues.jboss.org/browse/SECURITY-983?page=com.atlassian.jira.plug... ]
Teresa Miyar closed SECURITY-983.
---------------------------------
Resolution: Duplicate Issue
> NameNotFoundException due to policyRegistration -- service jboss.naming.context.java.policyRegistration
> -------------------------------------------------------------------------------------------------------
>
> Key: SECURITY-983
> URL: https://issues.jboss.org/browse/SECURITY-983
> Project: PicketBox
> Issue Type: Bug
> Components: PicketBox
> Reporter: Teresa Miyar
> Assignee: Stefan Guilhen
>
> "NameNotFoundException due to policyRegistration -- service jboss.naming.context.java.policyRegistration" is recorded in server.log during quickstart example run by changing log level:
> {noformat}
> <logger category="org.jboss.as.security">
> <level name="TRACE"/>
> </logger>
> <logger category="org.jboss.security">
> <level name="TRACE"/>
> </logger>
> {noformat}
> See detailed description in community discussion [#907134|https://developer.jboss.org/message/907134]
> I choose Jira component picketbox since the exception is titled as "PBOX000293: Exception caught: javax.naming.NameNotFoundException"
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (SECURITY-983) NameNotFoundException due to policyRegistration -- service jboss.naming.context.java.policyRegistration
by Teresa Miyar (JIRA)
Teresa Miyar created SECURITY-983:
-------------------------------------
Summary: NameNotFoundException due to policyRegistration -- service jboss.naming.context.java.policyRegistration
Key: SECURITY-983
URL: https://issues.jboss.org/browse/SECURITY-983
Project: PicketBox
Issue Type: Bug
Components: PicketBox
Reporter: Teresa Miyar
Assignee: Stefan Guilhen
"NameNotFoundException due to policyRegistration -- service jboss.naming.context.java.policyRegistration" is recorded in server.log during quickstart example run by changing log level:
{noformat}
<logger category="org.jboss.as.security">
<level name="TRACE"/>
</logger>
<logger category="org.jboss.security">
<level name="TRACE"/>
</logger>
{noformat}
See detailed description in community discussion [#907134|https://developer.jboss.org/message/907134]
I choose Jira component picketbox since the exception is titled as "PBOX000293: Exception caught: javax.naming.NameNotFoundException"
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (JGRP-2218) New payload interface
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/JGRP-2218?page=com.atlassian.jira.plugin.... ]
Dan Berindei edited comment on JGRP-2218 at 11/6/17 8:36 AM:
-------------------------------------------------------------
In general I like implementing an interface better than extending an abstract class, but you're right about the memory savings. Both options should be fine for us.
was (Author: dan.berindei):
In general I like implementing an interface better than extending an abstract class in this case, but you're right about the memory savings. Both options should be fine for us.
> New payload interface
> ---------------------
>
> Key: JGRP-2218
> URL: https://issues.jboss.org/browse/JGRP-2218
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 5.0
>
> Attachments: jgrp-2218.jfr, master.jfr
>
>
> h3. Goal
> Change payload in {{Message}} from byte[] arrays to a {{Payload}} interface which can have multiple implementations.
> h3. Reason
> Currently, having to pass a byte[] array to a message leads to unnecessary copying:
> * When an application has a ref to an NIO (direct) {{ByteBuffer}}, the bytes in the byte buffer have to be copied into a byte[] array and then set in the message
> * When the application sends around byte[] arrays, but also wants to add some additional metadata, e.g. type (1000-byte requests/responses), it needs to create a new byte[] array of (say) 1001 bytes and copy the data (1000 bytes) plus the request type (1 byte) into the new copy. Example: {{MPerf}} and {{UPerf}}
> * When an object has to be sent (e.g. in Infinispan), the object has to be marshalled into a byte[] array (first allocation) and then added to the message. With the suggested {{ObjectPayload}} (below), marshalling of the object would occur late, and it would be marshalled directly into the output stream of the bundler, eliminating the byte[] array allocation made by the application.
> h3. Design
> Instead of copying, the application creates an instance of {{Payload}} and sets the payload in {{Message}}. The {{Payload}} is then passed all the way down into the transport where it is marshalled and sent. There can be a number of payload implementations, e.g.
> * {{ByteArrayPayload}}: wraps a byte[] array with an offset and length
> * {{NioDirectPayload}}: wraps an NIO direct {{ByteBuffer}}
> * {{NioHeapPayload}}: wraps an NIO heap-based {{ByteBuffer}}
> * {{CompositePayload}}: wraps multiple Buffers. E.g. type (1 byte) and data (1000 bytes) as described above
> * {{IntPayload}}: a single integer
> * {{ObjectPayload}}: has an Object and a ClassLoader (for reading), plus a Marshaller which know how to marshal the object, this allows for objects to be passed in payloads and they're only marshalled at the end (transport).
> * {{PartialPayload}}: a ref to a {{Payload}}, with an offset and length
> * {{InputStreamPayload}}: has a ref to an input stream and copies data from input- to output stream when marshalling
> The {{Payload}} interface has methods:
> * {{size()}}
> * {{writeTo(DataOutput)}}
> * {{readFrom(DataInput)}}
> * {{getInput()}}: this provides a {{DataInput}} stream for reading from the underlying payload
> and possibly also
> * {{acquire()}} and
> * {{release()}} (for ref-counting)
> * {{copy()}}
> Each payload impl has an ID and it should be possible to register new impls. A {{PayloadFactory}} maintains a mapping between IDs and impl classes.
> When marshalling a {{Payload}}, the ID is written first, followed by the payload's {{writeTo()}} method. When reading payloads, the {{PayloadFactory}} is used to create instances from IDs.
> h4. Fragmentation
> When fragmenting a buffer, the fragments are instances of {{PartialPayload}} which maintains an offset and length over an underlying payload. When marshalling a {{PartialPayload}}, only the part between offset and offset+length is written to the output stream.
> For fragmentation, method {{size()}} is crucial to determine whether a payload needs to be fragmented, or not. If, for example, a payload (e.g. an {{ObjectPayload}}) cannot determine the correct size, it may return {{-1}}. This leads to the {{ObjectPayload}} getting marshalled right away and getting wrapped into a {{ByteArrayPayload}}. So if {{size()}} cannot be determined, we have exactly the same behavior as what's currently done.
> h4. Reference counting
> If we implement ref-counting, then payloads can be reused as soon as the ref-count is 0. For example, when sending a message, the payload's ref-count could be incremented by the app calling {{acquire()}}. (Assuming the message is a unicast message), {{UNICAST3}} would increment the count to 2. This is needed because {{UNICAST3}} might have to retransmit the message if it was lost on the network, and meanwhile the payload cannot be reused (changed). The app calls {{release()}} when the {{JChannel.send()}} call returns, but the payload cannot be reused until {{UNICAST3}} calls {{release()}} as well. This will happen when an {{ACK}} for the given message has been received.
> h4. Payload factory
> When a request is received, the buffer is created from the bytes received on the network, based on the ID. This should be done by asking a {{PayloadFactory}} component for a new buffer. A naive implementation might create a new buffer every time, but a more sophisticated one might use a pool of payloads.
> The {{PayloadFactory}} instance could be replaced by one's own implementation; this allows for an application to control the lifecycle of payloads: thus the creation of buffers by the application and of payloads received over the network can be controlled by the same payload management impl.
> h4. Symmetry
> When sending a {{CompositePayload}} of a 500 byte {{ByteArrayPayload}} and a 1000 byte {{NioDirectPayload}}, would we want to also get the same {{CompositePayload}} consisting of 2 payloads on the receiver side, or would we want to combine the 2 payloads into one and make the 2 payloads refer to the same combined byte[] array (or NIO buffer)? Should this be made configurable?
> h4. ObjectPayload
> If ObjectPayload cannot determine the size of the serialized data, it should return {{-1}}. This means that {{Message.setPayload(ObjectPayload)}} would right away serialize {{ObjectPayload}} into {{ByteArrayPayload}}.
> This means we do have the {{byte[]}} array creation (same as now), but for object payloads which do implement {{size()}} correctly, we could still do late serialization.
> h5. ObjectPayload and fragmentation
> {{FRAG3}} could decorate {{ObjectPayload}} with a fragmentation payload, which generates fragments on serialization and sends them down the stack.
> h4. Misc
> * Since this issue includes API changes, the version will be 5.0
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-9524) Messaging - default max client threads
by Martyn Taylor (JIRA)
[ https://issues.jboss.org/browse/WFLY-9524?page=com.atlassian.jira.plugin.... ]
Martyn Taylor commented on WFLY-9524:
-------------------------------------
[~mstyk] The client defaults should remain the same. The change required here is specific to the WF use case. This should therefore be configured via the messaging subsystem.
> Messaging - default max client threads
> --------------------------------------
>
> Key: WFLY-9524
> URL: https://issues.jboss.org/browse/WFLY-9524
> Project: WildFly
> Issue Type: Enhancement
> Components: JMS
> Affects Versions: 11.0.0.Final
> Reporter: Martin Styk
> Assignee: Jeff Mesnil
>
> By default, size of client thread pool is configured as 8 * number of CPU cores.
> On 1 CPU machine, with default configuration and MDB deployed on server, resource starvation is possible
> On one CPU there are by default
> * 8 ActiveMQ client threads (8 * CPU count)
> * 4 MDB instances (mdb-strict-max-pool = 4 * CPU count)
> * 15 JCA RA sessions consuming messages from queue (default value of maxSession)
> Consuming of messages by MDB gets stuck because all 8 client threads are awaiting large message completion and there is no other thread to handle other tasks.
> {code:title=Client thread waiting for large message completion}
> "Thread-7 (ActiveMQ-client-global-threads)" #475 daemon prio=5 os_prio=0
> tid=0x000000000590f000 nid=0x7c7a in Object.wait() [0x00007fda43413000]
> java.lang.Thread.State: TIMED_WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at
> org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl.waitCompletion(LargeMessageControllerImpl.java:302)
> - locked <0x00000000b0083e88> (a
> org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl)
> at
> org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl.saveBuffer(LargeMessageControllerImpl.java:276)
> - locked <0x00000000b0083e88> (a
> org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl)
> at
> org.apache.activemq.artemis.core.client.impl.ClientLargeMessageImpl.checkBuffer(ClientLargeMessageImpl.java:159)
> at
> org.apache.activemq.artemis.core.client.impl.ClientLargeMessageImpl.checkCompletion(ClientLargeMessageImpl.java:84)
> at
> org.apache.activemq.artemis.jms.client.ActiveMQMessage.doBeforeReceive(ActiveMQMessage.java:786)
> at
> org.apache.activemq.artemis.jms.client.ActiveMQTextMessage.doBeforeReceive(ActiveMQTextMessage.java:110)
> at
> org.apache.activemq.artemis.ra.inflow.ActiveMQMessageHandler.onMessage(ActiveMQMessageHandler.java:295)
> at
> org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1001)
> at
> org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:49)
> at
> org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1124)
> at
> org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> This can be fixed by adjusting default values for these parameters.
> In this case, we need more client threads than JCA RA sessions (maxSession).
> To avoid resource starvation, number of client threads must be greater than sum of {{maxSession}} for each MDB deployed on server.
> We should check number of client threads required by deployments (MDBs), and at least print warning message that size of client thread pool may be insufficient.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (JGRP-2218) New payload interface
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2218?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2218:
--------------------------------
Yes, they do perform roughly the same amount of work (number of requests in 60s)
> New payload interface
> ---------------------
>
> Key: JGRP-2218
> URL: https://issues.jboss.org/browse/JGRP-2218
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 5.0
>
> Attachments: jgrp-2218.jfr, master.jfr
>
>
> h3. Goal
> Change payload in {{Message}} from byte[] arrays to a {{Payload}} interface which can have multiple implementations.
> h3. Reason
> Currently, having to pass a byte[] array to a message leads to unnecessary copying:
> * When an application has a ref to an NIO (direct) {{ByteBuffer}}, the bytes in the byte buffer have to be copied into a byte[] array and then set in the message
> * When the application sends around byte[] arrays, but also wants to add some additional metadata, e.g. type (1000-byte requests/responses), it needs to create a new byte[] array of (say) 1001 bytes and copy the data (1000 bytes) plus the request type (1 byte) into the new copy. Example: {{MPerf}} and {{UPerf}}
> * When an object has to be sent (e.g. in Infinispan), the object has to be marshalled into a byte[] array (first allocation) and then added to the message. With the suggested {{ObjectPayload}} (below), marshalling of the object would occur late, and it would be marshalled directly into the output stream of the bundler, eliminating the byte[] array allocation made by the application.
> h3. Design
> Instead of copying, the application creates an instance of {{Payload}} and sets the payload in {{Message}}. The {{Payload}} is then passed all the way down into the transport where it is marshalled and sent. There can be a number of payload implementations, e.g.
> * {{ByteArrayPayload}}: wraps a byte[] array with an offset and length
> * {{NioDirectPayload}}: wraps an NIO direct {{ByteBuffer}}
> * {{NioHeapPayload}}: wraps an NIO heap-based {{ByteBuffer}}
> * {{CompositePayload}}: wraps multiple Buffers. E.g. type (1 byte) and data (1000 bytes) as described above
> * {{IntPayload}}: a single integer
> * {{ObjectPayload}}: has an Object and a ClassLoader (for reading), plus a Marshaller which know how to marshal the object, this allows for objects to be passed in payloads and they're only marshalled at the end (transport).
> * {{PartialPayload}}: a ref to a {{Payload}}, with an offset and length
> * {{InputStreamPayload}}: has a ref to an input stream and copies data from input- to output stream when marshalling
> The {{Payload}} interface has methods:
> * {{size()}}
> * {{writeTo(DataOutput)}}
> * {{readFrom(DataInput)}}
> * {{getInput()}}: this provides a {{DataInput}} stream for reading from the underlying payload
> and possibly also
> * {{acquire()}} and
> * {{release()}} (for ref-counting)
> * {{copy()}}
> Each payload impl has an ID and it should be possible to register new impls. A {{PayloadFactory}} maintains a mapping between IDs and impl classes.
> When marshalling a {{Payload}}, the ID is written first, followed by the payload's {{writeTo()}} method. When reading payloads, the {{PayloadFactory}} is used to create instances from IDs.
> h4. Fragmentation
> When fragmenting a buffer, the fragments are instances of {{PartialPayload}} which maintains an offset and length over an underlying payload. When marshalling a {{PartialPayload}}, only the part between offset and offset+length is written to the output stream.
> For fragmentation, method {{size()}} is crucial to determine whether a payload needs to be fragmented, or not. If, for example, a payload (e.g. an {{ObjectPayload}}) cannot determine the correct size, it may return {{-1}}. This leads to the {{ObjectPayload}} getting marshalled right away and getting wrapped into a {{ByteArrayPayload}}. So if {{size()}} cannot be determined, we have exactly the same behavior as what's currently done.
> h4. Reference counting
> If we implement ref-counting, then payloads can be reused as soon as the ref-count is 0. For example, when sending a message, the payload's ref-count could be incremented by the app calling {{acquire()}}. (Assuming the message is a unicast message), {{UNICAST3}} would increment the count to 2. This is needed because {{UNICAST3}} might have to retransmit the message if it was lost on the network, and meanwhile the payload cannot be reused (changed). The app calls {{release()}} when the {{JChannel.send()}} call returns, but the payload cannot be reused until {{UNICAST3}} calls {{release()}} as well. This will happen when an {{ACK}} for the given message has been received.
> h4. Payload factory
> When a request is received, the buffer is created from the bytes received on the network, based on the ID. This should be done by asking a {{PayloadFactory}} component for a new buffer. A naive implementation might create a new buffer every time, but a more sophisticated one might use a pool of payloads.
> The {{PayloadFactory}} instance could be replaced by one's own implementation; this allows for an application to control the lifecycle of payloads: thus the creation of buffers by the application and of payloads received over the network can be controlled by the same payload management impl.
> h4. Symmetry
> When sending a {{CompositePayload}} of a 500 byte {{ByteArrayPayload}} and a 1000 byte {{NioDirectPayload}}, would we want to also get the same {{CompositePayload}} consisting of 2 payloads on the receiver side, or would we want to combine the 2 payloads into one and make the 2 payloads refer to the same combined byte[] array (or NIO buffer)? Should this be made configurable?
> h4. ObjectPayload
> If ObjectPayload cannot determine the size of the serialized data, it should return {{-1}}. This means that {{Message.setPayload(ObjectPayload)}} would right away serialize {{ObjectPayload}} into {{ByteArrayPayload}}.
> This means we do have the {{byte[]}} array creation (same as now), but for object payloads which do implement {{size()}} correctly, we could still do late serialization.
> h5. ObjectPayload and fragmentation
> {{FRAG3}} could decorate {{ObjectPayload}} with a fragmentation payload, which generates fragments on serialization and sends them down the stack.
> h4. Misc
> * Since this issue includes API changes, the version will be 5.0
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months