December 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-69) Using an extended persistence context in a stateless session bean should throw an exception

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-69?page=com.atlassian.jira.plugin.sy... ] Jason Greene updated WFLY-69: ----------------------------- Fix Version/s: 8.0.0.Final > Using an extended persistence context in a stateless session bean should throw an exception > ------------------------------------------------------------------------------------------- > > Key: WFLY-69 > URL: https://issues.jboss.org/browse/WFLY-69 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JPA / Hibernate > Reporter: Karsten Wutzke > Fix For: 8.0.0.CR1, 8.0.0.Final > > > Using an extended persistence context in a stateless session bean should not initiate. It should throw an exception to notify the user of incorrect use. > See JPA 2.0 spec, section 7.6.2: > "A container-managed extended persistence context can only be initiated within the scope of a stateful session bean." -- 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

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-362) provide means to specify allowed ciphers for management https or change default to exclude weak ciphers

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-362?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-362: ------------------------------ Fix Version/s: (was: 8.0.0.CR1) > provide means to specify allowed ciphers for management https or change default to exclude weak ciphers > ------------------------------------------------------------------------------------------------------- > > Key: WFLY-362 > URL: https://issues.jboss.org/browse/WFLY-362 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management, Security > Reporter: R Stokoe > Assignee: Darran Lofthouse > Fix For: 8.0.0.Final > > > Provide means to specify allowed ciphers for management https. -- 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

10 years, 6 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: (was: 8.0.0.CR1) > 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.0.0.Final > > > 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 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

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-80) Product Version should not prepend product name with JBoss

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-80?page=com.atlassian.jira.plugin.sy... ] Jason Greene updated WFLY-80: ----------------------------- Fix Version/s: 8.0.0.Final > Product Version should not prepend product name with JBoss > ---------------------------------------------------------- > > Key: WFLY-80 > URL: https://issues.jboss.org/browse/WFLY-80 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Server > Reporter: NadirX > Assignee: Jason Greene > Priority: Minor > Fix For: 8.0.0.CR1, 8.0.0.Final > > > version/src/main/java/org/jboss/as/version/ProductConfig.java prepends the Product Name with 'JBoss' which is inappropriate for community projects. The result is that at startup I get the following > "INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss Infinispan Server 5.3.0-SNAPSHOT (AS 7.2.0.Final) started in 3059ms" > where instead I should see > "INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: Infinispan Server 5.3.0-SNAPSHOT (AS 7.2.0.Final) started in 3059ms" -- 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

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-366) Add support for grouping to Infinispan subsystem

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-366?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-366: ------------------------------ Fix Version/s: (was: 8.0.0.CR1) > Add support for grouping to Infinispan subsystem > ------------------------------------------------ > > Key: WFLY-366 > URL: https://issues.jboss.org/browse/WFLY-366 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Clustering > Reporter: Martin Gencur > Assignee: Tristan Tarrant > Fix For: 8.0.0.Final > > > Enable setting of groups in Infinispan subsystem. More information about grouping can be found at https://docs.jboss.org/author/display/ISPN/The+Grouping+API. > It should be possible to enable it as well as set a grouper class. The following is respective configuration for standalone Infinispan. > {code:xml} > <clustering> > <hash> > <groups enabled="true"> > <grouper class="com.acme.KXGrouper" /> > </groups> > </hash> > </clustering> > {code} -- 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

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-375) Add support to specify ciphers available with Remoting

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-375?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-375: ------------------------------ Fix Version/s: (was: 8.0.0.CR1) > Add support to specify ciphers available with Remoting > ------------------------------------------------------ > > Key: WFLY-375 > URL: https://issues.jboss.org/browse/WFLY-375 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management, Remoting, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 8.0.0.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

10 years, 6 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.0.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 (JBoss Web) > Reporter: David Lloyd > Assignee: Remy Maucherat > Fix For: 8.0.0.CR1, 8.0.0.Final > > > 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 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

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-377) Provide "destroy-queue" and "destroy-topic" operations to CLI

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-377?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-377: ------------------------------ Fix Version/s: (was: 8.0.0.CR1) > Provide "destroy-queue" and "destroy-topic" operations to CLI > ------------------------------------------------------------- > > Key: WFLY-377 > URL: https://issues.jboss.org/browse/WFLY-377 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: CLI, JMS > Reporter: Miroslav Novak > Assignee: Alexey Loubyansky > Fix For: 8.0.0.Final > > > Operations "destroy-queue" and "destroy-topic" would destroy queue/topic with all its messages and subscriptions. > They would be used under for example /subsystem=messaging/hornetq-server=default/jms-queue=testQueue or /subsystem=messaging/hornetq-server=default/jms-topic=testTopic. > The goal is to provide a simple way how to get rid of those objects to administrators. -- 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

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-89) Spurious server dirs created when directory-grouping="by-type" is set

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-89?page=com.atlassian.jira.plugin.sy... ] Jason Greene updated WFLY-89: ----------------------------- Fix Version/s: 8.0.0.Final > Spurious server dirs created when directory-grouping="by-type" is set > --------------------------------------------------------------------- > > Key: WFLY-89 > URL: https://issues.jboss.org/browse/WFLY-89 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Brian Stansberry > Assignee: James Perkins > Priority: Minor > Fix For: 8.0.0.CR1, 8.0.0.Final > > > Add directory-grouping="by-type" to the <host><servers> element in the stock host.xml and run domain.sh. The following empty directories are created: > $JBOSS_HOME/domain/servers/server-one > $JBOSS_HOME/domain/servers/server-two > The content that would normally be in those dirs if directory-grouping="by-type" wasn't set appears to all be going where it should (e.g. under domain/data, domain/log etc) so the only issue here is the empty directories. -- 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

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-122) Clean unreferenced deployments from the content repository

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-122?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-122: ------------------------------ Fix Version/s: 8.0.0.Final > Clean unreferenced deployments from the content repository > ---------------------------------------------------------- > > Key: WFLY-122 > URL: https://issues.jboss.org/browse/WFLY-122 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 8.0.0.CR1, 8.0.0.Final > > > The algorithm for removing unused deployments from the content repository is based on doing this as part of undeploy operation execution. This doesn't cover cases where the content is never explicitly undeployed. For example: > 1) Scanner content that is updated when the server is offline; the old content will not have been "undeployed" during shutdown, and on startup the new content will be installed. > 2) Similar issues with deployments generated from module resources (see "A Mixed Approach on https://community.jboss.org/wiki/ExtendingAS7). When the server shuts down, there is no "subsystem remove" as part of shutdown, so the content added during start will not be removed. -- 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

10 years, 6 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 December 2013