[JBoss JIRA] (DROOLS-5200) Enumeration types are "dirty" when opened (without making changes)
by Michael Anstis (Jira)
[ https://issues.redhat.com/browse/DROOLS-5200?page=com.atlassian.jira.plug... ]
Michael Anstis moved JBPM-9079 to DROOLS-5200:
----------------------------------------------
Project: Drools (was: jBPM)
Key: DROOLS-5200 (was: JBPM-9079)
Issue Type: Bug (was: Feature Request)
Component/s: Enumerations Editor
(was: Console)
Affects Version/s: 7.35.0.Final
(was: 7.35.0.Final)
QE Assignee: Jozef Marko
> Enumeration types are "dirty" when opened (without making changes)
> ------------------------------------------------------------------
>
> Key: DROOLS-5200
> URL: https://issues.redhat.com/browse/DROOLS-5200
> Project: Drools
> Issue Type: Bug
> Components: Enumerations Editor
> Affects Versions: 7.35.0.Final
> Reporter: Tihomir Surdilovic
> Assignee: Eder Ignatowicz
> Priority: Major
> Labels: drools-tools
> Attachments: Screen Shot 2020-03-26 at 10.29.31 PM.png
>
>
> Open existing enumeration type in BC
> Close it
> Popup shows asking if you want to save changes
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-4746) UX for DMN "quick test" tool
by Edson Tirelli (Jira)
[ https://issues.redhat.com/browse/DROOLS-4746?page=com.atlassian.jira.plug... ]
Edson Tirelli commented on DROOLS-4746:
---------------------------------------
That is correct Guilherme, provide inputs, and see the results.
> UX for DMN "quick test" tool
> ----------------------------
>
> Key: DROOLS-4746
> URL: https://issues.redhat.com/browse/DROOLS-4746
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Elizabeth Clayton
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: UX, UXTeam, drools-tools
>
> As a DMN author, I'd like to probe the DMN model during the authoring phase without leaving the DMN Editor. Actually, it's really important to explore the DMN model to understand with values are required by the test.
> When the user run the test he can get back the results of the DMN execution.
> Moreover, it would be handy to add those input/output to an existing (or new) test scenario.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13077) Support protostream-based marshalling of user objects
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-13077?page=com.atlassian.jira.plugi... ]
Paul Ferraro updated WFLY-13077:
--------------------------------
Component/s: Clustering
> Support protostream-based marshalling of user objects
> -----------------------------------------------------
>
> Key: WFLY-13077
> URL: https://issues.redhat.com/browse/WFLY-13077
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
>
> Currently, WildFly uses JBoss Marshalling to marshal user objects (session attributes, SFSB instances) for the purposes of replication and persistence.
> Protostream (developed by the Infinispan team) offers several advantages over JBoss Marshalling.
> * Lower memory footprint (marshalling schemas are built during compilation time)
> * Faster marshalling - as it does not rely on reflection
> * Produces generally smaller replication payloads (see https://docs.google.com/spreadsheets/d/1f6FlXqxX7dYm44naHZfqLc5TjqlmscIdG... )
> * Resolves security concerns due to JBM's reliance on reflection and Java serialization inherently permitting arbitrary execution of rogue code
> * JBoss Marshalling is effectively in maintenance mode
> We can either auto-detect the intended marshaller by looking for requisite SerializationContextInitializers in the deployment classpath, and/or use an explicit configuration attribute.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13296) Allow distributable deployments to leverage ProtoStream to marshal distributable objects
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-13296?page=com.atlassian.jira.plugi... ]
Paul Ferraro closed WFLY-13296.
-------------------------------
Resolution: Duplicate Issue
Duplicate of WFLY-13077.
> Allow distributable deployments to leverage ProtoStream to marshal distributable objects
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-13296
> URL: https://issues.redhat.com/browse/WFLY-13296
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 19.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
>
> EAP currently uses JBoss Marshalling to serialize user objects (e.g. HttpSession attributes, SFSB instances, JPA entity keys, CommandDispatcher commands, etc.).
> JBoss Marshalling is convenient, as it follows roughly the same usage semantics as Java Serialization. Consequently, it suffers from the same security concerns as Java Serialization, specifically:
> https://cwe.mitre.org/data/definitions/502.html
> https://docs.oracle.com/javase/6/docs/platform/serialization/spec/securit...
> ProtoStream (https://github.com/infinispan/protostream), which is now the default marshalling framework used by Infinispan since RHDG 8, offers an alternative to JBoss Marshalling, with some attractive advantages:
> * Invulnerable to arbitrary code execution during unmarshalling
> * Reduced memory footprint during marshalling/unmarshalling
> * Marginally smaller replication/persistence payload sizes (in general)
> This RFE seeks to allow users to use ProtoStream for marshalling of distributable objects. This will require:
> * The org.infinispan.protostream module to be public and exported to user deployments
> * Instructions for developers on how to generate protobuf schemas for their distributable objects
> * A mechanism for determining the user's intention to use ProtoStream instead of JBoss Marshalling.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13077) Support protostream-based marshalling of user objects
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-13077?page=com.atlassian.jira.plugi... ]
Paul Ferraro reassigned WFLY-13077:
-----------------------------------
Assignee: Paul Ferraro
> Support protostream-based marshalling of user objects
> -----------------------------------------------------
>
> Key: WFLY-13077
> URL: https://issues.redhat.com/browse/WFLY-13077
> Project: WildFly
> Issue Type: Feature Request
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
>
> Currently, WildFly uses JBoss Marshalling to marshal user objects (session attributes, SFSB instances) for the purposes of replication and persistence.
> Protostream (developed by the Infinispan team) offers several advantages over JBoss Marshalling.
> * Lower memory footprint (marshalling schemas are built during compilation time)
> * Faster marshalling - as it does not rely on reflection
> * Produces generally smaller replication payloads (see https://docs.google.com/spreadsheets/d/1f6FlXqxX7dYm44naHZfqLc5TjqlmscIdG... )
> * Resolves security concerns due to JBM's reliance on reflection and Java serialization inherently permitting arbitrary execution of rogue code
> * JBoss Marshalling is effectively in maintenance mode
> We can either auto-detect the intended marshaller by looking for requisite SerializationContextInitializers in the deployment classpath, and/or use an explicit configuration attribute.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13295) REST-AT inbound bridge is not activated for EJB without TransactionalManagement annotation
by Ondrej Chaloupka (Jira)
[ https://issues.redhat.com/browse/WFLY-13295?page=com.atlassian.jira.plugi... ]
Ondrej Chaloupka commented on WFLY-13295:
-----------------------------------------
The fix consists of two parts. One in Narayana (https://github.com/jbosstm/narayana/pull/1573), the second of the same fashin in the WFLY rts subsystem (https://github.com/ochaloup/wildfly/commit/c282cb5ebcaad776719e9ea236b791...)
> REST-AT inbound bridge is not activated for EJB without TransactionalManagement annotation
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-13295
> URL: https://issues.redhat.com/browse/WFLY-13295
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 19.0.0.Final
> Reporter: Ondrej Chaloupka
> Assignee: Ondrej Chaloupka
> Priority: Major
>
> The REST-AT inbound bridge is activated per deployment. It's activated for a deployment which contains a REST endpoint identified with `@Path` annotation where in the same class has to be included either annotation `@Transactional` or `@TransactionAttribute`.
> The point is to activate the inbound bridge for deployments which contain a transactional managed method (CDI or EJB) which can receive the txn context, ie. possibly a context of REST-AT transaction as well.
> The issue is that EJB beans are transactional by default. The EJB bean class does not need to specify any `@TransactionalAttribute` to be already container managed (from txn perspective) with attribute `REQUIRED`. Which means taking incoming txn context and will work with it.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-5038) Create testing webapp module
by Anna Dupliak (Jira)
[ https://issues.redhat.com/browse/DROOLS-5038?page=com.atlassian.jira.plug... ]
Anna Dupliak updated DROOLS-5038:
---------------------------------
Description:
This is a module for testing / debugging purposes.
h2. Acceptance criteria
- Readme file with description of the module and command for its running is created
- GWT development mode is available and Koglito webapp could be launched in browser using it
was:
h2. Acceptance citeria
- Readme file with description of the module and command for its running is created
> Create testing webapp module
> ----------------------------
>
> Key: DROOLS-5038
> URL: https://issues.redhat.com/browse/DROOLS-5038
> Project: Drools
> Issue Type: Sub-task
> Components: Scenario Simulation and Testing
> Reporter: Yeser Amer
> Assignee: Yeser Amer
> Priority: Major
> Labels: drools-tools, kogito-tooling
>
> This is a module for testing / debugging purposes.
> h2. Acceptance criteria
> - Readme file with description of the module and command for its running is created
> - GWT development mode is available and Koglito webapp could be launched in browser using it
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (JGRP-2462) TransferQueueBundler: drop messages if queue is full
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2462?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2462:
--------------------------------
{quote}
Wouldn't you also have to implement explicit congestion notification as well, at least from the transport to xFC, for RED/Blue to work?
{quote}
This could quickly become too complex... The xFC protocol at the sender still subtracts the credits for a message M even if M ends up getting dropped by RED, so when the sender runs out of credits, it will block until new credits have been received. This is similar to TCP in which dropped packets slow down the sender.
{quote}
Also, would you have a single RED/Blue instance or all the members, or would each member get a separate instance, so that when a node is really slow, messages can still be sent normally to other nodes? I was thinking of JGRP-2463 and the coordinator having more load with RELAY2.
{quote}
For now, I'll experiment with a single {{RED}} instance for _all_ members.
> TransferQueueBundler: drop messages if queue is full
> ----------------------------------------------------
>
> Key: JGRP-2462
> URL: https://issues.redhat.com/browse/JGRP-2462
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.2.2, 5.0.0.Alpha4
>
>
> When a bundler (like {{TransferQueueBundler}}) has a full queue, the senders will block.
> This can happen for example when the TCP {{send}} blocks due to a full send-window.
> Retransmission requests and responses compound the problem when the TQB's queue is full.
> Therefore, in addition to blocking, we should add an option to _drop_ packets when the queue is full. Investigate whether we could use some priority based scheme, which drops non-important messages first.
> Also investigate whether senders can selectively be unblocked when the queue is full, to either drop or add their messages. This could be done for example by removing elements from the queue, using the aformentioned filter.
> Look at random early detection )\[1\]) for inspiration.
> \[1\] https://en.wikipedia.org/wiki/Random_early_detection
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month