[JBoss JIRA] (DROOLS-1734) FEEL if in case of otherwise
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1734?page=com.atlassian.jira.plugi... ]
Edson Tirelli updated DROOLS-1734:
----------------------------------
Sprint: 2017 Week 36-37
> FEEL if in case of otherwise
> ----------------------------
>
> Key: DROOLS-1734
> URL: https://issues.jboss.org/browse/DROOLS-1734
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
>
> Spec says:
> if FEEL(e 1 ) is true then FEEL(e 2 ) else FEEL(e 3 )
> so if I follow the spec, NOT the code, it could happen that FEEL(e1) is:
> true follows the spec, returns FEEL(e2)
> false follows the spec, returns FEEL(e3)
> otherwise if I follow the spec, it should return FEEL(e3), if I follow the code, it's returning null (and an error).
> The spec takes the position that 'if x then 1 else 2' should always
> result in either 1 or 2, regardless of x (or the type of x). This
> makes it easier for users to handle missing data, e.g. if x > 0 then x
> else 0.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFLY-9355) Undertow doesn't seem to handle Windows shortened names with overlays
by Radim Hatlapatka (JIRA)
[ https://issues.jboss.org/browse/WFLY-9355?page=com.atlassian.jira.plugin.... ]
Radim Hatlapatka moved JBEAP-13183 to WFLY-9355:
------------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-9355 (was: JBEAP-13183)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Web (Undertow)
(was: Web (Undertow))
Affects Version/s: 11.0.0.CR1
(was: 7.1.0.CR1)
> Undertow doesn't seem to handle Windows shortened names with overlays
> ---------------------------------------------------------------------
>
> Key: WFLY-9355
> URL: https://issues.jboss.org/browse/WFLY-9355
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 11.0.0.CR1
> Environment: Windows
> Reporter: Radim Hatlapatka
> Assignee: Radim Hatlapatka
> Priority: Optional
> Attachments: overlay.war
>
>
> When using overlays and the overlay directory is defined via shortened path allowed on Windows (path looking something like {{C:\Users\ADMINI~1\overlay}}, the files in overlay directory are not found and 404 is returned.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (DROOLS-1729) Unable to load rule with global variables via kiescanner.
by Pedro Almeida (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1729?page=com.atlassian.jira.plugi... ]
Pedro Almeida updated DROOLS-1729:
----------------------------------
Description:
I have a master drl that has global *variables declaration* as well as *class role declarations*. Other drl files depend on those declarations.
Build is successful and I'm able to use the engine as intended. The thing is when I use kiescanner to unload a rule and load it back, I get compilation errors that make it look like the master drl is not being accounted.
*Errors:*
1) "A Sliding Window can only be assigned to types declared with @role( event )
[Actually my object type is declared with role event on the master drl]
2) "helper cannot be resolved"
[helper being my global variable, an instance of a class]
*Rule:*
package rules;
import model.Car;
global Boolean isTest;
rule "Red Car"
when
Car (color=="Red") over window:time(2h);
then
System.out.println("*** Red car");
System.out.println("*** " + isTest);
end
*Master Drl*
package rules;
import model.Car;
global Boolean isTest;
declare Car
@role( event )
end
was:
I have a master drl that has global *variables declaration* as well as *class role declarations*. Other drl files depend on those declarations.
Build is successful and I'm able to use the engine as intended. The thing is when I use kiescanner to unload a rule and load it back, I get compilation errors that make it look like the master drl is not being accounted.
*Errors:*
1) "A Sliding Window can only be assigned to types declared with @role( event )
[Actually my object type is declared with role event on the master drl]
2) "helper cannot be resolved"
[helper being my global variable, an instance of a class]
*Rule:*
package rules;
import model.Car;
global Boolean isTest;
rule "Red Car"
when
Car (color=="Red") over window:time(2h);
then
System.out.println("*** Red car");
System.out.println("*** " + isTest);
end
> Unable to load rule with global variables via kiescanner.
> ---------------------------------------------------------
>
> Key: DROOLS-1729
> URL: https://issues.jboss.org/browse/DROOLS-1729
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.5.0.Final
> Reporter: Pedro Almeida
> Assignee: Edson Tirelli
> Priority: Blocker
>
> I have a master drl that has global *variables declaration* as well as *class role declarations*. Other drl files depend on those declarations.
> Build is successful and I'm able to use the engine as intended. The thing is when I use kiescanner to unload a rule and load it back, I get compilation errors that make it look like the master drl is not being accounted.
> *Errors:*
> 1) "A Sliding Window can only be assigned to types declared with @role( event )
> [Actually my object type is declared with role event on the master drl]
> 2) "helper cannot be resolved"
> [helper being my global variable, an instance of a class]
> *Rule:*
> package rules;
> import model.Car;
> global Boolean isTest;
> rule "Red Car"
> when
> Car (color=="Red") over window:time(2h);
> then
> System.out.println("*** Red car");
> System.out.println("*** " + isTest);
> end
> *Master Drl*
> package rules;
> import model.Car;
> global Boolean isTest;
> declare Car
> @role( event )
> end
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (DROOLS-1729) Unable to load rule with global variables via kiescanner.
by Pedro Almeida (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1729?page=com.atlassian.jira.plugi... ]
Pedro Almeida updated DROOLS-1729:
----------------------------------
Description:
I have a master drl that has global *variables declaration* as well as *class role declarations*. Other drl files depend on those declarations.
Build is successful and I'm able to use the engine as intended. The thing is when I use kiescanner to unload a rule and load it back, I get compilation errors that make it look like the master drl is not being accounted for.
*Errors:*
1) "A Sliding Window can only be assigned to types declared with @role( event )
[Actually my object type is declared with role event on the master drl]
2) "helper cannot be resolved"
[helper being my global variable, an instance of a class]
*Rule:*
package rules;
import model.Car;
global Boolean isTest;
rule "Red Car"
when
Car (color=="Red") over window:time(2h);
then
System.out.println("*** Red car");
System.out.println("*** " + isTest);
end
*Master Drl*
package rules;
import model.Car;
global Boolean isTest;
declare Car
@role( event )
end
was:
I have a master drl that has global *variables declaration* as well as *class role declarations*. Other drl files depend on those declarations.
Build is successful and I'm able to use the engine as intended. The thing is when I use kiescanner to unload a rule and load it back, I get compilation errors that make it look like the master drl is not being accounted.
*Errors:*
1) "A Sliding Window can only be assigned to types declared with @role( event )
[Actually my object type is declared with role event on the master drl]
2) "helper cannot be resolved"
[helper being my global variable, an instance of a class]
*Rule:*
package rules;
import model.Car;
global Boolean isTest;
rule "Red Car"
when
Car (color=="Red") over window:time(2h);
then
System.out.println("*** Red car");
System.out.println("*** " + isTest);
end
*Master Drl*
package rules;
import model.Car;
global Boolean isTest;
declare Car
@role( event )
end
> Unable to load rule with global variables via kiescanner.
> ---------------------------------------------------------
>
> Key: DROOLS-1729
> URL: https://issues.jboss.org/browse/DROOLS-1729
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.5.0.Final
> Reporter: Pedro Almeida
> Assignee: Edson Tirelli
> Priority: Blocker
>
> I have a master drl that has global *variables declaration* as well as *class role declarations*. Other drl files depend on those declarations.
> Build is successful and I'm able to use the engine as intended. The thing is when I use kiescanner to unload a rule and load it back, I get compilation errors that make it look like the master drl is not being accounted for.
> *Errors:*
> 1) "A Sliding Window can only be assigned to types declared with @role( event )
> [Actually my object type is declared with role event on the master drl]
> 2) "helper cannot be resolved"
> [helper being my global variable, an instance of a class]
> *Rule:*
> package rules;
> import model.Car;
> global Boolean isTest;
> rule "Red Car"
> when
> Car (color=="Red") over window:time(2h);
> then
> System.out.println("*** Red car");
> System.out.println("*** " + isTest);
> end
> *Master Drl*
> package rules;
> import model.Car;
> global Boolean isTest;
> declare Car
> @role( event )
> end
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFCORE-3302) Intermittent protocol and controller module unit test failures since move to JBoss Remoting 5
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3302?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3302:
-------------------------------------
Description:
This bug is about problems in WF Core management tests. I believe it exposes a flaw in how remoting handles server sockets, but AFAIK there is no impact on WF Core remoting server sockets.
Since the move to JBoss Remoting 5 we've seen intermittent failures in the protocol and controller module testsuites involving the tests that use their respective copies of the ChannelServer + RemoteChannelPairSetup test fixture. These tests all do a setup and teardown of the fixture for each test method (i.e. @Before and @After) with the failure being that a test fails creating a remoting server with a failure that indicates the server from a previous test hasn't completely shut down yet:
{code}
java.lang.RuntimeException: java.net.BindException: Address already in use: bind
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:433)
at sun.nio.ch.Net.bind(Net.java:425)
at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:181)
at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:282)
at org.jboss.remoting3.remote.RemoteConnectionProvider$ProviderInterface.createServer(RemoteConnectionProvider.java:372)
at org.jboss.as.controller.support.ChannelServer.create(ChannelServer.java:92)
at org.jboss.as.controller.support.RemoteChannelPairSetup.setupRemoting(RemoteChannelPairSetup.java:88)
at org.jboss.as.controller.ModelControllerClientTestCase.setupTestClient(ModelControllerClientTestCase.java:94)
at org.jboss.as.controller.ModelControllerClientTestCase.testCloseInputStreamEntry(ModelControllerClientTestCase.java:346)
{code}
These failures have been mildly annoying on ci.wildfly.org, but now that the same code is being on other test machines, e.g. brontes used for EAP testing, they are completely intolerable, affecting a high percentage of CI runs for pull requests.
I believe the issue arises from changes to these fixtures that came in as part of the Remoting 5 upgrade such that a remoting Endpoint is not being created/shutdown for each test method. This causes a problem because the AcceptingChannel<StreamConnection> created by Endpoint.getConnectionProviderInterface(...).createServer(...) *does not* synchronously close down the underlying socket as part of a call to its close() method.
The socket is not closed synchronously because the ServerSocketChannel impl of close() does not close the socket if there are any registered keys. Debugging shows the socket is not closed until this stack happens:
{code}
"XNIO-1 Accept@1562" daemon prio=5 tid=0xf nid=NA runnable
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.ServerSocketChannelImpl.kill(ServerSocketChannelImpl.java:307)
- locked <0xc0d> (a java.lang.Object)
at sun.nio.ch.KQueueSelectorImpl.implDereg(KQueueSelectorImpl.java:229)
at sun.nio.ch.SelectorImpl.processDeregisterQueue(SelectorImpl.java:149)
- locked <0xc38> (a java.util.HashSet)
at sun.nio.ch.KQueueSelectorImpl.doSelect(KQueueSelectorImpl.java:107)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- locked <0xc2b> (a sun.nio.ch.KQueueSelectorImpl)
- locked <0xc39> (a java.util.Collections$UnmodifiableSet)
- locked <0xc3a> (a sun.nio.ch.Util$2)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:519)
{code}
That thread is not under the control of the test fixture, which means there's a race between it closing the socket and the test moving on the next setup where it tries to open the socket.
I think the only solution for this is to bring the endpoint lifecycle back under the control of the test fixture such that the fixture knows all is shutdown. I don't see anything else the test can block on to ensure the server socket is closed.
I think this would be a bug for any use of remoting where a server may quickly be shutdown and then recreated.
was:
Since the move to JBoss Remoting 5 we've seen intermittent failures in the protocol and controller module testsuites involving the tests that use their respective copies of the ChannelServer + RemoteChannelPairSetup test fixture. These tests all do a setup and teardown of the fixture for each test method (i.e. @Before and @After) with the failure being that a test fails creating a remoting server with a failure that indicates the server from a previous test hasn't completely shut down yet:
{code}
java.lang.RuntimeException: java.net.BindException: Address already in use: bind
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:433)
at sun.nio.ch.Net.bind(Net.java:425)
at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:181)
at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:282)
at org.jboss.remoting3.remote.RemoteConnectionProvider$ProviderInterface.createServer(RemoteConnectionProvider.java:372)
at org.jboss.as.controller.support.ChannelServer.create(ChannelServer.java:92)
at org.jboss.as.controller.support.RemoteChannelPairSetup.setupRemoting(RemoteChannelPairSetup.java:88)
at org.jboss.as.controller.ModelControllerClientTestCase.setupTestClient(ModelControllerClientTestCase.java:94)
at org.jboss.as.controller.ModelControllerClientTestCase.testCloseInputStreamEntry(ModelControllerClientTestCase.java:346)
{code}
These failures have been mildly annoying on ci.wildfly.org, but now that the same code is being on other test machines, e.g. brontes used for EAP testing, they are completely intolerable, affecting a high percentage of CI runs for pull requests.
I believe the issue arises from changes to these fixtures that came in as part of the Remoting 5 upgrade such that a remoting Endpoint is not being created/shutdown for each test method. This causes a problem because the AcceptingChannel<StreamConnection> created by Endpoint.getConnectionProviderInterface(...).createServer(...) *does not* synchronously close down the underlying socket as part of a call to its close() method.
The socket is not closed synchronously because the ServerSocketChannel impl of close() does not close the socket if there are any registered keys. Debugging shows the socket is not closed until this stack happens:
{code}
"XNIO-1 Accept@1562" daemon prio=5 tid=0xf nid=NA runnable
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.ServerSocketChannelImpl.kill(ServerSocketChannelImpl.java:307)
- locked <0xc0d> (a java.lang.Object)
at sun.nio.ch.KQueueSelectorImpl.implDereg(KQueueSelectorImpl.java:229)
at sun.nio.ch.SelectorImpl.processDeregisterQueue(SelectorImpl.java:149)
- locked <0xc38> (a java.util.HashSet)
at sun.nio.ch.KQueueSelectorImpl.doSelect(KQueueSelectorImpl.java:107)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- locked <0xc2b> (a sun.nio.ch.KQueueSelectorImpl)
- locked <0xc39> (a java.util.Collections$UnmodifiableSet)
- locked <0xc3a> (a sun.nio.ch.Util$2)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:519)
{code}
That thread is not under the control of the test fixture, which means there's a race between it closing the socket and the test moving on the next setup where it tries to open the socket.
I think the only solution for this is to bring the endpoint lifecycle back under the control of the test fixture such that the fixture knows all is shutdown. I don't see anything else the test can block on to ensure the server socket is closed.
I think this would be a bug for any use of remoting where a server may quickly be shutdown and then recreated.
> Intermittent protocol and controller module unit test failures since move to JBoss Remoting 5
> ---------------------------------------------------------------------------------------------
>
> Key: WFCORE-3302
> URL: https://issues.jboss.org/browse/WFCORE-3302
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Test Suite
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> This bug is about problems in WF Core management tests. I believe it exposes a flaw in how remoting handles server sockets, but AFAIK there is no impact on WF Core remoting server sockets.
> Since the move to JBoss Remoting 5 we've seen intermittent failures in the protocol and controller module testsuites involving the tests that use their respective copies of the ChannelServer + RemoteChannelPairSetup test fixture. These tests all do a setup and teardown of the fixture for each test method (i.e. @Before and @After) with the failure being that a test fails creating a remoting server with a failure that indicates the server from a previous test hasn't completely shut down yet:
> {code}
> java.lang.RuntimeException: java.net.BindException: Address already in use: bind
> at sun.nio.ch.Net.bind0(Native Method)
> at sun.nio.ch.Net.bind(Net.java:433)
> at sun.nio.ch.Net.bind(Net.java:425)
> at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
> at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:181)
> at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:282)
> at org.jboss.remoting3.remote.RemoteConnectionProvider$ProviderInterface.createServer(RemoteConnectionProvider.java:372)
> at org.jboss.as.controller.support.ChannelServer.create(ChannelServer.java:92)
> at org.jboss.as.controller.support.RemoteChannelPairSetup.setupRemoting(RemoteChannelPairSetup.java:88)
> at org.jboss.as.controller.ModelControllerClientTestCase.setupTestClient(ModelControllerClientTestCase.java:94)
> at org.jboss.as.controller.ModelControllerClientTestCase.testCloseInputStreamEntry(ModelControllerClientTestCase.java:346)
> {code}
> These failures have been mildly annoying on ci.wildfly.org, but now that the same code is being on other test machines, e.g. brontes used for EAP testing, they are completely intolerable, affecting a high percentage of CI runs for pull requests.
> I believe the issue arises from changes to these fixtures that came in as part of the Remoting 5 upgrade such that a remoting Endpoint is not being created/shutdown for each test method. This causes a problem because the AcceptingChannel<StreamConnection> created by Endpoint.getConnectionProviderInterface(...).createServer(...) *does not* synchronously close down the underlying socket as part of a call to its close() method.
> The socket is not closed synchronously because the ServerSocketChannel impl of close() does not close the socket if there are any registered keys. Debugging shows the socket is not closed until this stack happens:
> {code}
> "XNIO-1 Accept@1562" daemon prio=5 tid=0xf nid=NA runnable
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.ServerSocketChannelImpl.kill(ServerSocketChannelImpl.java:307)
> - locked <0xc0d> (a java.lang.Object)
> at sun.nio.ch.KQueueSelectorImpl.implDereg(KQueueSelectorImpl.java:229)
> at sun.nio.ch.SelectorImpl.processDeregisterQueue(SelectorImpl.java:149)
> - locked <0xc38> (a java.util.HashSet)
> at sun.nio.ch.KQueueSelectorImpl.doSelect(KQueueSelectorImpl.java:107)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0xc2b> (a sun.nio.ch.KQueueSelectorImpl)
> - locked <0xc39> (a java.util.Collections$UnmodifiableSet)
> - locked <0xc3a> (a sun.nio.ch.Util$2)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:519)
> {code}
> That thread is not under the control of the test fixture, which means there's a race between it closing the socket and the test moving on the next setup where it tries to open the socket.
> I think the only solution for this is to bring the endpoint lifecycle back under the control of the test fixture such that the fixture knows all is shutdown. I don't see anything else the test can block on to ensure the server socket is closed.
> I think this would be a bug for any use of remoting where a server may quickly be shutdown and then recreated.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFCORE-3273) sharedState is passed null by PluginAuthenticationCallbackHandler
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3273?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-3273:
------------------------------------------
Good to hear, my code change should now be ensuring we have a shared state map in all cases now and not just when we have both authentication and authorization defined.
> sharedState is passed null by PluginAuthenticationCallbackHandler
> -----------------------------------------------------------------
>
> Key: WFCORE-3273
> URL: https://issues.jboss.org/browse/WFCORE-3273
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Environment: Fedora 26, using ovirt-engine-wildfly package
> Reporter: Roy Golan
> Assignee: Darran Lofthouse
> Fix For: 3.0.2.Final, 4.0.0.Alpha1
>
>
> oVirt's ovirt-engine uses an authorization plugin [1] for management interface that recently after upgrading to Wildfly 11 stopped working. The reason is the sharedState passed to the plugin's init method is now null.
> A current workaround this would be to avoid adding to plugin into the shareState but that means any delegating plugin would fail to find this plugin and possibly other bad stuff I'm not aware of.
> [1] https://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=backend/manag...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFCORE-3273) sharedState is passed null by PluginAuthenticationCallbackHandler
by Roy Golan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3273?page=com.atlassian.jira.plugi... ]
Roy Golan commented on WFCORE-3273:
-----------------------------------
[~dlofthouse] That's correct I think, we have only auth plugin.
<security-realm name="management">
<plug-ins>
<plug-in module="org.ovirt.engine.core.auth-plugin"/>
</plug-ins>
<authentication>
<plug-in name="OvirtAuth" mechanism="PLAIN"/>
</authentication>
</security-realm>
> sharedState is passed null by PluginAuthenticationCallbackHandler
> -----------------------------------------------------------------
>
> Key: WFCORE-3273
> URL: https://issues.jboss.org/browse/WFCORE-3273
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Environment: Fedora 26, using ovirt-engine-wildfly package
> Reporter: Roy Golan
> Assignee: Darran Lofthouse
> Fix For: 3.0.2.Final, 4.0.0.Alpha1
>
>
> oVirt's ovirt-engine uses an authorization plugin [1] for management interface that recently after upgrading to Wildfly 11 stopped working. The reason is the sharedState passed to the plugin's init method is now null.
> A current workaround this would be to avoid adding to plugin into the shareState but that means any delegating plugin would fail to find this plugin and possibly other bad stuff I'm not aware of.
> [1] https://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=backend/manag...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months