July 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3554) ejb-jar.xml interceptor-binding does not accept "*"

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/WFLY-3554?page=com.atlassian.jira.plugin.... ] Bartosz Baranowski updated WFLY-3554: ------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/6554, https://github.com/wildfly/wildfly/pull/6555, https://github.com/jbossas/jboss-eap/pull/1545 (was: https://github.com/wildfly/wildfly/pull/6554, https://github.com/wildfly/wildfly/pull/6555) > ejb-jar.xml interceptor-binding does not accept "*" > --------------------------------------------------- > > Key: WFLY-3554 > URL: https://issues.jboss.org/browse/WFLY-3554 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Affects Versions: 8.1.0.Final > Reporter: Wolf-Dieter Fink > Assignee: Bartosz Baranowski > > From the ejb3.1 specification (JSR 318) chapter 12.7 Specification of Interceptors in the Deployment Descriptor: > "" > In the interceptor-binding element, the target-name element must be the name of one of > the enterprise beans contained in the ejb-jar or the wildcard value “*”. > "" > But the "*" as ejb-name is ignored, only a bean name will result in binding the interceptor during deployment -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3554) ejb-jar.xml interceptor-binding does not accept "*"

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3554?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3554: ----------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1114061|https://bugzilla.redhat.com/show_bug.cgi?id=1114061] from ASSIGNED to POST > ejb-jar.xml interceptor-binding does not accept "*" > --------------------------------------------------- > > Key: WFLY-3554 > URL: https://issues.jboss.org/browse/WFLY-3554 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Affects Versions: 8.1.0.Final > Reporter: Wolf-Dieter Fink > Assignee: Bartosz Baranowski > > From the ejb3.1 specification (JSR 318) chapter 12.7 Specification of Interceptors in the Deployment Descriptor: > "" > In the interceptor-binding element, the target-name element must be the name of one of > the enterprise beans contained in the ejb-jar or the wildcard value “*”. > "" > But the "*" as ejb-name is ignored, only a bean name will result in binding the interceptor during deployment -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3696) Security domain configuration doesn't allow empty or missing login-module-stack

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3696?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-3696: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=901075 > Security domain configuration doesn't allow empty or missing login-module-stack > ------------------------------------------------------------------------------- > > Key: WFLY-3696 > URL: https://issues.jboss.org/browse/WFLY-3696 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Security > Affects Versions: 8.1.0.Final > Reporter: Chao Wang > Assignee: Chao Wang > > https://bugzilla.redhat.com/show_bug.cgi?id=901075 description: > project_key: JBPAPP6 > Adding a security domain with JASPI authentication fails if there is no (or is empty) login-module-stack. It should be possible to add custom ServerAuthModule, which doesn't use JAAS login modules. > {code:xml} > <security-domain name="jmx-console" cache-type="default"> > <authentication-jaspi> >  > <login-module-stack name="lm-stack"> > <login-module code="UsersRoles" flag="required"/> > </login-module-stack> > <auth-module code="org.jboss.example.CustomServerAuthModule" flag="required"> > <module-option name="option1" value="value1" /> > </auth-module> > </authentication-jaspi> > </security-domain> > {code} > It should be possible to remove here the login-module-stack element. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3696) Security domain configuration doesn't allow empty or missing login-module-stack

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3696?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3696: ----------------------------------------------- Chao Wang <chaowan(a)redhat.com> changed the Status of [bug 901075|https://bugzilla.redhat.com/show_bug.cgi?id=901075] from NEW to ASSIGNED > Security domain configuration doesn't allow empty or missing login-module-stack > ------------------------------------------------------------------------------- > > Key: WFLY-3696 > URL: https://issues.jboss.org/browse/WFLY-3696 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Security > Affects Versions: 8.1.0.Final > Reporter: Chao Wang > Assignee: Chao Wang > > https://bugzilla.redhat.com/show_bug.cgi?id=901075 description: > project_key: JBPAPP6 > Adding a security domain with JASPI authentication fails if there is no (or is empty) login-module-stack. It should be possible to add custom ServerAuthModule, which doesn't use JAAS login modules. > {code:xml} > <security-domain name="jmx-console" cache-type="default"> > <authentication-jaspi> >  > <login-module-stack name="lm-stack"> > <login-module code="UsersRoles" flag="required"/> > </login-module-stack> > <auth-module code="org.jboss.example.CustomServerAuthModule" flag="required"> > <module-option name="option1" value="value1" /> > </auth-module> > </authentication-jaspi> > </security-domain> > {code} > It should be possible to remove here the login-module-stack element. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3696) Security domain configuration doesn't allow empty or missing login-module-stack

by Chao Wang (JIRA)

Chao Wang created WFLY-3696: ------------------------------- Summary: Security domain configuration doesn't allow empty or missing login-module-stack Key: WFLY-3696 URL: https://issues.jboss.org/browse/WFLY-3696 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: Security Affects Versions: 8.1.0.Final Reporter: Chao Wang Assignee: Chao Wang https://bugzilla.redhat.com/show_bug.cgi?id=901075 description: project_key: JBPAPP6 Adding a security domain with JASPI authentication fails if there is no (or is empty) login-module-stack. It should be possible to add custom ServerAuthModule, which doesn't use JAAS login modules. {code:xml} <security-domain name="jmx-console" cache-type="default"> <authentication-jaspi>  <login-module-stack name="lm-stack"> <login-module code="UsersRoles" flag="required"/> </login-module-stack> <auth-module code="org.jboss.example.CustomServerAuthModule" flag="required"> <module-option name="option1" value="value1" /> </auth-module> </authentication-jaspi> </security-domain> {code} It should be possible to remove here the login-module-stack element. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1706) Clone a profile

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1706?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-1706: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1125143 > Clone a profile > --------------- > > Key: WFLY-1706 > URL: https://issues.jboss.org/browse/WFLY-1706 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 9.0.0.CR1 > > > Add the ability to clone a profile. > This could be a new "clone" operation on the existing profile resource, or perhaps a "clone-from" parameter on the existing "add" operation. Probably the former, as that will be more transformation-friendly. > Implementation will likely involve using the "describe" operation used for configuring managed domain servers and adding steps from the describe results directly on the HC instead of passing them to a server. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-546) FactType.get/set should throw specific exception (not NPE) for unknown fields

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-546?page=com.atlassian.jira.plugin... ] Mario Fusco resolved DROOLS-546. -------------------------------- Fix Version/s: 6.1.0.Final Resolution: Done > FactType.get/set should throw specific exception (not NPE) for unknown fields > ----------------------------------------------------------------------------- > > Key: DROOLS-546 > URL: https://issues.jboss.org/browse/DROOLS-546 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.1.0.CR1 > Reporter: Benoit Voisin > Assignee: Mario Fusco > Fix For: 6.2.0.Beta1, 6.1.0.Final > > > factType.get(instance, "unknownField") is currently throwing an NPE. This gives improper information to the user/developper. > I propose that it throws a new UnknownFactFieldException giving improved information giving good hints for debugging or enabling specific exception management. > See pull request for test-case and proposed fix -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1856) FD_ALL should not update all mbrs timestamp in handleViewChange

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1856?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1856: -------------------------------- Fixed as suggested by Takayoshi, thanks ! > FD_ALL should not update all mbrs timestamp in handleViewChange > --------------------------------------------------------------- > > Key: JGRP-1856 > URL: https://issues.jboss.org/browse/JGRP-1856 > Project: JGroups > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Affects Versions: 3.4.4 > Reporter: Takayoshi Kimura > Assignee: Bela Ban > Fix For: 3.4.5, 3.5 > > > In large cluster, when multiple instances (e.g. A, B, C, D) gone at once, FD_ALL interval based checker detects first few instances already timed out (e.g. A, B), suspects them and the coord sends a view change. > In FD_ALL.handleViewChange(), it updates all mbrs timestamps including the rest of dead members (e.g. C, D) and they get extra life until suspect. > It would be better not to do this so we can expel them sooner. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1855) FD_HOST: host failure detection protocol

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1855?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-1855 at 7/31/14 2:17 AM: --------------------------------------------------------- OK, first impl is done and has been tested with VirtualBox/Fedora 14 instances. The config would look like this: {code:xml} <FD_HOST interval="10000" timeout="35000" /> {code} The current impl uses {{InetAddress.isReachable()}}. Next: include ability to use external commands such as {{/sbin/ping}}. was (Author: belaban): OK, first impl is done and has been tested with VirtualBox/Fedora 14 instances. The config would look like this: {code:xml} <FD_PING2 interval="10000" timeout="35000" /> {code} The current impl uses {{InetAddress.isReachable()}}. Next: include ability to use external commands such as {{/sbin/ping}}. > FD_HOST: host failure detection protocol > ---------------------------------------- > > Key: JGRP-1855 > URL: https://issues.jboss.org/browse/JGRP-1855 > Project: JGroups > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.4.5, 3.5 > > > A new protocol similar to FD_PING which detects entire host failures and suspects all members on the failed host. > Features are: > * Contrary to FD_PING which uses a ring structure, FD_HOST will have everyone ping everybody else (similar to FD_ALL) > ** A structure keeps track of hosts (IP addresses) and members on those hosts > *** Example > ||192.168.1.2||192.168.1.3||192.168.1.5|| > |A,B,C|D,E,F|X,Y,Z| > * We sort the members lexically and the *first* member runs a ping against each other IP address, e.g. A pings 192.168.1.3 and 192.168.1.5, D pings 192.168.1.2 and 192.168.1.5 etc > * The ping command itself is pluggable and can be a Java class (e.g. using {{InetAddress.isReachable()}}, a script or a command (e.g. {{/sbin/ping}}). > * When an entire host is suspected, we suspect *all* cluster members on it > ** Example: if B suspects 192.168.1.5, members X, Y and Z are suspected and removed from the view -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1855) FD_HOST: host failure detection protocol

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1855?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1855: --------------------------- Description: A new protocol similar to FD_PING which detects entire host failures and suspects all members on the failed host. Features are: * Contrary to FD_PING which uses a ring structure, FD_HOST will have everyone ping everybody else (similar to FD_ALL) ** A structure keeps track of hosts (IP addresses) and members on those hosts *** Example ||192.168.1.2||192.168.1.3||192.168.1.5|| |A,B,C|D,E,F|X,Y,Z| * We sort the members lexically and the *first* member runs a ping against each other IP address, e.g. A pings 192.168.1.3 and 192.168.1.5, D pings 192.168.1.2 and 192.168.1.5 etc * The ping command itself is pluggable and can be a Java class (e.g. using {{InetAddress.isReachable()}}, a script or a command (e.g. {{/sbin/ping}}). * When an entire host is suspected, we suspect *all* cluster members on it ** Example: if B suspects 192.168.1.5, members X, Y and Z are suspected and removed from the view was: A new protocol similar to FD_PING which detects entire host failures and suspects all members on the failed host. Features are: * Contrary to FD_PING which uses a ring structure, FD_HOST will have everyone ping everybody else (similar to FD_ALL) ** A structure keeps track of hosts (IP addresses) and members on those hosts *** Example ||192.168.1.2||192.168.1.3||192.168.1.5|| |A,B,C|D,E,F|X,Y,Z| * We sort the members lexically and the *first* member runs a ping against each other IP address, e.g. A pings 192.168.1.3 and 192.168.1.5, D pings 192.168.1.2 and 192.168.1.5 etc * The ping command itself is pluggable and can be a Java class (e.g. using {{InetAddress.isReachable()}}, a script or a command (e.g. {{/sbin/ping}}). * When an entire host is suspected, we suspect *all* clusters members on it ** Example: if B suspects 192.168.1.5, members X, Y and Z are suspected and removed from the view > FD_HOST: host failure detection protocol > ---------------------------------------- > > Key: JGRP-1855 > URL: https://issues.jboss.org/browse/JGRP-1855 > Project: JGroups > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.4.5, 3.5 > > > A new protocol similar to FD_PING which detects entire host failures and suspects all members on the failed host. > Features are: > * Contrary to FD_PING which uses a ring structure, FD_HOST will have everyone ping everybody else (similar to FD_ALL) > ** A structure keeps track of hosts (IP addresses) and members on those hosts > *** Example > ||192.168.1.2||192.168.1.3||192.168.1.5|| > |A,B,C|D,E,F|X,Y,Z| > * We sort the members lexically and the *first* member runs a ping against each other IP address, e.g. A pings 192.168.1.3 and 192.168.1.5, D pings 192.168.1.2 and 192.168.1.5 etc > * The ping command itself is pluggable and can be a Java class (e.g. using {{InetAddress.isReachable()}}, a script or a command (e.g. {{/sbin/ping}}). > * When an entire host is suspected, we suspect *all* cluster members on it > ** Example: if B suspects 192.168.1.5, members X, Y and Z are suspected and removed from the view -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2014