December 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBJCA-1112) DataSource marked as Serializable

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1112?page=com.atlassian.jira.plugin... ] Paul Ferraro commented on JBJCA-1112: ------------------------------------- [~jesper.pedersen] I tried uncommenting the @Ignored test case mentioned in a previous comment: https://github.com/wildfly/wildfly/blob/master/testsuite/integration/clus... which reproduces this issue by testing the serialization of the following SFSB: https://github.com/wildfly/wildfly/blob/master/testsuite/integration/clus... However, this test still fails. Should reopen this jira? > DataSource marked as Serializable > --------------------------------- > > Key: JBJCA-1112 > URL: https://issues.jboss.org/browse/JBJCA-1112 > Project: IronJacamar > Issue Type: Bug > Components: JDBC > Affects Versions: 1.0.21.Final, 1.1.1.Final > Reporter: Paul Ferraro > Assignee: Jesper Pedersen > Priority: Critical > Fix For: 1.0.24.Final, 1.1.2.Final > > > See JBPAPP6-1762 for details. -- 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-2593) Memory leak in JBoss AS / Hibernate JPA integration

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-2593?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-2593: ------------------------------------ fix will probably be something like: {code} private boolean hasQuery(PathElement element) { boolean result = false; final PersistenceUnitService puService = persistenceUnitRegistry.getPersistenceUnitService(puName); final Statistics stats = getStatistics(); if (stats != null && puService != null) { final String scopedPUName = puService.getScopedPersistenceUnitName(); final String unqualifiedQueryName = element.getValue(); result = getQueryNames().contains(unqualifiedQueryName) } return result; } {code} > 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

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2595) Logging DUP leaking class loaders

by James Perkins (JIRA)

James Perkins created WFLY-2595: ----------------------------------- Summary: Logging DUP leaking class loaders Key: WFLY-2595 URL: https://issues.jboss.org/browse/WFLY-2595 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: Logging Reporter: James Perkins Assignee: James Perkins Priority: Critical Fix For: 8.0.0.CR1 When a new {{LogContext}} is created for per-deployment logging the class loader is registered as the key. On undeploy the {{LogContext}} should be removed, but the wrong {{LogContext}}t is retrieved due to the caller class loader being used rather than the TCCL. The use of the caller class loader is for filtering out system dependencies from the deployment so the correct {{LogContext}} is retrieved from the selector. -- 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-2507) InflowFlatTestCase and InflowJarTestCase are failing on Windows

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/WFLY-2507?page=com.atlassian.jira.plugin.... ] Jesper Pedersen commented on WFLY-2507: --------------------------------------- [~emmartins], feel free to assign to [~jeff.zhang]] if you don't have the cycles > InflowFlatTestCase and InflowJarTestCase are failing on Windows > --------------------------------------------------------------- > > Key: WFLY-2507 > URL: https://issues.jboss.org/browse/WFLY-2507 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JCA > Reporter: Brian Stansberry > Assignee: Eduardo Martins > Fix For: 8.0.0.CR1 > > > Tests are consisently failing on Windows but not on Linux: > http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WF&testNameI... > Typically that would indicate a problem that manifests when tests are run in a different order; i.e. one test leaving behind something that impacts another. > I suspect what's happening here is an RA is getting left behind and these tests are finding the wrong one and making assertions against it. > Note this in the test is used to find the RA id: > Set<String> ids = repository.getResourceAdapters(); > {code} > assertNotNull(ids); > System.out.println("////RA" + ids.toString()); > String piId = getElementContaining(ids, "MultipleResourceAdapter"); > {code} > The test logging shows there are two RAs that would match: > 03:45:54,709 INFO [stdout] (pool-1-thread-4) ////RA[org.jboss.as.test.integration.jca.rar.MultipleResourceAdapter#27, org.jboss.as.test.integration.jca.rar.MultipleResourceAdapter#28] -- 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] (DROOLS-360) Incremental compilation: Flawed for Rule Templates

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-360?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated DROOLS-360: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1036842 > Incremental compilation: Flawed for Rule Templates > -------------------------------------------------- > > Key: DROOLS-360 > URL: https://issues.jboss.org/browse/DROOLS-360 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Michael Anstis > Assignee: Mario Fusco > Fix For: 6.0.1.Final > > > Incremental compilation does not add new messages when a Rule Template is updated from being valid to being invalid. Full build with valid Rule Template passes; but Incremental Compilation with updated (and invalid) Rule Template does not lead to any "added" messages. > Updating a Rule Template from invalid to valid does however work. Full build with invalid Rule Template correctly returns error messages and Incremental Compilation with updated (and valid) Rule Template does lead to error message being removed. > Unit tests created (failing one @Ignored). -- 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] (DROOLS-360) Incremental compilation: Flawed for Rule Templates

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-360?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-360: ------------------------------------------------ Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1036842|https://bugzilla.redhat.com/show_bug.cgi?id=1036842] from NEW to ASSIGNED > Incremental compilation: Flawed for Rule Templates > -------------------------------------------------- > > Key: DROOLS-360 > URL: https://issues.jboss.org/browse/DROOLS-360 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Michael Anstis > Assignee: Mario Fusco > Fix For: 6.0.1.Final > > > Incremental compilation does not add new messages when a Rule Template is updated from being valid to being invalid. Full build with valid Rule Template passes; but Incremental Compilation with updated (and invalid) Rule Template does not lead to any "added" messages. > Updating a Rule Template from invalid to valid does however work. Full build with invalid Rule Template correctly returns error messages and Incremental Compilation with updated (and valid) Rule Template does lead to error message being removed. > Unit tests created (failing one @Ignored). -- 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] (DROOLS-360) Incremental compilation: Flawed for Rule Templates

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-360?page=com.atlassian.jira.plugin... ] Mario Fusco resolved DROOLS-360. -------------------------------- Fix Version/s: 6.0.1.Final Resolution: Done > Incremental compilation: Flawed for Rule Templates > -------------------------------------------------- > > Key: DROOLS-360 > URL: https://issues.jboss.org/browse/DROOLS-360 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Michael Anstis > Assignee: Mario Fusco > Fix For: 6.0.1.Final > > > Incremental compilation does not add new messages when a Rule Template is updated from being valid to being invalid. Full build with valid Rule Template passes; but Incremental Compilation with updated (and invalid) Rule Template does not lead to any "added" messages. > Updating a Rule Template from invalid to valid does however work. Full build with invalid Rule Template correctly returns error messages and Incremental Compilation with updated (and valid) Rule Template does lead to error message being removed. > Unit tests created (failing one @Ignored). -- 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] (DROOLS-360) Incremental compilation: Flawed for Rule Templates

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-360?page=com.atlassian.jira.plugin... ] Mario Fusco reassigned DROOLS-360: ---------------------------------- Assignee: Mario Fusco (was: Mark Proctor) > Incremental compilation: Flawed for Rule Templates > -------------------------------------------------- > > Key: DROOLS-360 > URL: https://issues.jboss.org/browse/DROOLS-360 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Michael Anstis > Assignee: Mario Fusco > > Incremental compilation does not add new messages when a Rule Template is updated from being valid to being invalid. Full build with valid Rule Template passes; but Incremental Compilation with updated (and invalid) Rule Template does not lead to any "added" messages. > Updating a Rule Template from invalid to valid does however work. Full build with invalid Rule Template correctly returns error messages and Incremental Compilation with updated (and valid) Rule Template does lead to error message being removed. > Unit tests created (failing one @Ignored). -- 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] (JBJCA-1112) DataSource marked as Serializable

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1112?page=com.atlassian.jira.plugin... ] Jesper Pedersen commented on JBJCA-1112: ---------------------------------------- Yes, for upstream, with a hack > DataSource marked as Serializable > --------------------------------- > > Key: JBJCA-1112 > URL: https://issues.jboss.org/browse/JBJCA-1112 > Project: IronJacamar > Issue Type: Bug > Components: JDBC > Affects Versions: 1.0.21.Final, 1.1.1.Final > Reporter: Paul Ferraro > Assignee: Jesper Pedersen > Priority: Critical > Fix For: 1.0.24.Final, 1.1.2.Final > > > See JBPAPP6-1762 for details. -- 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-1957) Upgrade Narayana to 5.0.0.M5

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/WFLY-1957?page=com.atlassian.jira.plugin.... ] Michael Musgrove resolved WFLY-1957. ------------------------------------ Resolution: Out of Date > Upgrade Narayana to 5.0.0.M5 > ---------------------------- > > Key: WFLY-1957 > URL: https://issues.jboss.org/browse/WFLY-1957 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: Transactions > Reporter: Paul Robinson > Assignee: Michael Musgrove > Fix For: 8.0.0.CR1 > > > In particular, needed for the fix to WFLY-1929. -- 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