April 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1518) JMXFacade write attribute notifications are not filtered according to where they are registered

by Kabir Khan (JIRA)

Kabir Khan created WFCORE-1518: ---------------------------------- Summary: JMXFacade write attribute notifications are not filtered according to where they are registered Key: WFCORE-1518 URL: https://issues.jboss.org/browse/WFCORE-1518 Project: WildFly Core Issue Type: Feature Request Components: Domain Management Reporter: Kabir Khan Assignee: Jeff Mesnil If I register a jmx notification listener for jboss.as:management-root=server, I also see notifications for child resources such as: javax.management.AttributeChangeNotification[source=jboss.as:core-service=management,access=authorization][type=jmx.attribute.change][message=WFLYCTL0360: The attribute provider value has been changed from undefined to "simple".] The filter in ModelControllerMBeanServerPlugin.JMXNotificationHandler does not take into account where the listener was registered. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6574) Cloud environment example profiles still specify default multicast-based socket bindings

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-6574: ------------------------------------ Summary: Cloud environment example profiles still specify default multicast-based socket bindings Key: WFLY-6574 URL: https://issues.jboss.org/browse/WFLY-6574 Project: WildFly Issue Type: Enhancement Components: Clustering Affects Versions: 10.0.0.Final, 9.0.2.Final, 8.2.1.Final Reporter: Radoslav Husar Assignee: Radoslav Husar Priority: Minor -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6210) Example ec2/gossip/azure server profiles do not have any modifications from the standard HA profiles (missing proper discovery protocols)

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6210?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-6210: --------------------------------- Affects Version/s: 9.0.2.Final 9.0.1.Final 9.0.0.Final > Example ec2/gossip/azure server profiles do not have any modifications from the standard HA profiles (missing proper discovery protocols) > ----------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-6210 > URL: https://issues.jboss.org/browse/WFLY-6210 > Project: WildFly > Issue Type: Bug > Components: Build System > Affects Versions: 9.0.0.Final, 9.0.1.Final, 9.0.2.Final, 10.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Critical > Fix For: 10.1.0.Final > > > {noformat} > [rhusar@syrah wildfly-10.1.0.Final-SNAPSHOT]$ diff -s standalone/configuration/standalone_xml_history/standalone-ha.initial.xml docs/examples/configs/standalone-ec2-ha.xml > Files standalone/configuration/standalone_xml_history/standalone-ha.initial.xml and docs/examples/configs/standalone-ec2-ha.xml are identical > {noformat} > {noformat} > [rhusar@syrah wildfly-10.1.0.Final-SNAPSHOT]$ diff -s standalone/configuration/standalone_xml_history/standalone-ha.initial.xml docs/examples/configs/standalone-gossip-ha.xml > Files standalone/configuration/standalone_xml_history/standalone-ha.initial.xml and docs/examples/configs/standalone-gossip-ha.xml are identical > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6554) Cache configuration are not eagerly defined in Cache Container

by Mathieu Lachance (JIRA)

[ https://issues.jboss.org/browse/WFLY-6554?page=com.atlassian.jira.plugin.... ] Mathieu Lachance commented on WFLY-6554: ---------------------------------------- I think I should have used the SharedInfinispanRegionFactory which seems more suited to JPA. That said, the implementation is very similar and I end up with the same NPE. Since our application is Spring based, to wire the EntityManager we exports many of the Wildfly provided libraries within the jboss-deployment-structure.xml (partial listing): {code} <module name="org.hibernate" services="import" slot="main"/> <module name="org.hibernate.infinispan" services="import" slot="main"/> <module name="org.hibernate.jipijapa-hibernate5" services="import" slot="main"/> <module name="org.infinispan.commons" services="import" slot="main"/> <module name="org.infinispan" services="import" slot="main"/> <module name="org.javassist" services="import" slot="main"/> <module name="org.jboss.as.clustering.infinispan" services="import" slot="main"/> <module name="org.jboss.logging" services="import" slot="main"/> <module name="org.jgroups" services="import" slot="main"/> {code} In our persistence.xml we use the following vendor properties for the second level cache integration: {code} hibernate.cache.use_query_cache=true hibernate.cache.use_second_level_cache=true hibernate.cache.region_prefix=the_name_of_our_war hibernate.cache.region.factory_class=org.jboss.as.jpa.hibernate5.infinispan.SharedInfinispanRegionFactory {code} In the standalone.xml we have kept the almost same default configuration (basically we just enabled statistics): {code} <cache-container name="hibernate" default-cache="local-query" module="org.hibernate" statistics-enabled="true"> <transport lock-timeout="60000"/> <local-cache name="local-query" statistics-enabled="true"> <eviction strategy="LIRS" max-entries="10000"/> <expiration max-idle="100000"/> </local-cache> <invalidation-cache name="entity" statistics-enabled="true" mode="SYNC"> <transaction mode="NON_XA"/> <eviction strategy="LIRS" max-entries="10000"/> <expiration max-idle="100000"/> </invalidation-cache> <replicated-cache name="timestamps" statistics-enabled="true" mode="ASYNC"/> </cache-container> {code} After that, when trying to bootstrap the EntityManager through Spring, this will result in the following stack trace: {code} Caused by: org.hibernate.service.spi.ServiceException: Unable to create requested service [org.hibernate.engine.spi.CacheImplementor] at org.hibernate.service.internal.AbstractServiceRegistryImpl.createService(AbstractServiceRegistryImpl.java:244) at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:208) at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:189) at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:242) at org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:444) at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:879) ... 64 more Caused by: org.hibernate.cache.CacheException: java.lang.NullPointerException at org.jboss.as.jpa.hibernate5.infinispan.SharedInfinispanRegionFactory.createCacheManager(SharedInfinispanRegionFactory.java:60) at org.hibernate.cache.infinispan.InfinispanRegionFactory.start(InfinispanRegionFactory.java:380) at org.hibernate.internal.CacheImpl.<init>(CacheImpl.java:49) at org.hibernate.engine.spi.CacheInitiator.initiateService(CacheInitiator.java:28) at org.hibernate.engine.spi.CacheInitiator.initiateService(CacheInitiator.java:20) at org.hibernate.service.internal.SessionFactoryServiceRegistryImpl.initiateService(SessionFactoryServiceRegistryImpl.java:46) at org.hibernate.service.internal.AbstractServiceRegistryImpl.createService(AbstractServiceRegistryImpl.java:234) ... 69 more Caused by: java.lang.NullPointerException at org.jboss.as.jpa.hibernate5.infinispan.SharedInfinispanRegionFactory.createCacheManager(SharedInfinispanRegionFactory.java:58) ... 75 more {code} Let me know if I can provide you any other informations, thanks! > Cache configuration are not eagerly defined in Cache Container > -------------------------------------------------------------- > > Key: WFLY-6554 > URL: https://issues.jboss.org/browse/WFLY-6554 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.Final, 10.1.0.Final > Reporter: Mathieu Lachance > Assignee: Paul Ferraro > > In WF8 we used the cache configuration start="EAGER" to force the initialization of the cache configuration. > In my scenario, we especially used that trick to define all cache configuration (i.e. entity / timestamps / local-query) in the hibernate cache container before any of our war was deployed. Doing so, when wiring the EntityManager programatically (in our application), we were able to depend on the JNDIRegionFactory without getting any NullPointerException/etc. > This trick has only one bad side effect, which was the creation of unecessary caches. > Now in WF10, the eager feature is gone and it seems that even if the cache container is available at startup (as discussed in: https://developer.jboss.org/thread/259151) the defined caches are not. > I do not know if this is a bug or this is by design but this seems wrong to me. > If we define caches within standalone.xml, I would definitly like to have them defined at the container level. I think it's fair to assume that when pulling the CacheManager all defined caches should have been there. > I would suggest that when reading all the infinispan subsystem, each cache contained in each cache container be eagerly defined to avoid any issue (and I really meant "defined" and not "started"). > Doing so this would resolve our EntityManager second level cache bootstraping without relying on our application to define the missing cache configuration. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1144) Missing equals/hashCode in ClassFieldImpl

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1144?page=com.atlassian.jira.plugi... ] Mario Fusco closed DROOLS-1144. ------------------------------- Fix Version/s: 7.0.0.Beta1 Resolution: Done Fixed by https://github.com/droolsjbpm/drools/commit/7d0c204864b809f836eba61435d35... > Missing equals/hashCode in ClassFieldImpl > ----------------------------------------- > > Key: DROOLS-1144 > URL: https://issues.jboss.org/browse/DROOLS-1144 > Project: Drools > Issue Type: Bug > Components: core engine > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 7.0.0.Beta1 > > > An alpha constraint with a Class literal is not hashed/compared correctly due to the missing equals/hashCode method in ClassFieldImpl. This causes the problem also reported here http://stackoverflow.com/questions/36845229/drools-condition-conflicts-co... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1517) can't start server with configuration file from EAP 6.4.7 (and above)

by Ladislav Thon (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1517?page=com.atlassian.jira.plugi... ] Ladislav Thon updated WFCORE-1517: ---------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1531 > can't start server with configuration file from EAP 6.4.7 (and above) > --------------------------------------------------------------------- > > Key: WFCORE-1517 > URL: https://issues.jboss.org/browse/WFCORE-1517 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Ladislav Thon > Assignee: Brian Stansberry > Priority: Blocker > > When trying to run WildFly 10 with a configuration file from EAP 6.4.7 (i.e. management version 1.8), presumably for migration, the server fails to boot with an error message like this: > {code} > 14:44:44,305 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1] > at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1] > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_92] > Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[3,1] > Message: Unexpected element '{urn:jboss:domain:1.8}server' > at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:108) [staxmapper-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1] > at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1] > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1] > ... 3 more > 14:44:44,306 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} > This is really because the {{org.jboss.as.controller.parsing.Namespace}} enum doesn't have a constant for management version 1.8. After fixing that, everything seems to work fine (I guess that the rest of the server is fully aware of mgmt version 1.8), so this was hopefully just this single omission. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6554) Cache configuration are not eagerly defined in Cache Container

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-6554?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on WFLY-6554: ------------------------------------ Can you post your hibernate configuration file? > Cache configuration are not eagerly defined in Cache Container > -------------------------------------------------------------- > > Key: WFLY-6554 > URL: https://issues.jboss.org/browse/WFLY-6554 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.Final, 10.1.0.Final > Reporter: Mathieu Lachance > Assignee: Paul Ferraro > > In WF8 we used the cache configuration start="EAGER" to force the initialization of the cache configuration. > In my scenario, we especially used that trick to define all cache configuration (i.e. entity / timestamps / local-query) in the hibernate cache container before any of our war was deployed. Doing so, when wiring the EntityManager programatically (in our application), we were able to depend on the JNDIRegionFactory without getting any NullPointerException/etc. > This trick has only one bad side effect, which was the creation of unecessary caches. > Now in WF10, the eager feature is gone and it seems that even if the cache container is available at startup (as discussed in: https://developer.jboss.org/thread/259151) the defined caches are not. > I do not know if this is a bug or this is by design but this seems wrong to me. > If we define caches within standalone.xml, I would definitly like to have them defined at the container level. I think it's fair to assume that when pulling the CacheManager all defined caches should have been there. > I would suggest that when reading all the infinispan subsystem, each cache contained in each cache container be eagerly defined to avoid any issue (and I really meant "defined" and not "started"). > Doing so this would resolve our EntityManager second level cache bootstraping without relying on our application to define the missing cache configuration. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1515) Improve PersistentResourceDefinition to make it easier to register attribute write handlers

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1515?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-1515: -------------------------------- Summary: Improve PersistentResourceDefinition to make it easier to register attribute write handlers (was: Improve PeristentResourceDefinition to make it easier to register attribute write handlers) > Improve PersistentResourceDefinition to make it easier to register attribute write handlers > ------------------------------------------------------------------------------------------- > > Key: WFCORE-1515 > URL: https://issues.jboss.org/browse/WFCORE-1515 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 3.0.0.Alpha1 > > > Currently if you want to take register custom write handler you need to override whole registerAttributes methods and do it yourself all the way. > We could add PersistentResourceDefinition.getAttributeHandlers() method that returns > a Map<String, OperationStepHandler>. > And then registerAttributes uses the map instead of hardcoding ReloadRequiredWriteAttributeHandler. Default impl just fills the map values with > ReloadRequiredWriteAttributeHandler. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6572) ageout-history does not report failures

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-6572?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-6572: ----------------------------------------------- Bartek Spyrko-Smietanko <bspyrkos(a)redhat.com> changed the Status of [bug 1331586|https://bugzilla.redhat.com/show_bug.cgi?id=1331586] from NEW to ASSIGNED > ageout-history does not report failures > ---------------------------------------- > > Key: WFLY-6572 > URL: https://issues.jboss.org/browse/WFLY-6572 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.0.0.Final > Reporter: Dennis Reed > Assignee: Jason Greene > > When ageout-history cannot delete the old CP files, it silently fails and returns "success". > LocalAgeoutHistoryHandler#recursiveDelete does keep track of whether the > delete failed or succeeded, but the return value from this method is ignored > in execute(...). > If recursiveDelete returns false, it should report a failure. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6572) ageout-history does not report failures

by Bartosz Spyrko-Śmietanko (JIRA)

[ https://issues.jboss.org/browse/WFLY-6572?page=com.atlassian.jira.plugin.... ] Bartosz Spyrko-Śmietanko reassigned WFLY-6572: ---------------------------------------------- Assignee: Bartosz Spyrko-Śmietanko (was: Jason Greene) > ageout-history does not report failures > ---------------------------------------- > > Key: WFLY-6572 > URL: https://issues.jboss.org/browse/WFLY-6572 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.0.0.Final > Reporter: Dennis Reed > Assignee: Bartosz Spyrko-Śmietanko > > When ageout-history cannot delete the old CP files, it silently fails and returns "success". > LocalAgeoutHistoryHandler#recursiveDelete does keep track of whether the > delete failed or succeeded, but the return value from this method is ignored > in execute(...). > If recursiveDelete returns false, it should report a failure. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 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 April 2016