[JBoss JIRA] (WFCORE-1842) Support RBAC based on raw roles from an Identity
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1842?page=com.atlassian.jira.plugi... ]
Darran Lofthouse reassigned WFCORE-1842:
----------------------------------------
Assignee: Darran Lofthouse
> Support RBAC based on raw roles from an Identity
> -------------------------------------------------
>
> Key: WFCORE-1842
> URL: https://issues.jboss.org/browse/WFCORE-1842
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Security
> Reporter: Pedro Igor
> Assignee: Darran Lofthouse
>
> Currently, RBAC requires a static mapping between standard roles and raw roles from an identity.
> We should be able to use RBAC without necessarily forcing this static mapping and just consider the raw roles from the identity.
> This issue may be related with exposing {{org.jboss.as.controller.access.management.WritableAuthorizerConfiguration#useRealmRoles}} in the management model.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFCORE-482) Add log4j2 support for WildFly
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-482?page=com.atlassian.jira.plugin... ]
James Perkins commented on WFCORE-482:
--------------------------------------
This is something I've started working on. Currently I'm just implementing a log4j2 {{LoggerContextFactory}} which uses a {{org.jboss.logmanager.Logger}}. If anyone has some example uses cases of how they use log4j2 that would be helpful.
Some questions that would be helpful to know the answer to:
# Do you just use the log4j2-api?
# Do you use a custom {{LoggerContextFactory}}?
# Are you using system properties or a properties file to configure log4j2?
# Are you using the log4j-web dependency?
Any other comments on how you're using log4j2 in WildFly or any container would be helpful.
Thanks in advance!
> Add log4j2 support for WildFly
> ------------------------------
>
> Key: WFCORE-482
> URL: https://issues.jboss.org/browse/WFCORE-482
> Project: WildFly Core
> Issue Type: Task
> Components: Logging
> Environment: Spring 3, Hibernate, Wicket, JBoss AS7
> Reporter: Amarkanth Ranganamayna
> Assignee: James Perkins
> Priority: Optional
>
> I am trying to use Flume Appender which comes with Log4j2 (log4j 1.x doesn't support flume appender) (AND) inorder to acheive this, I am looking at how to configure JBoss AS7 to use log4j2.
> Looks like Jboss AS7 by default use log4j 1.x
> Are you guys already working on using log4j2 ?
> If NOT, can you please suggest how to configure Jboss AS7 such that it picks up "log4j2.xml" file and doesn't use its own logging.
> Thanks,
> Amar
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a supported scenario for Dynamic rule management
by Bill Tuminaro (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1313?page=com.atlassian.jira.plugi... ]
Bill Tuminaro commented on DROOLS-1313:
---------------------------------------
I added some System.gc() calls after the updateToVersion() calls, they do not seem to have any affect.
> Memory Leak - but is this a supported scenario for Dynamic rule management
> --------------------------------------------------------------------------
>
> Key: DROOLS-1313
> URL: https://issues.jboss.org/browse/DROOLS-1313
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Reporter: Bill Tuminaro
> Assignee: Mario Fusco
> Attachments: SAVE_SimpleTest.java, SAVE_SimpleTest2.java, SimpleTest2_dump1.PNG, SimpleTest2_dump2.PNG, SimpleTest2_dump3.PNG, SimpleTestDump1.PNG, SimpleTestDump2.PNG, SimpleTestDump3.PNG
>
>
> I have a reproducer that shows a clear memory leak based on heap dumps created and reviewing them with the Eclipse Memory Analyzer tool (http://www.eclipse.org/mat/).
> However, I am not sure this is a supported scenario. If this is a supported approach this needs to get fixed, otherwise we need to use another approach.
> The attached source does this:
> +*Initialize stuff*+
> - Create a new ReleaseId
> - Create a new KieFileSystem
> - Generate and write the PomXML for the ReleaseId created above
> - Create a new KieModuleModel
> - Create a new KieBaseModel
> - Write the ModuleModel XML to the KieFileSystem
> - Write 2 rules into the KieFileSystem
> +*1st build and dump*+
> - Create a new KieBuilder
> - Do a buildall() with the KieBuilder
> - Create a new KieContainer
> - Create a new KieSession from the KieContainer
> - Print out the rules in the KieContainer for the package used in my rules
> - Create a java heap dump (SimpleTestFirstDump.dmp), see SimpleTestDump1.png as you can see we have 2 classloaders for each class created for these rules. This is not the leak, yet, just curious if this is expected.
> +*2nd build and dump*+
> - Delete 2 rules from the KieFileSystem created above
> - Call incrementalBuild() on the KieBuilder created above
> - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> - Add 2 new rules to the KieFileSystem created above
> - Call incrementalBuild() on the KieBuilder created above
> - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> - Print out the rules in the KieContainer for the package used in my rules
> - Create a java heap dump (SimpleTestSecondDump.dmp), see SimpleTestDump2.png.
> - Rule_120_Triggered_Part_1_ 0 is not there
> - Another class loader and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> +*3rd build and dump*+
> - Delete 1 rule from the KieFileSystem created above
> - Call incrementalBuild() on the KieBuilder created above
> - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> - Add 2 new rules to the KieFileSystem created above
> - Call incrementalBuild() on the KieBuilder created above
> - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> - Print out the rules in the KieContainer for the package used in my rules
> - Create a java heap dump (SimpleTestThirdDump.dmp), see SimpleTestDump3.png.
> - Rule_120_Triggered_Part_1_ 0 is STILL not there
> - TWO more class loaders and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> - Another class loader and instances of Rule_120_Triggered_part_10DefaultConsequenceInvoker is present ( I think this is also part of the leak)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFCORE-1842) Support RBAC based on raw roles from an Identity
by Pedro Igor (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1842?page=com.atlassian.jira.plugi... ]
Pedro Igor commented on WFCORE-1842:
------------------------------------
Nope. Accordingly with [~darranl], we just need to get it back and keep original behavior.
> Support RBAC based on raw roles from an Identity
> -------------------------------------------------
>
> Key: WFCORE-1842
> URL: https://issues.jboss.org/browse/WFCORE-1842
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Security
> Reporter: Pedro Igor
>
> Currently, RBAC requires a static mapping between standard roles and raw roles from an identity.
> We should be able to use RBAC without necessarily forcing this static mapping and just consider the raw roles from the identity.
> This issue may be related with exposing {{org.jboss.as.controller.access.management.WritableAuthorizerConfiguration#useRealmRoles}} in the management model.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFCORE-1842) Support RBAC based on raw roles from an Identity
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1842?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1842:
------------------------------------------
Is this a proposal to do anything beyond what the original useRealmRoles did?
> Support RBAC based on raw roles from an Identity
> -------------------------------------------------
>
> Key: WFCORE-1842
> URL: https://issues.jboss.org/browse/WFCORE-1842
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Security
> Reporter: Pedro Igor
>
> Currently, RBAC requires a static mapping between standard roles and raw roles from an identity.
> We should be able to use RBAC without necessarily forcing this static mapping and just consider the raw roles from the identity.
> This issue may be related with exposing {{org.jboss.as.controller.access.management.WritableAuthorizerConfiguration#useRealmRoles}} in the management model.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFLY-7247) Wildfly 10 JSESSIONIDSSOs not being created
by M Wardell (JIRA)
M Wardell created WFLY-7247:
-------------------------------
Summary: Wildfly 10 JSESSIONIDSSOs not being created
Key: WFLY-7247
URL: https://issues.jboss.org/browse/WFLY-7247
Project: WildFly
Issue Type: Bug
Affects Versions: 10.1.0.Final, 10.0.0.Final
Reporter: M Wardell
Assignee: Jason Greene
Found on wildfly 10.1 and 10.0. With SSO enabled, the server can startup in a state where not all the deployments get the SSO auth mechanism. Possibly caused by a missing dependency between the UndertowDeploymentInfoService and SingleSignOnService, which could be allowing the deployments to start before the SSO auth mechanism is registered in the host service.
Issue in intermittent on startup. After most startups the JESSSIONIDSSO is reliably generated during login. After some startups the JSESSIONIDSSO is never created after login.
Details in the referenced forum thread.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (JBJCA-1335) Add protection in RaXmlDeployer to prevent from loading xml resource
by COLLIGNON Thomas (JIRA)
COLLIGNON Thomas created JBJCA-1335:
---------------------------------------
Summary: Add protection in RaXmlDeployer to prevent from loading xml resource
Key: JBJCA-1335
URL: https://issues.jboss.org/browse/JBJCA-1335
Project: IronJacamar
Issue Type: Enhancement
Components: Deployer
Affects Versions: 1.2.7.Final
Reporter: COLLIGNON Thomas
Priority: Minor
Fix For: 1.2.8.Final
If we place a -ra.xml in jar file, the class RaXmlDeployer will fail with "URI not hierarchical error", because it doesn't handle jar file.
The goal of this issue is prevent for loading jar file in RaXmlDeployer .
The second goal is to provide ability of overring RaXmlDeployer in custom deployer who extends this class.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (JGRP-2102) bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2102?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2102 at 9/30/16 10:56 AM:
----------------------------------------------------------
I cannot reproduce this, and I'm not sure I understand what you're describing.
I suggest drop {{bind_interface}} and only use {{bind_addr}}, e.g. {{bind_addr="match-interface:eth0"}}. The {{bind_interface}} attribute was removed in 4.0 anyway.
was (Author: belaban):
I cannot reproduce this, and I'm not sure I understand what you're describing.
I suggest drop {{bind_interface}} and only use {{bind_addr}}, e.g. {{ bind_addr="match-interface:eth0"}}. The {{bind_interface}} attribute was removed in 4.0 anyway.
> bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict
> --------------------------------------------------------------------
>
> Key: JGRP-2102
> URL: https://issues.jboss.org/browse/JGRP-2102
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.1
> Environment: {noformat}
> [root@wtc2k01v27 ~] CLONE # ip a
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> inet6 2606:ae00:e200:3f::83/128 scope global
> valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
> link/ether 00:50:56:ab:2a:ea brd ff:ff:ff:ff:ff:ff
> inet 107.250.167.28/25 brd 107.250.167.127 scope global eth0
> inet6 2606:ae00:e200:3f::28/64 scope global
> valid_lft forever preferred_lft forever
> inet6 fe80::250:56ff:feab:2aea/64 scope link
> valid_lft forever preferred_lft forever
> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
> link/ether 00:50:56:ab:d6:12 brd ff:ff:ff:ff:ff:ff
> inet 192.168.0.59/24 brd 192.168.0.255 scope global eth1
> inet6 fe80::250:56ff:feab:d612/64 scope link
> valid_lft forever preferred_lft forever
> {noformat}
> There're eth0 and eth1 exists in the environment
> Reporter: 俐佳 张
> Assignee: Bela Ban
> Fix For: 3.6.12
>
> Attachments: jgroups-udp.xml
>
>
> Error happens while
> Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000085: Error while trying to create a channel using the specified configuration file: /opt/oss/NSN-icf_notification_dispatcher/conf/jgroups-udp.xml
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:406)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:307)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:351)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:188)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56)
> at java.lang.reflect.Method.invoke(Method.java:620)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:226)
> ... 26 more
> Caused by: java.lang.Exception: Property assignment of bind_interface in UDP with original property value eth0 and converted to null could not be assigned
> at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1153)
> at org.jgroups.stack.Configurator.createLayer(Configurator.java:444)
> at org.jgroups.stack.Configurator.createProtocols(Configurator.java:398)
> at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:90)
> at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57)
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:477)
> at org.jgroups.JChannel.init(JChannel.java:854)
> at org.jgroups.JChannel.<init>(JChannel.java:159)
> at org.jgroups.JChannel.<init>(JChannel.java:129)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:404)
> ... 39 more
> Caused by: java.lang.Exception: Conversion of bind_interface in UDP with original property value eth0 failed
> at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:84)
> at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1147)
> ... 48 more
> Caused by: java.lang.mail(a)example.comIllegalArgumentException: network interface eth0 does not contain address fe80:0:0:0:250:56ff:feab:d612%3
> at org.jgroups.util.Util.validateBindAddressFromInterface(Util.java:3132)
> bind_interface="eth0" and bind_addr="LINK_LOCAL" config are config at the same time
> but it couldn't get the eth0 link local address but return eth1 link local address
> This code return the first address that match, it should return with eth0
> jgroups-3.6.1.Final-sources\org\jgroups\util\Util.java
> {code}
> public static InetAddress getAddress(AddressScope scope) // ----> scope is LINK_LOCAL
> throws SocketException
> {
> InetAddress address = null;
> Enumeration intfs = NetworkInterface.getNetworkInterfaces();
> while (intfs.hasMoreElements()) {
> NetworkInterface intf = (NetworkInterface)intfs.nextElement();
> try {
> if (intf.isUp()) {
> address = getAddress(intf, scope); // -------> It will return the first LINK_LOCAL address from NICs list
> if (address != null)
> return address;
> }
> }
> catch (SocketException e) {
> }
> }
> return null;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months