[JBoss JIRA] (WFLY-10338) Discovery subsystem is missing from the domain profiles
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/WFLY-10338?page=com.atlassian.jira.plugin... ]
Yeray Borges commented on WFLY-10338:
-------------------------------------
>From Brian's input, it looks like the only profile in doubt regarding discovery subsystem is the ha profile, (I guess default should match with wfcore, full, full-ha are required by Brian's comment). [~dmlloyd] Could you confirm if ha profile must have the discovery subsystem added by default?
> Discovery subsystem is missing from the domain profiles
> -------------------------------------------------------
>
> Key: WFLY-10338
> URL: https://issues.jboss.org/browse/WFLY-10338
> Project: WildFly
> Issue Type: Bug
> Components: Build System, Management
> Reporter: Brian Stansberry
> Assignee: Yeray Borges
> Fix For: 13.0.0.Beta1
>
>
> Same problem as WFCORE-3784 except in the full feature-pack.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10020) Custom Hibernate slot and second level cache with Wildfly 12 causes NullPointer Exception
by Jan-Willem Gmelig Meyling (JIRA)
[ https://issues.jboss.org/browse/WFLY-10020?page=com.atlassian.jira.plugin... ]
Jan-Willem Gmelig Meyling commented on WFLY-10020:
--------------------------------------------------
Hibernate 5.2.x seems to be incompatible with Infinispan 9.1.x (and especially the new infinispan.hibernate module in WildFly 12). While I've worked with both Hibernate 5.2.x and Infinispan in WildFly 10 and 11, WildFly 12 I don't seem to get it to work either. It however works fine with the Infinispan 9.2.x in the next WildFly 13. If you're on WildFly 12 with Hibernate 5.2.x like me, you probably have to let this version pass. Now WildFly 13 is on Infinispan 9.2.x anyway, which seemed to be the last blocker, I am wondering why Hibernate 5.2.x isn't going to be the new default (WFLY-6682). I've also published an updated pull request for migrating to Hibernate 5.2.x in WildFly 13: https://github.com/wildfly/wildfly/pull/11188 .
> Custom Hibernate slot and second level cache with Wildfly 12 causes NullPointer Exception
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-10020
> URL: https://issues.jboss.org/browse/WFLY-10020
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 12.0.0.Final
> Reporter: Alessandro Moscatelli
> Assignee: Scott Marlow
>
> Migrating to 12 with Hibernate Custom slot causes NullPointer Exception.
> https://mvnrepository.com/artifact/org.hibernate/hibernate-orm-modules
> <property name="jboss.as.jpa.providerModule" value="org.hibernate:5.2.13.Final" />
> 16:12:28,868 INFO [org.jboss.as.jpa] (MSC service thread 1-1) WFLYJPA0002: Read persistence.xml for optoplus
> 16:12:29,142 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."optoplus-services-ear-1.0.18-SNAPSHOT.ear".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.unit."optoplus-services-ear-1.0.18-SNAPSHOT.ear".FIRST_MODULE_USE: WFLYSRV0153: Failed to process phase FIRST_MODULE_USE of deployment "optoplus-services-ear-1.0.18-SNAPSHOT.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:151)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1714)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1693)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1540)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException
> at org.jboss.as.jpa.processor.secondLevelCache.InfinispanCacheDeploymentListener.addCacheDependencies(InfinispanCacheDeploymentListener.java:129)
> at org.jboss.as.jpa.processor.secondLevelCache.CacheDeploymentListener.addCacheDependencies(CacheDeploymentListener.java:111)
> at org.jipijapa.event.impl.internal.Notification.addCacheDependencies(Notification.java:95)
> at org.jboss.as.jpa.hibernate5.HibernateSecondLevelCache.addSecondLevelCacheDependencies(HibernateSecondLevelCache.java:125)
> at org.jboss.as.jpa.hibernate5.HibernatePersistenceProviderAdaptor.addProviderDependencies(HibernatePersistenceProviderAdaptor.java:107)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deployPersistenceUnitPhaseOne(PersistenceUnitServiceHandler.java:538)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:273)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleEarDeployment(PersistenceUnitServiceHandler.java:228)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:135)
> at org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:144)
> ... 8 more
> 16:12:29,155 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"optoplus-services-ear-1.0.18-SNAPSHOT.ear\".FIRST_MODULE_USE" => "WFLYSRV0153: Failed to process phase FIRST_MODULE_USE of deployment \"optoplus-services-ear-1.0.18-SNAPSHOT.ear\"
> Caused by: java.lang.NullPointerException"}}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-8542) StatefulSessionSynchronizationInterceptor fails weirdly if the transaction is in ROLLBACK_ONLY
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-8542?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on WFLY-8542:
-------------------------------------
[~dmlloyd] - they are not: https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes...
> StatefulSessionSynchronizationInterceptor fails weirdly if the transaction is in ROLLBACK_ONLY
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-8542
> URL: https://issues.jboss.org/browse/WFLY-8542
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: David Lloyd
>
> It's not really clear what the correct behavior is, but it definitely isn't this:
> {noformat}
> 2017-04-07 14:53:09 javax.ejb.EJBTransactionRolledbackException: WFLYTX0029: Syncs are not allowed to be registered when the tx is in state 1
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:160)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:257)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:334)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:240)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:327)
> 2017-04-07 14:53:09 at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> 2017-04-07 14:53:09 at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:84)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:256)
> 2017-04-07 14:53:09 at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609)
> 2017-04-07 14:53:09 at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> 2017-04-07 14:53:09 at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 2017-04-07 14:53:09 at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:380)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:457)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:452)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:164)
> 2017-04-07 14:53:09 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 2017-04-07 14:53:09 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 2017-04-07 14:53:09 at java.lang.Thread.run(Thread.java:745)
> 2017-04-07 14:53:09 Caused by: java.lang.IllegalStateException: WFLYTX0029: Syncs are not allowed to be registered when the tx is in state 1
> 2017-04-07 14:53:09 at org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList.registerInterposedSynchronization(JCAOrderedLastSynchronizationList.java:76)
> 2017-04-07 14:53:09 at org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper.registerInterposedSynchronization(TransactionSynchronizationRegistryWrapper.java:78)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:118)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> 2017-04-07 14:53:09 at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:59)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:255)
> 2017-04-07 14:53:09 ... 42 more
> {noformat}
> If the transaction is in ROLLBACK_ONLY, then any of these might possibly be correct behavior:
> * Reject the invocation with a specific exception explaining that the method cannot be invoked when the transaction is in ROLLBACK_ONLY (preferably with a spec citation)
> * Allow the invocation to proceed without registering the synchronization (this probably isn't correct but might be)
> * Allow the invocation to proceed and use a "backdoor" to register the user synchronization anyway
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (DROOLS-2531) Scenario Simulation feature
by Daniele Zonca (JIRA)
Daniele Zonca created DROOLS-2531:
-------------------------------------
Summary: Scenario Simulation feature
Key: DROOLS-2531
URL: https://issues.jboss.org/browse/DROOLS-2531
Project: Drools
Issue Type: Enhancement
Reporter: Daniele Zonca
Assignee: Daniele Zonca
We want to create a new feature in Drools WB and core to support scenario testing.
The scenarios will be executed in a simulation mode to let the user able to test his system and export results for post-simulation analysis/no regression.
Drools WB should support user in scenario definition (i.e. define facts template) and then let insert input data (single or bulk) with corresponding expected results.
Drools core should support steps definition with a fluent API and then simulation runs. We should also support a JUnit-like output format.
This feature will also dismiss current Test Scenario asset
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10344) Deployment order based on jboss-all.xml doesn't work properly
by Panos Mitronikas (JIRA)
Panos Mitronikas created WFLY-10344:
---------------------------------------
Summary: Deployment order based on jboss-all.xml doesn't work properly
Key: WFLY-10344
URL: https://issues.jboss.org/browse/WFLY-10344
Project: WildFly
Issue Type: Bug
Affects Versions: 12.0.0.Final
Reporter: Panos Mitronikas
Assignee: Jason Greene
Our application consists of a core module (ear or war) and several component modules (wars) that register to the core upon deployment.
The process is implemented with a REST service available in the core module and REST clients in each component that call a register method upon deployment and an unregister upon removal. This requires a deployment order for server restarts and it is implemented with jboss-all.xml files in each component war.
The process was smooth on Wildfly 10 but on 12 restarts seem not to follow the deployment order, or for being exact it appears that the core REST service doesn't get initialized properly and clients just hang there waiting, resulting in a total crash of the server upon initialization (never goes up and crashes with some concurrency error after 5 minutes).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFWIP-35) Colors are printed in non interactive mode when echo-command is enabled
by Ingo Weiss (JIRA)
[ https://issues.jboss.org/browse/WFWIP-35?page=com.atlassian.jira.plugin.s... ]
Ingo Weiss commented on WFWIP-35:
---------------------------------
Thanks [~jdenise]. Tested locally and worked fine. Just pushed.
> Colors are printed in non interactive mode when echo-command is enabled
> -----------------------------------------------------------------------
>
> Key: WFWIP-35
> URL: https://issues.jboss.org/browse/WFWIP-35
> Project: WildFly WIP
> Issue Type: Bug
> Reporter: Erich Duda
> Assignee: Ingo Weiss
> Priority: Blocker
> Labels: WFCORE-3577
>
> If you execute CLI in following non-interactive way, colors are printed out. This can break users automation and do the output hard readable.
> {code}
> ./bin/jboss-cli.sh --file=commands.txt --echo-command
> {code}
> {code:title=commands.txt}
> embed-server
> batch
> :read-attribute(name=server-state)
> list-batch
> run-batch
> exit
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3807) Persist extensions and subsystems in a consistent order
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3807?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3807:
-------------------------------------
Description:
Always persist extension resources to xml in alphabetical order of the extension module name.
Always persist subsystem resources to xml in alphabetical order of the subsystem name, except logging goes first just because it always has. (There has been no technical need for it to go first since probably before AS 7.0.0.Final.)
The above describes the "conventional" order for the extensions / subsystems in our standard config files that we've manually applied for many years.
The current persister behavior is to persist extension and subsystems in the order they were added. This follows the general rule applied everywhere: sibling resources of a type are persisted in the same order in which they were added. Since most extensions/subsystems are added at boot based on the parsing of our conventionally ordered standard configs, we typically persist in our conventional order.
This enhancement is to have the persister force extensions/subsystem persistence in our conventional order, ignoring the order in which the items were added.
This change has the following pros:
1) If an extension/subsystem is added after initial boot (e.g. via CLI) the placement of that added subsystem will now be in a more intuitive spot in the same order as the conventionally ordered others, versus now where it comes last.
2) The galleon provisioning tool when it provisions a server basically does a bunch of 1), with the adds happening based on dependency analysis of the features. This results in an ordering that can seem quite unintuitive. This enhancement prevents this.
3) With the current behavior if a galleon feature pack is upgraded, and the feature-spec reports new dependency information that was previously missing (e.g. proper capability/requirement wiring between subsystems was added whereas before only invisible-in-the-model service dependencies were used) then when galleon re-provisions the server the order of extensions/subsystems might mysteriously change. This enhancement prevents this.
This change has the following cons:
1) If users for some reason had deliberately organized their xml in a different order from our convention, the ability to retain this order following persistence by the server would be lost. (We could add a system property hook to disable this enhancement, but it would need to be clear that it's not something the galleon tool itself supports. So probably not a great idea.)
2) The ordering that galleon will create without this enhancement does provide some value to the user since it gives a rough sense of dependency ordering. It's pretty rough though, as there can be numerous items A, B, C that come before other items X, Y, Z where there is no dependency relationship involved.
was:
Always persist extension resources to xml in alphabetical order of the extension module name.
Always persist subsystem resources to xml in alphabetical order of the subsystem name, except logging goes first just because it always has. (There has been no technical need for it to go first since probably before AS 7.0.0.Final.)
The above describes the "conventional" order for the extensions / subsystems in our standard config files that we've manually applied for many years.
The current persister behavior is to persist extension and subsystems in the order they were added. This follows the general rule applied everywhere: sibling resources of a type are persisted in the same order in which they were added. Since most extensions/subsystems are added at boot based on the parsing of our conventionally ordered standard configs, we typically persist in our conventional order.
This enhancement is to have the persister force extensions/subsystem persistence in our conventional order, ignoring the order in which the items were added.
This change has the following pros:
1) If an extension/subsystem is added after initial boot (e.g. via CLI) the placement of that added subsystem will now be in a more intuitive spot in the same order as the conventionally ordered others, versus now where it comes last.
2) The galleon provisioning tool when it provisions a server basically does a bunch of 1), with the adds happening based on dependency analysis of the features. This results in an ordering that can seem quite unintuitive. This enhancement prevents this.
3) With the current behavior if a galleon feature pack is upgraded, and the feature-spec reports new dependency information that was previously missing (e.g. proper capability/requirement wiring between subsystems was added whereas before only invisible-in-the-model service dependencies were used) then when galleon re-provisions the server the order of extensions/subsystems might mysteriously change.
This change has the following cons:
1) If users for some reason had deliberately organized their xml in a different order from our convention, the ability to do this would be lost. (We could add a system property hook to disable this enhancement, but it would need to be clear that it's not something the galleon tool itself supports. So probably not a great idea.)
2) The ordering that galleon will create without this enhancement does provide some value to the user since it gives a rough sense of dependency ordering. It's pretty rough though, as there can be numerous items A, B, C that come before other items X, Y, Z where there is no dependency relationship involved.
> Persist extensions and subsystems in a consistent order
> -------------------------------------------------------
>
> Key: WFCORE-3807
> URL: https://issues.jboss.org/browse/WFCORE-3807
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 5.0.0.Alpha6
>
>
> Always persist extension resources to xml in alphabetical order of the extension module name.
> Always persist subsystem resources to xml in alphabetical order of the subsystem name, except logging goes first just because it always has. (There has been no technical need for it to go first since probably before AS 7.0.0.Final.)
> The above describes the "conventional" order for the extensions / subsystems in our standard config files that we've manually applied for many years.
> The current persister behavior is to persist extension and subsystems in the order they were added. This follows the general rule applied everywhere: sibling resources of a type are persisted in the same order in which they were added. Since most extensions/subsystems are added at boot based on the parsing of our conventionally ordered standard configs, we typically persist in our conventional order.
> This enhancement is to have the persister force extensions/subsystem persistence in our conventional order, ignoring the order in which the items were added.
> This change has the following pros:
> 1) If an extension/subsystem is added after initial boot (e.g. via CLI) the placement of that added subsystem will now be in a more intuitive spot in the same order as the conventionally ordered others, versus now where it comes last.
> 2) The galleon provisioning tool when it provisions a server basically does a bunch of 1), with the adds happening based on dependency analysis of the features. This results in an ordering that can seem quite unintuitive. This enhancement prevents this.
> 3) With the current behavior if a galleon feature pack is upgraded, and the feature-spec reports new dependency information that was previously missing (e.g. proper capability/requirement wiring between subsystems was added whereas before only invisible-in-the-model service dependencies were used) then when galleon re-provisions the server the order of extensions/subsystems might mysteriously change. This enhancement prevents this.
> This change has the following cons:
> 1) If users for some reason had deliberately organized their xml in a different order from our convention, the ability to retain this order following persistence by the server would be lost. (We could add a system property hook to disable this enhancement, but it would need to be clear that it's not something the galleon tool itself supports. So probably not a great idea.)
> 2) The ordering that galleon will create without this enhancement does provide some value to the user since it gives a rough sense of dependency ordering. It's pretty rough though, as there can be numerous items A, B, C that come before other items X, Y, Z where there is no dependency relationship involved.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10343) Some subsystems are not in conventional order in the standard configs
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-10343:
---------------------------------------
Summary: Some subsystems are not in conventional order in the standard configs
Key: WFLY-10343
URL: https://issues.jboss.org/browse/WFLY-10343
Project: WildFly
Issue Type: Bug
Components: Build System
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 13.0.0.Beta1
The subsystems in our standard configs should be in alphabetical order by subsystem name, except logging is first. There are a number of mistakes about this in our standard configs.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-1146) Research behavior of fork with ProcessBuilder on modern JVMs
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1146?page=com.atlassian.jira.plugi... ]
David Lloyd resolved WFCORE-1146.
---------------------------------
Resolution: Done
> Research behavior of fork with ProcessBuilder on modern JVMs
> ------------------------------------------------------------
>
> Key: WFCORE-1146
> URL: https://issues.jboss.org/browse/WFCORE-1146
> Project: WildFly Core
> Issue Type: Task
> Components: Management
> Reporter: David Lloyd
> Labels: domain-mode
>
> Right now our Process Controller exists for two primary reasons:
> # fork() misbehaves for large processes on some OSes, causing leaks or crashes
> # if the HC crashes, the PC can respawn it
> We have never (afaik) seen #2 happen. We need to verify whether #1 is still true on modern JVMs on the following operating systems:
> * Linux
> * Solaris
> * IBM OSes
> * Windows
> * BSDs
> * Mac OS X
> Test by creating processes with large heap and lots of concurrent file descriptor activity while forking to see what happens.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months