June 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-1895) Provide a "default" role for management users with no other role specified

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-1895?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-1895: ------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.1.0.Final) > Provide a "default" role for management users with no other role specified > -------------------------------------------------------------------------- > > Key: WFLY-1895 > URL: https://issues.jboss.org/browse/WFLY-1895 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Domain Management, Security > Reporter: Jakub Cechacek > Assignee: Emanuel Muckenhuber > Labels: rbac-filed-by-qa > Fix For: 8.2.0.CR1 > > > Currently it seems that when using RBAC provider users with no defined role are unable to read domain model at all. Consequently logging into Admin Console leads to 500 error page. Similar errors in CLI. > In relation to this, it should be considered what is the expected behavior of unsecured management interface. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-343) lower messaging's min-large-message-size value in standalone-full.xml

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-343?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-343: ------------------------------ Fix Version/s: 8.2.0.CR1 (was: 8.1.0.Final) > lower messaging's min-large-message-size value in standalone-full.xml > --------------------------------------------------------------------- > > Key: WFLY-343 > URL: https://issues.jboss.org/browse/WFLY-343 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 8.2.0.CR1 > > > AS7's messaging subsystem defines 2 attributes: > journal-file-size => 10MiB > min-large-message-size => 100KiB > However, for startup performance issue, the standalone-full.xml sets the journal-file-size at 1OOKiB. This leads to issues since it's the same value than the min-large-message-size. > If we want to keep a low journal-file-size value in standalone-full.xml, the min-large-message-size must also bet set appropriately (eg 75KiB?) > For production use, however, we should suggest to the users to remove the journal-file-size and min-large-message-size from standalone-full.xml to use the default values (resp. 10MiB & 100KiB) -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-368) Naming subsystem <lookup> could use LinkRef/Reference

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-368?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-368: ------------------------------ Fix Version/s: 8.2.0.CR1 (was: 8.1.0.Final) > Naming subsystem <lookup> could use LinkRef/Reference > ----------------------------------------------------- > > Key: WFLY-368 > URL: https://issues.jboss.org/browse/WFLY-368 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Naming > Reporter: James Livingston > Assignee: Eduardo Martins > Fix For: 8.2.0.CR1 > > > NameBindingAdd.installLookup() sets up the machinery so that when Context.lookup() is done it looks up the redirected name and returns it. > It should be possible to do that by binding a LinkRef, Reference or similar object into JNDI instead. > Where this could make a difference is when Context.lookupLink() is called instead. > Currently if you have > <simple name="java:/v" value="hello"/> > <lookup name="java:/a" lookup="java:/b"/> > lookupLink("java:/a") will return "hello" rather a LinkRef/Reference/whatever pointing to java:/b. > We need to decide whether a <lookup> should be considered a "link" for the purposes of lookup() or not. If it should be considered one, then we should change NameBindingAdd.installLookup() to make lookupLink() return the other value. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2893) Determine cause of unreported test failures

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-2893?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-2893: ------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.1.0.Final) > Determine cause of unreported test failures > ------------------------------------------- > > Key: WFLY-2893 > URL: https://issues.jboss.org/browse/WFLY-2893 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Build System, Test Suite > Affects Versions: 8.0.0.CR1 > Reporter: Brian Stansberry > Assignee: Tomaz Cerar > Fix For: 8.2.0.CR1 > > > Identify the reason why the failing tests that needed https://github.com/wildfly/wildfly/commit/90643bc435a9ba439cf2988e5b7407d... to get working did not fail the build. Those tests were failing for 2.5 months. Fortunately it was just a test problem, not a broken feature. > They involved separate surefire executions. We want to avoid those, but sometimes they are needed to use different config files. We have separate executions in testsuite/integration/basic as well, covering a much broader scope, so if this kind of problem happened there as well we could have a big problem. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-465) Attribute check-for-live-server must set on live server to faillback

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-465?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-465: ------------------------------ Fix Version/s: 8.2.0.CR1 (was: 8.1.0.Final) > Attribute check-for-live-server must set on live server to faillback > -------------------------------------------------------------------- > > Key: WFLY-465 > URL: https://issues.jboss.org/browse/WFLY-465 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JMS > Reporter: Miroslav Novak > Assignee: Jeff Mesnil > Fix For: 8.2.0.CR1 > > Attachments: standalone-full-ha-backup.xml, standalone-full-ha-live.xml > > > When there is live/backup pair with replicated journal then it should be sufficient to set attribute "check-for-live-server" in messaging subsystem only on backup to force backup server to shutdown when live server comes alive again. Problem is this won't happen. > Only when attribute "check-for-live-server" is set on live server then failback is successful (backup shutdown itself) > It's not well documented where "check-for-live-server" should be set in HornetQ project documentation: > http://docs.jboss.org/hornetq/2.3.0.CR1/docs/user-manual/html_single/inde... > This issue was hit with EAP 6.1.0.DR2 (HQ 2.3.0.CR1). -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3110) Don't copy the contents to all hosts when assigning a deployment to a server-group

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-3110?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-3110: ------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.1.0.Final) > Don't copy the contents to all hosts when assigning a deployment to a server-group > ---------------------------------------------------------------------------------- > > Key: WFLY-3110 > URL: https://issues.jboss.org/browse/WFLY-3110 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.Final > Reporter: Emanuel Muckenhuber > Assignee: Emanuel Muckenhuber > Fix For: 8.2.0.CR1 > > > When assigning a deployment to a server-group it also copies the actual deployment contents to all hosts regardless of the whether the deployment is used locally or not. This should be changed that the contents are only retrieved if they are actually needed on a local server. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2275) StackOverflowError on DataSource resource injection

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-2275?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-2275: ------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.1.0.Final) > StackOverflowError on DataSource resource injection > --------------------------------------------------- > > Key: WFLY-2275 > URL: https://issues.jboss.org/browse/WFLY-2275 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Naming > Affects Versions: 8.0.0.Beta1 > Reporter: Thomas Diesler > Assignee: Thomas Diesler > Fix For: 8.2.0.CR1 > > Attachments: standalone-osgi.xml > > > {code} > @Resource(name="java:comp/DefaultDataSource") > public DataSource ds; > {code} > leads to > {code} > 10:59:21,901 INFO [org.jboss.osgi.framework] (MSC service thread 1-3) JBOSGI011001: Bundle installed: resource-injection.jar:0.0.0 > 10:59:21,937 INFO [org.jboss.as.arquillian] (MSC service thread 1-3) Arquillian deployment detected: ArquillianConfig[service=jboss.arquillian.config."resource-injection.jar",unit=resource-injection.jar,tests=[org.jboss.test.osgi.example.resource.ResourceInjectionTestCase]] > 10:59:21,993 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."resource-injection.jar".Activate: org.jboss.msc.service.StartException in service jboss.deployment.unit."resource-injection.jar".Activate: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > Caused by: java.lang.StackOverflowError > at java.util.Vector.<init>(Vector.java:127) [rt.jar:1.7.0_25] > at java.util.Vector.<init>(Vector.java:144) [rt.jar:1.7.0_25] > at java.util.Vector.<init>(Vector.java:153) [rt.jar:1.7.0_25] > at javax.naming.NameImpl.<init>(NameImpl.java:273) [rt.jar:1.7.0_25] > at javax.naming.NameImpl.<init>(NameImpl.java:277) [rt.jar:1.7.0_25] > at javax.naming.CompositeName.<init>(CompositeName.java:231) [rt.jar:1.7.0_25] > at org.jboss.as.naming.util.NameParser.parse(NameParser.java:49) > at org.jboss.as.naming.NamingContext.parseName(NamingContext.java:496) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184) > at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:302) > at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140) > at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:81) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184) > at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:302) > at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140) > at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:81) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184) > at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:302) > at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140) > at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:81) > {code} -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-84) Jasper using wrong ProtectionDomain for compiled JSP

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-84?page=com.atlassian.jira.plugin.sy... ] Jason Greene updated WFLY-84: ----------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.1.0.Final) > Jasper using wrong ProtectionDomain for compiled JSP > ---------------------------------------------------- > > Key: WFLY-84 > URL: https://issues.jboss.org/browse/WFLY-84 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Reporter: David Lloyd > Assignee: Remy Maucherat > Fix For: 8.2.0.CR1 > > > Compiled JSPs loaded via JasperLoader appear to be using a different ProtectionDomain than the rest of the WAR deployment. I think it should probably be using a PD which contains the permissions from the deployment's ClassLoader, and probably the CodeSource from the deployment unit from which the JSP file originated. This will ensure that permissions set via deployment descriptor and/or the management model will take proper effect. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-261) Add way to properly parse JNDI urls in AS codebase

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-261?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-261: ------------------------------ Fix Version/s: 8.2.0.CR1 (was: 8.1.0.Final) > Add way to properly parse JNDI urls in AS codebase > -------------------------------------------------- > > Key: WFLY-261 > URL: https://issues.jboss.org/browse/WFLY-261 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Naming > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Fix For: 8.2.0.CR1 > > > This is a followup of AS7-2138. Original code, in case no URL context threw NamingException. The AS7-2138 introduced a fallback to NamingContext in case AS7 does not provide custom hack for url( like EJB ). However the fallback did not fail with NamingException in case it did not locate Context. This essentially made it go knee deep into AS7 service lookups, which hides real cause of failure. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2620) Zero Timeout Stateful EJB Leak (clustered)

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-2620?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-2620: ------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.1.0.Final) > Zero Timeout Stateful EJB Leak (clustered) > ------------------------------------------ > > Key: WFLY-2620 > URL: https://issues.jboss.org/browse/WFLY-2620 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Reporter: Paul Ferraro > Assignee: Eduardo Martins > Fix For: 8.2.0.CR1 > > > Stateful EJB instances are not removed from cache upon release, if the timeout is zero. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2014