[JBoss JIRA] (WFLY-10339) Broadcast/discovery-group resources have ambiguous requirement specs
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFLY-10339?page=com.atlassian.jira.plugin... ]
Alexey Loubyansky commented on WFLY-10339:
------------------------------------------
[~jmesnil] do you think it'll be ok to fix it for WF14?
> Broadcast/discovery-group resources have ambiguous requirement specs
> --------------------------------------------------------------------
>
> Key: WFLY-10339
> URL: https://issues.jboss.org/browse/WFLY-10339
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 12.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Jeff Mesnil
>
> Currently, the broadcast/discovery-group resources have messy requirement specs, as the capabilities that they require are dependent whether or not the jgroups-cluster attribute is defined.
> I suggest splitting these resources into 2:
> {code}/subsystem=messaging-activemq/server=*/jgroups-broadcast-group=*{code}
> {code}/subsystem=messaging-activemq/server=*/jgroups-discovery-group=*{code}
> which requires clustering capabilities
> and
> {code}/subsystem=messaging-activemq/server=*/socket-broadcast-group=*{code}
> {code}/subsystem=messaging-activemq/server=*/socket-discovery-group=*{code}
> which requires a socket-binding capability.
> This results in clearer requirement specs - which helps simplify the introspection of this subsystem for provisioning purposes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-8954) Wildfly 10 with eclipselink Onscucess observer gets stale entity
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.... ]
Nuno Godinho de Matos commented on WFLY-8954:
---------------------------------------------
Hi Scott,
Of course.
Please feel free to make use the full request.
In full or in part. Whatever is considered to have some use.
Kindest regards.
> Wildfly 10 with eclipselink Onscucess observer gets stale entity
> ----------------------------------------------------------------
>
> Key: WFLY-8954
> URL: https://issues.jboss.org/browse/WFLY-8954
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Nuno Godinho de Matos
> Assignee: Scott Marlow
>
> Hi,
> In widlfly there seems to be an important issue concerning CDI events and observing these events during onsuccess. At least while using eclipselink.
> When using wildfly 10.0.0.Final together with eclipselink, if an application modifies an entity A, fires an event stating entity A has been modified, and an observer consumes this event during transaction success.
> Then the observer will be working with stale entities that do not reflect the modifications done to the entity.
> A sample application for this issue is available in:
> https://github.com/99sono/wildfly10-observe-on-success-stale-entity
> The widlfly configuration xml for the sample application, is available in the application itself, as can be seen in the readme documentation.
> Many thanks for taking a look.
> Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (DROOLS-2744) [DMN Designer] Global diagram properties
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2744?page=com.atlassian.jira.plugi... ]
Jozef Marko commented on DROOLS-2744:
-------------------------------------
Thanks for comments [~manstis] [~roger600] . I just want to clarify this jira. I was not sure what given (Dimensions, Font, Background) properties should affect when no node is selected. They seemed to me to be shown just by mistake. So I proposed to hide them. But sure, if there is already some logic behind them we can investigate it more.
Please let me know:
- Are we going to hide them?
- Are we going to investigate more? Who?
> [DMN Designer] Global diagram properties
> ----------------------------------------
>
> Key: DROOLS-2744
> URL: https://issues.jboss.org/browse/DROOLS-2744
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.9.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Minor
> Labels: drools-tools
>
> The global diagram properties for DMN diagram contains sections settings for:
> - dimensions
> - backround
> - font
> However change of any of them (globally, for the whole diagram) doesn't seem to affect particular nodes somehow. We should hide these settings or implement the logic that would affect all nodes in diagram by change on this place.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-8954) Wildfly 10 with eclipselink Onscucess observer gets stale entity
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.... ]
Nuno Godinho de Matos edited comment on WFLY-8954 at 7/18/18 2:10 AM:
----------------------------------------------------------------------
Hi Scott,
Of course I agree to the mi-license agreement.
Please feel free to make use the full request.
In full or in part. Whatever is considered to have some use.
Kindest regards.
was (Author: nuno.godinhomatos):
Hi Scott,
Of course.
Please feel free to make use the full request.
In full or in part. Whatever is considered to have some use.
Kindest regards.
> Wildfly 10 with eclipselink Onscucess observer gets stale entity
> ----------------------------------------------------------------
>
> Key: WFLY-8954
> URL: https://issues.jboss.org/browse/WFLY-8954
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Nuno Godinho de Matos
> Assignee: Scott Marlow
>
> Hi,
> In widlfly there seems to be an important issue concerning CDI events and observing these events during onsuccess. At least while using eclipselink.
> When using wildfly 10.0.0.Final together with eclipselink, if an application modifies an entity A, fires an event stating entity A has been modified, and an observer consumes this event during transaction success.
> Then the observer will be working with stale entities that do not reflect the modifications done to the entity.
> A sample application for this issue is available in:
> https://github.com/99sono/wildfly10-observe-on-success-stale-entity
> The widlfly configuration xml for the sample application, is available in the application itself, as can be seen in the readme documentation.
> Many thanks for taking a look.
> Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (JBEE-195) API requires more privileged blocks when Security Manager is enabled
by R Searls (JIRA)
R Searls created JBEE-195:
-----------------------------
Summary: API requires more privileged blocks when Security Manager is enabled
Key: JBEE-195
URL: https://issues.jboss.org/browse/JBEE-195
Project: JBoss JavaEE Spec APIs
Issue Type: Bug
Components: jboss-jaxrs-api
Affects Versions: jboss-jaxrs-api_2.1 1.0.0.Alpha2
Reporter: R Searls
Assignee: R Searls
Priority: Minor
Resteasy testsuite requires classLoader permission for nearly every test.
Adding several security blocks will resolve this need.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10703) Upgrade to Galleon and WildFly Galleon Plugins 2.0.0.Alpha4
by Alexey Loubyansky (JIRA)
Alexey Loubyansky created WFLY-10703:
----------------------------------------
Summary: Upgrade to Galleon and WildFly Galleon Plugins 2.0.0.Alpha4
Key: WFLY-10703
URL: https://issues.jboss.org/browse/WFLY-10703
Project: WildFly
Issue Type: Component Upgrade
Components: Build System
Reporter: Alexey Loubyansky
Assignee: Alexey Loubyansky
Galleon 2.x is the version branch which is going to be exposed as a supported external tool for provisioning, updates and patching.
The main difference to Galleon 1.x that it brings into WildFly build process is it is based on different format for expressing feature-pack locations than Maven coordinates and uses a resolution mechanism to resolve feature-pack artifacts, which is the base for version updates and patches discovery.
There is still a way to provide Maven coordinates for feature-packs and avoid going through the default feature-pack resolution mechanism.
Another feature it brings in and which appears in wildfly feature-pack configs is proper transitive dependency customizations.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (DROOLS-2592) PMML - tests in class ScorecardReasonCodeTest fail randomly
by Lance Leverich (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2592?page=com.atlassian.jira.plugi... ]
Lance Leverich commented on DROOLS-2592:
----------------------------------------
After coming up with a script (see test.sh above) that
# would execute the tests over and over
# and would save...
* Generated PMML
* DRL and Java classes generated directly from the PMML
* Java classes generated from the generated DRL
* Output of the maven command
I have concluded that this must be a race condition of some sort. If you compare the directories in the two attached zip files, you will find that the only differences in the generated files (excepting the output.log which is the maven output) are related to time stamps. The output.log files differ in the amount of time spent executing various tests, and of course in the results of the ScorecardReasonTest.
I believe that failures caused by this kind of "race condition" are most likely due to some rules having the same salience, and then the consequences of those rules being applied in a semi-arbitrary manner. This presents me with the opportunity to more thoroughly go through the generated rules to look for when this kind of issue would be able to occur.
Please let me know if you have any thoughts on my reasoning here, or suggestions as to how I might approach this more effectively.
> PMML - tests in class ScorecardReasonCodeTest fail randomly
> -----------------------------------------------------------
>
> Key: DROOLS-2592
> URL: https://issues.jboss.org/browse/DROOLS-2592
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.7.0.Final
> Reporter: Tibor Zimányi
> Assignee: Lance Leverich
> Priority: Critical
> Attachments: results_bad.zip, results_good.zip, test.sh
>
>
> When the ScorecardReasonCodeTest.testPointsBelow is run repeatedly, it sometimes fail with following assertion fail [1]. Setting this as critical, because the random fail causes build problems in the CI environment. Same applies for testPointsAbove, testReasonCodesCombination and probably others (I tested those 3 mentioned).
> [1] https://gist.github.com/baldimir/4c8ac4563fd17d13e4646fd60dd3a357
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years