[JBoss JIRA] (WFCORE-3867) Space char always last char of read system property on Windows
by R Searls (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3867?page=com.atlassian.jira.plugi... ]
R Searls commented on WFCORE-3867:
----------------------------------
This jira is related to the other in that the error is seen when running appclient.ps1 testcases from jbossws-cxf
> Space char always last char of read system property on Windows
> --------------------------------------------------------------
>
> Key: WFCORE-3867
> URL: https://issues.jboss.org/browse/WFCORE-3867
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Affects Versions: 5.0.0.Beta4
> Reporter: R Searls
> Assignee: R Searls
> Priority: Minor
>
> On Windows each system property read has a space char as the last char of string.
> This causes failures when the property represents a directory name. Calling
> tmp.toPath().toRealPath() in this situation.
> ServerEnvironment line, 434 Path resolved = tmp.toPath().toRealPath();
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFCORE-1649) RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1649?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1649:
-------------------------------------
Fix Version/s: 5.0.0.Beta5
(was: 5.0.0.Beta4)
> RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1649
> URL: https://issues.jboss.org/browse/WFCORE-1649
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Critical
> Labels: domain-mode
> Fix For: 5.0.0.Beta5
>
>
> The management model for RBAC constraints is maintained using synthetic resources, with resources only existing for those items (SensitivityClassification and ApplicationClassification) that are registered in the current process. Operations that touch classifications unknown to that process will fail due to missing resource problems.
> This is a big problem in the following scenarios:
> 1) Mixed domain, where legacy slaves do not know about newly introduced classifications.
> 2) Slimming scenarios where slaves are ignoring unrelated parts of the domain wide config and also don't have some extension installed, resulting in classifications registered by those extensions not being present.
> A partial workaround to 1) is for the kernel to register transformers for newly introduced classifications (e.g. SERVER_SSL added in EAP 6.4.7 and EAP 7). But:
> -- that doesn't help with problem 2)
> -- only the kernel can register kernel transformers, so if extensions add new classifications there is no way for them to register the transformer.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFCORE-3867) Space char always last char of read system property on Windows
by R Searls (JIRA)
R Searls created WFCORE-3867:
--------------------------------
Summary: Space char always last char of read system property on Windows
Key: WFCORE-3867
URL: https://issues.jboss.org/browse/WFCORE-3867
Project: WildFly Core
Issue Type: Bug
Components: Server
Affects Versions: 5.0.0.Beta4
Reporter: R Searls
Assignee: R Searls
Priority: Minor
On Windows each system property read has a space char as the last char of string.
This causes failures when the property represents a directory name. Calling
tmp.toPath().toRealPath() in this situation.
ServerEnvironment line, 434 Path resolved = tmp.toPath().toRealPath();
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFCORE-3806) Eliminate code that was using transitive MSC dependencies
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3806?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3806:
-------------------------------------
Fix Version/s: 5.0.0.Beta5
(was: 5.0.0.Beta4)
> Eliminate code that was using transitive MSC dependencies
> ---------------------------------------------------------
>
> Key: WFCORE-3806
> URL: https://issues.jboss.org/browse/WFCORE-3806
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Server
> Reporter: Richard Opalka
> Assignee: Richard Opalka
> Fix For: 5.0.0.Beta5
>
>
> Prior MSC 1.2.8 stability monitors were reporting problems if
> some transitive dependency wasn't available. This has changed
> since MSC 1.2.8. There is no notion of transitive
> dependencies in JBoss MSC anymore. If stability monitor detects
> a problem it is always immediate dependency of monitored controller.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (DROOLS-2569) [DMN Designer] Marshalling of magnet positions
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2569?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-2569:
----------------------------------------
[~roger600] Hi, not sure it helps on it's own!
However I see BPMN uses "waypoints" to define connector end-points (and others for presumably orthogonal lines).
{code}
<bpmndi:BPMNEdge id="_tGgC5Vj0EeiASpIQ4UhanA" bpmnElement="_15A3A674-931B-4285-9F3C-91F2DB5B7EC2" sourceElement="_tGgC4lj0EeiASpIQ4UhanA" targetElement="_tGgC41j0EeiASpIQ4UhanA">
<di:waypoint xsi:type="dc:Point" x="128.0" y="128.0"/>
<di:waypoint xsi:type="dc:Point" x="313.0" y="128.0"/>
</bpmndi:BPMNEdge>
{code}
I assume we'd need to also store the "waypoints" and use them when unmarshalling.
Do you recall whether the "snap to closest magnet" is "Stunner" or specific to the BPMN marshaller?
> [DMN Designer] Marshalling of magnet positions
> ----------------------------------------------
>
> Key: DROOLS-2569
> URL: https://issues.jboss.org/browse/DROOLS-2569
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Reporter: Michael Anstis
> Assignee: Matteo Mortari
>
> When attaching connectors to different magnets (other than "centre") re-opening a DMN diagram resets connections to the "centre" magnet. IDK if this is an issue with writing magnet positions to the XML or recreating the connections from the XML.
> [~tari_manga] could you please liaise with [~roger600] to understand where the issue is?
> h2. PR Acceptance test
> In DMN Designer, change magnet position in:
> - Source node
> -- BKM, BKS, Decision, Input
> - Target node
> -- BKM, BKS, Decision, Annotation
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month