[JBoss JIRA] (WFLY-2387) CDI injection in entity listeners failing
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-2387?page=com.atlassian.jira.plugin.... ]
Martin Kouba commented on WFLY-2387:
------------------------------------
[~alxs] I see. So your workaround is not used for JPA entity listeners at all. Nevertheless, thanks a lot for a good tip! ;-)
> CDI injection in entity listeners failing
> -----------------------------------------
>
> Key: WFLY-2387
> URL: https://issues.jboss.org/browse/WFLY-2387
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Class Loading, JPA / Hibernate
> Affects Versions: 8.0.0.Beta1
> Reporter: Emond Papegaaij
> Assignee: Scott Marlow
> Attachments: TEST-org.jboss.as.test.integration.ee.injection.support.jpa.EntityListenerInjectionSupportTestCase.xml
>
>
> When trying to use CDI injection in JPA entity listeners, deployment fails with the following exception:
> {code}
> 16:16:37,448 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 15) MSC000001: Failed to start service jboss.persistenceunit."inject-ear.ear#primary": org.jboss.msc.service.StartException in service jboss.persistenceunit."inject-ear.ear#primary": java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader@4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader@4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:75)
> at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:128)
> at org.jboss.weld.Container.instance(Container.java:65)
> at org.jboss.weld.manager.BeanManagerImpl.getBeans(BeanManagerImpl.java:563)
> at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:90)
> at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358)
> at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369)
> at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72)
> at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60)
> at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
> at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
> at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
> at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90)
> at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:82)
> at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:71)
> at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory.buildListener(BeanManagerListenerFactory.java:57)
> at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.resolveCallbacks(LegacyCallbackProcessor.java:168)
> at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.processCallbacksForEntity(LegacyCallbackProcessor.java:71)
> at org.hibernate.jpa.event.spi.JpaIntegrator.integrate(JpaIntegrator.java:150)
> at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
> at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151)
> ... 8 more
> {code}
> I've created a small showcase of the problem: https://github.com/papegaaij/listener-injection
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (DROOLS-1046) Threads blocking during ReteWorkingMemory initialization of facts
by Akshay Gehi (JIRA)
Akshay Gehi created DROOLS-1046:
-----------------------------------
Summary: Threads blocking during ReteWorkingMemory initialization of facts
Key: DROOLS-1046
URL: https://issues.jboss.org/browse/DROOLS-1046
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.3.0.Final
Reporter: Akshay Gehi
Assignee: Mario Fusco
While initializing facts for the first time the following method in ReteWorkingMemory is invoked:
{code:java}
private final Integer syncLock = 42;
public void initInitialFact() {
if ( initialFactHandle == null ) {
synchronized ( syncLock ) {
if ( initialFactHandle == null ) {
// double check, inside of sync point incase some other thread beat us to it.
initInitialFact(kBase, null);
}
}
}
}
{code}
Since the synchronized lock is taken on a Integer constant variable, the same object gets used across different threads. This causes the initialization of all the ReteMemoryObjects to wait in the initInitialFact() method across different threads.
The lock should be taken on Object lock = new Object() instead
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFLY-6091) Problems with passivation listener ordering cause CoarseSessionPassivationTestCase to fail intermittently with Undertow 1.3.16.Final
by Stuart Douglas (JIRA)
Stuart Douglas created WFLY-6091:
------------------------------------
Summary: Problems with passivation listener ordering cause CoarseSessionPassivationTestCase to fail intermittently with Undertow 1.3.16.Final
Key: WFLY-6091
URL: https://issues.jboss.org/browse/WFLY-6091
Project: WildFly
Issue Type: Bug
Components: Clustering
Reporter: Stuart Douglas
Assignee: Paul Ferraro
The upgrade to Undertow 1.3.16.Final causes this test to fail frequently (but not every time).
The change that makes this more frequent was the change to send the response before closing the session. If you are having trouble reproducing this you can add the following code to the bottom of the SessionOperationServlet doGet method to make it 100% reproducible (this should work with any version of Undertow):
{code}
resp.getOutputStream().close();
try {
Thread.sleep(100);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
{code}
The underlying problem here is the way the passivation/activation listeners are called.
Previously if you did not close the response in the Servlet the session would be closed before the response would be sent, which guaranteed that prePassivate would be called. This also had the side effect that the test would only ever require a single request to see the first session passivating.
This is no longer the case, which means the following:
- Sometimes session1 has not had its passivation listener called before the session2 request is made
- The second session2 request can result in a call to sessionActivated (which makes the test fail). This is especially bogus as there is a chance session2 has not had sessionWillPassivate called yet.
The underlying cause of all this is the way listeners are handled in InfinispanSessionManager when persistent is true. Basically:
- Requests can cause a session to activate before the passivation listener has been called, resulting in out of order invocations
- Multiple concurrent requests to a session will result in multiple activation callbacks, followed by multiple passivation callbacks.
Basically at the moment the ordering these events is completely broken.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFCORE-1340) Store "host ignore" data in the domain wide model
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1340?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1340:
-------------------------------------
Description:
Including an EAP 6.x slave in a mixed domain managed by a WF 10 / EAP 7 DC is overly difficult operationally because potentially numerous host configurations need to be manually updated whenever new server groups and profiles are added.
An issue with managing mixed domains is the need for the slave's host.xml to include configuration of what domain-wide content should be ignored. This isn't nice as it requires modifying potentially many host configs when new domain-wide content is added (e.g. new server groups or profiles that the legacy slaves won't understand.)
Core 2 / Full 10 are better in this regard as they allow "ignore-unused-configuration" where stuff is auto-ignored. But this still has weaknesses:
1) The "ignore-unused-configuration" logic is slave-side and is not present in EAP 6.x slaves. So for those slaves manual configuration is the only option.
2) Extensions are not covered, so new extensions in later releases may need to be manually configured. (The goal though is to cover this in 11, so this JIRA would just provide a fallback for 11 DCs managing 10 slaves in case that goal is not met. EAP 6 slaves would not benefit from this though.)
Idea here is to include config for host-ignores in the domain-wide model, for use by the DC. It's in the domain-wide model, not the DC's host.xml, to ensure that any backup HC has the latest data.
Proposed structure:
Resources are at address /host-ignore=*
Attributes are:
* management-major-version
* management-minor-version
* management-micro-version
* slave-release
These identify the category of slave to which host-ignore data should be applied when a matching slave registers. The first 3 attributes identify the *core management API version* of the slave (not its release version.) The last is a user-friendly *alternative* to the first 3 and is an enum identifying well known releases (e.g. EAP6.2, EAP6.3, EAP6.4) from which the api versions can be derived.
If management-micro-version is undefined, the meaning is the config applies to all releases of the given major/minor version, excluding any for which a config with a micro version specified is also present. Not specifying a micro is expected to be the norm. The "slave-release" enums will be for minors.
In addition to the above scoping attributes, the following attributes will be supported:
* ignored-extensions
* active-server-groups
The ignored-extensions attribute is a list of extension names the resources for which (/extension=X) should be treated as ignored by the target hosts.
The active-server-groups attribute is a list of server groups names the members of which should be treated as *not* ignored by the target hosts. These are the groups used by the host's servers. The server-group and related profile, socket-binding-group and deployment resources will not be ignored; all others will be ignored. This is the same data that a core 2 / WF 10 slave sends when it registers. This JIRA just provides a different mechanism for making the data known to the DC.
Adding a new group to active-server-groups will not cause existing slave HCs to get new data sent to them, at least not in the first round of this work. The slave will need to reconnect to get new data.
There is other data that could be included in these resources, e.g. fine grained "ignore" information matching what can be configured in host.xml, but that is out of scope for this first cut, and may never be added if there is no clear demand.
was:
Including an EAP 6.x slave in a mixed domain managed by a WF 10 / EAP 7 DC is overly difficult operationally because potentially numerous host configurations need to be manually updated whenever new server groups and profiles are added.
An issue with managing mixed domains is the need for the slave's host.xml to include configuration of what domain-wide content should be ignored. This isn't nice as it requires modifying potentially many host configs when new domain-wide content is added (e.g. new server groups or profiles that the legacy slaves won't understand.)
Core 2 / Full 10 are better in this regard as they allow "ignore-unused-configuration" where stuff is auto-ignored. But this still has weaknesses:
1) The "ignore-unused-configuration" logic is slave-side and is not present in EAP 6.x slaves. So for those slaves manual configuration is the only option.
2) Extensions are not covered, so new extensions in later releases may need to be manually configured. (The goal though is to cover this in 11, so this JIRA would just provide a fallback for 11 DCs managing 10 slaves in case that goal is not met. EAP 6 slaves would not benefit from this though.)
Idea here is to include config for host-ignores in the domain-wide model, for use by the DC. It's in the domain-wide model, not the DC's host.xml, to ensure that any backup HC has the latest data.
Proposed structure:
Resources are at address /host-ignore=*
Attributes are:
* slave-api-major-version
* slave-api-minor-version
* slave-api-micro-version
* slave-release
These identify the category of slave to which host-ignore data should be applied when a matching slave registers. The first 3 attributes identify the *core management API version* of the slave (not its release version.) The last is a user-friendly *alternative* to the first 3 and is an enum identifying well known releases (e.g. EAP6.2, EAP6.3, EAP6.4) from which the api versions can be derived.
If slave-api-micro-version is undefined, the meaning is the config applies to all releases of the given major/minor version, excluding any for which a config with a micro version specified is also present. Not specifying a micro is expected to be the norm. The "slave-release" enums will be for minors.
In addition to the above scoping attributes, the following attributes will be supported:
* ignored-extensions
* unignored-server-groups
The ignored-extensions attribute is a list of extension names the resources for which (/extension=X) should be treated as ignored by the target hosts.
The unignored-server-groups attribute is a list of server groups names the members of which should be treated as *not* ignored by the target hosts. These are the groups used by the host's servers. The server-group and related profile, socket-binding-group and deployment resources will not be ignored; all others will be ignored. This is the same data that a core 2 / WF 10 slave sends when it registers. This JIRA just provides a different mechanism for making the data known to the DC.
Adding a new group to unignored-server-groups will not cause existing slave HCs to get new data sent to them, at least not in the first round of this work. The slave will need to reconnect to get new data.
There is other data that could be included in these resources, e.g. fine grained "ignore" information matching what can be configured in host.xml, but that is out of scope for this first cut, and may never be added if there is no clear demand.
> Store "host ignore" data in the domain wide model
> -------------------------------------------------
>
> Key: WFCORE-1340
> URL: https://issues.jboss.org/browse/WFCORE-1340
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha1
>
>
> Including an EAP 6.x slave in a mixed domain managed by a WF 10 / EAP 7 DC is overly difficult operationally because potentially numerous host configurations need to be manually updated whenever new server groups and profiles are added.
> An issue with managing mixed domains is the need for the slave's host.xml to include configuration of what domain-wide content should be ignored. This isn't nice as it requires modifying potentially many host configs when new domain-wide content is added (e.g. new server groups or profiles that the legacy slaves won't understand.)
> Core 2 / Full 10 are better in this regard as they allow "ignore-unused-configuration" where stuff is auto-ignored. But this still has weaknesses:
> 1) The "ignore-unused-configuration" logic is slave-side and is not present in EAP 6.x slaves. So for those slaves manual configuration is the only option.
> 2) Extensions are not covered, so new extensions in later releases may need to be manually configured. (The goal though is to cover this in 11, so this JIRA would just provide a fallback for 11 DCs managing 10 slaves in case that goal is not met. EAP 6 slaves would not benefit from this though.)
> Idea here is to include config for host-ignores in the domain-wide model, for use by the DC. It's in the domain-wide model, not the DC's host.xml, to ensure that any backup HC has the latest data.
> Proposed structure:
> Resources are at address /host-ignore=*
> Attributes are:
> * management-major-version
> * management-minor-version
> * management-micro-version
> * slave-release
> These identify the category of slave to which host-ignore data should be applied when a matching slave registers. The first 3 attributes identify the *core management API version* of the slave (not its release version.) The last is a user-friendly *alternative* to the first 3 and is an enum identifying well known releases (e.g. EAP6.2, EAP6.3, EAP6.4) from which the api versions can be derived.
> If management-micro-version is undefined, the meaning is the config applies to all releases of the given major/minor version, excluding any for which a config with a micro version specified is also present. Not specifying a micro is expected to be the norm. The "slave-release" enums will be for minors.
> In addition to the above scoping attributes, the following attributes will be supported:
> * ignored-extensions
> * active-server-groups
> The ignored-extensions attribute is a list of extension names the resources for which (/extension=X) should be treated as ignored by the target hosts.
> The active-server-groups attribute is a list of server groups names the members of which should be treated as *not* ignored by the target hosts. These are the groups used by the host's servers. The server-group and related profile, socket-binding-group and deployment resources will not be ignored; all others will be ignored. This is the same data that a core 2 / WF 10 slave sends when it registers. This JIRA just provides a different mechanism for making the data known to the DC.
> Adding a new group to active-server-groups will not cause existing slave HCs to get new data sent to them, at least not in the first round of this work. The slave will need to reconnect to get new data.
> There is other data that could be included in these resources, e.g. fine grained "ignore" information matching what can be configured in host.xml, but that is out of scope for this first cut, and may never be added if there is no clear demand.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFLY-6090) Problems with passivation listener ordering cause CoarseSessionPassivationTestCase to fail intermittently with Undertow 1.3.16.Final
by Stuart Douglas (JIRA)
Stuart Douglas created WFLY-6090:
------------------------------------
Summary: Problems with passivation listener ordering cause CoarseSessionPassivationTestCase to fail intermittently with Undertow 1.3.16.Final
Key: WFLY-6090
URL: https://issues.jboss.org/browse/WFLY-6090
Project: WildFly
Issue Type: Bug
Components: Clustering
Reporter: Stuart Douglas
Assignee: Paul Ferraro
The upgrade to Undertow 1.3.16.Final causes this test to fail frequently (but not every time).
The change that makes this more frequent was the change to send the response before closing the session. If you are having trouble reproducing this you can add the following code to the bottom of the SessionOperationServlet doGet method to make it 100% reproducible (this should work with any version of Undertow):
{code}
resp.getOutputStream().close();
try {
Thread.sleep(100);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
{code}
The underlying problem here is the way the passivation/activation listeners are called.
Previously if you did not close the response in the Servlet the session would be closed before the response would be sent, which guaranteed that prePassivate would be called. This also had the side effect that the test would only ever require a single request to see the first session passivating.
This is no longer the case, which means the following:
- Sometimes session1 has not had its passivation listener called before the session2 request is made
- The second session2 request can result in a call to sessionActivated (which makes the test fail). This is especially bogus as there is a chance session2 has not had sessionWillPassivate called yet.
The underlying cause of all this is the way listeners are handled in InfinispanSessionManager when persistent is true. Basically:
- Requests can cause a session to activate before the passivation listener has been called, resulting in out of order invocations
- Multiple concurrent requests to a session will result in multiple activation callbacks, followed by multiple passivation callbacks.
Basically at the moment the ordering these events is completely broken.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFLY-5828) Format differences between default configuration and read/persisted one
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5828?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-5828:
---------------------------------
Component/s: EJB
Web (Undertow)
> Format differences between default configuration and read/persisted one
> -----------------------------------------------------------------------
>
> Key: WFLY-5828
> URL: https://issues.jboss.org/browse/WFLY-5828
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB, Web (Undertow)
> Affects Versions: 10.0.0.CR4
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Labels: ux
>
> Neverending classic, just like every release:
> {noformat}[rhusar@syrah wildfly-10.0.0.Final-SNAPSHOT]$ diff standalone/configuration/standalone-ha.xml standalone/configuration/standalone_xml_history/standalone-ha.initial.xml
> 1c1
> < <?xml version='1.0' encoding='UTF-8'?>
> ---
> > <?xml version="1.0" ?>
> 4d3
> <
> 36,37d34
> <
> <
> 64c61
> < <file-handler name="file" formatter="json-formatter" path="audit-log.log" relative-to="jboss.server.data.dir"/>
> ---
> > <file-handler name="file" formatter="json-formatter" relative-to="jboss.server.data.dir" path="audit-log.log"/>
> 87d83
> <
> 178a175
> > <stateful default-access-timeout="5000" cache-ref="distributable" passivation-disabled-cache-ref="simple"/>
> 182d178
> < <stateful default-access-timeout="5000" cache-ref="distributable" passivation-disabled-cache-ref="simple"/>
> 186a183
> > <!-- Automatically configure pools. Alternatively, max-pool-size can be set to a specific value -->
> 193c190
> < <cache name="distributable" passivation-store-ref="infinispan" aliases="passivating clustered"/>
> ---
> > <cache name="distributable" aliases="passivating clustered" passivation-store-ref="infinispan"/>
> 220c217
> < <cache-container name="server" aliases="singleton cluster" module="org.wildfly.clustering.server" default-cache="default">
> ---
> > <cache-container name="server" aliases="singleton cluster" default-cache="default" module="org.wildfly.clustering.server">
> 226c223
> < <cache-container name="web" module="org.wildfly.clustering.web.infinispan" default-cache="dist">
> ---
> > <cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan">
> 234c231
> < <cache-container name="ejb" aliases="sfsb" module="org.wildfly.clustering.ejb.infinispan" default-cache="dist">
> ---
> > <cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan">
> 242c239
> < <cache-container name="hibernate" module="org.hibernate.infinispan" default-cache="local-query">
> ---
> > <cache-container name="hibernate" default-cache="local-query" module="org.hibernate.infinispan">
> 244,247d240
> < <local-cache name="local-query">
> < <eviction max-entries="10000" strategy="LRU"/>
> < <expiration max-idle="100000"/>
> < </local-cache>
> 250c243
> < <eviction max-entries="10000" strategy="LRU"/>
> ---
> > <eviction strategy="LRU" max-entries="10000"/>
> 252a246,249
> > <local-cache name="local-query">
> > <eviction strategy="LRU" max-entries="10000"/>
> > <expiration max-idle="100000"/>
> > </local-cache>
> 403c400
> < <http-listener name="default" redirect-socket="https" socket-binding="http"/>
> ---
> > <http-listener name="default" socket-binding="http" redirect-socket="https"/>
> 418,419c415,416
> < <response-header name="server-header" header-value="WildFly/10" header-name="Server"/>
> < <response-header name="x-powered-by-header" header-value="Undertow/1" header-name="X-Powered-By"/>
> ---
> > <response-header name="server-header" header-name="Server" header-value="WildFly/10"/>
> > <response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="Undertow/1"/>
> 434d430
> <
> 446d441
> <
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFLY-6089) Format differences between default configuration and read/persisted one
by Radoslav Husar (JIRA)
Radoslav Husar created WFLY-6089:
------------------------------------
Summary: Format differences between default configuration and read/persisted one
Key: WFLY-6089
URL: https://issues.jboss.org/browse/WFLY-6089
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 10.0.0.CR4
Reporter: Radoslav Husar
Assignee: Radoslav Husar
Neverending classic, just like every release:
{noformat}[rhusar@syrah wildfly-10.0.0.Final-SNAPSHOT]$ diff standalone/configuration/standalone-ha.xml standalone/configuration/standalone_xml_history/standalone-ha.initial.xml
1c1
< <?xml version='1.0' encoding='UTF-8'?>
---
> <?xml version="1.0" ?>
4d3
<
36,37d34
<
<
64c61
< <file-handler name="file" formatter="json-formatter" path="audit-log.log" relative-to="jboss.server.data.dir"/>
---
> <file-handler name="file" formatter="json-formatter" relative-to="jboss.server.data.dir" path="audit-log.log"/>
87d83
<
178a175
> <stateful default-access-timeout="5000" cache-ref="distributable" passivation-disabled-cache-ref="simple"/>
182d178
< <stateful default-access-timeout="5000" cache-ref="distributable" passivation-disabled-cache-ref="simple"/>
186a183
> <!-- Automatically configure pools. Alternatively, max-pool-size can be set to a specific value -->
193c190
< <cache name="distributable" passivation-store-ref="infinispan" aliases="passivating clustered"/>
---
> <cache name="distributable" aliases="passivating clustered" passivation-store-ref="infinispan"/>
220c217
< <cache-container name="server" aliases="singleton cluster" module="org.wildfly.clustering.server" default-cache="default">
---
> <cache-container name="server" aliases="singleton cluster" default-cache="default" module="org.wildfly.clustering.server">
226c223
< <cache-container name="web" module="org.wildfly.clustering.web.infinispan" default-cache="dist">
---
> <cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan">
234c231
< <cache-container name="ejb" aliases="sfsb" module="org.wildfly.clustering.ejb.infinispan" default-cache="dist">
---
> <cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan">
242c239
< <cache-container name="hibernate" module="org.hibernate.infinispan" default-cache="local-query">
---
> <cache-container name="hibernate" default-cache="local-query" module="org.hibernate.infinispan">
244,247d240
< <local-cache name="local-query">
< <eviction max-entries="10000" strategy="LRU"/>
< <expiration max-idle="100000"/>
< </local-cache>
250c243
< <eviction max-entries="10000" strategy="LRU"/>
---
> <eviction strategy="LRU" max-entries="10000"/>
252a246,249
> <local-cache name="local-query">
> <eviction strategy="LRU" max-entries="10000"/>
> <expiration max-idle="100000"/>
> </local-cache>
403c400
< <http-listener name="default" redirect-socket="https" socket-binding="http"/>
---
> <http-listener name="default" socket-binding="http" redirect-socket="https"/>
418,419c415,416
< <response-header name="server-header" header-value="WildFly/10" header-name="Server"/>
< <response-header name="x-powered-by-header" header-value="Undertow/1" header-name="X-Powered-By"/>
---
> <response-header name="server-header" header-name="Server" header-value="WildFly/10"/>
> <response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="Undertow/1"/>
434d430
<
446d441
<
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months