January 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2725) Class-Path: . can cause JBAS011046: A component named 'TestBean' is already defined in this module

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2725?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-2725: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1049999 > Class-Path: . can cause JBAS011046: A component named 'TestBean' is already defined in this module > -------------------------------------------------------------------------------------------------- > > Key: WFLY-2725 > URL: https://issues.jboss.org/browse/WFLY-2725 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Server > Affects Versions: 8.0.0.CR1 > Reporter: Brad Maxwell > Assignee: Stuart Douglas > > 'JBAS011046: A component named > 'TestBean' is already defined in this module', I have narrowed it > down to it occurs if they have a jar manifest with Class-Path: . > It looks like when deploying it looks at the jar with the manifest > entry which then must be having it scan the jar containing the EJB > again and failing. > Having the Class-Path: . doesn't really make sense to me, however it > also seems like we should not be trying to deploy it twice. > It appears ManifestClassPathProcessor ignores the . when the Class-Path is in a jar at the root of an ear but not when the jar is in a war's WEB-INF/lib > server/src/main/java/org/jboss/as/server/deployment/module/ManifestClassPathProcessor.java -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2725) Class-Path: . can cause JBAS011046: A component named 'TestBean' is already defined in this module

by Brad Maxwell (JIRA)

Brad Maxwell created WFLY-2725: ---------------------------------- Summary: Class-Path: . can cause JBAS011046: A component named 'TestBean' is already defined in this module Key: WFLY-2725 URL: https://issues.jboss.org/browse/WFLY-2725 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: Server Affects Versions: 8.0.0.CR1 Reporter: Brad Maxwell Assignee: Stuart Douglas 'JBAS011046: A component named 'TestBean' is already defined in this module', I have narrowed it down to it occurs if they have a jar manifest with Class-Path: . It looks like when deploying it looks at the jar with the manifest entry which then must be having it scan the jar containing the EJB again and failing. Having the Class-Path: . doesn't really make sense to me, however it also seems like we should not be trying to deploy it twice. It appears ManifestClassPathProcessor ignores the . when the Class-Path is in a jar at the root of an ear but not when the jar is in a war's WEB-INF/lib server/src/main/java/org/jboss/as/server/deployment/module/ManifestClassPathProcessor.java -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2593) Memory leak in JBoss AS / Hibernate JPA integration

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2593?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2593: ----------------------------------------------- Carlo de Wolf <cdewolf(a)redhat.com> changed the Status of [bug 1037636|https://bugzilla.redhat.com/show_bug.cgi?id=1037636] from POST to MODIFIED > Memory leak in JBoss AS / Hibernate JPA integration > --------------------------------------------------- > > Key: WFLY-2593 > URL: https://issues.jboss.org/browse/WFLY-2593 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JPA / Hibernate > Affects Versions: No Release > Environment: JBoss 7.1.1 > JBoss EAP 6.2 beta > Reporter: Michael Kozak > Assignee: Scott Marlow > Priority: Critical > Fix For: No Release > > Attachments: jmxp.ear.ear, jmxp.tar.gz > > > The leak exists in AS integration code with Hibernate JPA. > When a persistence unit is deployed which has 2nd level cache and statistics enabled each query for "query-cache" elements produces new elements. > The issue lies in org.jboss.as.jpa.hibernate4.management.HibernateStatisticsResource. getQueryNames() method requests query names from Hibernate and applies QueryName.queryName(query).getDisplayName() to change names. Then for all queries hasQuery() is called which invokes stats.getQueryStatistics(). Within this method Hibernate creates a new object to track the statistics because the name is not found. > Possible solution is to reverse the work done by getDisplayName() but I'm not sure if it's the right thing to do. > This issue arised when we deployed jmxproxy application which was queried from Zabbix installation. For some MBean queries the implementation visits all MBeans deployed on the server. This kills the JVM after about 7 days. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2633) Cannot use deployments with same runtime-name in a domain

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2633?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2633: ----------------------------------------------- Carlo de Wolf <cdewolf(a)redhat.com> changed the Status of [bug 1039699|https://bugzilla.redhat.com/show_bug.cgi?id=1039699] from POST to MODIFIED > Cannot use deployments with same runtime-name in a domain > --------------------------------------------------------- > > Key: WFLY-2633 > URL: https://issues.jboss.org/browse/WFLY-2633 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 8.0.0.CR1 > > > The check for duplicate runtime-name in a server group on startup is too aggressive. It is incorrectly throwing an error on startup if there are any duplicate runtime-names in the whole domain, instead of just in a single server group. > Steps to Reproduce: > 1. Start a single HC/DC > 2. deploy --name=foo1 --runtime-name=bar --disabled testfile > 3. deploy --name=foo2 --runtime-name=bar --disabled testfile > 4. restart the DC/HC > Actual results: > JBAS010932: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration > ... > Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1348,9] > ... > Message: JBAS014664: An element of this type named 'bar' has already been declared > Expected results: > No errors -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2536) NPE in cli is thrown when using preserve, override without parameter

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2536?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2536: ----------------------------------------------- Emanuel Muckenhuber <emuckenh(a)redhat.com> changed the Status of [bug 1032041|https://bugzilla.redhat.com/show_bug.cgi?id=1032041] from NEW to ASSIGNED > NPE in cli is thrown when using preserve, override without parameter > -------------------------------------------------------------------- > > Key: WFLY-2536 > URL: https://issues.jboss.org/browse/WFLY-2536 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Patching > Affects Versions: 8.0.0.Beta1 > Reporter: Emanuel Muckenhuber > Assignee: Alexey Loubyansky > Priority: Minor > Fix For: 8.0.0.CR1 > > -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-782) EXTC with timeout not properly detected by loadPassword utility in login modules

by Peter Skopek (JIRA)

[ https://issues.jboss.org/browse/SECURITY-782?page=com.atlassian.jira.plug... ] Peter Skopek updated SECURITY-782: ---------------------------------- Fix Version/s: JBossSecurity_2.0.7.Final > EXTC with timeout not properly detected by loadPassword utility in login modules > -------------------------------------------------------------------------------- > > Key: SECURITY-782 > URL: https://issues.jboss.org/browse/SECURITY-782 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JBossSX > Affects Versions: JBossSecurity_2.0.6.Final > Reporter: Peter Skopek > Assignee: Peter Skopek > Fix For: JBossSecurity_2.0.7.Final > > > This is a backport of SECURITY-780. > Using cached external command with time out to get user credential in login modules if not properly detected as to call the external command. > Example: {EXTC:1000}/usr/bin/getmysecretpwd -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-782) EXTC with timeout not properly detected by loadPassword utility in login modules

by Peter Skopek (JIRA)

[ https://issues.jboss.org/browse/SECURITY-782?page=com.atlassian.jira.plug... ] Peter Skopek resolved SECURITY-782. ----------------------------------- Resolution: Done > EXTC with timeout not properly detected by loadPassword utility in login modules > -------------------------------------------------------------------------------- > > Key: SECURITY-782 > URL: https://issues.jboss.org/browse/SECURITY-782 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JBossSX > Affects Versions: JBossSecurity_2.0.6.Final > Reporter: Peter Skopek > Assignee: Peter Skopek > Fix For: JBossSecurity_2.0.7.Final > > > This is a backport of SECURITY-780. > Using cached external command with time out to get user credential in login modules if not properly detected as to call the external command. > Example: {EXTC:1000}/usr/bin/getmysecretpwd -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2715) Upgrade to PicketBox 4.0.20.Beta4

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-2715?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-2715. ---------------------------------- Resolution: Done > Upgrade to PicketBox 4.0.20.Beta4 > --------------------------------- > > Key: WFLY-2715 > URL: https://issues.jboss.org/browse/WFLY-2715 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: Security > Affects Versions: 8.0.0.CR1 > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1766) NAKACK2/UNICAST3: faster acceptance test

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1766?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1766: --------------------------- Comment: was deleted (was: I need to retract the previous comment: message batches received by NAKACK2 have the same dest: so either all messages in a batch have dest=null or all messages have dest!= null ! So the first comment is still valid and this optimization can be also be done for NAKACK2 !) > NAKACK2/UNICAST3: faster acceptance test > ---------------------------------------- > > Key: JGRP-1766 > URL: https://issues.jboss.org/browse/JGRP-1766 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5 > > > In NAKACK2/UNICAST3, when a message batch is received, we check every single message for presence of the corresponding header. If present we accept (and later process) the message. > A faster acceptance test would be to check if the destination of the message batch matches, e.g. > * UNICAST3: {{MessageBatch.getDest() != null}} > * NAKACK2: {{MessageBatch.getDest() == nul}} > If these conditions are false, we simply pass the batch up. This is faster than iterating through every message in the batch. > Same for single messages: this is already done in UNICAST3, but not in NAKACK2. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-782) EXTC with timeout not properly detected by loadPassword utility in login modules

by Peter Skopek (JIRA)

[ https://issues.jboss.org/browse/SECURITY-782?page=com.atlassian.jira.plug... ] Peter Skopek updated SECURITY-782: ---------------------------------- Description: This is a backport of SECURITY-780. Using cached external command with time out to get user credential in login modules if not properly detected as to call the external command. Example: {EXTC:1000}/usr/bin/getmysecretpwd was: Using cached external command with time out to get user credential in login modules if not properly detected as to call the external command. Example: {EXTC:1000}/usr/bin/getmysecretpwd > EXTC with timeout not properly detected by loadPassword utility in login modules > -------------------------------------------------------------------------------- > > Key: SECURITY-782 > URL: https://issues.jboss.org/browse/SECURITY-782 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JBossSX > Affects Versions: JBossSecurity_2.0.6.Final > Reporter: Peter Skopek > Assignee: Peter Skopek > > This is a backport of SECURITY-780. > Using cached external command with time out to get user credential in login modules if not properly detected as to call the external command. > Example: {EXTC:1000}/usr/bin/getmysecretpwd -- 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, 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 2014