[JBoss JIRA] (WFCORE-1499) logging custom-handler does not load module with slot
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1499?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration updated WFCORE-1499:
--------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1349223
Bugzilla Update: Perform
> logging custom-handler does not load module with slot
> -----------------------------------------------------
>
> Key: WFCORE-1499
> URL: https://issues.jboss.org/browse/WFCORE-1499
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: Erwan Lacoste
> Assignee: James Perkins
> Fix For: 2.2.0.CR1, 3.0.0.Alpha1
>
>
> Tested on EAP 6.4
> when creating a module for a custom *loghandler*, everything works fine if the module is package in default main slot, e.g.
> my/loghandler/main
> - module.xml
> - my.jar
> {code:xml}
> <custom-handler name="4H" class="my.handler.Periodic4HFileHandler" module="my.loghandler">
> {code}
> Nevertheless I want to version the module, therefore package my module with a given slot:
> my/loghandler/1.0
> - module.xml
> - my.jar
> {code:xml}
> <custom-handler name="4H" class="my.handler.Periodic4HFileHandler" module="my.loghandler:1.0">
> {code}
> But this fails with following stacktrace:
> {code}
> 11:53:50,458 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014612: Operation ("add") failed - address: ([
> ("subsystem" => "logging"),
> ("custom-handler" => "4H")
> ]): java.lang.IllegalArgumentException: JBAS011532: Failed to load module 'my.loghandler:1.0' for handler '4H'
> at org.jboss.as.logging.HandlerOperations$HandlerAddOperationStepHandler.createHandlerConfiguration(HandlerOperations.java:320) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.logging.HandlerOperations$HandlerAddOperationStepHandler.performRuntime(HandlerOperations.java:255) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.logging.LoggingOperations$LoggingAddOperationStepHandler$1.execute(LoggingOperations.java:206) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:702) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:537) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:338) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:314) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1144) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:416) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:301) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.server.ServerService.boot(ServerService.java:355) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.server.ServerService.boot(ServerService.java:330) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:263) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_65]
> Caused by: org.jboss.modules.ModuleNotFoundException: my.loghandler:1.0:main
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:240) [jboss-modules.jar:1.3.6.Final-redhat-1]
> at org.jboss.as.logging.HandlerOperations$HandlerAddOperationStepHandler.createHandlerConfiguration(HandlerOperations.java:295) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> ... 13 more
> {code}
> why is the module not found being *my.loghandler:1.0:main* ?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1612) Allow applying the same configuration changes to multiple Standalone nodes
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1612?page=com.atlassian.jira.plugi... ]
Tomaz Cerar commented on WFCORE-1612:
-------------------------------------
(sorry posted previous comment, without seeing the additional comments)
I don't think we should go to such great lengths as to have on-the-fly runtime updates once config changes trough koubernetes (or other xpaas)
As main point with whole container based deployments is that everything is stateless and updating application or changing its config just means to deploy new version of container or at least restart it to properly apply config from ConfigMap / etcd.
As such, we could just read config from there on boot of the server, which is in spirit of stateless containers.
Another thing that our openshift containers expose is access to WildFly/EAP mgmt port trough which you can manage servers any way you like.
> Allow applying the same configuration changes to multiple Standalone nodes
> --------------------------------------------------------------------------
>
> Key: WFCORE-1612
> URL: https://issues.jboss.org/browse/WFCORE-1612
> Project: WildFly Core
> Issue Type: Feature Request
> Reporter: Sebastian Łaskawiec
> Assignee: Brian Stansberry
>
> I would like to request a supporting configuration changes to multiple standalone nodes the same way as currently DMR in domain mode works.
> The main motivation behind that is using WF based Projects (like Infinispan HotRod Server) in the Cloud. By using DMR we can ensure changing configuration on the fly, which is very important in our case.
> In Infinispan project we use DMR to propagate configuration changes to all nodes in the cluster (e.g. adding a cache, changing it etc). When considering Cloud deployment we use Standalone mode. It would be nice to find a way to propagate configuration changes to all servers the same way as we do in Domain mode.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1612) Allow applying the same configuration changes to multiple Standalone nodes
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1612?page=com.atlassian.jira.plugi... ]
Tomaz Cerar updated WFCORE-1612:
--------------------------------
Comment: was deleted
(was: Well, than just connect to each standalone server separately and apply changes, I don't see what could we do to help with this kind of scenario.
you need some coordinator "server" which pushes updates to all standalone servers.
Our ootb solution for that is domain mode, but with standalone you can do it with some other server / tool that does that for you.
maybe ansible or something like that.)
> Allow applying the same configuration changes to multiple Standalone nodes
> --------------------------------------------------------------------------
>
> Key: WFCORE-1612
> URL: https://issues.jboss.org/browse/WFCORE-1612
> Project: WildFly Core
> Issue Type: Feature Request
> Reporter: Sebastian Łaskawiec
> Assignee: Brian Stansberry
>
> I would like to request a supporting configuration changes to multiple standalone nodes the same way as currently DMR in domain mode works.
> The main motivation behind that is using WF based Projects (like Infinispan HotRod Server) in the Cloud. By using DMR we can ensure changing configuration on the fly, which is very important in our case.
> In Infinispan project we use DMR to propagate configuration changes to all nodes in the cluster (e.g. adding a cache, changing it etc). When considering Cloud deployment we use Standalone mode. It would be nice to find a way to propagate configuration changes to all servers the same way as we do in Domain mode.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6566) SAR deployer uses wrong MBean class to resolve source Method for property injection
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-6566?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-6566:
-----------------------------------------------
Ivo Hradek <ihradek(a)redhat.com> changed the Status of [bug 1329314|https://bugzilla.redhat.com/show_bug.cgi?id=1329314] from ON_QA to VERIFIED
> SAR deployer uses wrong MBean class to resolve source Method for property injection
> -----------------------------------------------------------------------------------
>
> Key: WFLY-6566
> URL: https://issues.jboss.org/browse/WFLY-6566
> Project: WildFly
> Issue Type: Bug
> Components: JMX, Server
> Affects Versions: 10.0.0.Final
> Reporter: Bartosz Spyrko-Śmietanko
> Assignee: Bartosz Spyrko-Śmietanko
> Labels: downstream_dependency
> Fix For: 10.1.0.Final
>
>
> If using a <value-factory> or <inject> element with "parameter" attribute in jboss-service.xml to inject a value from one bean to another, a "java.lang.IllegalArgumentException: object is not an instance of declaring class" error is raised during deployment.
> jboss-service.xml
> {noformat}
> <server xmlns="urn:jboss:service:7.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:jboss:service:7.0 jboss-service_7_0.xsd">
> <mbean code="com.test.redhat.mbean.OtherValueFactory" name="test:type=OtherValueFactory">
> <attribute name="WelcomeString">Welcome</attribute>
> <attribute name="CustName">Other</attribute>
> </mbean>
> <mbean code="com.test.redhat.mbean.TestValueFactory" name="test:type=SarTestValueFactory">
> <depends>test:type=OtherValueFactory</depends>
> <attribute name="WelcomeString">Welcome</attribute>
> <attribute name="CustName">
> <value-factory bean="test:type=OtherValueFactory" method="getNameOfCustomer">
> <parameter class="java.lang.String">Foo</parameter>
> </value-factory>
> </attribute>
> </mbean>
> </server>
> {noformat}
> Full error:
> {noformat}
> 16:54:36,505 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0027: Starting deployment of "test.sar" (runtime-name: "test.sar")
> 16:54:36,690 WARN [org.jboss.msc.inject] (MSC service thread 1-2) MSC000100: Unexpected failure to uninject public void com.test.redhat.mbean.TestValueFactory.setCustName(java.lang.String): java.lang.NullPointerException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.msc.value.MethodValue.getValue(MethodValue.java:62)
> at org.jboss.msc.value.CachedValue.getValue(CachedValue.java:54)
> at org.jboss.msc.value.Values.getValues(Values.java:68)
> at org.jboss.msc.value.Values.getValues(Values.java:82)
> at org.jboss.msc.inject.MethodInjector.uninject(MethodInjector.java:119)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.performInjections(ServiceControllerImpl.java:1923)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1876)
> 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)
> 16:54:36,691 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.mbean.service.test:type=SarTestValueFactory.create: org.jboss.msc.service.StartException in service jboss.mbean.service.test:type=SarTestValueFactory.create: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> 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.msc.inject.InjectionException: Injection failed
> at org.jboss.msc.inject.MethodInjector.inject(MethodInjector.java:102)
> at org.jboss.msc.service.ServiceControllerImpl.doInject(ServiceControllerImpl.java:1672)
> at org.jboss.msc.service.ServiceControllerImpl.access$2000(ServiceControllerImpl.java:51)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.performInjections(ServiceControllerImpl.java:1917)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1876)
> ... 3 more
> Caused by: java.lang.IllegalArgumentException: object is not an instance of declaring class
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.msc.value.MethodValue.getValue(MethodValue.java:62)
> at org.jboss.msc.value.CachedValue.getValue(CachedValue.java:54)
> at org.jboss.msc.value.Values.getValues(Values.java:68)
> at org.jboss.msc.value.Values.getValues(Values.java:82)
> at org.jboss.msc.inject.MethodInjector.inject(MethodInjector.java:92)
> ... 7 more
> 16:54:36,697 INFO [com.test.redhat.mbean.OtherValueFactory] (ServerService Thread Pool -- 58) >> TestValuFactory.start() invoked
> 16:54:36,698 INFO [stdout] (ServerService Thread Pool -- 58) TestValuFactory.start() invoked
> 16:54:36,776 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "test.sar")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.mbean.service.test:type=SarTestValueFactory.create" => "org.jboss.msc.service.StartException in service jboss.mbean.service.test:type=SarTestValueFactory.create: Failed to start service
> Caused by: org.jboss.msc.inject.InjectionException: Injection failed
> Caused by: java.lang.IllegalArgumentException: object is not an instance of declaring class"}}
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1495) server instances cannot find keytab during domain startup
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1495?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1495:
-------------------------------------------------
Ivo Hradek <ihradek(a)redhat.com> changed the Status of [bug 1328997|https://bugzilla.redhat.com/show_bug.cgi?id=1328997] from ON_QA to VERIFIED
> server instances cannot find keytab during domain startup
> ---------------------------------------------------------
>
> Key: WFCORE-1495
> URL: https://issues.jboss.org/browse/WFCORE-1495
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Reporter: Derek Horton
> Assignee: Vlado Pakan
> Fix For: 3.0.0.Alpha2
>
> Original Estimate: 4 days
> Time Spent: 3 days, 4 hours
> Remaining Estimate: 4 hours
>
> In domain mode, the server instances cannot find the keytab if the ApplicationRealm is configured to use kerberos as the server-identity:
> {code}
> <security-realm name="ApplicationRealm">
> <server-identities>
> <kerberos>
> <keytab principal="remote/imahost.imadomain.net@VM29" path="/path/to/keytab"/>
> </kerberos>
> </server-identities>
> <authentication>
> <kerberos remove-realm="true"/>
> </authentication>
> <authorization>
> <properties path="application-roles.properties" relative-to="jboss.domain.config.dir"/>
> </authorization>
> </security-realm>
> {code}
> This results in the following error and the server instances fail to start:
> [Server:server-one] 15:10:35,360 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("validate-authentication") failed - address: ([
> [Server:server-one] ("core-service" => "management"),
> [Server:server-one] ("security-realm" => "ApplicationRealm")
> [Server:server-one] ]) - failure description: "WFLYDM0094: Kerberos is enabled for authentication on security realm 'ApplicationRealm' but no Keytab has been added to the server-identity."
> [Server:server-one] 15:10:35,376 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-64) Filesystem deployment scanner deployment failure removes unrelated deployments
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-64?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFCORE-64:
-----------------------------------------------
Jiří Bílek <jbilek(a)redhat.com> changed the Status of [bug 1327093|https://bugzilla.redhat.com/show_bug.cgi?id=1327093] from ON_QA to VERIFIED
> Filesystem deployment scanner deployment failure removes unrelated deployments
> ------------------------------------------------------------------------------
>
> Key: WFCORE-64
> URL: https://issues.jboss.org/browse/WFCORE-64
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha5
> Environment: WIndows and Linux platforms both exhibit the issue
> Reporter: Jess Holle
> Assignee: ehsavoie Hugonnet
>
> If one's standalone-full.xml configuration contains something like:
> <deployments>
> <deployment name="MyWebApp.war" runtime-name="MyWebApp.war" enabled="true">
> <fs-exploded path="../../SomeDir/MyWebApp.war" relative-to="jboss.home.dir"/>
> </deployment>
> </deployments>
> whether manually inserted (while the server is not running) or installed via the CLI via
> /deployment=ServiceCenter.war/:add(runtime-name=ServiceCenter.war,content=[{archive=false,path="../../Windchill/ServiceCenter.war",relative-to="jboss.home.dir"}])
> and a deployment scanner like:
> <subsystem xmlns="urn:jboss:domain:deployment-scanner:2.0">
> <deployment-scanner name="1" path="../../../Applications" relative-to="jboss.server.base.dir" scan-interval="5000" auto-deploy-exploded="true"/>
> </subsystem>
> a failure by a deployment-scanner to deploy an application (exploded in my case, though I'm not sure this makes a difference) will cause the explicitly listed <deployments> to be removed from the configuration!
> This occurs irrespective of the value used for auto-deploy-exploded and to <deployment> elements that had already successfully been deployed and started.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1585) Logging handler lost due to conflict handlers in logging.properties and standalone.xml
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1585?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1585:
-------------------------------------------------
Martin Šmérek <msmerek(a)redhat.com> changed the Status of [bug 1345816|https://bugzilla.redhat.com/show_bug.cgi?id=1345816] from NEW to ASSIGNED
> Logging handler lost due to conflict handlers in logging.properties and standalone.xml
> --------------------------------------------------------------------------------------
>
> Key: WFCORE-1585
> URL: https://issues.jboss.org/browse/WFCORE-1585
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Affects Versions: 2.0.10.Final
> Reporter: Takayoshi Kimura
> Assignee: James Perkins
> Attachments: logging.properties
>
>
> Console logging doesn't work after logging subsystem init with the following configuration.
> * logging.properties is configured with ASYNC with CONSOLE handlers.
> * standalone.xml is configured with stock FILE and CONSOLE handlers.
> Background of why there is a mismatch between logging.properties and standalone.xml, EAP image for OpenShift is configured with ASYNC with CONSOLE handlers by default. But users can customize standalone.xml and apply custom configuration based on the stock standalone.xml.
> Expected result is logging configuration from standalone.xml is applied once logging subsystem come up regardless the mismatch.
> Most likely related to WFCORE-159.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-64) Filesystem deployment scanner deployment failure removes unrelated deployments
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-64?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFCORE-64:
-----------------------------------------------
Jiří Bílek <jbilek(a)redhat.com> changed the Status of [bug 1291710|https://bugzilla.redhat.com/show_bug.cgi?id=1291710] from ON_QA to VERIFIED
> Filesystem deployment scanner deployment failure removes unrelated deployments
> ------------------------------------------------------------------------------
>
> Key: WFCORE-64
> URL: https://issues.jboss.org/browse/WFCORE-64
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha5
> Environment: WIndows and Linux platforms both exhibit the issue
> Reporter: Jess Holle
> Assignee: ehsavoie Hugonnet
>
> If one's standalone-full.xml configuration contains something like:
> <deployments>
> <deployment name="MyWebApp.war" runtime-name="MyWebApp.war" enabled="true">
> <fs-exploded path="../../SomeDir/MyWebApp.war" relative-to="jboss.home.dir"/>
> </deployment>
> </deployments>
> whether manually inserted (while the server is not running) or installed via the CLI via
> /deployment=ServiceCenter.war/:add(runtime-name=ServiceCenter.war,content=[{archive=false,path="../../Windchill/ServiceCenter.war",relative-to="jboss.home.dir"}])
> and a deployment scanner like:
> <subsystem xmlns="urn:jboss:domain:deployment-scanner:2.0">
> <deployment-scanner name="1" path="../../../Applications" relative-to="jboss.server.base.dir" scan-interval="5000" auto-deploy-exploded="true"/>
> </subsystem>
> a failure by a deployment-scanner to deploy an application (exploded in my case, though I'm not sure this makes a difference) will cause the explicitly listed <deployments> to be removed from the configuration!
> This occurs irrespective of the value used for auto-deploy-exploded and to <deployment> elements that had already successfully been deployed and started.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months