[JBoss JIRA] (WFCORE-3243) EAP7.0 slave host with ignore-unused-configuration=false throws NPE
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3243?page=com.atlassian.jira.plugi... ]
Ken Wills updated WFCORE-3243:
------------------------------
Description:
When ignore-unuised-configuration is set to false on the EAP7.0 slave and it is started and connects to a master version wildfly-core / wildfly, the below exception occurs. The slave does connect and appears to operate correctly otherwise.
[Host Controller] 15:41:44,863 ERROR [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 2) WFLYCTL0013: Operation ("describe-model") failed - address: ([("profile" => "default")]): java.lang.NullPointerException
[Host Controller] at org.jboss.as.domain.controller.operations.GenericModelDescribeOperationHandler.execute(GenericModelDescribeOperationHandler.java:144)
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
[Host Controller] at org.jboss.as.controller.ReadOnlyContext.executeOperation(ReadOnlyContext.java:83)
[Host Controller] at org.jboss.as.controller.ModelControllerImpl.executeReadOnlyOperation(ModelControllerImpl.java:284)
[Host Controller] at org.jboss.as.controller.ModelControllerImpl.executeReadOnlyOperation(ModelControllerImpl.java:267)
[Host Controller] at org.jboss.as.controller.AbstractControllerService.executeReadOnlyOperation(AbstractControllerService.java:444)
[Host Controller] at org.jboss.as.host.controller.DomainModelControllerService.access$1500(DomainModelControllerService.java:179)
[Host Controller] at org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor.executeReadOnly(DomainModelControllerService.java:1269)
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.execute(SyncModelOperationHandler.java:135)
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
[Host Controller] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
[Host Controller] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
[Host Controller] at org.jboss.as.controller.AbstractControllerService.internalExecute(AbstractControllerService.java:408)
[Host Controller] at org.jboss.as.host.controller.DomainModelControllerService.access$900(DomainModelControllerService.java:179)
[Host Controller] at org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor.execute(DomainModelControllerService.java:1238)
[Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService.applyRemoteDomainModel(RemoteDomainConnectionService.java:572)
[Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService.access$1100(RemoteDomainConnectionService.java:131)
[Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService$2.applyDomainModel(RemoteDomainConnectionService.java:515)
[Host Controller] at org.jboss.as.host.controller.RemoteDomainConnection.applyDomainModel(RemoteDomainConnection.java:311)
[Host Controller] at org.jboss.as.host.controller.RemoteDomainConnection$RegisterSubsystemsRequest$1.execute(RemoteDomainConnection.java:454)
[Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
[Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
[Host Controller] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[Host Controller] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[Host Controller] at java.lang.Thread.run(Thread.java:748)
[Host Controller] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
[Host Controller]
was:
[Host Controller] 15:41:44,863 ERROR [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 2) WFLYCTL0013: Operation ("describe-model") failed - address: ([("profile" => "default")]): java.lang.NullPointerException
[Host Controller] at org.jboss.as.domain.controller.operations.GenericModelDescribeOperationHandler.execute(GenericModelDescribeOperationHandler.java:144)
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
[Host Controller] at org.jboss.as.controller.ReadOnlyContext.executeOperation(ReadOnlyContext.java:83)
[Host Controller] at org.jboss.as.controller.ModelControllerImpl.executeReadOnlyOperation(ModelControllerImpl.java:284)
[Host Controller] at org.jboss.as.controller.ModelControllerImpl.executeReadOnlyOperation(ModelControllerImpl.java:267)
[Host Controller] at org.jboss.as.controller.AbstractControllerService.executeReadOnlyOperation(AbstractControllerService.java:444)
[Host Controller] at org.jboss.as.host.controller.DomainModelControllerService.access$1500(DomainModelControllerService.java:179)
[Host Controller] at org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor.executeReadOnly(DomainModelControllerService.java:1269)
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.execute(SyncModelOperationHandler.java:135)
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
[Host Controller] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
[Host Controller] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
[Host Controller] at org.jboss.as.controller.AbstractControllerService.internalExecute(AbstractControllerService.java:408)
[Host Controller] at org.jboss.as.host.controller.DomainModelControllerService.access$900(DomainModelControllerService.java:179)
[Host Controller] at org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor.execute(DomainModelControllerService.java:1238)
[Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService.applyRemoteDomainModel(RemoteDomainConnectionService.java:572)
[Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService.access$1100(RemoteDomainConnectionService.java:131)
[Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService$2.applyDomainModel(RemoteDomainConnectionService.java:515)
[Host Controller] at org.jboss.as.host.controller.RemoteDomainConnection.applyDomainModel(RemoteDomainConnection.java:311)
[Host Controller] at org.jboss.as.host.controller.RemoteDomainConnection$RegisterSubsystemsRequest$1.execute(RemoteDomainConnection.java:454)
[Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
[Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
[Host Controller] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[Host Controller] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[Host Controller] at java.lang.Thread.run(Thread.java:748)
[Host Controller] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
[Host Controller]
> EAP7.0 slave host with ignore-unused-configuration=false throws NPE
> -------------------------------------------------------------------
>
> Key: WFCORE-3243
> URL: https://issues.jboss.org/browse/WFCORE-3243
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Ken Wills
>
> When ignore-unuised-configuration is set to false on the EAP7.0 slave and it is started and connects to a master version wildfly-core / wildfly, the below exception occurs. The slave does connect and appears to operate correctly otherwise.
> [Host Controller] 15:41:44,863 ERROR [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 2) WFLYCTL0013: Operation ("describe-model") failed - address: ([("profile" => "default")]): java.lang.NullPointerException
> [Host Controller] at org.jboss.as.domain.controller.operations.GenericModelDescribeOperationHandler.execute(GenericModelDescribeOperationHandler.java:144)
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> [Host Controller] at org.jboss.as.controller.ReadOnlyContext.executeOperation(ReadOnlyContext.java:83)
> [Host Controller] at org.jboss.as.controller.ModelControllerImpl.executeReadOnlyOperation(ModelControllerImpl.java:284)
> [Host Controller] at org.jboss.as.controller.ModelControllerImpl.executeReadOnlyOperation(ModelControllerImpl.java:267)
> [Host Controller] at org.jboss.as.controller.AbstractControllerService.executeReadOnlyOperation(AbstractControllerService.java:444)
> [Host Controller] at org.jboss.as.host.controller.DomainModelControllerService.access$1500(DomainModelControllerService.java:179)
> [Host Controller] at org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor.executeReadOnly(DomainModelControllerService.java:1269)
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.execute(SyncModelOperationHandler.java:135)
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> [Host Controller] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> [Host Controller] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> [Host Controller] at org.jboss.as.controller.AbstractControllerService.internalExecute(AbstractControllerService.java:408)
> [Host Controller] at org.jboss.as.host.controller.DomainModelControllerService.access$900(DomainModelControllerService.java:179)
> [Host Controller] at org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor.execute(DomainModelControllerService.java:1238)
> [Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService.applyRemoteDomainModel(RemoteDomainConnectionService.java:572)
> [Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService.access$1100(RemoteDomainConnectionService.java:131)
> [Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService$2.applyDomainModel(RemoteDomainConnectionService.java:515)
> [Host Controller] at org.jboss.as.host.controller.RemoteDomainConnection.applyDomainModel(RemoteDomainConnection.java:311)
> [Host Controller] at org.jboss.as.host.controller.RemoteDomainConnection$RegisterSubsystemsRequest$1.execute(RemoteDomainConnection.java:454)
> [Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> [Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> [Host Controller] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [Host Controller] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [Host Controller] at java.lang.Thread.run(Thread.java:748)
> [Host Controller] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> [Host Controller]
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3243) EAP7.0 slave host with ignore-unused-configuration=false throws NPE
by Ken Wills (JIRA)
Ken Wills created WFCORE-3243:
---------------------------------
Summary: EAP7.0 slave host with ignore-unused-configuration=false throws NPE
Key: WFCORE-3243
URL: https://issues.jboss.org/browse/WFCORE-3243
Project: WildFly Core
Issue Type: Bug
Reporter: Ken Wills
[Host Controller] 15:41:44,863 ERROR [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 2) WFLYCTL0013: Operation ("describe-model") failed - address: ([("profile" => "default")]): java.lang.NullPointerException
[Host Controller] at org.jboss.as.domain.controller.operations.GenericModelDescribeOperationHandler.execute(GenericModelDescribeOperationHandler.java:144)
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
[Host Controller] at org.jboss.as.controller.ReadOnlyContext.executeOperation(ReadOnlyContext.java:83)
[Host Controller] at org.jboss.as.controller.ModelControllerImpl.executeReadOnlyOperation(ModelControllerImpl.java:284)
[Host Controller] at org.jboss.as.controller.ModelControllerImpl.executeReadOnlyOperation(ModelControllerImpl.java:267)
[Host Controller] at org.jboss.as.controller.AbstractControllerService.executeReadOnlyOperation(AbstractControllerService.java:444)
[Host Controller] at org.jboss.as.host.controller.DomainModelControllerService.access$1500(DomainModelControllerService.java:179)
[Host Controller] at org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor.executeReadOnly(DomainModelControllerService.java:1269)
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.execute(SyncModelOperationHandler.java:135)
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
[Host Controller] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
[Host Controller] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
[Host Controller] at org.jboss.as.controller.AbstractControllerService.internalExecute(AbstractControllerService.java:408)
[Host Controller] at org.jboss.as.host.controller.DomainModelControllerService.access$900(DomainModelControllerService.java:179)
[Host Controller] at org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor.execute(DomainModelControllerService.java:1238)
[Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService.applyRemoteDomainModel(RemoteDomainConnectionService.java:572)
[Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService.access$1100(RemoteDomainConnectionService.java:131)
[Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService$2.applyDomainModel(RemoteDomainConnectionService.java:515)
[Host Controller] at org.jboss.as.host.controller.RemoteDomainConnection.applyDomainModel(RemoteDomainConnection.java:311)
[Host Controller] at org.jboss.as.host.controller.RemoteDomainConnection$RegisterSubsystemsRequest$1.execute(RemoteDomainConnection.java:454)
[Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
[Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
[Host Controller] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[Host Controller] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[Host Controller] at java.lang.Thread.run(Thread.java:748)
[Host Controller] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
[Host Controller]
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3210) Wildfly module isolation not working consistently
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugi... ]
David Lloyd commented on WFCORE-3210:
-------------------------------------
You can use appenders written to the log4j API with our (JUL-based) log manager, yes. I believe all you have to do is add a custom-handler with the module and class name of the appender. I believe that it does require you to package any customized appender as a module though.
> Wildfly module isolation not working consistently
> -------------------------------------------------
>
> Key: WFCORE-3210
> URL: https://issues.jboss.org/browse/WFCORE-3210
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging, Modules
> Affects Versions: 2.2.0.Final
> Reporter: Nuno Godinho de Matos
>
> There is an underministic bug on the module layer of wildfly, whereby the boot logic of the application server is not ensured to give the appropriate module isolation - which can lead to unexpected boot classpath problems.
> An example of this phenomena is given on the wildfly forum thread:
> https://developer.jboss.org/thread/275839
> In this example, we have the logging subsystem setup to use a custome handler.
> The custom handler wishes to have acces to the JUL extension classes on the org.jboss.logmanger module, but wishes to do have no relationship with the org.apache.log4j packages associated to the wildfly org.jboss.log4j module.
> What we see in this example is that an application gets from wildfly mixed behavior.
> Most of the time, during boot, the processes works without problem, where the custom handler runs isolated from the undersired log4j libraries within wildfly.
> But other times the application boot procedure will not go smoothly with the custom handler having processes routing JUL LogRecords events into the bundled log4j because the application server has loaded some of the classes that exist the org.jboss.log4j module.
> And as we know when the same class is loaded by different class loaders, then that class that orinates from class loader A cannot be assigned to the corresponding class of class loader B, even if the classes are exactly the same.
> This is not an isolated issue.
> There are also open issues on the wildfly forum reporting on startup problems on the logging subsystme where sometimes the LogManager class had not yet been loaded, and sometimes this issue goes away.
> This is an indication of some deep issue engrained into the module loading, where the module isolation behavior is not ensured to work all the time and that the boot procedure is not deterministically reliable.
> It should not be that the application server some time starts successfully and others not.
> Booting wildfly should always result in the same outcode.
> Problems of this nature with class loading problems should either always happen if the configuration is not done properly or never happen if the configuration is proper.
> In the case of thread:
> https://developer.jboss.org/thread/275839
> Our belief is that the configuration is doing all it possible can to request the necessary module isolation from base packages and the outcome where log4j class load problems take place should never be allowed to happen.
> Many thanks.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3210) Wildfly module isolation not working consistently
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugi... ]
Nuno Godinho de Matos commented on WFCORE-3210:
-----------------------------------------------
Hi David,
Many thanks for your question.
No I did not know.
My impression was that if I were to deploy an individual application with log4jproperties file, wildfly would understand this and configure that application to be Logging with log4j.
Therefore a per deployment support of log4j.
The disadvantage there would be:
You lose the ability of supporting a single log file to keep track of category log levels for all of the deployments
Each application will have to log to its own log files.
You miss out on important background log messages that are not directly related to your deployed application.
To name but a few of the reasons why the per deployment logging configuration is not of interest to us, and the logging configuration like done logging subsytem level is much more I retesting for us.
Are you then saying that it is possible to have something like the subsystem logging configuration but instead of using jul based appenders to simply use log4j?
Can you point me onto the documentation for this?
Many many thanks.
> Wildfly module isolation not working consistently
> -------------------------------------------------
>
> Key: WFCORE-3210
> URL: https://issues.jboss.org/browse/WFCORE-3210
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging, Modules
> Affects Versions: 2.2.0.Final
> Reporter: Nuno Godinho de Matos
>
> There is an underministic bug on the module layer of wildfly, whereby the boot logic of the application server is not ensured to give the appropriate module isolation - which can lead to unexpected boot classpath problems.
> An example of this phenomena is given on the wildfly forum thread:
> https://developer.jboss.org/thread/275839
> In this example, we have the logging subsystem setup to use a custome handler.
> The custom handler wishes to have acces to the JUL extension classes on the org.jboss.logmanger module, but wishes to do have no relationship with the org.apache.log4j packages associated to the wildfly org.jboss.log4j module.
> What we see in this example is that an application gets from wildfly mixed behavior.
> Most of the time, during boot, the processes works without problem, where the custom handler runs isolated from the undersired log4j libraries within wildfly.
> But other times the application boot procedure will not go smoothly with the custom handler having processes routing JUL LogRecords events into the bundled log4j because the application server has loaded some of the classes that exist the org.jboss.log4j module.
> And as we know when the same class is loaded by different class loaders, then that class that orinates from class loader A cannot be assigned to the corresponding class of class loader B, even if the classes are exactly the same.
> This is not an isolated issue.
> There are also open issues on the wildfly forum reporting on startup problems on the logging subsystme where sometimes the LogManager class had not yet been loaded, and sometimes this issue goes away.
> This is an indication of some deep issue engrained into the module loading, where the module isolation behavior is not ensured to work all the time and that the boot procedure is not deterministically reliable.
> It should not be that the application server some time starts successfully and others not.
> Booting wildfly should always result in the same outcode.
> Problems of this nature with class loading problems should either always happen if the configuration is not done properly or never happen if the configuration is proper.
> In the case of thread:
> https://developer.jboss.org/thread/275839
> Our belief is that the configuration is doing all it possible can to request the necessary module isolation from base packages and the outcome where log4j class load problems take place should never be allowed to happen.
> Many thanks.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3242) Seam integration jar name mismatch between WildFly Core and WildFly
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-3242:
----------------------------------------
Summary: Seam integration jar name mismatch between WildFly Core and WildFly
Key: WFCORE-3242
URL: https://issues.jboss.org/browse/WFCORE-3242
Project: WildFly Core
Issue Type: Bug
Affects Versions: 3.0.1.Final
Reporter: Tõnis Pool
Assignee: Tomaz Cerar
Priority: Critical
Fix For: 3.0.2.Final
Trying to deploy a simple JBoss Seam 2.3.x application on WildFly 11.0.0.CR1 will fail with:
{noformat}
09:06:16,492 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."pkg-seamJboss23-notChangedComponentsReinitializedOnce.war".DEPENDENCIES: org.jboss.msc.service.StartException in service jboss.deployment.unit."pkg-seamJboss23-notChangedComponentsReinitializedOnce.war".DEPENDENCIES: WFLYSRV0153: Failed to process phase DEPENDENCIES of deployment "pkg-seamJboss23-notChangedComponentsReinitializedOnce.war"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
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)
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYSRV0157: No Seam Integration jar present: Module "org.jboss.integration.ext-content" from local module loader @1ae369b7 (finder: local module finder @6fffcba5 (roots: /Users/poolik/app_servers/wildfly-11.0.0.CR1/modules,/Users/poolik/app_servers/wildfly-11.0.0.CR1/modules/system/layers/base))
at org.jboss.as.server.deployment.integration.Seam2Processor.deploy(Seam2Processor.java:161)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165)
... 5 more
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYSRV0157: No Seam Integration jar present: Module "org.jboss.integration.ext-content" from local module loader @1ae369b7 (finder: local module finder @6fffcba5 (roots: /Users/poolik/app_servers/wildfly-11.0.0.CR1/modules,/Users/poolik/app_servers/wildfly-11.0.0.CR1/modules/system/layers/base))
at org.jboss.as.server.deployment.integration.Seam2Processor.getSeamIntResourceRoot(Seam2Processor.java:127)
at org.jboss.as.server.deployment.integration.Seam2Processor.deploy(Seam2Processor.java:158)
... 6 more
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYSRV0157: No Seam Integration jar present: Module "org.jboss.integration.ext-content" from local module loader @1ae369b7 (finder: local module finder @6fffcba5 (roots: /Users/poolik/app_servers/wildfly-11.0.0.CR1/modules,/Users/poolik/app_servers/wildfly-11.0.0.CR1/modules/system/layers/base))
at org.jboss.as.server.deployment.integration.Seam2Processor.getSeamIntResourceRoot(Seam2Processor.java:100)
... 7 more
{noformat}
The issue is that in WFLY-8660 the Seam Integration jar was renamed to {{jboss-seam-int-jbossas.jar}}
([commit|https://github.com/wildfly/wildfly/pull/9982/commits/e8e751299ed24...]) but Seam2Processor in WildFly Core still [expects it to be|https://github.com/wildfly/wildfly-core/blob/master/server/src/main/ja...] {{jboss-seam-int.jar}}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (HAWKULARQE-173) UX Improvement - When adding a datasource - MIQ Sprint-67
by Guilherme Baufaker Rêgo (JIRA)
[ https://issues.jboss.org/browse/HAWKULARQE-173?page=com.atlassian.jira.pl... ]
Guilherme Baufaker Rêgo updated HAWKULARQE-173:
-----------------------------------------------
Attachment: miq-screen.png
Error Screen.png
> UX Improvement - When adding a datasource - MIQ Sprint-67
> ---------------------------------------------------------
>
> Key: HAWKULARQE-173
> URL: https://issues.jboss.org/browse/HAWKULARQE-173
> Project: Hawkular QE
> Issue Type: Task
> Reporter: Matt Mahoney
> Assignee: Sunil kondkar
> Attachments: Error Screen.png, Error Screen.png, miq-screen.png
>
>
> From MIQ Sprint-67 Demo:
> UX Improvement - When adding a datasource, there is a need to fetch available jdbc drivers from middleware server. If a provider is not running, do not display an exception when fetching jdbc drivers, but show a descriptive warning message and allow the user to close the wizard.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (HAWKULARQE-173) UX Improvement - When adding a datasource - MIQ Sprint-67
by Guilherme Baufaker Rêgo (JIRA)
[ https://issues.jboss.org/browse/HAWKULARQE-173?page=com.atlassian.jira.pl... ]
Guilherme Baufaker Rêgo reassigned HAWKULARQE-173:
--------------------------------------------------
Assignee: Guilherme Baufaker Rêgo (was: Sunil kondkar)
> UX Improvement - When adding a datasource - MIQ Sprint-67
> ---------------------------------------------------------
>
> Key: HAWKULARQE-173
> URL: https://issues.jboss.org/browse/HAWKULARQE-173
> Project: Hawkular QE
> Issue Type: Task
> Reporter: Matt Mahoney
> Assignee: Guilherme Baufaker Rêgo
> Attachments: Error Screen.png
>
>
> From MIQ Sprint-67 Demo:
> UX Improvement - When adding a datasource, there is a need to fetch available jdbc drivers from middleware server. If a provider is not running, do not display an exception when fetching jdbc drivers, but show a descriptive warning message and allow the user to close the wizard.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (HAWKULARQE-173) UX Improvement - When adding a datasource - MIQ Sprint-67
by Guilherme Baufaker Rêgo (JIRA)
[ https://issues.jboss.org/browse/HAWKULARQE-173?page=com.atlassian.jira.pl... ]
Guilherme Baufaker Rêgo reassigned HAWKULARQE-173:
--------------------------------------------------
Assignee: Sunil kondkar (was: Guilherme Baufaker Rêgo)
> UX Improvement - When adding a datasource - MIQ Sprint-67
> ---------------------------------------------------------
>
> Key: HAWKULARQE-173
> URL: https://issues.jboss.org/browse/HAWKULARQE-173
> Project: Hawkular QE
> Issue Type: Task
> Reporter: Matt Mahoney
> Assignee: Sunil kondkar
> Attachments: Error Screen.png
>
>
> From MIQ Sprint-67 Demo:
> UX Improvement - When adding a datasource, there is a need to fetch available jdbc drivers from middleware server. If a provider is not running, do not display an exception when fetching jdbc drivers, but show a descriptive warning message and allow the user to close the wizard.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months