[JBoss JIRA] (DROOLS-5119) [Guided Rule Editor] Workbench BigDecimal value turns into 0.0 in DRL
by Bhala Hadkar (Jira)
[ https://issues.redhat.com/browse/DROOLS-5119?page=com.atlassian.jira.plug... ]
Bhala Hadkar updated DROOLS-5119:
---------------------------------
Description:
When I set up a Guided rule on Workbench having a comparison condition on one of the domain field of type Big Decimal then the int value entered through literal text disappears and turns into 0.0B.
For e.g. if you look at this Guided Rule screenshot the literal value 100 turned into 0.0.
!Workbench-Guided-Rule.png|thumbnail!
Also in the drools the value becomes 0.0B.
!drools.png|thumbnail!
was:
When I set up a Guided rule on Workbench having a comparison condition on one of the domain field of type int then the int value entered through literal text disappears and turns into 0.0B.
For e.g. if you look at this Guided Rule screenshot the literal value 100 turned into 0.0.
!Workbench-Guided-Rule.png|thumbnail!
Also in the drools the value becomes 0.0B.
!drools.png|thumbnail!
> [Guided Rule Editor] Workbench BigDecimal value turns into 0.0 in DRL
> ---------------------------------------------------------------------
>
> Key: DROOLS-5119
> URL: https://issues.redhat.com/browse/DROOLS-5119
> Project: Drools
> Issue Type: Bug
> Components: Examples (Workbench), Guided Rule Editor
> Affects Versions: 7.34.0.Final
> Reporter: Bhala Hadkar
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
> Attachments: Workbench-Guided-Rule.png, drools.png
>
>
> When I set up a Guided rule on Workbench having a comparison condition on one of the domain field of type Big Decimal then the int value entered through literal text disappears and turns into 0.0B.
> For e.g. if you look at this Guided Rule screenshot the literal value 100 turned into 0.0.
> !Workbench-Guided-Rule.png|thumbnail!
> Also in the drools the value becomes 0.0B.
> !drools.png|thumbnail!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFCORE-4805) WildFly Security Manager does not act for javaagents
by Boris Unckel (Jira)
[ https://issues.redhat.com/browse/WFCORE-4805?page=com.atlassian.jira.plug... ]
Boris Unckel commented on WFCORE-4805:
--------------------------------------
I have backported the JBoss Module Loader javaagent feature. It did not work for both InspectIt and AppDyn because both use their own proprietary way (separate threads with homegrown classloaders) to load themselves. This part can be solved by the conventional JSM policy file.
The generated code to measure code execution, follow transactions,... is the problem. They use bytecode modification causing parts of the run code to be without valid codesource (location is null). Therefor you can't assign any permission by configuration.
> WildFly Security Manager does not act for javaagents
> ----------------------------------------------------
>
> Key: WFCORE-4805
> URL: https://issues.redhat.com/browse/WFCORE-4805
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Boris Unckel
> Assignee: Darran Lofthouse
> Priority: Major
>
> The WildFly Core Security Manager cares for modules and deployed artifacts. It offers a JavaEE 7 compliant solution to permissions.xml in META-INF of EARs/WARs.
> Unfortunately it does not take care of javaagents, specified in
> https://docs.oracle.com/javase/8/docs/api/java/lang/instrument/package-su...
> OpenSource:
> https://inspectit.github.io/inspectit-ocelot/docs/getting-started/quick-s...
> java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "setContextClassLoader")" in code source "(file:/opt/inspectit/inspectit-ocelot-agent-0.6.jar <no signer certificates>)" of "sun.misc.Launcher$AppClassLoader@18b4aac2")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:295)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:192)
> at java.lang.Thread.setContextClassLoader(Thread.java:1474)
> at rocks.inspectit.ocelot.bootstrap.AgentManager.startOrReplaceInspectitCore(AgentManager.java:49)
> at rocks.inspectit.ocelot.agent.AgentMain.startAgent(AgentMain.java:78)
> at rocks.inspectit.ocelot.agent.AgentMain.lambda$premain$0(AgentMain.java:67)
> at java.lang.Thread.run(Thread.java:748)
> The specified JARs need AllPermission Config in the same way as container modules.
> Other Examples for JavaAgents - closed source:
> https://docs.appdynamics.com/display/PRO45/Java+Agent
> https://docs.appdynamics.com/display/PRO45/JBoss+and+Wildfly+Startup+Sett...
> https://docs.appdynamics.com/display/PRO45/Java+Security+Manager+Configur...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-13121) jgroups channel protocol read-resource error with include-runtime
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFLY-13121?page=com.atlassian.jira.plugi... ]
Radoslav Husar commented on WFLY-13121:
---------------------------------------
Merged.
> jgroups channel protocol read-resource error with include-runtime
> ------------------------------------------------------------------
>
> Key: WFLY-13121
> URL: https://issues.redhat.com/browse/WFLY-13121
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 19.0.0.Beta2
> Reporter: Jean Francois Denise
> Assignee: Radoslav Husar
> Priority: Major
> Fix For: 20.0.0.Beta1
>
>
> Start standlone-ha.xml
> /subsystem=jgroups/channel=ee/protocol=UDP:read-resource(include-runtime
> Client:
> {
> "outcome" => "failed",
> "rolled-back" => true
> }
> Server:
> 12:01:32,541 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> ("subsystem" => "jgroups"),
> ("channel" => "ee"),
> ("protocol" => "UDP")
> ]) - failure description: "newValue is null"
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months