[JBoss JIRA] (WFLY-2692) infinite wait in BasicComponent#waitForComponentStart() causes server hang
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-2692?page=com.atlassian.jira.plugin.... ]
jaikiran pai commented on WFLY-2692:
------------------------------------
I think this is a duplicate of https://issues.jboss.org/browse/WFLY-917
> infinite wait in BasicComponent#waitForComponentStart() causes server hang
> --------------------------------------------------------------------------
>
> Key: WFLY-2692
> URL: https://issues.jboss.org/browse/WFLY-2692
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EE
> Affects Versions: 8.0.0.CR1
> Reporter: Thomas Frühbeck
> Assignee: David Lloyd
> Labels: EE, MSC, hangs
> Attachments: WFLY-2692_infiniteHang_stacktrace.log
>
>
> some error in deployment may cause infinite wait on BasicComponent#waitForComponentStart():
> protected void waitForComponentStart() {
> if (!gate) {
> // Block until successful start
> synchronized (this) {
> while (!gate) {
> // TODO: check for failure condition
> try {
> wait();
>
> The server life cycle management is completely blocked, no normal redeployment/shutdown will work!
> Please provide some remedy (e.g. timed wait and fail?), IMHO this is really _very_ distressing for a production ready system.
>
> Sample stack trace:
> "MSC service thread 1-7" prio=10 tid=0x00007f6c60001800 nid=0x7af0 in Object.wait() [0x00007f6cbd785000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x00000000e20a0a20> (a org.jboss.as.ejb3.component.singleton.SingletonComponent)
> at java.lang.Object.wait(Object.java:503)
> at org.jboss.as.ee.component.BasicComponent.waitForComponentStart(BasicComponent.java:115)
> - locked <0x00000000e20a0a20> (a org.jboss.as.ejb3.component.singleton.SingletonComponent)
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:145)
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:133)
> at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:89)
> at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:123)
> - locked <0x00000000e20bfa10> (a java.lang.Object)
> at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterce
> ptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185)
> at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
--
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
10 years, 4 months
[JBoss JIRA] (WFLY-2692) infinite wait in BasicComponent#waitForComponentStart() causes server hang
by Thomas Frühbeck (JIRA)
[ https://issues.jboss.org/browse/WFLY-2692?page=com.atlassian.jira.plugin.... ]
Thomas Frühbeck updated WFLY-2692:
----------------------------------
Attachment: WFLY-2692_infiniteHang_stacktrace.log
full stack dump of infinitely blocked server
> infinite wait in BasicComponent#waitForComponentStart() causes server hang
> --------------------------------------------------------------------------
>
> Key: WFLY-2692
> URL: https://issues.jboss.org/browse/WFLY-2692
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EE
> Affects Versions: 8.0.0.CR1
> Reporter: Thomas Frühbeck
> Assignee: David Lloyd
> Labels: EE, MSC, hangs
> Attachments: WFLY-2692_infiniteHang_stacktrace.log
>
>
> some error in deployment may cause infinite wait on BasicComponent#waitForComponentStart():
> protected void waitForComponentStart() {
> if (!gate) {
> // Block until successful start
> synchronized (this) {
> while (!gate) {
> // TODO: check for failure condition
> try {
> wait();
>
> The server life cycle management is completely blocked, no normal redeployment/shutdown will work!
> Please provide some remedy (e.g. timed wait and fail?), IMHO this is really _very_ distressing for a production ready system.
>
> Sample stack trace:
> "MSC service thread 1-7" prio=10 tid=0x00007f6c60001800 nid=0x7af0 in Object.wait() [0x00007f6cbd785000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x00000000e20a0a20> (a org.jboss.as.ejb3.component.singleton.SingletonComponent)
> at java.lang.Object.wait(Object.java:503)
> at org.jboss.as.ee.component.BasicComponent.waitForComponentStart(BasicComponent.java:115)
> - locked <0x00000000e20a0a20> (a org.jboss.as.ejb3.component.singleton.SingletonComponent)
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:145)
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:133)
> at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:89)
> at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:123)
> - locked <0x00000000e20bfa10> (a java.lang.Object)
> at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterce
> ptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185)
> at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
--
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
10 years, 4 months
[JBoss JIRA] (WFLY-2692) infinite wait in BasicComponent#waitForComponentStart() causes server hang
by Thomas Frühbeck (JIRA)
Thomas Frühbeck created WFLY-2692:
-------------------------------------
Summary: infinite wait in BasicComponent#waitForComponentStart() causes server hang
Key: WFLY-2692
URL: https://issues.jboss.org/browse/WFLY-2692
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EE
Affects Versions: 8.0.0.CR1
Reporter: Thomas Frühbeck
Assignee: David Lloyd
some error in deployment may cause infinite wait on BasicComponent#waitForComponentStart():
protected void waitForComponentStart() {
if (!gate) {
// Block until successful start
synchronized (this) {
while (!gate) {
// TODO: check for failure condition
try {
wait();
The server life cycle management is completely blocked, no normal redeployment/shutdown will work!
Please provide some remedy (e.g. timed wait and fail?), IMHO this is really _very_ distressing for a production ready system.
Sample stack trace:
"MSC service thread 1-7" prio=10 tid=0x00007f6c60001800 nid=0x7af0 in Object.wait() [0x00007f6cbd785000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000e20a0a20> (a org.jboss.as.ejb3.component.singleton.SingletonComponent)
at java.lang.Object.wait(Object.java:503)
at org.jboss.as.ee.component.BasicComponent.waitForComponentStart(BasicComponent.java:115)
- locked <0x00000000e20a0a20> (a org.jboss.as.ejb3.component.singleton.SingletonComponent)
at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:145)
at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:133)
at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:89)
at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:123)
- locked <0x00000000e20bfa10> (a java.lang.Object)
at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterce
ptor.java:47)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185)
at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
--
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
10 years, 4 months
[JBoss JIRA] (WFLY-2689) @Producer method never called when producing a bean from a static module
by Pedro Igor (JIRA)
[ https://issues.jboss.org/browse/WFLY-2689?page=com.atlassian.jira.plugin.... ]
Pedro Igor commented on WFLY-2689:
----------------------------------
FYI, the same code works for EAP 6.1 and 6.2.
> @Producer method never called when producing a bean from a static module
> ------------------------------------------------------------------------
>
> Key: WFLY-2689
> URL: https://issues.jboss.org/browse/WFLY-2689
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 8.0.0.CR1
> Environment: WildFly 8.0.0.CR1
> Reporter: Pedro Igor
> Assignee: Stuart Douglas
>
> I've configured a static module for PicketLink CDI library. This library provides some extensions which are loaded fine, as described by WFLY-1370.
> However, I'm trying to deploy my application which the following producer method:
> {code}
> @Produces
> @PicketLink
> public PartitionManager getPartitionManager() {
> // produce an instance
> }
> {code}
> Where the @PicketLink annotation is a qualifier that allows my deployment to provide its own instance instead.
> In the PicketLink side, we have a injection point as follows:
> @Inject
> @PicketLink
> private Instance<PartitionManager> partitionManagerInstance;
> Where a call to partitionManagerInstance.isUnsatisfied() always returns true, even if my deployment provides a proper producer method.
> The issue here is that the producer method is never called, despite the use of qualifiers or not.
> FYI, I'm able to listen for events fired by PicketLink during the application startup as follows:
> public void observeIdentityConfigurationEvent(@Observes IdentityConfigurationEvent event) {
> // observer
> }
> Where IdentityConfigurationEvent is one of the lifecycle events fired by PicketLink during the startup.
--
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
10 years, 4 months
[JBoss JIRA] (JBMESSAGING-1949) JMS Error - thread is already associated with a transaction - MDB
by vish vars (JIRA)
[ https://issues.jboss.org/browse/JBMESSAGING-1949?page=com.atlassian.jira.... ]
vish vars commented on JBMESSAGING-1949:
----------------------------------------
Any comments would be helpful
> JMS Error - thread is already associated with a transaction - MDB
> -----------------------------------------------------------------
>
> Key: JBMESSAGING-1949
> URL: https://issues.jboss.org/browse/JBMESSAGING-1949
> Project: JBoss Messaging
> Issue Type: Bug
> Environment: jboss-5.1.0 GA
> Reporter: vish vars
> Labels: JMS, MDB, jboss, transactionmanager
>
> Getting the below Exception while the MDB consumes the Message from Queue.
> This ERROR results in the message getting discarded and its critical. Appreciate if there is a patch for this problem or any workaround.
> Complete Stack trace:
> 2013-11-25 00:00:08,011 ERROR [org.jboss.resource.adapter.jms.inflow.JmsServerSession] (WorkManager(2)-74) Unexpected error delivering message delegator->JBossMessage[22697371369499608]:PERSISTENT, deliveryId=256984
> java.lang.NoClassDefFoundError: org/jboss/ejb3/tx/AbstractInterceptor
> at org.jboss.ejb3.tx.TxUtil.getApplicationException(TxUtil.java:71)
> at org.jboss.ejb3.tx.Ejb3TxPolicy.handleInCallerTx(Ejb3TxPolicy.java:92)
> at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:130)
> at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:194)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:80)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.ejb3.mdb.MessagingContainer.localInvoke(MessagingContainer.java:282)
> at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.delivery(MessageInflowLocalProxy.java:270)
> at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.invoke(MessageInflowLocalProxy.java:140)
> at $Proxy320.onMessage(Unknown Source)
> at org.jboss.resource.adapter.jms.inflow.JmsServerSession.onMessage(JmsServerSession.java:178)
> at org.jboss.jms.client.container.ClientConsumer.callOnMessageStatic(ClientConsumer.java:160)
> at org.jboss.jms.client.container.SessionAspect.handleRun(SessionAspect.java:831)
> at org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect_z_handleRun_836584.invoke(SessionAspect_z_handleRun_836584.java)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
> at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.jms.client.delegate.ClientSessionDelegate.run(ClientSessionDelegate.java)
> at org.jboss.jms.client.JBossSession.run(JBossSession.java:199)
> at org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:234)
> at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:205)
> at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:260)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> 2013-11-25 00:00:10,530 WARN [org.jboss.system.server.profileservice.hotdeploy.HDScanner] (HDScanner) Scan failed
> java.io.IOException: Error listing files: /home/JBOSS/jboss-5.1.0.GA/server/default/deploy/management/console-mgr.sar/META-INF
> at org.jboss.virtual.plugins.context.file.FileHandler.getChildren(FileHandler.java:225)
> at org.jboss.virtual.plugins.context.AbstractVFSContext.getChildren(AbstractVFSContext.java:219)
> at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:336)
> at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:306)
> at org.jboss.virtual.VFS.visit(VFS.java:421)
> at org.jboss.virtual.VirtualFile.visit(VirtualFile.java:437)
> at org.jboss.virtual.VirtualFile.getChildren(VirtualFile.java:386)
> at org.jboss.deployers.vfs.spi.structure.modified.MetaDataStructureModificationChecker.hasStructureBeenModifed(MetaDataStructureModificationChecker.java:144)
> at org.jboss.deployers.vfs.spi.structure.modified.MetaDataStructureModificationChecker.hasStructureBeenModified(MetaDataStructureModificationChecker.java:115)
> at org.jboss.deployers.vfs.spi.structure.modified.MetaDataStructureModificationChecker.hasStructureBeenModifed(MetaDataStructureModificationChecker.java:84)
> at org.jboss.deployers.vfs.spi.structure.modified.SynchWrapperModificationChecker.hasStructureBeenModifed(SynchWrapperModificationChecker.java:83)
> at org.jboss.deployers.vfs.spi.structure.modified.SynchWrapperModificationChecker.hasStructureBeenModifed(SynchWrapperModificationChecker.java:83)
> at org.jboss.deployers.vfs.spi.structure.modified.AbstractStructureModificationChecker.hasStructureBeenModified(AbstractStructureModificationChecker.java:195)
> at org.jboss.deployers.vfs.spi.structure.modified.AbstractStructureModificationChecker.hasStructureBeenModified(AbstractStructureModificationChecker.java:138)
> at org.jboss.system.server.profileservice.repository.HotDeploymentRepository.getModifiedDeployments(HotDeploymentRepository.java:120)
> at org.jboss.system.server.profile.repository.AbstractProfile.getModifiedDeployments(AbstractProfile.java:128)
> at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:336)
> at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:255)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> 2013-11-25 00:00:14,620 ERROR [org.jboss.resource.adapter.jms.inflow.JmsServerSession] (WorkManager(2)-95) org.jboss.resource.adapter.jms.inflow.JmsServerSession$DemarcationStrategyFactory@54ae94 error creating transaction demarcation
> javax.transaction.NotSupportedException: BaseTransaction.checkTransactionState - [com.arjuna.ats.internal.jta.transaction.arjunacore.alreadyassociated] [com.arjuna.ats.internal.jta.transaction.arjunacore.alreadyassociated] thread is already associated with a transaction!
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.begin(BaseTransaction.java:80)
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.begin(BaseTransactionManagerDelegate.java:65)
> at org.jboss.resource.adapter.jms.inflow.JmsServerSession$XATransactionDemarcationStrategy.<init>(JmsServerSession.java:560)
> at org.jboss.resource.adapter.jms.inflow.JmsServerSession$DemarcationStrategyFactory.getStrategy(JmsServerSession.java:295)
> at org.jboss.resource.adapter.jms.inflow.JmsServerSession.createTransactionDemarcation(JmsServerSession.java:252)
> at org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:224)
> at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:205)
> at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:260)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
--
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
10 years, 4 months
[JBoss JIRA] (WFLY-2691) Wildfly don't uses error pages
by Otávio Garcia (JIRA)
Otávio Garcia created WFLY-2691:
-----------------------------------
Summary: Wildfly don't uses error pages
Key: WFLY-2691
URL: https://issues.jboss.org/browse/WFLY-2691
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Otávio Garcia
My web.xml contains declaration for error pages.
But if an 500 error occurs, Wildfly print your own error page. It should use my error pages, since it's declared in web.xml.
<error-page>
<error-code>500</error-code>
<location>/error.jsp</location>
</error-page>
--
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
10 years, 4 months
[JBoss JIRA] (WFLY-768) Caused by: javax.sound.sampled.UnsupportedAudioFileException: could not get audio input stream from input stream
by Andrew Kroh (JIRA)
[ https://issues.jboss.org/browse/WFLY-768?page=com.atlassian.jira.plugin.s... ]
Andrew Kroh commented on WFLY-768:
----------------------------------
I was able to resolve a similar issue by adding the following path to the module.xml file and adding the SPI files as listed above. Note that I'm using {{com/sun/media/sound}} and not {{com/sun/media}}.
{code:xml|title=modules/system/layers/base/sun/jdk/main/module.xml}
<path name="com/sun/media/sound"/>
{code}
> Caused by: javax.sound.sampled.UnsupportedAudioFileException: could not get audio input stream from input stream
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-768
> URL: https://issues.jboss.org/browse/WFLY-768
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Server
> Environment: windows 7 jdk1.6,eclipse juno,
> Reporter: raky k
> Assignee: Jason Greene
> Labels: UnsupportedAudioFileException
> Fix For: 8.0.0.Final
>
>
> The application is working fine in the tomcat when deployed in the Jboss server it does not recognizes wav format and throws error Caused by: javax.sound.sampled.UnsupportedAudioFileException: could not get audio input stream from input stream
> The application is open source and can be found
> http://sourceforge.net/projects/simplecaptcha/files/simplecaptcha-1.2-j2e...
> i have done below changes but still no luck. ( as advised on https://community.jboss.org/thread/197517 )
> "
> Darran is right, it requires to edit the modules/sun/jdk/main/modules.xml and add an entry for com.sun.media.
>
> Moreover, copy the following files to modules/sun/jdk/main/service-loader-resources/META-INF/services/
> javax.sound.sampled.spi.AudioFileReader
> javax.sound.sampled.spi.AudioFileWriter
> javax.sound.sampled.spi.FormatConversionProvider
> javax.sound.sampled.spi.MixerProvider
> These files can be found inside /jre/lib/resources.jar of JDK, under /META-INF/services/ "
--
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
10 years, 4 months
[JBoss JIRA] (WFLY-2690) JSP/JSPX tags doesn't work with Wildfly CR1
by Otávio Garcia (JIRA)
Otávio Garcia created WFLY-2690:
-----------------------------------
Summary: JSP/JSPX tags doesn't work with Wildfly CR1
Key: WFLY-2690
URL: https://issues.jboss.org/browse/WFLY-2690
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Undertow)
Affects Versions: 8.0.0.CR1
Environment: OpenJDK Runtime Environment (fedora-2.4.3.0.fc18-x86_64 u45-b15)
OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)
Reporter: Otávio Garcia
Assignee: Stuart Douglas
My app works fine on JBoss AS 7.1. When I migrate to Wildfly 8.0.0 CR1, my JSP tags don't work as expected. My project is a EAR with WAR module.
When app starts, in the 1st access to page A, tag file is compiled and the page are rendered fine. But when I access another page (B in example), I got this error: org.apache.jasper.JasperException: java.lang.ClassCastException: org.apache.jsp.tag.web.default_tagx cannot be cast to org.apache.jsp.tag.web.default_tagx
If I restart Wildfly and try to access page B, works fine. But when I access page A, I got the same error.
My default.tagx is bellow:
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml" version="2.2">
<jsp:output doctype-root-element="HTML" doctype-system="about:legacy-compat" omit-xml-declaration="yes" />
some code
<jsp:doBody />
more code
</jsp:root>
And the pages are somethink like this:
<tags:default xmlns:tags="urn:jsptagdir:/WEB-INF/tags" xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml">
<jsp:output omit-xml-declaration="yes" />
my code here
</tags:default>
I was created a new empty project with two pages and one tagfile. The error don't occurs. But when I add CDI capabilities, the error occurs. There are something in CDI that confuses Jastow?
As discussed here: https://community.jboss.org/message/850730
--
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
10 years, 4 months
[JBoss JIRA] (WFLY-2689) @Producer method never called when producing a bean from a static module
by Pedro Igor (JIRA)
[ https://issues.jboss.org/browse/WFLY-2689?page=com.atlassian.jira.plugin.... ]
Pedro Igor updated WFLY-2689:
-----------------------------
Steps to Reproduce:
1) Please clone this branch:
https://github.com/pedroigor/picketlink-as-subsystem/tree/WFLY_8.PLINK-348
2) Run mvn -Pintegration-tests clean install
3) Start WildFly from the following location target/integration-tests/containers/wildfly-8.0.0.CR1/
4) Run the following Arquillian test: test.org.picketlink.as.subsystem.core.integration.AuthenticationWithSubsystemPartitionManagerTestCase
The test.org.picketlink.as.subsystem.core.integration.MyPartitionManagerProducer producer method is never called.
was:
I'm using a simple Arquillian test deploying an archive like this:
{code}
ShrinkWrap
.create(WebArchive.class, "test.war")
.addAsWebInfResource(EmptyAsset.INSTANCE, "beans.xml")
.addAsManifestResource(new StringAsset("Dependencies: org.picketlink.core meta-inf,org.picketlink.core.api meta-inf,org.picketlink.idm.api meta-inf\n"), "MANIFEST.MF")
.addClass(AuthenticationWithEmbeddedPartitionManagerTestCase.class);
{code}
> @Producer method never called when producing a bean from a static module
> ------------------------------------------------------------------------
>
> Key: WFLY-2689
> URL: https://issues.jboss.org/browse/WFLY-2689
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 8.0.0.CR1
> Environment: WildFly 8.0.0.CR1
> Reporter: Pedro Igor
> Assignee: Stuart Douglas
>
> I've configured a static module for PicketLink CDI library. This library provides some extensions which are loaded fine, as described by WFLY-1370.
> However, I'm trying to deploy my application which the following producer method:
> {code}
> @Produces
> @PicketLink
> public PartitionManager getPartitionManager() {
> // produce an instance
> }
> {code}
> Where the @PicketLink annotation is a qualifier that allows my deployment to provide its own instance instead.
> In the PicketLink side, we have a injection point as follows:
> @Inject
> @PicketLink
> private Instance<PartitionManager> partitionManagerInstance;
> Where a call to partitionManagerInstance.isUnsatisfied() always returns true, even if my deployment provides a proper producer method.
> The issue here is that the producer method is never called, despite the use of qualifiers or not.
> FYI, I'm able to listen for events fired by PicketLink during the application startup as follows:
> public void observeIdentityConfigurationEvent(@Observes IdentityConfigurationEvent event) {
> // observer
> }
> Where IdentityConfigurationEvent is one of the lifecycle events fired by PicketLink during the startup.
--
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
10 years, 4 months
[JBoss JIRA] (WFLY-2689) @Producer method never called when producing a bean from a static module
by Pedro Igor (JIRA)
Pedro Igor created WFLY-2689:
--------------------------------
Summary: @Producer method never called when producing a bean from a static module
Key: WFLY-2689
URL: https://issues.jboss.org/browse/WFLY-2689
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: CDI / Weld
Affects Versions: 8.0.0.CR1
Environment: WildFly 8.0.0.CR1
Reporter: Pedro Igor
Assignee: Stuart Douglas
I've configured a static module for PicketLink CDI library. This library provides some extensions which are loaded fine, as described by WFLY-1370.
However, I'm trying to deploy my application which the following producer method:
{code}
@Produces
@PicketLink
public PartitionManager getPartitionManager() {
// produce an instance
}
{code}
Where the @PicketLink annotation is a qualifier that allows my deployment to provide its own instance instead.
In the PicketLink side, we have a injection point as follows:
@Inject
@PicketLink
private Instance<PartitionManager> partitionManagerInstance;
Where a call to partitionManagerInstance.isUnsatisfied() always returns true, even if my deployment provides a proper producer method.
The issue here is that the producer method is never called, despite the use of qualifiers or not.
FYI, I'm able to listen for events fired by PicketLink during the application startup as follows:
public void observeIdentityConfigurationEvent(@Observes IdentityConfigurationEvent event) {
// observer
}
Where IdentityConfigurationEvent is one of the lifecycle events fired by PicketLink during the startup.
--
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
10 years, 4 months