April 2016 - jboss-jira - Jboss List Archives

[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'd like very much to get rid of Spring, though this is not something possible. Is there a way to changes to change the requisites dependencies to make is start? I guess this is related to the "module" attribute within: {code} <cache-container name="hibernate" default-cache="local-query" module="org.hibernate" statistics-enabled="true"> {code} > 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, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1516) CLI, some completion issues

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1516?page=com.atlassian.jira.plugi... ] Jean-Francois Denise updated WFCORE-1516: ----------------------------------------- Description: 4 issues with command arguments completion: 1) " " and "=false" shouldn't be proposed for argument without values (that is a regression introduced by the support of implicit true value). 2) arguments without values used to stop completion to operate. For example ls --resolve-expressions should complete to the argument separator " " if no more arguments can be added. 3) "=" character is not appended to argument that has a value (that is a regression introduced by the support of implicit true value). 4) Exception in read-attribute completing the node read-attribute --node org.jboss.as.cli.CommandFormatException: Couldn't locate ' --node=' in the line: 'read-attribute --node' at org.jboss.as.cli.handlers.ReadAttributeHandler.getAddress(ReadAttributeHandler.java:325) at org.jboss.as.cli.handlers.ReadAttributeHandler$2.canAppearNext(ReadAttributeHandler.java:114) at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:257) at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:73) at org.jboss.as.cli.CommandCompleter.doComplete(CommandCompleter.java:126) at org.jboss.as.cli.CommandCompleter.complete(CommandCompleter.java:63) at org.jboss.as.cli.impl.Console$Factory$1$1.complete(Console.java:141) at org.jboss.aesh.console.AeshCompletionHandler.complete(AeshCompletionHandler.java:150) at org.jboss.aesh.console.AeshInputProcessor.complete(AeshInputProcessor.java:420) at org.jboss.aesh.console.AeshInputProcessor.parseOperation(AeshInputProcessor.java:165) at org.jboss.aesh.console.Console.processInternalOperation(Console.java:735) at org.jboss.aesh.console.Console.execute(Console.java:718) at org.jboss.aesh.console.Console.access$900(Console.java:73) at org.jboss.aesh.console.Console$6.run(Console.java:627) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) was: 3 issues with command arguments completion: 1) " " and "=false" shouldn't be proposed for argument without values (that is a regression introduced by the support of implicit true value). 2) arguments without values used to stop completion to operate. For example ls --resolve-expressions should complete to the argument separator " " if no more arguments can be added. 3) "=" character is not appended to argument that has a value (that is a regression introduced by the support of implicit true value). > CLI, some completion issues > --------------------------- > > Key: WFCORE-1516 > URL: https://issues.jboss.org/browse/WFCORE-1516 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > 4 issues with command arguments completion: > 1) " " and "=false" shouldn't be proposed for argument without values (that is a regression introduced by the support of implicit true value). > 2) arguments without values used to stop completion to operate. For example ls --resolve-expressions should complete to the argument separator " " if no more arguments can be added. > 3) "=" character is not appended to argument that has a value (that is a regression introduced by the support of implicit true value). > 4) Exception in read-attribute completing the node > read-attribute --node > org.jboss.as.cli.CommandFormatException: Couldn't locate ' --node=' in the line: 'read-attribute --node' > at org.jboss.as.cli.handlers.ReadAttributeHandler.getAddress(ReadAttributeHandler.java:325) > at org.jboss.as.cli.handlers.ReadAttributeHandler$2.canAppearNext(ReadAttributeHandler.java:114) > at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:257) > at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:73) > at org.jboss.as.cli.CommandCompleter.doComplete(CommandCompleter.java:126) > at org.jboss.as.cli.CommandCompleter.complete(CommandCompleter.java:63) > at org.jboss.as.cli.impl.Console$Factory$1$1.complete(Console.java:141) > at org.jboss.aesh.console.AeshCompletionHandler.complete(AeshCompletionHandler.java:150) > at org.jboss.aesh.console.AeshInputProcessor.complete(AeshInputProcessor.java:420) > at org.jboss.aesh.console.AeshInputProcessor.parseOperation(AeshInputProcessor.java:165) > at org.jboss.aesh.console.Console.processInternalOperation(Console.java:735) > at org.jboss.aesh.console.Console.execute(Console.java:718) > at org.jboss.aesh.console.Console.access$900(Console.java:73) > at org.jboss.aesh.console.Console$6.run(Console.java:627) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6575) Cloud environment example profiles have configured mod_cluster with multicast-based advertise

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6575?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-6575: --------------------------------- Description: The cloud modification should/could: * disable multicast server advertise * specify an example proxy setting (WFBUILD-19) * do not define multicast socket binding (WFLY-6574) > Cloud environment example profiles have configured mod_cluster with multicast-based advertise > --------------------------------------------------------------------------------------------- > > Key: WFLY-6575 > URL: https://issues.jboss.org/browse/WFLY-6575 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Affects Versions: 10.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > The cloud modification should/could: > * disable multicast server advertise > * specify an example proxy setting (WFBUILD-19) > * do not define multicast socket binding (WFLY-6574) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6575) Cloud environment example profiles have configured mod_cluster with multicast-based advertise

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-6575: ------------------------------------ Summary: Cloud environment example profiles have configured mod_cluster with multicast-based advertise Key: WFLY-6575 URL: https://issues.jboss.org/browse/WFLY-6575 Project: WildFly Issue Type: Feature Request Components: Clustering Affects Versions: 10.0.0.Final Reporter: Radoslav Husar Assignee: Radoslav Husar -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFBUILD-19) Add support for conditional socket bindings based on supplement replacement

by Radoslav Husar (JIRA)

Radoslav Husar created WFBUILD-19: ------------------------------------- Summary: Add support for conditional socket bindings based on supplement replacement Key: WFBUILD-19 URL: https://issues.jboss.org/browse/WFBUILD-19 Project: WildFly Build Tools Issue Type: Feature Request Affects Versions: 1.1.6.Final Reporter: Radoslav Husar Assignee: Stuart Douglas Priority: Minor So that for instance we could not add a multicast-based socket binding to cloud profiles that do not support mutlicast. {code:xml} <config default-supplement="default"> <extension-module>org.jboss.as.modcluster</extension-module> <subsystem xmlns="urn:jboss:domain:modcluster:2.0"> <mod-cluster-config advertise-socket="modcluster" connector="ajp"> <dynamic-load-provider> <load-metric type="cpu"/> </dynamic-load-provider> </mod-cluster-config> </subsystem> <?SOCKETB?> <supplement name="default"> <replacement placeholder="SOCKETB"> <socket-binding name="modcluster" port="0" multicast-address="224.0.1.105" multicast-port="23364"/> </replacement> </supplement> <supplement name="no-multicast"> <replacement placeholder="SOCKETB"> </replacement> </supplement> </config> {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 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: ------------------------------------ Ah, no wonder you're getting an NPE. The org.jboss.as.jpa.hibernate5.infinispan.SharedInfinispanRegionFactory implementation is only usable if your JPA deployment is handled by WildFly, otherwise none of the requisite dependencies will be established. My recommendation: get rid of Spring, at least as it relates to EE components, as it is completely unnecessary (and overly complicated to setup) if you're deploying in an EE container. Follow the instructions here: https://docs.jboss.org/author/display/WFLY10/JPA+Reference+Guide You'll find that your persistence.xml only needs 2 properties: <property name="hibernate.cache.use_second_level_cache" value="true"/> <property name="hibernate.cache.use_query_cache" value="true"/> > 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, 8 months

1
0
0 / 0

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

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1518?page=com.atlassian.jira.plugi... ] Kabir Khan reassigned WFCORE-1518: ---------------------------------- Assignee: Kabir Khan (was: Jeff Mesnil) > 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: Kabir Khan > > 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, 8 months

1
0
0 / 0

[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, 8 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, 8 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, 8 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