March 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3102) EJB in WAR should inherit WAR's security domain

by Bill Burke (JIRA)

Bill Burke created WFLY-3102: -------------------------------- Summary: EJB in WAR should inherit WAR's security domain Key: WFLY-3102 URL: https://issues.jboss.org/browse/WFLY-3102 Project: WildFly Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Web (Undertow) Affects Versions: 8.0.0.Final Reporter: Bill Burke Assignee: Stuart Douglas If you define an EJB within WEB-INF/classes it does not inherit the security domain from the WAR file and defaults to "other". Counter-intuitive, IMO. Not sure if it is easily fixable though -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-2920) StackOverflowError when org.jboss.as.jacorb.rmi.InterfaceAnalysis is analyzing javax.ejb.EJBObject

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2920?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2920: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1064644|https://bugzilla.redhat.com/show_bug.cgi?id=1064644] from MODIFIED to ON_QA > StackOverflowError when org.jboss.as.jacorb.rmi.InterfaceAnalysis is analyzing javax.ejb.EJBObject > -------------------------------------------------------------------------------------------------- > > Key: WFLY-2920 > URL: https://issues.jboss.org/browse/WFLY-2920 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: IIOP > Affects Versions: 8.0.0.Final > Reporter: Osamu Nagano > Assignee: Stefan Guilhen > Attachments: td.dump > > > Depending on when a thread context switch happens, an IIOP enabled EJB fails to be deployed by throwing {{java.lang.StackOverflowError}}. Here is the stack trace from the attached thread dump. > {code} > "MSC service thread 1-7" prio=10 tid=0x00007f52e8001800 nid=0x4d12 at breakpoint[0x00007f534093f000] > java.lang.Thread.State: RUNNABLE > at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105) > at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53) > at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104) > at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50) > at org.jboss.as.jacorb.rmi.OperationAnalysis.<init>(OperationAnalysis.java:91) > at org.jboss.as.jacorb.rmi.InterfaceAnalysis.analyzeOperations(InterfaceAnalysis.java:116) > at org.jboss.as.jacorb.rmi.ContainerAnalysis.doAnalyze(ContainerAnalysis.java:186) > at org.jboss.as.jacorb.rmi.InterfaceAnalysis.doAnalyze(InterfaceAnalysis.java:62) > at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.as.jacorb.rmi.WorkCacheManager.doTheWork(WorkCacheManager.java:177) > at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105) > at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53) > at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104) > at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50) > at org.jboss.as.jacorb.rmi.OperationAnalysis.<init>(OperationAnalysis.java:91) > at org.jboss.as.jacorb.rmi.InterfaceAnalysis.analyzeOperations(InterfaceAnalysis.java:116) > at org.jboss.as.jacorb.rmi.ContainerAnalysis.doAnalyze(ContainerAnalysis.java:186) > at org.jboss.as.jacorb.rmi.InterfaceAnalysis.doAnalyze(InterfaceAnalysis.java:62) > at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > ... > at org.jboss.as.jacorb.rmi.WorkCacheManager.doTheWork(WorkCacheManager.java:177) > at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105) > at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53) > at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104) > at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50) > Locked ownable synchronizers: > - <0x00000000f9698790> (a java.util.concurrent.ThreadPoolExecutor$Worker) > {code} > The last part including {{Util.getTypeIDLName}} has been repeated as many as possible and the bottom of the stack has been lost. The same stack has been appeared in a different MSC service thread which is also executing an IIOP enabled EJB deployment. > The customer identified an improper synchronization in {{org.jboss.as.jacorb.rmi.WorkCacheManager#getAnalysis()}}. It is reproducible by manually controlling a thread context switch using a debugger. -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3094) Warn if there is no resource bound for address-settings expiry and dead-letter addresses

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3094?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3094: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1014099|https://bugzilla.redhat.com/show_bug.cgi?id=1014099] from MODIFIED to ON_QA > Warn if there is no resource bound for address-settings expiry and dead-letter addresses > ---------------------------------------------------------------------------------------- > > Key: WFLY-3094 > URL: https://issues.jboss.org/browse/WFLY-3094 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: JMS > Affects Versions: 8.0.0.Final > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 8.0.1.Final > > > Warns the user if a address-setting has defined an expiry-address or a dead-letter-address with no queue bound for them as this will result in unintended message loss. > WildFly default full configuration specifies an expiry address (jms.queue.ExpiryQueue) and dead-letter-addres (jms.queue.DLQ) for the # address settings (i.e. matching all addresses). > To have a consistent configuration, we must also define 2 queues that will be bound to these settings. -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3073) MBeanServer.createMBean methods that take a classloader don't work

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3073?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3073: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1073106|https://bugzilla.redhat.com/show_bug.cgi?id=1073106] from MODIFIED to ON_QA > MBeanServer.createMBean methods that take a classloader don't work > ------------------------------------------------------------------ > > Key: WFLY-3073 > URL: https://issues.jboss.org/browse/WFLY-3073 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JMX > Affects Versions: 8.0.0.Final > Reporter: Stuart Douglas > Assignee: Kabir Khan > Fix For: 8.0.1.Final > > > The MBeanServer.createMBean methods that take an "ObjectName loaderName" argument are completely broken in EAP 6. > These methods call findDelegate to make sure there is already an existing MBean registered with the given name passed in for the new MBean, or else it throws an exception. > This is obviously wrong, as there'd be no point in calling createMBean if it already existed. > javax.management.InstanceNotFoundException: test:service=Test > at org.jboss.as.jmx.PluggableMBeanServerImpl.findDelegate(PluggableMBeanServerImpl.java:1083) > at org.jboss.as.jmx.PluggableMBeanServerImpl.createMBean(PluggableMBeanServerImpl.java:253) -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3069) slaves cannot reconnect to a restarted master if RBAC is enabled

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3069?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3069: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1072915|https://bugzilla.redhat.com/show_bug.cgi?id=1072915] from MODIFIED to ON_QA > slaves cannot reconnect to a restarted master if RBAC is enabled > ---------------------------------------------------------------- > > Key: WFLY-3069 > URL: https://issues.jboss.org/browse/WFLY-3069 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.Final > Reporter: Tom Fonteyne > Assignee: Emanuel Muckenhuber > Priority: Critical > Fix For: 8.0.1.Final > > > Enable RBAC in an Wilfly domain setup. "reload --host=master" and the slaves will no longer be connected to the master -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3071) upgrade Generic JMS RA to 1.0.2.Final

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3071?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3071: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1073354|https://bugzilla.redhat.com/show_bug.cgi?id=1073354] from MODIFIED to ON_QA > upgrade Generic JMS RA to 1.0.2.Final > ------------------------------------- > > Key: WFLY-3071 > URL: https://issues.jboss.org/browse/WFLY-3071 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: JCA > Affects Versions: 8.0.0.Final > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 8.0.1.Final > > -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3077) Convert command line IPv6 URL literals to address literals

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3077?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3077: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1064771|https://bugzilla.redhat.com/show_bug.cgi?id=1064771] from MODIFIED to ON_QA > Convert command line IPv6 URL literals to address literals > ---------------------------------------------------------- > > Key: WFLY-3077 > URL: https://issues.jboss.org/browse/WFLY-3077 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Affects Versions: 8.0.0.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > Fix For: 8.0.1.Final > > > When people provide URL-style values like [::1] for command line args like -b, convert them to address values (i.e. strip the enclosing brackets.) -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3078) directory-grouping configuration is not getting persisted via CLI when no servers defined

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3078?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3078: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1073715|https://bugzilla.redhat.com/show_bug.cgi?id=1073715] from MODIFIED to ON_QA > directory-grouping configuration is not getting persisted via CLI when no servers defined > ----------------------------------------------------------------------------------------- > > Key: WFLY-3078 > URL: https://issues.jboss.org/browse/WFLY-3078 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.Final > Environment: All Operating System > Reporter: Jay Kumar SenSharma > Assignee: Emanuel Muckenhuber > Fix For: 8.0.1.Final > > > - If none of the servers are defined in "host.xml" (means <servers></servers> empty tag is present) and if the user tries to run the following CLI command to change the "directory-grouping" to "by-type" then the value is not persisted in the configuration file (host.xml) and the <servers></servers> tag is also removed from the host.xml > {code} > /host=master/:write-attribute(name=directory-grouping,value=by-type) > {code} > - The value of "directory-grouping" is stored "in memory" so this change does not survive the host restart. -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3042) There should be a warning logged if the default value of node identifier has not been changed.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3042?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3042: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1072312|https://bugzilla.redhat.com/show_bug.cgi?id=1072312] from MODIFIED to ON_QA > There should be a warning logged if the default value of node identifier has not been changed. > ------------------------------------------------------------------------------------------------ > > Key: WFLY-3042 > URL: https://issues.jboss.org/browse/WFLY-3042 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Transactions > Affects Versions: 8.0.0.Final > Environment: JBoss EAP 6.x > Reporter: Tom Ross > Assignee: Gytis Trikleris > > JBoss EAP instance is using the value of node identifier to identify XA transactions that belong to it. By default this value is set to 1. Now days in most environments there will be multiple JBoss instances sharing XA resources there for it is necessary to set the value of node identifier to a unique value for each instance. This is something that most end users fail to perform. Therefor it would be helpful if a warning message was logged at startup telling the user to do it. -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3007) Ipv6 addresses may not be canonized properly

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3007?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3007: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1067348|https://bugzilla.redhat.com/show_bug.cgi?id=1067348] from MODIFIED to ON_QA > Ipv6 addresses may not be canonized properly > -------------------------------------------- > > Key: WFLY-3007 > URL: https://issues.jboss.org/browse/WFLY-3007 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 8.0.0.Final > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > > On an ipv6 environment we may obtain IP addresses that are not properly canonized which may lead to strange issue with http proxies since the JDK ProxySelector relies on char per char matching. > All call to InetAddress.getHostName() may produce such an uncanonized address. -- 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

12 years, 1 month

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 March 2014