[JBoss JIRA] (DROOLS-4907) DMN FunctionDefinition parameter not trimmed by editor
by Michael Anstis (Jira)
[ https://issues.redhat.com/browse/DROOLS-4907?page=com.atlassian.jira.plug... ]
Michael Anstis updated DROOLS-4907:
-----------------------------------
Description:
Parameter are not trimmed by the editor
!image-2020-01-07-17-19-25-638.png|thumbnail!
h3. Acceptance criteria
- Add a parameter and before dismissing the dialog add spaces to it's start/end. Press tab.
-- The view should update to show the trimmed name.
-- Undoing the add parameter should remove the parameter.
-- Redoing should add it back.
- Add a parameter and dismiss dialog
- Edit parameters and add spaces to the start/end of the parameters name. Press tab.
-- The view should update to show the trimmed name.
-- Undoing the add parameter should remove the parameter.
-- Redoing should add it back.
- Edit parameters and change the parameters name. Press tab.
-- The view should update to show the new name.
-- Undoing the name change should restore the original name.
-- Redoing should restore the changed name.
- Add a parameter. Dismiss the dialog.
-- Undo should remove parameter. Redoing should add it back with the same name.
was:
Parameter are not trimmed by the editor
!image-2020-01-07-17-19-25-638.png|thumbnail!
h3. Acceptance criteria
- Add a parameter and before dismissing the dialog add spaces to it's start/end. Press tab.
-- The view should update to show the trimmed name.
-- Undoing the add parameter should remove the parameter.
-- Redoing should add it back.
- Add a parameter and dismiss dialog
- Edit parameters and add spaces to the start/end of the parameters name. Press tab.
-- The view should update to show the trimmed name.
-- Undoing the add parameter should remove the parameter.
-- Redoing should add it back.
- Add a parameter. Dismiss the dialog.
-- Undo should remove parameter. Redoing should add it back with the same name.
> DMN FunctionDefinition parameter not trimmed by editor
> ------------------------------------------------------
>
> Key: DROOLS-4907
> URL: https://issues.redhat.com/browse/DROOLS-4907
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Reporter: Matteo Mortari
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
> Attachments: image-2020-01-07-17-19-25-638.png
>
>
> Parameter are not trimmed by the editor
> !image-2020-01-07-17-19-25-638.png|thumbnail!
> h3. Acceptance criteria
> - Add a parameter and before dismissing the dialog add spaces to it's start/end. Press tab.
> -- The view should update to show the trimmed name.
> -- Undoing the add parameter should remove the parameter.
> -- Redoing should add it back.
> - Add a parameter and dismiss dialog
> - Edit parameters and add spaces to the start/end of the parameters name. Press tab.
> -- The view should update to show the trimmed name.
> -- Undoing the add parameter should remove the parameter.
> -- Redoing should add it back.
> - Edit parameters and change the parameters name. Press tab.
> -- The view should update to show the new name.
> -- Undoing the name change should restore the original name.
> -- Redoing should restore the changed name.
> - Add a parameter. Dismiss the dialog.
> -- Undo should remove parameter. Redoing should add it back with the same name.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months
[JBoss JIRA] (DROOLS-4912) DMN Data type editor - inline add action button.
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-4912?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-4912:
--------------------------------
Affects Version/s: 7.31.0.Final
> DMN Data type editor - inline add action button.
> -------------------------------------------------
>
> Key: DROOLS-4912
> URL: https://issues.redhat.com/browse/DROOLS-4912
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.31.0.Final
> Reporter: Elizabeth Clayton
> Assignee: Guilherme Gomes
> Priority: Minor
> Labels: UX, drools-tools
> Attachments: Screen Shot 2020-01-08 at 7.06.20 PM.png
>
>
> Change the behavior and tooltip for the inline add icon-button (+). Currently it converts the type to Structure before adding a row below. Instead, we want it to add another row without converting the type.
> Acceptance criteria:
> *Tooltip: "Add row below (Ctrl + B)"
> Behavior - Clicking the (+) inline add button:
> * from a type defined as Structure, will add a field row below.
> * from a Field row (within a Structure), will add another field row below.
> * from a Simple type, such as "Person(string)", will add another row of the same type below.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months
[JBoss JIRA] (JGRP-2432) Use maven release plugin
by Bela Ban (Jira)
Bela Ban created JGRP-2432:
------------------------------
Summary: Use maven release plugin
Key: JGRP-2432
URL: https://issues.redhat.com/browse/JGRP-2432
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 5.1
For releases, switch to the mvn-release plugin.
This should simplify releasing a new version and entails
* Updating the POM and ivy.xml (?)
* Updating the version in all the sample config files
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months
[JBoss JIRA] (DROOLS-4912) DMN Data type editor - inline add action button.
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-4912?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-4912:
--------------------------------
Description:
Change the behavior and tooltip for the inline add icon-button (+). Currently it converts the type to Structure before adding a row below. Instead, we want it to add another row without converting the type.
Acceptance criteria:
* Tooltip: "Add row below (Ctrl + B)"
Behavior - Clicking the (+) inline add button:
* from a type defined as Structure, will add a field row below.
* from a Field row (within a Structure), will add another field row below.
* from a Simple type, such as "Person(string)", will add another row of the same type below.
was:
Change the behavior and tooltip for the inline add icon-button (+). Currently it converts the type to Structure before adding a row below. Instead, we want it to add another row without converting the type.
Acceptance criteria:
*Tooltip: "Add row below (Ctrl + B)"
Behavior - Clicking the (+) inline add button:
* from a type defined as Structure, will add a field row below.
* from a Field row (within a Structure), will add another field row below.
* from a Simple type, such as "Person(string)", will add another row of the same type below.
> DMN Data type editor - inline add action button.
> -------------------------------------------------
>
> Key: DROOLS-4912
> URL: https://issues.redhat.com/browse/DROOLS-4912
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.31.0.Final
> Reporter: Elizabeth Clayton
> Assignee: Guilherme Gomes
> Priority: Minor
> Labels: UX, drools-tools
> Attachments: Screen Shot 2020-01-08 at 7.06.20 PM.png
>
>
> Change the behavior and tooltip for the inline add icon-button (+). Currently it converts the type to Structure before adding a row below. Instead, we want it to add another row without converting the type.
> Acceptance criteria:
> * Tooltip: "Add row below (Ctrl + B)"
> Behavior - Clicking the (+) inline add button:
> * from a type defined as Structure, will add a field row below.
> * from a Field row (within a Structure), will add another field row below.
> * from a Simple type, such as "Person(string)", will add another row of the same type below.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months
[JBoss JIRA] (JGRP-2285) ObjectMessage: handle objects with incorrect size
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2285?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2285:
---------------------------
Fix Version/s: 5.1
(was: 5.0)
> ObjectMessage: handle objects with incorrect size
> -------------------------------------------------
>
> Key: JGRP-2285
> URL: https://issues.redhat.com/browse/JGRP-2285
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.1
>
>
> An ObjectMessage accepts objects of type SizeStreamable. When such an object has an incorrect serializableSize() method, the following can happen:
> * Say the serialized size is 1000, but serializedSize() returns 1200
> * When the ObjectMessage is serialized, a length of 1200 is written, but then only 1000 bytes are serialized onto the output stream
> * On the receiving side, length=1200 is read and a byte array of 1200 is created
> * DataInput.readFully() reads 1000 bytes, but then reaches the eof of the stream, trying to read an additional 200 bytes
> * An exception is thrown and the reading of the message fails
> If we caught the exception, things would work, however this would mask other errors in the object serialization/deserialization code.
> If the serilization code was able to mark the position of the output stream, then we could write the *actual number of bytes written* (especially if it differs from serializedSize()); however, DataOutput doesn't give us this option!
> Investigate whether simply catching (and ignoring) the EOFException would work.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months
[JBoss JIRA] (JGRP-2289) FRAG4: handle ObjectMessage whose size() method is incorrect
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2289?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2289:
---------------------------
Fix Version/s: 5.1
(was: 5.0)
> FRAG4: handle ObjectMessage whose size() method is incorrect
> ------------------------------------------------------------
>
> Key: JGRP-2289
> URL: https://issues.redhat.com/browse/JGRP-2289
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.1
>
>
> When an ObjectMessage has a {{SizeStreamable}} object whose size() returns more bytes than are actually written, {{FRAG4}} will block on reading of the last fragment. Example: size() returns 27 bytes (LENGTH), but we only write 20 bytes, then {{readFully()}} (used to read the fragments) will throw an exception (EOF, IIRC).
> To fix this, {{FragmentedMessage.writeTo()}} could do the following:
> * Check if DataOutput is of type ByteArrayDataOutputStream. This is almost always the case as this is used on the bundler base class. If not -> use the current code path
> * Remember the current position
> * Write LENGTH bytes (27 in the example above)
> * Call obj.writeTo(out)
> * If the current position is *not* equal to the remembered position + LENGTH:
> ** Position the output stream back to the remembered position and write the correct length ACTUAL bytes (20) as an int
> Obviously, this only works for DataOutput implementations that support position(), but with most bundlers using ByteArrayDataOutputStream, this should be the case most of the time.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months
[JBoss JIRA] (JGRP-2417) Ref-counting for messages
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2417?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2417:
---------------------------
Fix Version/s: 5.1
(was: 5.0)
> Ref-counting for messages
> -------------------------
>
> Key: JGRP-2417
> URL: https://issues.redhat.com/browse/JGRP-2417
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.1
>
>
> When users do their own memory management, the message passed to {{Channel.send()}} might have a reference to a memory area that's allocated from a pool, and that needs to be returned when done.
> However, the return of a {{Channel.send()}} call does not necessarily mean that the memory area can be reused. If, for example, NAKACK2 or UNICAST3 have the message in their retransmission tables (to potentially retransmit it), then the memory cannot be reused until that message has been purged from the retransmission table.
> Add a reference-counting mechanism to {{Message}} (implemented in {{BaseMessage}}) that allows NAKACK2 or UNICAST3 to increment a ref-count. When a message is purged from the retransmission table, decrement its ref-count. When the ref-count is 0, a callback could be called. The callback could for example return the associated memory chunk back to the memory pool.
> This could possibly be a trait, with a no-op implementation as default. This could be overwritten, ie.
> {code:java}
> Message release() {
> if(refcount <= 0)
> // give associated memory area back to pool
> }
> {code}
> See if this needs to be integrated with {{MessageFactory}} as well.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months
[JBoss JIRA] (JGRP-2230) Multiple discovery protocols without MULTI_PING
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2230?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2230:
---------------------------
Fix Version/s: 5.1
(was: 5.0)
> Multiple discovery protocols without MULTI_PING
> -----------------------------------------------
>
> Key: JGRP-2230
> URL: https://issues.redhat.com/browse/JGRP-2230
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.1
>
>
> Currently, {{MULTI_PING}} is needed to forward discovery requests to multiple discovery protocols. If we change the API in 5.0, and pass a {{Responses}} object down to the discovery protocols, and each discovery protocol forwards discovery requests down (and responses up), and they all add responses to the same {{Responses}} object, then we would not need {{MULTI_PING}} any longer.
> However, this is an API change, so can be done only in 5.0.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months