[JBoss JIRA] (WFCORE-69) NullPointerException adding KeyStore to realm with {allow-resource-service-restart=true}
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-69?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFCORE-69:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1073866|https://bugzilla.redhat.com/show_bug.cgi?id=1073866] from POST to MODIFIED
> NullPointerException adding KeyStore to realm with {allow-resource-service-restart=true}
> ----------------------------------------------------------------------------------------
>
> Key: WFCORE-69
> URL: https://issues.jboss.org/browse/WFCORE-69
> Project: WildFly Core
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha4
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.0.0.Alpha6
>
>
> Executing the following CLI commands: -
> {code:title=CLI Commands}
> ./core-service=management/security-realm=SSLRealm:add
> ./core-service=management/security-realm=SSLRealm/server-identity=ssl:add(keystore-password=keystore_password, keystore-relative-to=jboss.server.config.dir, keystore-path=server.keystore){allow-resource-service-restart=true}
> {code}
> Results in the following NullPointerException being recorded: -
> {noformat}
> 15:23:28,074 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 6) WFLYCTL0013: Operation ("add") failed - address: ([
> ("core-service" => "management"),
> ("security-realm" => "SSLRealm"),
> ("server-identity" => "ssl")
> ]): java.lang.NullPointerException
> at org.jboss.as.domain.management.security.SecurityRealmAddHandler.addSSLServices(SecurityRealmAddHandler.java:596) [wildfly-domain-management-1.0.0.Alpha6-SNAPSHOT.jar:1.0.0.Alpha6-SNAPSHOT]
> at org.jboss.as.domain.management.security.SecurityRealmAddHandler.installServices(SecurityRealmAddHandler.java:188) [wildfly-domain-management-1.0.0.Alpha6-SNAPSHOT.jar:1.0.0.Alpha6-SNAPSHOT]
> at org.jboss.as.domain.management.security.SecurityRealmParentRestartHandler.recreateParentService(SecurityRealmParentRestartHandler.java:66) [wildfly-domain-management-1.0.0.Alpha6-SNAPSHOT.jar:1.0.0.Alpha6-SNAPSHOT]
> at org.jboss.as.controller.RestartParentResourceHandlerBase$1.execute(RestartParentResourceHandlerBase.java:74) [wildfly-controller-1.0.0.Alpha6-SNAPSHOT.jar:1.0.0.Alpha6-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:664) [wildfly-controller-1.0.0.Alpha6-SNAPSHOT.jar:1.0.0.Alpha6-SNAPSHOT]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (WFLY-2358) setting <jacc-star-role-allow> in jboss-web.xml does not set allRolesMode to "authOnly"
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2358?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2358:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1022240|https://bugzilla.redhat.com/show_bug.cgi?id=1022240] from NEW to MODIFIED
> setting <jacc-star-role-allow> in jboss-web.xml does not set allRolesMode to "authOnly"
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-2358
> URL: https://issues.jboss.org/browse/WFLY-2358
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (JBoss Web)
> Affects Versions: 8.0.0.Beta1
> Reporter: Derek Horton
> Assignee: Remy Maucherat
>
> I am trying to get only authentication (no authorization) to work for web application.
> In EAP 5, all that was required was to set the <role-name> to a '*' in
> the <security-constraint> of the web.xml. I tried this in EAP 6,
> however, it did not work.
> I then found the <jacc-star-role-allow> setting that goes in the
> jboss-web.xml. Unfortunately, adding this option did not cause the
> wildcard ('*') role-name to work for allowing any authenticated user
> to access the web application.
> Using the following system property does appear to work:
> org.apache.catalina.realm.RealmBase.ALL_ROLES_MODE=authOnly
> How reproducible:
> Everytime.
> Steps to Reproduce:
> 1. Set <role-name>*</role-name> in the security-contraint
> 2. Set <jacc-star-role-allow>true</jacc-star-role-allow> in jboss-web.xml
> 3. Set the security-domain so that no roles are assigned to a user
> 4. Attempt to access the web app
> Actual results:
> 403 - access denied
> Expected results:
> 200 - access allowed
> Additional info:
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (DROOLS-586) Drools doesn't calculate maximum expiration time properly
by kairat kushaev (JIRA)
[ https://issues.jboss.org/browse/DROOLS-586?page=com.atlassian.jira.plugin... ]
kairat kushaev updated DROOLS-586:
----------------------------------
Description:
Hello guys,
we found some contradiction between actual Drools behavior,
We use the following Rule:
import drools.test.Event;
dialect "mvel"
declare Event
@role(event)
@expires(10s)
end
rule "ExampleRule"
when
( $a : Event(name == "event a") ) and
( $b : Event((name == "event b") && (this after [1ms, 15s] $a)) )
then
System.out.println("bingo!");
end
In the code above Drools should wait for the second event when the first event came. But it turns out that Drools doesn't wait for the second event because of @expires tag. The value in this tag is less than this after value.
According to documentation
"The engine will make this analysis for the whole rulebase and find the offset for every event type. Whenever an implicit expiration offset clashes with the explicit expiration offset, then engine will use the greater of the two."
but it is not calculating maximal expiration offset. Also we are using STREAM mode.
Could you please clarify the situation?
was:
Hello guys,
we found some contradiction between actual Drools behaviour,
We use the following Rule:
import com.opensoft.mom.domain.Event;
import java.util.List;
import java.util.ArrayList;
import com.opensoft.mom.domain.MessageModelMap;
global com.opensoft.mom.service.actions.Actions actions;
dialect "mvel"
declare Event
@role(event)
@expires(10m)
end
rule "ExampleRule"
when
((($Time_delay_order:Event((this.isBelongToEventFormat(38)) && (this.getComparableStringValue("XXXXX") == Event.getDecodedString("ok")))))and(($Time_delay_submit:Event((this.isBelongToEventFormat(39)) && (this.getComparableStringValue("XXXXXX") == Event.getDecodedString("ok")) && (this after[1ms,0h15m20s] $Time_delay_order)))))
then
List recipients0 = new ArrayList();
recipients0.add(Event.getDecodedString("XXXXXXXXXX(a)gmail.com"));
MessageModelMap template0 = new MessageModelMap();
template0.setValue("XXXXXXXXXX", $Time_delay_order.getComparableStringValue("XXXXX"));
template0.setValue("XXXXXXXXXX", $Time_delay_order.getComparableStringValue("XXXXX"));
String subject0 = Event.getDecodedString("");
actions.sendMail(recipients0, subject0, 14, template0);
end
In the code above Drools should wait for the second rule when the first rule has fired. But it turns out that Drools doesn't wait for the second Rule because of @expires tag. The value in this tag is less than this after value.
According to documentation
"The engine will make this analysis for the whole rulebase and find the offset for every event type. Whenever an implicit expiration offset clashes with the explicit expiration offset, then engine will use the greater of the two."
but it is not calculating maximal expiration offset.
Also we turned on STREAM mode.
Could you please clarify the situation?
> Drools doesn't calculate maximum expiration time properly
> ---------------------------------------------------------
>
> Key: DROOLS-586
> URL: https://issues.jboss.org/browse/DROOLS-586
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: Linux, Java SE 1.7
> Reporter: kairat kushaev
> Assignee: Mark Proctor
> Fix For: 6.1.0.Final
>
>
> Hello guys,
> we found some contradiction between actual Drools behavior,
> We use the following Rule:
> import drools.test.Event;
> dialect "mvel"
> declare Event
> @role(event)
> @expires(10s)
> end
> rule "ExampleRule"
> when
> ( $a : Event(name == "event a") ) and
> ( $b : Event((name == "event b") && (this after [1ms, 15s] $a)) )
> then
> System.out.println("bingo!");
> end
> In the code above Drools should wait for the second event when the first event came. But it turns out that Drools doesn't wait for the second event because of @expires tag. The value in this tag is less than this after value.
> According to documentation
> "The engine will make this analysis for the whole rulebase and find the offset for every event type. Whenever an implicit expiration offset clashes with the explicit expiration offset, then engine will use the greater of the two."
> but it is not calculating maximal expiration offset. Also we are using STREAM mode.
> Could you please clarify the situation?
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (DROOLS-586) Drools doesn't calculate maximum expiration time properly
by kairat kushaev (JIRA)
kairat kushaev created DROOLS-586:
-------------------------------------
Summary: Drools doesn't calculate maximum expiration time properly
Key: DROOLS-586
URL: https://issues.jboss.org/browse/DROOLS-586
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: Linux, Java SE 1.7
Reporter: kairat kushaev
Assignee: Mark Proctor
Fix For: 6.1.0.Final
Hello guys,
we found some contradiction between actual Drools behaviour,
We use the following Rule:
import com.opensoft.mom.domain.Event;
import java.util.List;
import java.util.ArrayList;
import com.opensoft.mom.domain.MessageModelMap;
global com.opensoft.mom.service.actions.Actions actions;
dialect "mvel"
declare Event
@role(event)
@expires(10m)
end
rule "ExampleRule"
when
((($Time_delay_order:Event((this.isBelongToEventFormat(38)) && (this.getComparableStringValue("XXXXX") == Event.getDecodedString("ok")))))and(($Time_delay_submit:Event((this.isBelongToEventFormat(39)) && (this.getComparableStringValue("XXXXXX") == Event.getDecodedString("ok")) && (this after[1ms,0h15m20s] $Time_delay_order)))))
then
List recipients0 = new ArrayList();
recipients0.add(Event.getDecodedString("XXXXXXXXXX(a)gmail.com"));
MessageModelMap template0 = new MessageModelMap();
template0.setValue("XXXXXXXXXX", $Time_delay_order.getComparableStringValue("XXXXX"));
template0.setValue("XXXXXXXXXX", $Time_delay_order.getComparableStringValue("XXXXX"));
String subject0 = Event.getDecodedString("");
actions.sendMail(recipients0, subject0, 14, template0);
end
In the code above Drools should wait for the second rule when the first rule has fired. But it turns out that Drools doesn't wait for the second Rule because of @expires tag. The value in this tag is less than this after value.
According to documentation
"The engine will make this analysis for the whole rulebase and find the offset for every event type. Whenever an implicit expiration offset clashes with the explicit expiration offset, then engine will use the greater of the two."
but it is not calculating maximal expiration offset.
Also we turned on STREAM mode.
Could you please clarify the situation?
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (JGRP-1874) UNICAST3/UNICAST2: reduce traffic caused by GET-FIRST-SEQNO
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1874?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1874.
----------------------------
Resolution: Duplicate Issue
https://issues.jboss.org/browse/JGRP-1875 includes this functionality
> UNICAST3/UNICAST2: reduce traffic caused by GET-FIRST-SEQNO
> -----------------------------------------------------------
>
> Key: JGRP-1874
> URL: https://issues.jboss.org/browse/JGRP-1874
> Project: JGroups
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5.1, 3.6
>
>
> When we have sender A and receiver B, and B closes its connection unilaterally (see JGRP-1873), then a {{GET-FIRST-SEQNO}} will be sent from B to A when A's next message is received. This can potentially generate a lot of traffic.
> Example:
> # B has no entry for A in its recv-table
> # A has {{B:: 100 | 1000}}, so only message {{A::100}} has been acked by B ({{STABLE}} or {{ACK}} message
> # If B now gets {{A::560}}, it sends a {{GET-FIRST-SEQNO(560)}} to A
> #* As a matter of fact, for any message from A that not marked as {{first}}, B will send a {{GET-FIRST-SEQNO}} message: too much traffic
> # A now sends messages {{A::101}} - {{A::560}} to B
> #* This is also not needed: too much traffic
> h5. Solution to reduce traffic
> * Receiver: add timestamp to recv-table entries which drops {{GET-FIRST-SEQNO}} messages sent sooner than N ms after the previous one
> ** So rather than sending 1000 {{GET-FIRST-SEQNO}} messages to A when receiving 1000 unicasts from A not marked as {{first}}, we might only send a _single message_
> * Sender: when a {{GET-FIRST-SEQNO(560)}} message is received from B, only send the lowest sent (101) and the highest sent (560) back to B
> ** B will then retransmit all missing messages in that range
> ** For {{UNICAST3}}, we can only send the lowest sent message (101) as it will retransmit {{A::1000}} anyway and therefore trigger retransmission
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (JGRP-1874) UNICAST3/UNICAST2: reduce traffic caused by GET-FIRST-SEQNO
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1874?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1874:
--------------------------------
Closing this issue as a duplicate: https://issues.jboss.org/browse/JGRP-1875 includes reducing traffic between sender and receiver when syncing the receiver
> UNICAST3/UNICAST2: reduce traffic caused by GET-FIRST-SEQNO
> -----------------------------------------------------------
>
> Key: JGRP-1874
> URL: https://issues.jboss.org/browse/JGRP-1874
> Project: JGroups
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5.1, 3.6
>
>
> When we have sender A and receiver B, and B closes its connection unilaterally (see JGRP-1873), then a {{GET-FIRST-SEQNO}} will be sent from B to A when A's next message is received. This can potentially generate a lot of traffic.
> Example:
> # B has no entry for A in its recv-table
> # A has {{B:: 100 | 1000}}, so only message {{A::100}} has been acked by B ({{STABLE}} or {{ACK}} message
> # If B now gets {{A::560}}, it sends a {{GET-FIRST-SEQNO(560)}} to A
> #* As a matter of fact, for any message from A that not marked as {{first}}, B will send a {{GET-FIRST-SEQNO}} message: too much traffic
> # A now sends messages {{A::101}} - {{A::560}} to B
> #* This is also not needed: too much traffic
> h5. Solution to reduce traffic
> * Receiver: add timestamp to recv-table entries which drops {{GET-FIRST-SEQNO}} messages sent sooner than N ms after the previous one
> ** So rather than sending 1000 {{GET-FIRST-SEQNO}} messages to A when receiving 1000 unicasts from A not marked as {{first}}, we might only send a _single message_
> * Sender: when a {{GET-FIRST-SEQNO(560)}} message is received from B, only send the lowest sent (101) and the highest sent (560) back to B
> ** B will then retransmit all missing messages in that range
> ** For {{UNICAST3}}, we can only send the lowest sent message (101) as it will retransmit {{A::1000}} anyway and therefore trigger retransmission
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (WFLY-3791) Error on ModelControllerClient to list sections
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-3791?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-3791:
----------------------------------------
Yes I understand you are using the latest version, however are you using the default configuration or a clean configuration? Looking at your test code it is on the basis that you are using a modified configuration - what I am asking is that you run your test against an unmodified version of the configuration.
An no at this point I have not tried your java code, I have just verified that the security subsystem is accessible on a default installation at the same address as it has always been. The thing I need to know now is do you experience this error in a clean installation or only in your customised installation.
> Error on ModelControllerClient to list sections
> -----------------------------------------------
>
> Key: WFLY-3791
> URL: https://issues.jboss.org/browse/WFLY-3791
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.1.0.Final
> Environment: Java 7
> Reporter: ofbiz brazil
> Assignee: Darran Lofthouse
>
> Hello,
> When there's a client trying to list a node for a security section, Wildfly says it does not exist but on Jboss 7.1.1 it works fine.
> Java Code:
> --------------
> final ModelNode request = new ModelNode();
> request.get(ClientConstants.OP).set("read-resource");
> request.get("recursive").set(true);
> request.get(ClientConstants.OP_ADDR).add("subsystem", "security");
> final ModelControllerClient client = ModelControllerClient.Factory.create(InetAddress.getByName("127.0.0.1"), 9999);
> final ModelNode response = client.execute(new OperationBuilder(request).build());
> final String section = response.get(ClientConstants.RESULT).get("security-domain")
> .get("pw_MSSQL_CAS_DS")
> Result:
> ---------
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014807: Management resource '[(\"subsystem\" => \"security\")]' not found",
> "rolled-back" => true
> }
> Cheers,
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months