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] So is the original issue resolved now? > 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] (DROOLS-361) Incremental compilation requires to provide the list of modified files even if not necessary

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-361?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-361: ------------------------------------------------ Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1036807|https://bugzilla.redhat.com/show_bug.cgi?id=1036807] from NEW to MODIFIED > Incremental compilation requires to provide the list of modified files even if not necessary > -------------------------------------------------------------------------------------------- > > Key: DROOLS-361 > URL: https://issues.jboss.org/browse/DROOLS-361 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.0.1.Final > > > Incremental compilation requires to provide the list of the modified files since the last compilation. However this could be error-prone and violates the DRY principle, because this list could be automatically calculated. -- 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-361) Incremental compilation requires to provide the list of modified files even if not necessary

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-361?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-361: ------------------------------------------------ Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1036807|https://bugzilla.redhat.com/show_bug.cgi?id=1036807] from MODIFIED to ASSIGNED > Incremental compilation requires to provide the list of modified files even if not necessary > -------------------------------------------------------------------------------------------- > > Key: DROOLS-361 > URL: https://issues.jboss.org/browse/DROOLS-361 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.0.1.Final > > > Incremental compilation requires to provide the list of the modified files since the last compilation. However this could be error-prone and violates the DRY principle, because this list could be automatically calculated. -- 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-361) Incremental compilation requires to provide the list of modified files even if not necessary

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-361?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated DROOLS-361: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1036807 > Incremental compilation requires to provide the list of modified files even if not necessary > -------------------------------------------------------------------------------------------- > > Key: DROOLS-361 > URL: https://issues.jboss.org/browse/DROOLS-361 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.0.1.Final > > > Incremental compilation requires to provide the list of the modified files since the last compilation. However this could be error-prone and violates the DRY principle, because this list could be automatically calculated. -- 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-361) Incremental compilation requires to provide the list of modified files even if not necessary

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-361?page=com.atlassian.jira.plugin... ] Mario Fusco resolved DROOLS-361. -------------------------------- Fix Version/s: 6.0.1.Final Resolution: Done > Incremental compilation requires to provide the list of modified files even if not necessary > -------------------------------------------------------------------------------------------- > > Key: DROOLS-361 > URL: https://issues.jboss.org/browse/DROOLS-361 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.0.1.Final > > > Incremental compilation requires to provide the list of the modified files since the last compilation. However this could be error-prone and violates the DRY principle, because this list could be automatically calculated. -- 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: ------------------------------------ Thanks for reporting this issue! > 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] (DROOLS-361) Incremental compilation requires to provide the list of modified files even if not necessary

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-361: ---------------------------------- Summary: Incremental compilation requires to provide the list of modified files even if not necessary Key: DROOLS-361 URL: https://issues.jboss.org/browse/DROOLS-361 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Mario Fusco Assignee: Mario Fusco Incremental compilation requires to provide the list of the modified files since the last compilation. However this could be error-prone and violates the DRY principle, because this list could be automatically calculated. -- 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-364) a "failure-causes-rollback="false"" attribute for the filesystem scanner

by Martin Malina (JIRA)

[ https://issues.jboss.org/browse/WFLY-364?page=com.atlassian.jira.plugin.s... ] Martin Malina commented on WFLY-364: ------------------------------------ I just verified that with Wildfly 8.0.0.Beta1 it works as expected - a broken deployment doesn't break other modules when the server is restarted. And the broken deployment is marked as .failed. > a "failure-causes-rollback="false"" attribute for the filesystem scanner > ------------------------------------------------------------------------ > > Key: WFLY-364 > URL: https://issues.jboss.org/browse/WFLY-364 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Max Rydahl Andersen > Assignee: Emanuel Muckenhuber > Fix For: 8.0.0.CR1 > > > JBIDE-11509, AS7-783 and TORQUE-576 all talk about the problem of all deployments found at startup is deployed in one operation and if one deployment fails all is rolled back resulting in some rather bad usability issues - especially at development time, but even also at production time for those using file deployments. > Suggestion on irc was that there could be an option on the file scanner (possibly false by default?) to say that failure causes rollback. > Individual deployments could then still fail, but at least not everything would be rolledback and it would still allow proper interdependent deployments to work. -- 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 Michael Kozak (JIRA)

[ https://issues.jboss.org/browse/WFLY-2593?page=com.atlassian.jira.plugin.... ] Michael Kozak updated WFLY-2593: -------------------------------- Steps to Reproduce: Unpack a distribution of 7.1.1 community or EAP 6.2 beta. No changes are required to the configuration. 1. Deploy attached jmxp.ear.ear 2. Send a request to the application so a query gets executed: curl http://localhost:8080/jmxp/jmxp Expected output: queries executed Class is class org.hibernate.stat.internal.ConcurrentStatisticsImpl 3. Ask for queries: ./jboss-cli.sh --connect --command='/deployment=jmxp.ear.ear/subdeployment=jmxp.ejb.jar/subsystem=jpa/hibernate-persistence-unit=jmxp.ear.ear\/jmxp.ejb.jar\#fraudPU:read-children-resources(child-type=query-cache)' First time the result is fine. On subsequent requests with jboss-cli.sh new elements will appear although no requests were issued to the application. After a number of request (for example from a monitoring system) an OutOfMemoryError will occur. was: Unpack a distribution of 7.1.1 community or EAP 6.2 beta. No changes are required to the configuration. 1. Deploy attached jmxp.ear.ear 2. Send a request to the application so a query gets executed: curl http://localhost:8080/jmxp/jmxp Expected output: queries executed Class is class org.hibernate.stat.internal.ConcurrentStatisticsImpl 3. Ask for queries: ./jboss-cli.sh --connect --command='/deployment=jmxp.ear.ear/subdeployment=jmxp.ejb.jar/subsystem=jpa/hibernate-persistence-unit=jmxp.ear.ear\/jmxp.ejb.jar\#fraudPU:read-children-resources(child-type=query-cache)' First time the result is fine. On subsequent requests with jboss-cli.sh new elements will appear although no requests were issued to the application. After a number of request (for example from a monitoring system) an OutOfMemoryException will occur. > 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-2594) Undeploy of JSF application is throwing SEVERE messages, when there were deployed more JSF apps

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/WFLY-2594?page=com.atlassian.jira.plugin.... ] Farah Juma commented on WFLY-2594: ---------------------------------- Sure, I'll look into this. > Undeploy of JSF application is throwing SEVERE messages, when there were deployed more JSF apps > ----------------------------------------------------------------------------------------------- > > Key: WFLY-2594 > URL: https://issues.jboss.org/browse/WFLY-2594 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: JSF > Environment: WildFly Beta2-SNAPSHOT from 2013-12-02 > Reporter: Tomas Remes > Assignee: Farah Juma > > When you deploy more than one JSF application and then you undeploy one of them, you'll face following message in server log: > {noformat} > SEVERE [javax.faces] (MSC service thread 1-2) Unable to obtain InjectionProvider from init time FacesContext. Does this container implement the Mojarra Injection SPI? > SEVERE [javax.faces] (MSC service thread 1-2) Unable to call @PreDestroy annotated methods because no InjectionProvider can be found. Does this container implement the Mojarra Injection SPI? > {noformat} > I think javax.faces.FactoryFinder.FactoryManagerCache.getApplicationFactoryManager(ClassLoader) shouldn't try to create new instance of FactoryManager in this case. I am not really sure, what is special initialization case, but it seems to me that this should evaluate to true in this case (btw Does this javax.faces.FactoryFinder.FactoryManagerCache.detectSpecialInitializationCase(FacesContext) ever evaluate as true?). -- 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