[JBoss JIRA] (JBASPECT-39) java.lang.IllegalStateException: Wrong tx on thread: expected TransactionImple thrown when timer expires in a JTS transaction that has timed out
by Tom Ross (JIRA)
[ https://issues.jboss.org/browse/JBASPECT-39?page=com.atlassian.jira.plugi... ]
Tom Ross reassigned JBASPECT-39:
--------------------------------
Assignee: Tom Ross (was: Andrew Rubinger)
> java.lang.IllegalStateException: Wrong tx on thread: expected TransactionImple thrown when timer expires in a JTS transaction that has timed out
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBASPECT-39
> URL: https://issues.jboss.org/browse/JBASPECT-39
> Project: JBoss Aspects
> Issue Type: Bug
> Environment: JBoss EAP 5.1.2
> Reporter: Tom Ross
> Assignee: Tom Ross
> Attachments: JBASPECT-39_TEST_CASE.ear
>
>
> When a timer runs longer than a transaction timeout it throws an exception:
> {noformat}
> 2013-01-25 15:06:34,613 ERROR [org.jboss.ejb.txtimer.TimerImpl] (EJB-Timer-144eac73-8911-4bf7-ab78-7ac081374794[target=jboss.j2ee:ear=XX_TEST_CASE.ear,jar=XX_TEST_CASE_EJB.jar,name=TXTimerBean,service=EJB3]) Error invoking ejbTimeout
> java.lang.IllegalStateException: Wrong tx on thread: expected TransactionImple < jts, -3f57fe9c:d04e:51029e16:fc >, actual TransactionImple < jts, -3f57fe9c:d04e:51029e16:fc >
> at org.jboss.aspects.tx.TxPolicy.endTransaction(TxPolicy.java:157)
> at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:87)
> at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:190)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
> 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.ejb3.core.context.CurrentInvocationContextInterceptor.invoke(CurrentInvocationContextInterceptor.java:47)
> 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.interceptor.EJB3TCCLInterceptor.invoke(EJB3TCCLInterceptor.java:86)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.ejb3.stateless.StatelessContainer.callTimeout(StatelessContainer.java:686)
> at org.jboss.ejb3.stateless.StatelessContainer.callTimeout(StatelessContainer.java:202)
> at org.jboss.as.ejb3.timerservice.TimedObjectInvokerBridge.callTimeout(TimedObjectInvokerBridge.java:44)
> at org.jboss.ejb.txtimer.TimerImpl$TimerTaskImpl.run(TimerImpl.java:664)
> at java.util.TimerThread.mainLoop(Timer.java:512)
> at java.util.TimerThread.run(Timer.java:462)
> {noformat}
--
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, 3 months
[JBoss JIRA] (DROOLS-422) Timer based rules don't fire and facts can't expire after session restore
by Nedo Nedic (JIRA)
[ https://issues.jboss.org/browse/DROOLS-422?page=com.atlassian.jira.plugin... ]
Nedo Nedic updated DROOLS-422:
------------------------------
Description:
I have implemented a custom persistence engine for Drools sessions in MongoDB. When session is built for first time, everything works like a charm. I am having some problems when Drools sessions are restored from MongoDB collection. Firstly, interval based rules (for example timer(int: 10s 10s)) don't fire. Some facts that should expire, they just don't expire and remain forever in WM. I attached the source code. When session is built for first time, I use code like this:
KnowledgeBase kbase = createKBase(getKnowledgeBuilder(rulePackagePath),
config);
if (hasKnowledgeAgent) {
createKnowledgeAgent(kbase, correlatorId);
wm = (ReteooStatefulSession) ((KnowledgeBaseImpl) kagent
.getKnowledgeBase()).ruleBase.newStatefulSession(
(SessionConfiguration) ksconf, env);
ksession = new StatefulKnowledgeSessionImpl(wm, kagent
.getKnowledgeBase());
stateOutputMarshaller = StateMarshallerFactory.newOutputMarshaller(this, ksession, ksconf);
stateOutputMarshaller.init();
((InternalKnowledgeRuntime) ksession).setEndOperationListener(this);
}
Then, after every action I update the session in MongoDB collection.
public void endOperation(InternalKnowledgeRuntime ikr) {
stateOutputMarshaller.marshall();
}
For session restoring, after AS restart I use this code:
KnowledgeBase kbase = createKBase( getKnowledgeBuilder(rulePackagePath), getKBaseConfig() );
stateInputMarshaller = StateMarshallerFactory.newInputMarshaller( this, kbase, getSessionConf() );
ksession = stateInputMarshaller.unmarshall(correlatorId);
stateOutputMarshaller = StateMarshallerFactory.newOutputMarshaller( this, ksession, getSessionConf() );
((InternalKnowledgeRuntime)ksession).setEndOperationListener(this);
protected static KnowledgeBaseConfiguration getKBaseConfig() {
KnowledgeBaseConfiguration config = KnowledgeBaseFactory
.newKnowledgeBaseConfiguration();
config.setOption(EventProcessingOption.STREAM);
return config;
}
protected static KnowledgeSessionConfiguration getSessionConf() {
KnowledgeSessionConfiguration ksconf = KnowledgeBaseFactory.newKnowledgeSessionConfiguration();
ksconf.setOption(ClockTypeOption.get("realtime"));
return ksconf;
}
Any help is appreciated.
Thanks
was:
I have implemented a custom persistence engine for Drools sessions in MongoDB. When session is built for first time, everything works like a charm. I am having some problems when Drools sessions is restored from MongoDB collection. Firstly, interval based rules (for example timer(int: 10s 10s)) don't fire. Some facts that should expire, they just don't expire and remain forever in WM. I attached the source code. When session is built for first time, I use code like this:
KnowledgeBase kbase = createKBase(getKnowledgeBuilder(rulePackagePath),
config);
if (hasKnowledgeAgent) {
createKnowledgeAgent(kbase, correlatorId);
wm = (ReteooStatefulSession) ((KnowledgeBaseImpl) kagent
.getKnowledgeBase()).ruleBase.newStatefulSession(
(SessionConfiguration) ksconf, env);
ksession = new StatefulKnowledgeSessionImpl(wm, kagent
.getKnowledgeBase());
stateOutputMarshaller = StateMarshallerFactory.newOutputMarshaller(this, ksession, ksconf);
stateOutputMarshaller.init();
((InternalKnowledgeRuntime) ksession).setEndOperationListener(this);
}
Then, after every action I update the session in MongoDB collection.
public void endOperation(InternalKnowledgeRuntime ikr) {
stateOutputMarshaller.marshall();
}
For session restoring, after AS restart I use this code:
KnowledgeBase kbase = createKBase( getKnowledgeBuilder(rulePackagePath), getKBaseConfig() );
stateInputMarshaller = StateMarshallerFactory.newInputMarshaller( this, kbase, getSessionConf() );
ksession = stateInputMarshaller.unmarshall(correlatorId);
stateOutputMarshaller = StateMarshallerFactory.newOutputMarshaller( this, ksession, getSessionConf() );
((InternalKnowledgeRuntime)ksession).setEndOperationListener(this);
protected static KnowledgeBaseConfiguration getKBaseConfig() {
KnowledgeBaseConfiguration config = KnowledgeBaseFactory
.newKnowledgeBaseConfiguration();
config.setOption(EventProcessingOption.STREAM);
return config;
}
protected static KnowledgeSessionConfiguration getSessionConf() {
KnowledgeSessionConfiguration ksconf = KnowledgeBaseFactory.newKnowledgeSessionConfiguration();
ksconf.setOption(ClockTypeOption.get("realtime"));
return ksconf;
}
Any help is appreciated.
Thanks
> Timer based rules don't fire and facts can't expire after session restore
> -------------------------------------------------------------------------
>
> Key: DROOLS-422
> URL: https://issues.jboss.org/browse/DROOLS-422
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final
> Environment: Linux Mint 15
> JBoss AS 5.1
> Reporter: Nedo Nedic
> Assignee: Mark Proctor
> Attachments: drools-mongodb-persistence.zip
>
>
> I have implemented a custom persistence engine for Drools sessions in MongoDB. When session is built for first time, everything works like a charm. I am having some problems when Drools sessions are restored from MongoDB collection. Firstly, interval based rules (for example timer(int: 10s 10s)) don't fire. Some facts that should expire, they just don't expire and remain forever in WM. I attached the source code. When session is built for first time, I use code like this:
> KnowledgeBase kbase = createKBase(getKnowledgeBuilder(rulePackagePath),
> config);
> if (hasKnowledgeAgent) {
>
> createKnowledgeAgent(kbase, correlatorId);
>
> wm = (ReteooStatefulSession) ((KnowledgeBaseImpl) kagent
> .getKnowledgeBase()).ruleBase.newStatefulSession(
> (SessionConfiguration) ksconf, env);
> ksession = new StatefulKnowledgeSessionImpl(wm, kagent
> .getKnowledgeBase());
>
> stateOutputMarshaller = StateMarshallerFactory.newOutputMarshaller(this, ksession, ksconf);
> stateOutputMarshaller.init();
> ((InternalKnowledgeRuntime) ksession).setEndOperationListener(this);
> }
> Then, after every action I update the session in MongoDB collection.
> public void endOperation(InternalKnowledgeRuntime ikr) {
>
> stateOutputMarshaller.marshall();
> }
> For session restoring, after AS restart I use this code:
> KnowledgeBase kbase = createKBase( getKnowledgeBuilder(rulePackagePath), getKBaseConfig() );
> stateInputMarshaller = StateMarshallerFactory.newInputMarshaller( this, kbase, getSessionConf() );
> ksession = stateInputMarshaller.unmarshall(correlatorId);
> stateOutputMarshaller = StateMarshallerFactory.newOutputMarshaller( this, ksession, getSessionConf() );
>
> ((InternalKnowledgeRuntime)ksession).setEndOperationListener(this);
>
> protected static KnowledgeBaseConfiguration getKBaseConfig() {
> KnowledgeBaseConfiguration config = KnowledgeBaseFactory
> .newKnowledgeBaseConfiguration();
> config.setOption(EventProcessingOption.STREAM);
> return config;
> }
> protected static KnowledgeSessionConfiguration getSessionConf() {
> KnowledgeSessionConfiguration ksconf = KnowledgeBaseFactory.newKnowledgeSessionConfiguration();
> ksconf.setOption(ClockTypeOption.get("realtime"));
> return ksconf;
> }
> Any help is appreciated.
> Thanks
--
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, 3 months
[JBoss JIRA] (DROOLS-422) Timer based rules don't fire and facts can't expire after session restore
by Nedo Nedic (JIRA)
[ https://issues.jboss.org/browse/DROOLS-422?page=com.atlassian.jira.plugin... ]
Nedo Nedic updated DROOLS-422:
------------------------------
Attachment: drools-mongodb-persistence.zip
> Timer based rules don't fire and facts can't expire after session restore
> -------------------------------------------------------------------------
>
> Key: DROOLS-422
> URL: https://issues.jboss.org/browse/DROOLS-422
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final
> Environment: Linux Mint 15
> JBoss AS 5.1
> Reporter: Nedo Nedic
> Assignee: Mark Proctor
> Attachments: drools-mongodb-persistence.zip
>
>
> I have implemented a custom persistence engine for Drools sessions in MongoDB. When session is built for first time, everything works like a charm. I am having some problems when Drools sessions is restored from MongoDB collection. Firstly, interval based rules (for example timer(int: 10s 10s)) don't fire. Some facts that should expire, they just don't expire and remain forever in WM. I attached the source code. When session is built for first time, I use code like this:
> KnowledgeBase kbase = createKBase(getKnowledgeBuilder(rulePackagePath),
> config);
> if (hasKnowledgeAgent) {
>
> createKnowledgeAgent(kbase, correlatorId);
>
> wm = (ReteooStatefulSession) ((KnowledgeBaseImpl) kagent
> .getKnowledgeBase()).ruleBase.newStatefulSession(
> (SessionConfiguration) ksconf, env);
> ksession = new StatefulKnowledgeSessionImpl(wm, kagent
> .getKnowledgeBase());
>
> stateOutputMarshaller = StateMarshallerFactory.newOutputMarshaller(this, ksession, ksconf);
> stateOutputMarshaller.init();
> ((InternalKnowledgeRuntime) ksession).setEndOperationListener(this);
> }
> Then, after every action I update the session in MongoDB collection.
> public void endOperation(InternalKnowledgeRuntime ikr) {
>
> stateOutputMarshaller.marshall();
> }
> For session restoring, after AS restart I use this code:
> KnowledgeBase kbase = createKBase( getKnowledgeBuilder(rulePackagePath), getKBaseConfig() );
> stateInputMarshaller = StateMarshallerFactory.newInputMarshaller( this, kbase, getSessionConf() );
> ksession = stateInputMarshaller.unmarshall(correlatorId);
> stateOutputMarshaller = StateMarshallerFactory.newOutputMarshaller( this, ksession, getSessionConf() );
>
> ((InternalKnowledgeRuntime)ksession).setEndOperationListener(this);
>
> protected static KnowledgeBaseConfiguration getKBaseConfig() {
> KnowledgeBaseConfiguration config = KnowledgeBaseFactory
> .newKnowledgeBaseConfiguration();
> config.setOption(EventProcessingOption.STREAM);
> return config;
> }
> protected static KnowledgeSessionConfiguration getSessionConf() {
> KnowledgeSessionConfiguration ksconf = KnowledgeBaseFactory.newKnowledgeSessionConfiguration();
> ksconf.setOption(ClockTypeOption.get("realtime"));
> return ksconf;
> }
> Any help is appreciated.
> Thanks
--
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, 3 months
[JBoss JIRA] (DROOLS-422) Timer based rules don't fire and facts can't expire after session restore
by Nedo Nedic (JIRA)
Nedo Nedic created DROOLS-422:
---------------------------------
Summary: Timer based rules don't fire and facts can't expire after session restore
Key: DROOLS-422
URL: https://issues.jboss.org/browse/DROOLS-422
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 5.5.0.Final
Environment: Linux Mint 15
JBoss AS 5.1
Reporter: Nedo Nedic
Assignee: Mark Proctor
I have implemented a custom persistence engine for Drools sessions in MongoDB. When session is built for first time, everything works like a charm. I am having some problems when Drools sessions is restored from MongoDB collection. Firstly, interval based rules (for example timer(int: 10s 10s)) don't fire. Some facts that should expire, they just don't expire and remain forever in WM. I attached the source code. When session is built for first time, I use code like this:
KnowledgeBase kbase = createKBase(getKnowledgeBuilder(rulePackagePath),
config);
if (hasKnowledgeAgent) {
createKnowledgeAgent(kbase, correlatorId);
wm = (ReteooStatefulSession) ((KnowledgeBaseImpl) kagent
.getKnowledgeBase()).ruleBase.newStatefulSession(
(SessionConfiguration) ksconf, env);
ksession = new StatefulKnowledgeSessionImpl(wm, kagent
.getKnowledgeBase());
stateOutputMarshaller = StateMarshallerFactory.newOutputMarshaller(this, ksession, ksconf);
stateOutputMarshaller.init();
((InternalKnowledgeRuntime) ksession).setEndOperationListener(this);
}
Then, after every action I update the session in MongoDB collection.
public void endOperation(InternalKnowledgeRuntime ikr) {
stateOutputMarshaller.marshall();
}
For session restoring, after AS restart I use this code:
KnowledgeBase kbase = createKBase( getKnowledgeBuilder(rulePackagePath), getKBaseConfig() );
stateInputMarshaller = StateMarshallerFactory.newInputMarshaller( this, kbase, getSessionConf() );
ksession = stateInputMarshaller.unmarshall(correlatorId);
stateOutputMarshaller = StateMarshallerFactory.newOutputMarshaller( this, ksession, getSessionConf() );
((InternalKnowledgeRuntime)ksession).setEndOperationListener(this);
protected static KnowledgeBaseConfiguration getKBaseConfig() {
KnowledgeBaseConfiguration config = KnowledgeBaseFactory
.newKnowledgeBaseConfiguration();
config.setOption(EventProcessingOption.STREAM);
return config;
}
protected static KnowledgeSessionConfiguration getSessionConf() {
KnowledgeSessionConfiguration ksconf = KnowledgeBaseFactory.newKnowledgeSessionConfiguration();
ksconf.setOption(ClockTypeOption.get("realtime"));
return ksconf;
}
Any help is appreciated.
Thanks
--
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, 3 months
[JBoss JIRA] (WFLY-2861) Weld prevents integration of fabric webapp
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2861?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-2861:
--------------------------------------
For now you can work around this by using jboss-deployment-structure.xml to exclude the weld subsystem, or add a beans.xml with the bean discovery mode set to none:
{code}
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
bean-discovery-mode="none">
</beans>
{code}
> Weld prevents integration of fabric webapp
> ------------------------------------------
>
> Key: WFLY-2861
> URL: https://issues.jboss.org/browse/WFLY-2861
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 8.0.0.CR1
> Reporter: Thomas Diesler
> Assignee: Stuart Douglas
> Priority: Blocker
> Fix For: 8.0.0.Final
>
>
> {code}
> 09:30:11,682 INFO [org.jboss.weld.deployer] (MSC service thread 1-8) JBAS016008: Starting weld service for deployment fabric.war
> 09:30:12,898 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.deployment.unit."fabric.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."fabric.war".WeldStartService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type Set<Service> with qualifiers @Default
> at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject com.google.common.util.concurrent.ServiceManager(Set<Service>)
> at com.google.common.util.concurrent.ServiceManager.<init>(ServiceManager.java:0)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:368)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:289)
> at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:135)
> at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:166)
> at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:514)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
> ... 3 more
> 09:30:12,908 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "fabric.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"fabric.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"fabric.war\".WeldStartService: Failed to start service
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type Set<Service> with qualifiers @Default
> at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject com.google.common.util.concurrent.ServiceManager(Set<Service>)
> at com.google.common.util.concurrent.ServiceManager.<init>(ServiceManager.java:0)
> "}}
> 09:30:12,952 INFO [org.jboss.as.server] (ServerService Thread Pool -- 31) JBAS018559: Deployed "fabric.war" (runtime-name : "fabric.war")
> 09:30:12,954 INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014777: Services which failed to start: service jboss.deployment.unit."fabric.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."fabric.war".WeldStartService: Failed to start service
> 09:30:12,962 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
> 09:30:12,962 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
> 09:30:12,963 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: WildFly 8.0.0.Final-SNAPSHOT "WildFly" started (with errors) in 7908ms - Started 293 of 358 services (25 services failed or missing dependencies, 75 services are lazy, passive or on-demand)
> {code}
> http://174.129.32.31:8080/job/tdi-portable-runtime-wfsnap/
--
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, 3 months
[JBoss JIRA] (AS7-5849) Web application with bundled JSF and CDI activated fails to deploy
by jose jose (JIRA)
[ https://issues.jboss.org/browse/AS7-5849?page=com.atlassian.jira.plugin.s... ]
jose jose commented on AS7-5849:
--------------------------------
With Jboss eap6.2.0 final didn't work , the stacktrace are the same
> Web application with bundled JSF and CDI activated fails to deploy
> -------------------------------------------------------------------
>
> Key: AS7-5849
> URL: https://issues.jboss.org/browse/AS7-5849
> Project: Application Server 7
> Issue Type: Bug
> Components: Class Loading, JSF
> Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final)
> Reporter: Nicklas Karlsson
> Assignee: Stuart Douglas
> Attachments: hellomyfaces.war
>
>
> Starting with Stan Silverts sample in the thread https://community.jboss.org/thread/171282?start=0&tstart=0, I've added a beans.xmls and followed the suggestions in AS7-3940 and added the jboss-deployment-structure.xml but deployment still results in
> {code}
> 10:29:28,851 SEVERE [org.apache.myfaces.webapp.AbstractFacesInitializer] (MSC service thread 1-4) An error occured while initializing MyFaces: Class org.jboss.as.weld.webtier.jsf.WeldApplicationFactory is no javax.faces.application.ApplicationFactory: java.lang.IllegalArgumentException: Class org.jboss.as.weld.webtier.jsf.WeldApplicationFactory is no javax.faces.application.ApplicationFactory
> at javax.faces.FactoryFinder.newFactoryInstance(FactoryFinder.java:311) [myfaces-api-2.1.1.jar:2.1.1]
> at javax.faces.FactoryFinder._getFactory(FactoryFinder.java:277) [myfaces-api-2.1.1.jar:2.1.1]
> at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:200) [myfaces-api-2.1.1.jar:2.1.1]
> at org.apache.myfaces.config.FacesConfigurator.configureApplication(FacesConfigurator.java:489) [myfaces-impl-2.1.1.jar:2.1.1]
> at org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:401) [myfaces-impl-2.1.1.jar:2.1.1]
> at org.apache.myfaces.webapp.AbstractFacesInitializer.buildConfiguration(AbstractFacesInitializer.java:309) [myfaces-impl-2.1.1.jar:2.1.1]
> at org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:73) [myfaces-impl-2.1.1.jar:2.1.1]
> at org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:125) [myfaces-impl-2.1.1.jar:2.1.1]
> at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:111) [myfaces-impl-2.1.1.jar:2.1.1]
> at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3331) [jbossweb-7.2.0.Alpha2.jar:7.2.0.Alpha2]
> at org.apache.catalina.core.StandardContext.start(StandardContext.java:3769) [jbossweb-7.2.0.Alpha2.jar:7.2.0.Alpha2]
> at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:102) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_07]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_07]
> {code}
> on a fresh upstream origin
--
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, 3 months
[JBoss JIRA] (JGRP-1786) DefaultTimeScheduler: unit test fails
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1786?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1786:
--------------------------------
Only fixed on the 3.2 branch as I've never seen this on master. Richard, if you disagree, please re-open
> DefaultTimeScheduler: unit test fails
> -------------------------------------
>
> Key: JGRP-1786
> URL: https://issues.jboss.org/browse/JGRP-1786
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL 5 x86_64
> Windows x86_64
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13
>
>
> The test case starts off by scheduling a timer task using the DefaultTimeScheduler and then sleeping, waiting for the task to execute
> Instead of the task being executed, the call to sleep is interrupted and the test case fails with an interrupted exception. Catching this interrupted exception shows that the task has not had a chance to execute before the sleep was interrupted.
> The same test case passes with the other two TimeScheduler implementations: TimeScheduler2 and HashedTimingWheel.
>
--
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, 3 months
[JBoss JIRA] (JGRP-1786) DefaultTimeScheduler: unit test fails
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1786?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1786.
----------------------------
Fix Version/s: 3.2.13
(was: 3.5)
Resolution: Done
I added sleepUninterrupted() to TimeSchedulerTest, and replaced {{Thread.sleep()}} with {{sleepUninterrupted()}}.
This fixes the test suite failure, but I still don't know why the thread got interrupted and who interrupted it...
> DefaultTimeScheduler: unit test fails
> -------------------------------------
>
> Key: JGRP-1786
> URL: https://issues.jboss.org/browse/JGRP-1786
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL 5 x86_64
> Windows x86_64
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13
>
>
> The test case starts off by scheduling a timer task using the DefaultTimeScheduler and then sleeping, waiting for the task to execute
> Instead of the task being executed, the call to sleep is interrupted and the test case fails with an interrupted exception. Catching this interrupted exception shows that the task has not had a chance to execute before the sleep was interrupted.
> The same test case passes with the other two TimeScheduler implementations: TimeScheduler2 and HashedTimingWheel.
>
--
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, 3 months
[JBoss JIRA] (WFLY-2861) Weld prevents integration of fabric webapp
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-2861?page=com.atlassian.jira.plugin.... ]
Thomas Diesler updated WFLY-2861:
---------------------------------
Priority: Blocker (was: Major)
Raised to Blocker because it makes the current code base unusable for Fabric
> Weld prevents integration of fabric webapp
> ------------------------------------------
>
> Key: WFLY-2861
> URL: https://issues.jboss.org/browse/WFLY-2861
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 8.0.0.CR1
> Reporter: Thomas Diesler
> Assignee: Stuart Douglas
> Priority: Blocker
> Fix For: 8.0.0.Final
>
>
> {code}
> 09:30:11,682 INFO [org.jboss.weld.deployer] (MSC service thread 1-8) JBAS016008: Starting weld service for deployment fabric.war
> 09:30:12,898 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.deployment.unit."fabric.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."fabric.war".WeldStartService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type Set<Service> with qualifiers @Default
> at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject com.google.common.util.concurrent.ServiceManager(Set<Service>)
> at com.google.common.util.concurrent.ServiceManager.<init>(ServiceManager.java:0)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:368)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:289)
> at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:135)
> at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:166)
> at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:514)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
> ... 3 more
> 09:30:12,908 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "fabric.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"fabric.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"fabric.war\".WeldStartService: Failed to start service
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type Set<Service> with qualifiers @Default
> at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject com.google.common.util.concurrent.ServiceManager(Set<Service>)
> at com.google.common.util.concurrent.ServiceManager.<init>(ServiceManager.java:0)
> "}}
> 09:30:12,952 INFO [org.jboss.as.server] (ServerService Thread Pool -- 31) JBAS018559: Deployed "fabric.war" (runtime-name : "fabric.war")
> 09:30:12,954 INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014777: Services which failed to start: service jboss.deployment.unit."fabric.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."fabric.war".WeldStartService: Failed to start service
> 09:30:12,962 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
> 09:30:12,962 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
> 09:30:12,963 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: WildFly 8.0.0.Final-SNAPSHOT "WildFly" started (with errors) in 7908ms - Started 293 of 358 services (25 services failed or missing dependencies, 75 services are lazy, passive or on-demand)
> {code}
> http://174.129.32.31:8080/job/tdi-portable-runtime-wfsnap/
--
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, 3 months
[JBoss JIRA] (WFLY-2861) Weld prevents integration of fabric webapp
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-2861?page=com.atlassian.jira.plugin.... ]
Thomas Diesler edited comment on WFLY-2861 at 2/4/14 3:51 AM:
--------------------------------------------------------------
Raised to Blocker because it makes the current WildFly code base unusable for Fabric
was (Author: thomas.diesler):
Raised to Blocker because it makes the current code base unusable for Fabric
> Weld prevents integration of fabric webapp
> ------------------------------------------
>
> Key: WFLY-2861
> URL: https://issues.jboss.org/browse/WFLY-2861
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 8.0.0.CR1
> Reporter: Thomas Diesler
> Assignee: Stuart Douglas
> Priority: Blocker
> Fix For: 8.0.0.Final
>
>
> {code}
> 09:30:11,682 INFO [org.jboss.weld.deployer] (MSC service thread 1-8) JBAS016008: Starting weld service for deployment fabric.war
> 09:30:12,898 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.deployment.unit."fabric.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."fabric.war".WeldStartService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type Set<Service> with qualifiers @Default
> at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject com.google.common.util.concurrent.ServiceManager(Set<Service>)
> at com.google.common.util.concurrent.ServiceManager.<init>(ServiceManager.java:0)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:368)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:289)
> at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:135)
> at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:166)
> at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:514)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
> ... 3 more
> 09:30:12,908 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "fabric.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"fabric.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"fabric.war\".WeldStartService: Failed to start service
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type Set<Service> with qualifiers @Default
> at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject com.google.common.util.concurrent.ServiceManager(Set<Service>)
> at com.google.common.util.concurrent.ServiceManager.<init>(ServiceManager.java:0)
> "}}
> 09:30:12,952 INFO [org.jboss.as.server] (ServerService Thread Pool -- 31) JBAS018559: Deployed "fabric.war" (runtime-name : "fabric.war")
> 09:30:12,954 INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014777: Services which failed to start: service jboss.deployment.unit."fabric.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."fabric.war".WeldStartService: Failed to start service
> 09:30:12,962 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
> 09:30:12,962 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
> 09:30:12,963 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: WildFly 8.0.0.Final-SNAPSHOT "WildFly" started (with errors) in 7908ms - Started 293 of 358 services (25 services failed or missing dependencies, 75 services are lazy, passive or on-demand)
> {code}
> http://174.129.32.31:8080/job/tdi-portable-runtime-wfsnap/
--
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, 3 months