[JBoss JIRA] (WFLY-1719) ClassCastException on clustered deployment
by Aleksandar Kostadinov (JIRA)
[ https://issues.jboss.org/browse/WFLY-1719?page=com.atlassian.jira.plugin.... ]
Aleksandar Kostadinov commented on WFLY-1719:
---------------------------------------------
FYI I see the same exception running two standalone servers in cluster mode and deploying cluster-demo app (from jboss-ec2-eap-samples rpm)
> ClassCastException on clustered deployment
> ------------------------------------------
>
> Key: WFLY-1719
> URL: https://issues.jboss.org/browse/WFLY-1719
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.0.0.Alpha3
> Environment: windows; oracle jdk 1.7.0_17
> Reporter: Matthias Berndt
> Assignee: Paul Ferraro
> Attachments: cluster-demo.war
>
>
> In a windows 7 environment the cluster replication for a clustered web archive deployed in a server with _full-ha_-profile fails with a class cast exception.
> {code}
> 21:00:03,514 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "cd" (runtime-name: "cd.war")
> 21:00:05,179 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-3) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 21:00:05,179 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-4) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 21:00:05,182 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-4) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 21:00:05,182 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-3) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 21:00:05,183 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-3) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 21:00:05,184 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-3) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 21:00:05,228 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 61) ISPN000078: Starting JGroups Channel
> 21:00:05,240 INFO [stdout] (ServerService Thread Pool -- 61)
> 21:00:05,240 INFO [stdout] (ServerService Thread Pool -- 61) -------------------------------------------------------------------
> 21:00:05,240 INFO [stdout] (ServerService Thread Pool -- 61) GMS: address=master:server-three/web, cluster=web, physical address=127.0.0.1:55450
> 21:00:05,240 INFO [stdout] (ServerService Thread Pool -- 61) -------------------------------------------------------------------
> 21:00:07,251 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 61) ISPN000094: Received new cluster view: [master:server-three/web|0] [master:server-three/web]
> 21:00:07,317 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 61) ISPN000079: Cache local address is master:server-three/web, physical addresses are [127.0.0.1:55450]
> 21:00:07,326 INFO [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 61) ISPN000128: Infinispan version: Infinispan 'Tactical Nuclear Penguin' 5.3.0.Final
> 21:00:07,492 INFO [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 61) ISPN000031: MBeans were successfully registered to the platform MBean server.
> 21:00:07,492 INFO [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 65) ISPN000031: MBeans were successfully registered to the platform MBean server.
> 21:00:07,505 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 65) JBAS010281: Started default-host/cd cache from web container
> 21:00:07,505 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 61) JBAS010281: Started repl cache from web container
> 21:00:07,637 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) JBAS018210: Register web context: /cd
> 21:00:07,675 INFO [org.jboss.as.server] (host-controller-connection-threads - 1) JBAS018559: Deployed "cd" (runtime-name : "cd.war")
> 21:00:57,609 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016009: Caught:: java.lang.ClassCastException: org.infinispan.transaction.TransactionTable cannot be cast to org.infinispan.transaction.xa.XaTransactionTable
> at org.infinispan.transaction.xa.TransactionXaAdapter.<init>(TransactionXaAdapter.java:100)
> at org.infinispan.CacheImpl.getXAResource(CacheImpl.java:875)
> at org.infinispan.AbstractDelegatingAdvancedCache.getXAResource(AbstractDelegatingAdvancedCache.java:158)
> at org.jboss.as.clustering.infinispan.subsystem.CacheService$InfinispanXAResourceRecovery.getXAResources(CacheService.java:112)
> at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51) [narayana-jts-integration-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:503) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:159) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:743) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> {code}
> The exception is reoccuring every ten seconds.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (WFLY-1785) WAR_BUNDLES_JSF_IMPL does not work for EAR files
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1785?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1785:
-----------------------------------------------
James Livingston <jlivings(a)redhat.com> made a comment on [bug 991276|https://bugzilla.redhat.com/show_bug.cgi?id=991276]
If you package a JSF implementation inside a WAR you can use WAR_BUNDLE_JSF_IMPL to allow it to work rather than the container's implementation.
This does not work if it is packaged into an EAR.
> WAR_BUNDLES_JSF_IMPL does not work for EAR files
> ------------------------------------------------
>
> Key: WFLY-1785
> URL: https://issues.jboss.org/browse/WFLY-1785
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 8.0.0.Alpha3
> Environment: Windows 7 Professional. Service Pack 1. 32 Bit.
> Reporter: William Lovett
> Assignee: Stan Silvert
> Priority: Minor
> Fix For: 8.0.0.Alpha4
>
>
> Hello Learned and Astonishly Charming JBoss Associates,
> I've been trying for quite some time now to get my successfully deployed WAR to become a successfully deployed EAR. Much to my chagrin, this has been my white whale, and it just might kill me.
> In a nutshell, the attached EAR file contains a WAR. If you deploy that WAR file everything works smooth as butter. As soon as you put it in an EAR format however, you get the following well placed riposte:
> 19:33:57,513 WARN [org.jboss.as.jsf] (MSC service thread 1-2) JBAS012603: Unknown JSF version 'WAR_BUNDLES_JSF_IMPL'. Default version 'main' will be used instead.
> Not cool, JBoss. Not cool.
> I've tried moving the jars to different places in the WAR/EAR. I've tried using Manifest files. I've tried colorfully adorned four letter expletives. JBoss is unmoved. Does anyone know why JBoss is rejecting my JSF advances? Can the relationship be fixed?
> Using EAP 6.1 which I believe is equivalent to AS 7.2.
> Thanks in advance,
> Will
> PS: The forum didn't like me attaching a 1.8 meg file so here's a download link instead
> http://www.williverstravels.com/JDev/Forums/Threads/230850/TestEar.ear
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (WFLY-1785) WAR_BUNDLES_JSF_IMPL does not work for EAR files
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1785?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-1785:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=991276
> WAR_BUNDLES_JSF_IMPL does not work for EAR files
> ------------------------------------------------
>
> Key: WFLY-1785
> URL: https://issues.jboss.org/browse/WFLY-1785
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 8.0.0.Alpha3
> Environment: Windows 7 Professional. Service Pack 1. 32 Bit.
> Reporter: William Lovett
> Assignee: Stan Silvert
> Priority: Minor
> Fix For: 8.0.0.Alpha4
>
>
> Hello Learned and Astonishly Charming JBoss Associates,
> I've been trying for quite some time now to get my successfully deployed WAR to become a successfully deployed EAR. Much to my chagrin, this has been my white whale, and it just might kill me.
> In a nutshell, the attached EAR file contains a WAR. If you deploy that WAR file everything works smooth as butter. As soon as you put it in an EAR format however, you get the following well placed riposte:
> 19:33:57,513 WARN [org.jboss.as.jsf] (MSC service thread 1-2) JBAS012603: Unknown JSF version 'WAR_BUNDLES_JSF_IMPL'. Default version 'main' will be used instead.
> Not cool, JBoss. Not cool.
> I've tried moving the jars to different places in the WAR/EAR. I've tried using Manifest files. I've tried colorfully adorned four letter expletives. JBoss is unmoved. Does anyone know why JBoss is rejecting my JSF advances? Can the relationship be fixed?
> Using EAP 6.1 which I believe is equivalent to AS 7.2.
> Thanks in advance,
> Will
> PS: The forum didn't like me attaching a 1.8 meg file so here's a download link instead
> http://www.williverstravels.com/JDev/Forums/Threads/230850/TestEar.ear
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (JBPORTAL-2494) taperstry 5.2.5 doesnot work on jboss 6.1.0
by Rukmini nagarajaiah (JIRA)
Rukmini nagarajaiah created JBPORTAL-2494:
---------------------------------------------
Summary: taperstry 5.2.5 doesnot work on jboss 6.1.0
Key: JBPORTAL-2494
URL: https://issues.jboss.org/browse/JBPORTAL-2494
Project: JBoss Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Rukmini nagarajaiah
Priority: Blocker
Hi
Currently in our organization we use Tapestry for UI and version is 5.0.15, on jboss 4 .
And Recently we upgraded Jboss version to 6.1.0, and the current version of tapestry which is 5.0.15 , does not work in jboss 6.
So we upgraded tapestry version to 5.2.5 and still we see the problem. Main problem is .tml files components are not getting resolved. I'm getting " could not resolve outputraw component class". And none of component classes which we created(for example sh.layout) are working. Please help us finding solution to the problem.
Also I have added ClasspathURLConverterJBoss6, ClasspathURLConverterJBoss6 for jboss 6 and i'm using the same in my AppModule class.
The same code works on Jboss 4. Is there some things i'm missing. please help.
Here is the exception:
Caused by: org.apache.tapestry5.ioc.internal.util.TapestryException: Unable to resolve 'outputraw' to a component class name. [at context:HomePage.tml, line 6]
at org.apache.tapestry5.internal.pageload.PageLoaderImpl.startComponent(PageLoaderImpl.java:743)
at org.apache.tapestry5.internal.pageload.PageLoaderImpl.component(PageLoaderImpl.java:627)
at org.apache.tapestry5.internal.pageload.PageLoaderImpl.processTemplateToken(PageLoaderImpl.java:426)
at org.apache.tapestry5.internal.pageload.PageLoaderImpl.element(PageLoaderImpl.java:687)
at org.apache.tapestry5.internal.pageload.PageLoaderImpl.processTemplateToken(PageLoaderImpl.java:421)
at org.apache.tapestry5.internal.pageload.PageLoaderImpl.programAssembler(PageLoaderImpl.java:264)
at org.apache.tapestry5.internal.pageload.PageLoaderImpl.access$900(PageLoaderImpl.java:65)
at org.apache.tapestry5.internal.pageload.PageLoaderImpl$4.invoke(PageLoaderImpl.java:236)
at org.apache.tapestry5.internal.pageload.PageLoaderImpl$4.invoke(PageLoaderImpl.java:220)
at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:65)
... 128 more
Caused by: org.apache.tapestry5.ioc.util.UnknownValueException: Unable to resolve 'outputraw' to a component class name.
at org.apache.tapestry5.internal.services.ComponentClassResolverImpl$6.invoke(ComponentClassResolverImpl.java:479)
at org.apache.tapestry5.internal.services.ComponentClassResolverImpl$6.invoke(ComponentClassResolverImpl.java:474)
at org.apache.tapestry5.ioc.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java:85)
at org.apache.tapestry5.internal.services.ComponentClassResolverImpl.resolveComponentTypeToClassName(ComponentClassResolverImpl.java:472)
at $ComponentClassResolver_1403720b257.resolveComponentTypeToClassName($ComponentClassResolver_1403720b257.java)
at org.apache.tapestry5.internal.pageload.PageLoaderImpl.startComponent(PageLoaderImpl.java:739)
... 137 more
Thanks,
Rukmin
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (AS7-3798) JGroups subsystem tcp stack should set NAKACK.use_mcast_xmit to false
by Aleksandar Kostadinov (JIRA)
[ https://issues.jboss.org/browse/AS7-3798?page=com.atlassian.jira.plugin.s... ]
Aleksandar Kostadinov commented on AS7-3798:
--------------------------------------------
Would this also work if the stack is UDB but ip_mcast=false ?
> JGroups subsystem tcp stack should set NAKACK.use_mcast_xmit to false
> ---------------------------------------------------------------------
>
> Key: AS7-3798
> URL: https://issues.jboss.org/browse/AS7-3798
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 7.1.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Minor
> Fix For: 7.1.1.Final
>
>
> ... to avoid the following unnecessary warning in the log:
> 10:38:00,676 WARNING [org.jgroups.protocols.pbcast.NAKACK] (pool-4-thread-1) use_mcast_xmit should not be used because the transport (TCP) does not support IP multicasting; setting use_mcast_xmit to false
> Consider setting this property automatically, based on whether the transport supports multicast.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (JGRP-1669) UDP should not stop message receiver thread after SocketException is caught
by Aleksandr Korostov (JIRA)
[ https://issues.jboss.org/browse/JGRP-1669?page=com.atlassian.jira.plugin.... ]
Aleksandr Korostov commented on JGRP-1669:
------------------------------------------
Is it possible to make the similar fix in 2.x release (e.g. make a 2.12.3 with that fix)?
> UDP should not stop message receiver thread after SocketException is caught
> ---------------------------------------------------------------------------
>
> Key: JGRP-1669
> URL: https://issues.jboss.org/browse/JGRP-1669
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 2.6.13
> Environment: Windows 2008 R2, Oracle JDK 1.6.0.24
> Reporter: Aleksandr Korostov
> Assignee: Bela Ban
> Fix For: 3.4
>
>
> One of our customers is getting the following error sporadically:
> {code}
> java.net.SocketException: socket closed
> at java.net.PlainDatagramSocketImpl.receive0(Native Method)
> at java.net.PlainDatagramSocketImpl.receive(Unknown Source)
> at java.net.DatagramSocket.receive(Unknown Source)
> at org.jgroups.protocols.UDP.run(UDP.java:262)
> at java.lang.Thread.run(Unknown Source)
> {code}
> (note that I modified UPD class to log the full stack trace because this stack trace was not logged by original version of UDP)
> I'm sure that socket was not closed by any Java code, the sender thread keeps running and sending messages via the same socket (if mcast_socket.close() had been called, the mcast_socket.send() would have thrown "socket closed" exception too but it did not).
> The main problem that this error stops the receiver thread so node stops receiving UDP messages from other nodes in the cluster.
> We cannot reproduce the error in our environment but I found cases of similar problem on the Internet:
> * https://forums.oracle.com/thread/2190450 (read the last post). It looks like Time-to-live-exceeded ICMP packet could force such an error on the multicast socket.
> * https://github.com/elasticsearch/elasticsearch/pull/2783 Here this problem was faced but the devs did not manage to find the root cause so they ended up implementing socket re-creation on error
> Given all that I think that UDP receiver thread should check mcast_socket.isClosed() before exiting. If socket is still open the thread should continue running (it may be safer to close the old socket and create a new one though)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (WFLY-1503) Unable to remove custom logging handler
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-1503?page=com.atlassian.jira.plugin.... ]
James Perkins resolved WFLY-1503.
---------------------------------
Resolution: Duplicate Issue
I think WFLY-1578 should fix this. I don't think there are any other fixes required.
> Unable to remove custom logging handler
> ---------------------------------------
>
> Key: WFLY-1503
> URL: https://issues.jboss.org/browse/WFLY-1503
> Project: WildFly
> Issue Type: Bug
> Components: Logging
> Affects Versions: 8.0.0.Alpha1
> Reporter: Carlo de Wolf
> Assignee: James Perkins
> Priority: Blocker
> Fix For: 8.0.0.Alpha4
>
>
> During removal of the custom handler in {{Log4jCustomHandlerTestCase}} the following error is shown:
> {noformat}
> 09:38:24,266 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("remove") failed - address: ([
> ("subsystem" => "logging"),
> ("custom-handler" => "customFileAppender")
> ]): java.lang.IllegalArgumentException: No reference found for 'org.jboss.as.logging.logmanager.Log4jAppenderHandler'
> at org.jboss.logmanager.config.AbstractPropertyConfiguration$5.validate(AbstractPropertyConfiguration.java:399) [jboss-logmanager-1.4.1.Final.jar:1.4.1.Final]
> at org.jboss.logmanager.config.AbstractPropertyConfiguration$5.validate(AbstractPropertyConfiguration.java:391) [jboss-logmanager-1.4.1.Final.jar:1.4.1.Final]
> at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:333) [jboss-logmanager-1.4.1.Final.jar:1.4.1.Final]
> at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:292) [jboss-logmanager-1.4.1.Final.jar:1.4.1.Final]
> at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:302) [wildfly-logging-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:97) [wildfly-logging-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:235) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:124) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:148) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:97) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:114) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_19]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_19]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_19]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> {noformat}
> This effectively puts the server in a dead state (WFLY-1497 is hiding this issue, because it leaves the handler disabled).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (WFLY-1503) Unable to remove custom logging handler
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-1503?page=com.atlassian.jira.plugin.... ]
James Perkins updated WFLY-1503:
--------------------------------
Fix Version/s: (was: 8.0.0.Alpha4)
> Unable to remove custom logging handler
> ---------------------------------------
>
> Key: WFLY-1503
> URL: https://issues.jboss.org/browse/WFLY-1503
> Project: WildFly
> Issue Type: Bug
> Components: Logging
> Affects Versions: 8.0.0.Alpha1
> Reporter: Carlo de Wolf
> Assignee: James Perkins
> Priority: Blocker
>
> During removal of the custom handler in {{Log4jCustomHandlerTestCase}} the following error is shown:
> {noformat}
> 09:38:24,266 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("remove") failed - address: ([
> ("subsystem" => "logging"),
> ("custom-handler" => "customFileAppender")
> ]): java.lang.IllegalArgumentException: No reference found for 'org.jboss.as.logging.logmanager.Log4jAppenderHandler'
> at org.jboss.logmanager.config.AbstractPropertyConfiguration$5.validate(AbstractPropertyConfiguration.java:399) [jboss-logmanager-1.4.1.Final.jar:1.4.1.Final]
> at org.jboss.logmanager.config.AbstractPropertyConfiguration$5.validate(AbstractPropertyConfiguration.java:391) [jboss-logmanager-1.4.1.Final.jar:1.4.1.Final]
> at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:333) [jboss-logmanager-1.4.1.Final.jar:1.4.1.Final]
> at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:292) [jboss-logmanager-1.4.1.Final.jar:1.4.1.Final]
> at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:302) [wildfly-logging-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:97) [wildfly-logging-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:235) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:124) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:148) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:97) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:114) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_19]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_19]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_19]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> {noformat}
> This effectively puts the server in a dead state (WFLY-1497 is hiding this issue, because it leaves the handler disabled).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months