June 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-5068) CLONE - init.d startscript should not rely on the text of the start message 'JBoss .... started'

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created AS7-5068: ------------------------------------- Summary: CLONE - init.d startscript should not rely on the text of the start message 'JBoss .... started' Key: AS7-5068 URL: https://issues.jboss.org/browse/AS7-5068 Project: Application Server 7 Issue Type: Enhancement Affects Versions: 7.1.2.Final (EAP) Reporter: Wolf-Dieter Fink Assignee: Wolf-Dieter Fink Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1 The init.d/jboss-as-standalone.sh script will check the text of the message. This will be error prone in case of internationalisation. It is possible to use the unique "JBAS015874:" id. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
0
0 / 0

[JBoss JIRA] (AS7-5067) CLONE - CLI deploy with --name fails to deploy subdeployments

by Tom Fonteyne (JIRA)

[ https://issues.jboss.org/browse/AS7-5067?page=com.atlassian.jira.plugin.s... ] Tom Fonteyne moved JBPAPP-9390 to AS7-5067: ------------------------------------------- Project: Application Server 7 (was: JBoss Enterprise Application Platform) Key: AS7-5067 (was: JBPAPP-9390) Workflow: GIT Pull Request workflow (was: jira) Affects Version/s: 7.1.2.Final (EAP) (was: EAP 6.0.0 (CR1)) Component/s: Console (was: Consoles) Security: (was: Public) Docs QE Status: (was: NEW) > CLONE - CLI deploy with --name fails to deploy subdeployments > ------------------------------------------------------------- > > Key: AS7-5067 > URL: https://issues.jboss.org/browse/AS7-5067 > Project: Application Server 7 > Issue Type: Bug > Components: Console > Affects Versions: 7.1.2.Final (EAP) > Reporter: Tom Fonteyne > Assignee: Heiko Braun > Priority: Minor > Attachments: simpleejb3.ear > > > I have an ear file with inside a jar file with an ejb. > Use the CLI to deploy with: > > deploy simpleejb3.ear > In the console log: > 12:22:42,130 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) JBAS015876: Starting deployment of "simpleejb3.ear" > 12:22:42,174 INFO [org.jboss.as.server.deployment] (MSC service thread 1-16) JBAS015876: Starting deployment of "simpleejb3-ejb.jar" > 12:22:42,293 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-5) JNDI bindings for session bean named sbean in deployment unit subdeployment "simpleejb3-ejb.jar" of deployment "simpleejb3.ear" are as follows: > java:global/simpleejb3/simpleejb3-ejb/sbean!tf.sbeanLocal > java:app/simpleejb3-ejb/sbean!tf.sbeanLocal > java:module/sbean!tf.sbeanLocal > java:global/simpleejb3/simpleejb3-ejb/sbean!tf.sbeanRemote > java:app/simpleejb3-ejb/sbean!tf.sbeanRemote > java:module/sbean!tf.sbeanRemote > java:jboss/exported/simpleejb3/simpleejb3-ejb/sbean!tf.sbeanRemote > and the bean will work. > Now undeploy fully (+ restarted) and deploy again with: > > deploy simpleejb3.ear --name=b > and the log : > 12:23:41,300 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "b" > 12:23:41,431 INFO [org.jboss.as.osgi] (MSC service thread 1-4) JBAS011907: Register module: Module "deployment.b:main" from Service Module Loader > 12:23:41,598 INFO [org.jboss.as.server] (management-handler-thread - 2) JBAS018559: Deployed "b" > A test showed that the EJB was indeed not deployed/accessible. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBRULES-3558) Odd rules execution for expired events

by Karol Sobczak (JIRA)

Karol Sobczak created JBRULES-3558: -------------------------------------- Summary: Odd rules execution for expired events Key: JBRULES-3558 URL: https://issues.jboss.org/browse/JBRULES-3558 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core (fusion) Affects Versions: 5.4.0.Final Environment: Windows Vista 64, JRE6 (x86) Reporter: Karol Sobczak Assignee: Mark Proctor I have declared two types: declare Motion @role( event ) @expires( 5s ) @timestamp( eventTime ) eventTime : long end declare Recording end and following rules: rule "StartRecording" when Motion() not Recording() then insert(new Recording()) end the problem is that when I put a lot of "motions", sleep (so "motions" become expired) and then do fireAllRules(), I got "StartRecording" executed multiple times (and not only once), event though Recording is inserted every time. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
2
0 / 0

[JBoss JIRA] (AS7-5015) Using variable in persistence.xml <jta-data-source> leads to deployment-dependencies-error

by Stephan Pelikan (JIRA)

13 years, 10 months

4
12
0 / 0

[JBoss JIRA] (JBRULES-3364) Outdated Drools 5.3.0.Final documentation

by L Carlon (JIRA)

L Carlon created JBRULES-3364: --------------------------------- Summary: Outdated Drools 5.3.0.Final documentation Key: JBRULES-3364 URL: https://issues.jboss.org/browse/JBRULES-3364 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-docs Affects Versions: 5.3.0.Final Reporter: L Carlon Assignee: Geoffrey De Smet Priority: Minor Originally reported to BZ. Geoffrey, I wasn't sure who to assign this to, I hope you don't mind I gave it to you to reassign as appropriate. Copied from BZ: Description of problem: Documentation for Drools 5.3.0.Final is outdated because in part Drools Expert, section 8.6.4. The Audit View, is used outdated example about creating audit log where deprecated RuleBase is used instead of KnowledgeBase. Link to this documentation: http://docs.jboss.org/drools/release/5.3.0.Final/drools-expert-docs/html/... Version-Release number of selected component (if applicable): Drools 5.3.0.Final Documentation Actual results: WorkingMemory workingMemory = ruleBase.newWorkingMemory(); // Create a new Working Memory Logger, that logs to file. WorkingMemoryFileLogger logger = new WorkingMemoryFileLogger(workingMemory); // An event.log file is created in the subdirectory log (which must exist) // of the working directory. logger.setFileName( "log/event" ); workingMemory.assertObject(...); workingMemory.fireAllRules(); // stop logging logger.writeToDisk(); Expected results: ...something like this... KnowledgeBase kbase = readKnowledgeBase(); StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession(); KnowledgeRuntimeLogger logger = KnowledgeRuntimeLoggerFactory.newFileLogger(ksession, "test"); ksession.insert(...); ksession.fireAllRules(); logger.close(); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

3
15
0 / 0

[JBoss JIRA] (JGRP-1481) SEQUENCER can try forwarding to null coordinator

by David Hotham (JIRA)

13 years, 10 months

2
5
0 / 0

[JBoss JIRA] (JBRULES-3557) Selectors should support cacheType SOLVER with DroolsScoreDirector too: reuse multi-threading id technology to migrate the selector cache to the new solution clone

by Geoffrey De Smet (JIRA)

Geoffrey De Smet created JBRULES-3557: ----------------------------------------- Summary: Selectors should support cacheType SOLVER with DroolsScoreDirector too: reuse multi-threading id technology to migrate the selector cache to the new solution clone Key: JBRULES-3557 URL: https://issues.jboss.org/browse/JBRULES-3557 Project: Drools Issue Type: Enhancement Security Level: Public (Everyone can see) Components: drools-planner Reporter: Geoffrey De Smet Assignee: Geoffrey De Smet Priority: Optional Selector cacheType solver doesn't work because between phases, the bestSolution is set as the workingSolution and entities get cloned. Therefor the cached moves are pointing to the old entities which haven't been inserted into the new Drools Expert working memory. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
1
0 / 0

[JBoss JIRA] (JBRULES-3555) Allow to specify a relative value for the entity tabu

by Lukáš Petrovický (JIRA)

Lukáš Petrovický created JBRULES-3555: ----------------------------------------- Summary: Allow to specify a relative value for the entity tabu Key: JBRULES-3555 URL: https://issues.jboss.org/browse/JBRULES-3555 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-planner Affects Versions: 5.5.0.Beta1 Reporter: Lukáš Petrovický Assignee: Geoffrey De Smet Problems such as the RAS2012 challenge require us to provide a solution for problems of varying size - the number of entities in the various cases ranges from 3 to 30. In this case, it is nearly impossible to benchmark all those problems at once using the planning entity tabu. When you specify a tabu size larger than the number of entities, no solutions are accepted and thus the benchmark is useless. What I propose is to implement a planning entity tabu size that accepts the two different values: - Negative number. That would mean that the tabu would be of size Math.max($totalNumberOfEntities - 1, $totalNumberOfEntities - $specifiedNumber); - Percentage. That would mean that the tabu would be of the of Math.max($totalNumberOfEntities - 1, Math.round($percentage * $totalNumberOfEntities)). This way, the planning entity tabu size will become universally usable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

2
10
0 / 0

[JBoss JIRA] (AS7-4520) EJB subsystem gives uninformative error messages when an EJB class is invalid

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/AS7-4520?page=com.atlassian.jira.plugin.s... ] Stuart Douglas resolved AS7-4520. --------------------------------- Fix Version/s: 7.1.3.Final (EAP) 7.2.0.Alpha1 Resolution: Done > EJB subsystem gives uninformative error messages when an EJB class is invalid > ----------------------------------------------------------------------------- > > Key: AS7-4520 > URL: https://issues.jboss.org/browse/AS7-4520 > Project: Application Server 7 > Issue Type: Bug > Affects Versions: 7.1.1.Final > Environment: JBoss AS 7.1.1.Final > Reporter: Harold Campbell > Assignee: Stuart Douglas > Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1 > > > Singleton EJBs in the presence of beans.xml fail to deploy with a weld error. Without the presence of beans.xml the EJB deploys and functions as expected. Here's the full deployment attempt log: > 12:42:50,533 INFO [org.jboss.as.repository] (management-handler-thread - 2) JBAS014900: Content added at location /home/hcamp/code/jboss-as-7.1.1.Final/standalone/data/content/3a/11b79a5d3167adc8ec204eedf44cec07a50450/content > 12:42:50,561 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "rfpushtest.war" > 12:42:55,891 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016002: Processing weld deployment rfpushtest.war > 12:42:56,529 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named Poller in deployment unit deployment "rfpushtest.war" are as follows: > java:global/rfpushtest/Poller!com.foo.rfpushtest.ejb.singleton.Poller > java:app/rfpushtest/Poller!com.foo.rfpushtest.ejb.singleton.Poller > java:module/Poller!com.foo.rfpushtest.ejb.singleton.Poller > java:global/rfpushtest/Poller > java:app/rfpushtest/Poller > java:module/Poller > 12:42:57,493 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016005: Starting Services for CDI deployment: rfpushtest.war > 12:42:57,653 INFO [org.jboss.weld.Version] (MSC service thread 1-1) WELD-000900 1.1.5 (AS71) > 12:42:57,817 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016008: Starting weld service for deployment rfpushtest.war > 12:42:59,592 INFO [org.jboss.solder.config.xml.bootstrap.XmlConfigExtension] (MSC service thread 1-1) Solder Config XML provider starting... > 12:42:59,595 INFO [org.jboss.solder.config.xml.bootstrap.XmlConfigExtension] (MSC service thread 1-1) Loading XmlDocumentProvider: org.jboss.solder.config.xml.bootstrap.ResourceLoaderXmlDocumentProvider > 12:42:59,658 INFO [org.jboss.solder.config.xml.bootstrap.XmlConfigExtension] (MSC service thread 1-1) Reading XML file: vfs:/content/rfpushtest.war/WEB-INF/beans.xml > 12:42:59,699 INFO [org.jboss.solder.Version] (MSC service thread 1-1) Solder 3.1.0.Final (build id: 3.1.0.Final) > 12:43:07,485 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.deployment.unit."rfpushtest.war".component.Poller.START: org.jboss.msc.service.StartException in service jboss.deployment.unit."rfpushtest.war".component.Poller.START: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_26] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_26] > at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_26] > Caused by: java.lang.IllegalStateException: JBAS011048: Failed to construct component instance > at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163) > at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:85) > at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:116) > at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:130) > at org.jboss.as.ee.component.ComponentStartService.start(ComponentStartService.java:44) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] > ... 3 more > Caused by: javax.ejb.EJBException: java.lang.RuntimeException: java.lang.IllegalAccessException: Class org.jboss.as.weld.injection.WeldEEInjection can not access a member of class com.foo.rfpushtest.ejb.singleton.Poller with modifiers "" > at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:166) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:230) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:333) > at org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:56) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161) > ... 9 more > Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException: Class org.jboss.as.weld.injection.WeldEEInjection can not access a member of class com.foo.rfpushtest.ejb.singleton.Poller with modifiers "" > at org.jboss.as.weld.injection.WeldEEInjection.produce(WeldEEInjection.java:103) > at org.jboss.as.weld.injection.WeldManagedReferenceFactory.getReference(WeldManagedReferenceFactory.java:77) > at org.jboss.as.ee.component.ManagedReferenceInterceptorFactory$ManagedReferenceInterceptor.processInvocation(ManagedReferenceInterceptorFactory.java:90) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:228) > ... 18 more > Caused by: java.lang.IllegalAccessException: Class org.jboss.as.weld.injection.WeldEEInjection can not access a member of class com.foo.rfpushtest.ejb.singleton.Poller with modifiers "" > at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:65) [rt.jar:1.6.0_26] > at java.lang.Class.newInstance0(Class.java:349) [rt.jar:1.6.0_26] > at java.lang.Class.newInstance(Class.java:308) [rt.jar:1.6.0_26] > at org.jboss.as.weld.injection.WeldEEInjection.produce(WeldEEInjection.java:100) > ... 26 more > 12:43:07,792 INFO [org.jboss.as.server] (management-handler-thread - 2) JBAS015870: Deploy of deployment "rfpushtest.war" was rolled back with failure message {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"rfpushtest.war\".component.Poller.START" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"rfpushtest.war\".component.Poller.START: Failed to start service"}} > 12:43:07,811 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016009: Stopping weld service for deployment rfpushtest.war > 12:43:07,951 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015877: Stopped deployment rfpushtest.war in 173ms > 12:43:07,954 INFO [org.jboss.as.controller] (management-handler-thread - 2) JBAS014774: Service status report > JBAS014777: Services which failed to start: service jboss.deployment.unit."rfpushtest.war".component.Poller.START: org.jboss.msc.service.StartException in service jboss.deployment.unit."rfpushtest.war".component.Poller.START: Failed to start service -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
0
0 / 0

[JBoss JIRA] (AS7-4530) BasicComponent#waitForComponentStart() can result in deadlock if there is a deployment failure

by Stuart Douglas (JIRA)

Stuart Douglas created AS7-4530: ----------------------------------- Summary: BasicComponent#waitForComponentStart() can result in deadlock if there is a deployment failure Key: AS7-4530 URL: https://issues.jboss.org/browse/AS7-4530 Project: Application Server 7 Issue Type: Bug Components: EE Affects Versions: 7.1.1.Final Reporter: Stuart Douglas Assignee: David Lloyd If an invocation happens on a component that has not started yet then the MSC thread will block in waitForComponentStart(). If a deployment problem prevents this component from starting then MSC will jam. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
2
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2012