January 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1560) UnicastRequest.siteUnreachable does not check if it targets the site which is down

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JGRP-1560?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JGRP-1560: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 891662|https://bugzilla.redhat.com/show_bug.cgi?id=891662] from NEW to MODIFIED > UnicastRequest.siteUnreachable does not check if it targets the site which is down > ---------------------------------------------------------------------------------- > > Key: JGRP-1560 > URL: https://issues.jboss.org/browse/JGRP-1560 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.4 > Reporter: Radim Vansa > Assignee: Bela Ban > Fix For: 3.2.6, 3.3 > > > When {{RequestCorrelator}} holds several unicast requests to different sites and one of the sites becomes unreachable, it sets responses in all requests to unreachable. This is caused by {{UnicastRequest.siteUnreachable(short site)}} which checks that the target is a {{SiteAddress}} but not that the site in this address matches the unreachable site from the method argument. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
0
0 / 0

[JBoss JIRA] (AS7-6302) xa-datasource-properties are not writable

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/AS7-6302?page=com.atlassian.jira.plugin.s... ] Jesper Pedersen reassigned AS7-6302: ------------------------------------ Assignee: Stefano Maestri (was: Jesper Pedersen) > xa-datasource-properties are not writable > ----------------------------------------- > > Key: AS7-6302 > URL: https://issues.jboss.org/browse/AS7-6302 > Project: Application Server 7 > Issue Type: Feature Request > Components: JCA > Affects Versions: 7.1.1.Final, 7.1.2.Final (EAP) > Reporter: Akram Ben Aissi > Assignee: Stefano Maestri > > When trying to change a value of an xa-datasource-properties with the following command: > {code} > /subsystem=datasources/xa-data-source=testXA/xa-datasource-properties=User:write-attribute(name=value,value=Test) > {code} > One gets an error messaging saying: > {code} > { > "outcome" => "failed", > "failure-description" => "JBAS014639: Attribute value is not writable", > "rolled-back" => true, > "response-headers" => {"process-state" => "reload-required"} > } > {code} > However, the attribute can be removed and then re-added with different value, leading to a reload-required: > {code} > [standalone@localhost:9999 /] /subsystem=datasources/xa-data-source=testXA/xa-datasource-properties=User:remove() > {"outcome" => "success"} > [standalone@localhost:9999 /] /subsystem=datasources/xa-data-source=testXA/xa-datasource-properties=User:add(value=Test) > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > [standalone@localhost:9999 /] > {code} > To be consistent, the attribute value should be writable and also leads to a reload-required. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
0
0 / 0

[JBoss JIRA] (AS7-6031) deploy directories not cleaned up

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/AS7-6031?page=com.atlassian.jira.plugin.s... ] Bartosz Baranowski commented on AS7-6031: ----------------------------------------- jboss-as-quickstart apps: - wicket-ear - kitchensink-ear - ejb-in-ear > deploy directories not cleaned up > --------------------------------- > > Key: AS7-6031 > URL: https://issues.jboss.org/browse/AS7-6031 > Project: Application Server 7 > Issue Type: Bug > Affects Versions: 7.1.3.Final (EAP) > Reporter: Shaun Appleton > Assignee: Bartosz Baranowski > Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP) > > > JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories. > The following reproduces this - > i) ensure run.conf has the -Xrs set > ii) ensure deployments has a deployable .ear in it > iii) ./run standalone.sh and allow the deployments to deploy > iv) stop the EAP process ie kill <process_id> > v) observe content tmp/vfs > (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP) > This will eventually cause problems with lack of disk space. > Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems. > It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
0
0 / 0

[JBoss JIRA] (AS7-6302) xa-datasource-properties are not writable

by Heiko Braun (JIRA)

[ https://issues.jboss.org/browse/AS7-6302?page=com.atlassian.jira.plugin.s... ] Heiko Braun updated AS7-6302: ----------------------------- Assignee: Jesper Pedersen (was: Heiko Braun) Component/s: JCA (was: Console) > xa-datasource-properties are not writable > ----------------------------------------- > > Key: AS7-6302 > URL: https://issues.jboss.org/browse/AS7-6302 > Project: Application Server 7 > Issue Type: Feature Request > Components: JCA > Affects Versions: 7.1.1.Final, 7.1.2.Final (EAP) > Reporter: Akram Ben Aissi > Assignee: Jesper Pedersen > > When trying to change a value of an xa-datasource-properties with the following command: > {code} > /subsystem=datasources/xa-data-source=testXA/xa-datasource-properties=User:write-attribute(name=value,value=Test) > {code} > One gets an error messaging saying: > {code} > { > "outcome" => "failed", > "failure-description" => "JBAS014639: Attribute value is not writable", > "rolled-back" => true, > "response-headers" => {"process-state" => "reload-required"} > } > {code} > However, the attribute can be removed and then re-added with different value, leading to a reload-required: > {code} > [standalone@localhost:9999 /] /subsystem=datasources/xa-data-source=testXA/xa-datasource-properties=User:remove() > {"outcome" => "success"} > [standalone@localhost:9999 /] /subsystem=datasources/xa-data-source=testXA/xa-datasource-properties=User:add(value=Test) > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > [standalone@localhost:9999 /] > {code} > To be consistent, the attribute value should be writable and also leads to a reload-required. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
0
0 / 0

[JBoss JIRA] (AS7-6208) Admin console: Add paging to the server groups page

by Harald Pehl (JIRA)

[ https://issues.jboss.org/browse/AS7-6208?page=com.atlassian.jira.plugin.s... ] Harald Pehl commented on AS7-6208: ---------------------------------- See my comments on https://issues.jboss.org/browse/JBPAPP6-1754 > Admin console: Add paging to the server groups page > --------------------------------------------------- > > Key: AS7-6208 > URL: https://issues.jboss.org/browse/AS7-6208 > Project: Application Server 7 > Issue Type: Bug > Components: Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Fix For: 7.2.0.CR1 > > > The list of server groups is missing a pager. If more than 8 server groups were defined the 9th entry cannot be reached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-719) request.getRemoteUser() returns invalid username on EAP 6.0.1.ER4.2

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/SECURITY-719?page=com.atlassian.jira.plug... ] Darran Lofthouse commented on SECURITY-719: ------------------------------------------- The release that will be important is if this is reproducible in AS7/master. > request.getRemoteUser() returns invalid username on EAP 6.0.1.ER4.2 > ------------------------------------------------------------------- > > Key: SECURITY-719 > URL: https://issues.jboss.org/browse/SECURITY-719 > Project: PicketBox > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Negotiation > Affects Versions: Negotiation_2_2_1 > Environment: EAP 6.0.1.ER4.2 > SPNEGO setup with Kerberos > Kerberos user: demo(a)LOCAL.NETWORK > Reporter: Marek Posolda > Assignee: Darran Lofthouse > Fix For: Negotiation_2_2_2 > > > It seems that JBoss negotiation 2.2.1.Final doesn't work correctly on EAP 6.0.1.ER4.2. I am able to reproduce issue with SecuredServlet from negotiation toolkit. > I logged in through SPNEGO (Kerberos) and in SecuredServlet, I am seeing those outputs: > request.getUserPrincipal() returns principal with name "demo(a)LOCAL.NETWORK" -> OK > request.getRemoteUser() returns something like "dPC0cG6NhAUi88tSbvQar59M_1357729358922" -> FAILURE!!! > SecurityContextAssociation.getSecurityContext().getSubjectInfo().getIdentities().next() also returns "dPC0cG6NhAUi88tSbvQar59M_1357729358922" => FAILURE!!! > Note that JBoss Negotiation 2.2.1.Final works correctly on JBoss AS 7.1.3 but it failed only on EAP 6.0.1.ER4.2. The reason is not related to Negotiation itself, but due to changes in behaviour in related libraries like jboss-as-web and picketbox-infinispan. > In NegotiationAuthenticator the call to JBossWebRealm: > principal = realm.authenticate(username, (String) null); > now returns JBossGenericPrincipal with username taken from calling username. So it's something like "dPC0cG6NhAUi88tSbvQar59M_1357729358922" as calling username is only placeholder computed from sessionId and system time. > Previously the username was taken from principal of JAAS authenticated user, which correctly returned "demo(a)LOCAL.NETWORK". > So the bug seems to be due to changes in JBossWebRealm and maybe also picketbox classes like JBossCachedAuthenticationManager (seeing that cache key is now also calling username instead of username of authenticated principal). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-719) request.getRemoteUser() returns invalid username on EAP 6.0.1.ER4.2

by Marek Posolda (JIRA)

[ https://issues.jboss.org/browse/SECURITY-719?page=com.atlassian.jira.plug... ] Marek Posolda commented on SECURITY-719: ---------------------------------------- Note about version: AS 7.1.3 which works correctly is using: jboss-as-web-7.1.3.Final.jar (Library with JBossWebRealm class) picketbox-infinispan-4.0.13.Final.jar (Library with JbossCachedAuthenticationManager class) EAP 6.0.1.ER4.2 which doesn't work correctly is using: jboss-as-web-7.1.3.Final-redhat-4.jar picketbox-infinispan-4.0.14.Fianl-redhat-2.jar > request.getRemoteUser() returns invalid username on EAP 6.0.1.ER4.2 > ------------------------------------------------------------------- > > Key: SECURITY-719 > URL: https://issues.jboss.org/browse/SECURITY-719 > Project: PicketBox > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Negotiation > Affects Versions: Negotiation_2_2_1 > Environment: EAP 6.0.1.ER4.2 > SPNEGO setup with Kerberos > Kerberos user: demo(a)LOCAL.NETWORK > Reporter: Marek Posolda > Assignee: Darran Lofthouse > Fix For: Negotiation_2_2_2 > > > It seems that JBoss negotiation 2.2.1.Final doesn't work correctly on EAP 6.0.1.ER4.2. I am able to reproduce issue with SecuredServlet from negotiation toolkit. > I logged in through SPNEGO (Kerberos) and in SecuredServlet, I am seeing those outputs: > request.getUserPrincipal() returns principal with name "demo(a)LOCAL.NETWORK" -> OK > request.getRemoteUser() returns something like "dPC0cG6NhAUi88tSbvQar59M_1357729358922" -> FAILURE!!! > SecurityContextAssociation.getSecurityContext().getSubjectInfo().getIdentities().next() also returns "dPC0cG6NhAUi88tSbvQar59M_1357729358922" => FAILURE!!! > Note that JBoss Negotiation 2.2.1.Final works correctly on JBoss AS 7.1.3 but it failed only on EAP 6.0.1.ER4.2. The reason is not related to Negotiation itself, but due to changes in behaviour in related libraries like jboss-as-web and picketbox-infinispan. > In NegotiationAuthenticator the call to JBossWebRealm: > principal = realm.authenticate(username, (String) null); > now returns JBossGenericPrincipal with username taken from calling username. So it's something like "dPC0cG6NhAUi88tSbvQar59M_1357729358922" as calling username is only placeholder computed from sessionId and system time. > Previously the username was taken from principal of JAAS authenticated user, which correctly returned "demo(a)LOCAL.NETWORK". > So the bug seems to be due to changes in JBossWebRealm and maybe also picketbox classes like JBossCachedAuthenticationManager (seeing that cache key is now also calling username instead of username of authenticated principal). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-719) request.getRemoteUser() returns invalid username on EAP 6.0.1.ER4.2

by Marek Posolda (JIRA)

Marek Posolda created SECURITY-719: -------------------------------------- Summary: request.getRemoteUser() returns invalid username on EAP 6.0.1.ER4.2 Key: SECURITY-719 URL: https://issues.jboss.org/browse/SECURITY-719 Project: PicketBox Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Negotiation Affects Versions: Negotiation_2_2_1 Environment: EAP 6.0.1.ER4.2 SPNEGO setup with Kerberos Kerberos user: demo(a)LOCAL.NETWORK Reporter: Marek Posolda Assignee: Darran Lofthouse Fix For: Negotiation_2_2_2 It seems that JBoss negotiation 2.2.1.Final doesn't work correctly on EAP 6.0.1.ER4.2. I am able to reproduce issue with SecuredServlet from negotiation toolkit. I logged in through SPNEGO (Kerberos) and in SecuredServlet, I am seeing those outputs: request.getUserPrincipal() returns principal with name "demo(a)LOCAL.NETWORK" -> OK request.getRemoteUser() returns something like "dPC0cG6NhAUi88tSbvQar59M_1357729358922" -> FAILURE!!! SecurityContextAssociation.getSecurityContext().getSubjectInfo().getIdentities().next() also returns "dPC0cG6NhAUi88tSbvQar59M_1357729358922" => FAILURE!!! Note that JBoss Negotiation 2.2.1.Final works correctly on JBoss AS 7.1.3 but it failed only on EAP 6.0.1.ER4.2. The reason is not related to Negotiation itself, but due to changes in behaviour in related libraries like jboss-as-web and picketbox-infinispan. In NegotiationAuthenticator the call to JBossWebRealm: principal = realm.authenticate(username, (String) null); now returns JBossGenericPrincipal with username taken from calling username. So it's something like "dPC0cG6NhAUi88tSbvQar59M_1357729358922" as calling username is only placeholder computed from sessionId and system time. Previously the username was taken from principal of JAAS authenticated user, which correctly returned "demo(a)LOCAL.NETWORK". So the bug seems to be due to changes in JBossWebRealm and maybe also picketbox classes like JBossCachedAuthenticationManager (seeing that cache key is now also calling username instead of username of authenticated principal). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
0
0 / 0

[JBoss JIRA] (AS7-6303) Upgrade to Remoting JMX 1.1.0.Final

by Darran Lofthouse (JIRA)

Darran Lofthouse created AS7-6303: ------------------------------------- Summary: Upgrade to Remoting JMX 1.1.0.Final Key: AS7-6303 URL: https://issues.jboss.org/browse/AS7-6303 Project: Application Server 7 Issue Type: Task Components: JMX, Remoting Reporter: Darran Lofthouse Assignee: Darran Lofthouse Priority: Blocker Fix For: 7.2.0.Alpha1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-57) Memory leak due to connection IDs being retained within JMXConnectorServer

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-57?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved REMJMX-57. ------------------------------------ Resolution: Done No further releases currently planned on the AS 7.1 branch so only fixing in master of remoting-jmx. > Memory leak due to connection IDs being retained within JMXConnectorServer > -------------------------------------------------------------------------- > > Key: REMJMX-57 > URL: https://issues.jboss.org/browse/REMJMX-57 > Project: Remoting JMX > Issue Type: Bug > Components: Connection > Affects Versions: 1.0.5.Final, 1.1.0.Beta2 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.CR1 > > > As connections are opened the identifier for the connection is registered with JMXConnectorServer - however on termination of the connection this registration is not cleared leading to a build up and leak. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2013