September 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (AS7-1421) Modcluster subsystem has broken :read-resource-description

by Heiko Rupp (JIRA)

Modcluster subsystem has broken :read-resource-description ---------------------------------------------------------- Key: AS7-1421 URL: https://issues.jboss.org/browse/AS7-1421 Project: Application Server 7 Issue Type: Bug Components: Domain Management Affects Versions: 7.0.0.Final Reporter: Heiko Rupp Assignee: Brian Stansberry [domain@localhost:9999 subsystem=modcluster] :read-resource-description { "outcome" => "success", "result" => { "description" => "The configuration of the modcluster subsystem.", "head-comment-allowed" => true, "tail-comment-allowed" => true, "namespace" => "urn:jboss:domain:modcluster:1.0", "attributes" => {"mod-cluster-config" => { "type" => OBJECT, "description" => "The common modcluster configuration.", "required" => false, "access-type" => "read-only", "storage" => "configuration" }} } } is not usable at all to use for management operations. Also attributes of mod-cluster-config should directly live in 'attributes'. There is no point in adding one more level here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

3
2
0 / 0

[JBoss JIRA] Created: (AS7-1638) Exception after reloading in CLI

by Nicklas Karlsson (JIRA)

Exception after reloading in CLI -------------------------------- Key: AS7-1638 URL: https://issues.jboss.org/browse/AS7-1638 Project: Application Server 7 Issue Type: Bug Components: JCA, JMS Affects Versions: 7.1.0.Alpha1 Reporter: Nicklas Karlsson Assignee: Jesper Pedersen Running a CLI batch batch /subsystem=datasources/jdbc-driver=oracle:add(driver-name="oracle",driver-module-name="com.oracle.db") /subsystem=datasources/data-source=...:add.. /socket-binding-group=standard-sockets/socket-binding=http:write-attribute(name="port", value="80") /subsystem=deployment-scanner/scanner=default:write-attribute(name="auto-deploy-exploded", value="true") :reload run-batch gives a 08:52:55,533 INFO [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-8) trying to deploy queue jms.topic.testTopic 08:52:55,544 INFO [org.jboss.as.connector.services.ResourceAdapterActivatorService$ResourceAdapterActivator] (MSC service thread 1-4) Registered connection factory java:/JmsXA 08:52:55,545 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC00001: Failed to start service jboss.raactivator: org.jboss.msc.service.StartException in service jboss.raactivator: Failed to activate resource adapter hornetq-ra at org.jboss.as.connector.services.ResourceAdapterActivatorService.start(ResourceAdapterActivatorService.java:98) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765) at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [:1.7.0] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [:1.7.0] at java.lang.Thread.run(Thread.java:722) [:1.7.0] Caused by: org.jboss.jca.deployers.common.DeployException: IJ020056: Deployment failed: file://RaActivatorhornetq-ra at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:1929) at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:825) at org.jboss.as.connector.services.ResourceAdapterActivatorService$ResourceAdapterActivator.doDeploy(ResourceAdapterActivatorService.java:140) at org.jboss.as.connector.services.ResourceAdapterActivatorService.start(ResourceAdapterActivatorService.java:93) ... 5 more Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.connector.connection-factory.java:/JmsXA is already registered at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:154) at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:226) at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:560) at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:307) at org.jboss.as.connector.metadata.deployment.AbstractResourceAdapterDeploymentService$AbstractAS7RaDeployer.bindConnectionFactory(AbstractResourceAdapterDeploymentService.java:228) at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:1714) ... 8 more -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

4
5
0 / 0

[JBoss JIRA] Created: (JBRULES-3131) timer( cron: ...) causes ArrayStoreException with slightly erroneous (?) argument

by Wolfgang Laun (JIRA)

timer( cron: ...) causes ArrayStoreException with slightly erroneous (?) argument --------------------------------------------------------------------------------- Key: JBRULES-3131 URL: https://issues.jboss.org/browse/JBRULES-3131 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler (expert) Affects Versions: 5.2.0.Final Reporter: Wolfgang Laun Assignee: Mark Proctor Fix For: 5.2.1.Final rule xxx timer( cron: 0/30 * * * * * ) when then end Exception in thread "main" java.lang.ArrayStoreException at java.lang.System.arraycopy(Native Method) at java.util.ArrayList.toArray(ArrayList.java:306) at org.drools.compiler.PackageBuilder.getErrors(PackageBuilder.java:1274) at org.drools.builder.impl.KnowledgeBuilderImpl.getErrors(KnowledgeBuilderImpl.java:70) It would be a Good Thing if timer( cron: ) were documented. It deviates from UNIX crontab in at least two aspects. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

4
3
0 / 0

[JBoss JIRA] Created: (JBRULES-3132) Simple syntax error timer(int 10) causes RuntimeDroolsException in RuleBuilder

by Wolfgang Laun (JIRA)

Simple syntax error timer(int 10) causes RuntimeDroolsException in RuleBuilder ------------------------------------------------------------------------------- Key: JBRULES-3132 URL: https://issues.jboss.org/browse/JBRULES-3132 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 5.2.0.Final Reporter: Wolfgang Laun Assignee: Mark Proctor Fix For: 5.2.1.Final rule xxx timer(int 10 ) # not the missing colon when then System.out.println( "CRONTAB" ); end causes: Exception in thread "main" org.drools.RuntimeDroolsException: Error parsing time string: [ int ] at org.drools.time.TimeUtils.parseTimeString(TimeUtils.java:127) at org.drools.rule.builder.RuleBuilder.buildTimer(RuleBuilder.java:320) at org.drools.rule.builder.RuleBuilder.buildAttributes(RuleBuilder.java:139) at org.drools.rule.builder.RuleBuilder.build(RuleBuilder.java:92) at org.drools.compiler.PackageBuilder.addRule(PackageBuilder.java:1889) at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:755) at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:365) at org.drools.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:543) at org.drools.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:28) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

4
3
0 / 0

[JBoss JIRA] Created: (AS7-703) Display server VM metrics in console

by Heiko Braun (JIRA)

Display server VM metrics in console ------------------------------------ Key: AS7-703 URL: https://issues.jboss.org/browse/AS7-703 Project: Application Server 7 Issue Type: Feature Request Components: Console Reporter: Heiko Braun Assignee: Heiko Braun Fix For: 7.0.0.CR1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

3
8
0 / 0

[JBoss JIRA] Created: (JGRP-1371) Unable to suspend self in FLUSH.blockMessageDuringFlush(); Eternal timeouts not supported

by Nicolas Estrada (JIRA)

Unable to suspend self in FLUSH.blockMessageDuringFlush(); Eternal timeouts not supported ----------------------------------------------------------------------------------------- Key: JGRP-1371 URL: https://issues.jboss.org/browse/JGRP-1371 Project: JGroups Issue Type: Bug Affects Versions: 2.12.1 Environment: All Reporter: Nicolas Estrada Assignee: Bela Ban Priority: Critical If a positive timeout is specified for the FLUSH protocol, if the specified waiting time timeout elapses during the notBlockedDown.await(timeout) invocation, the shouldSuspendByItself flag will be set but it will continue looping forever. The if clause below should be moved into the while block. If the timeout is 0L or negative, instead of waiting forever, it will instantaneously return from the await(timeout) method, but seeing as it can never suspend itself as mentioned earlier, it will loop forever until a STOP_FLUSH or ABORT_FLUSH event is received. Changing the method to await() for "eternal" timeouts may be dangerous however; There must be a guarantee that the isBlockingFlushDown is toggled even if the FLUSH coordinator fails. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

4
7
0 / 0

[JBoss JIRA] Created: (JGRP-1366) CounterService: distributed counter

by Bela Ban (JIRA)

CounterService: distributed counter ----------------------------------- Key: JGRP-1366 URL: https://issues.jboss.org/browse/JGRP-1366 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.0 Provide a CounterService class (similar to LockService), which communicates with a protocol. Provide methods similar to what's in AtomicInteger, e.g. get(), compareAndSet(), incrAndGet(), decrAndGet() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

3
3
0 / 0

[JBoss JIRA] Created: (JBRULES-3150) NPE in ObjectTypeConfigurationRegistry when accumulate returns null (and "quick hack for 5.2")

by Wolfgang Laun (JIRA)

NPE in ObjectTypeConfigurationRegistry when accumulate returns null (and "quick hack for 5.2") ---------------------------------------------------------------------------------------------- Key: JBRULES-3150 URL: https://issues.jboss.org/browse/JBRULES-3150 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core (expert) Affects Versions: 5.2.0.Final Reporter: Wolfgang Laun Assignee: Mark Proctor Fix For: 5.2.1.Final rule foo # the problem is usually better "hidden" when Object() from accumulate( Object(), init( Object res = null; ) action( res = null; ) result( res ) ) then end causes the exception as shown below, or similar. A runtime diagnostic should tell the user (at least) that an accumulate result is null. ALSO, PLEASE NOTE THIS COMMENT in AccumulateNode.java:642! // this is a quick hack for the 5.2 release Exception in thread "main" java.lang.NullPointerException at org.drools.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:58) at org.drools.reteoo.AccumulateNode.evaluateResultConstraints(AccumulateNode.java:646) at org.drools.reteoo.AccumulateNode.assertLeftTuple(AccumulateNode.java:183) at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:197) at org.drools.reteoo.SingleLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:146) at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:154) at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59) at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:204) at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:191) at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:332) at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:293) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:905) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:864) at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:255) at match.Main.makeFacts(Main.java:120) at match.Main.execute(Main.java:98) at match.Main.main(Main.java:126) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

4
3
0 / 0

[JBoss JIRA] Created: (AS7-1054) The CallbackHandler is called multiple times on the client side with Remoting / Managent Interface

by Darran Lofthouse (JIRA)

The CallbackHandler is called multiple times on the client side with Remoting / Managent Interface -------------------------------------------------------------------------------------------------- Key: AS7-1054 URL: https://issues.jboss.org/browse/AS7-1054 Project: Application Server 7 Issue Type: Bug Components: Remoting, Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 7.1.0.Alpha1 This may be a side effect of the current problems where Remoting is looped to establish the connection but it means that we need to cache the users username and password from the first attempt so we don't keep prompting them - the problem then is we do not know if the subsequent call is because their values were invalid or just because of the retries. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

3
4
0 / 0

[JBoss JIRA] Created: (AS7-1374) Domain Management - Ensure we keep Native connections alive where appropriate

by Darran Lofthouse (JIRA)

Domain Management - Ensure we keep Native connections alive where appropriate ----------------------------------------------------------------------------- Key: AS7-1374 URL: https://issues.jboss.org/browse/AS7-1374 Project: Application Server 7 Issue Type: Task Components: Domain Management, Remoting Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 7.1.0.Beta1 Establishing a connection can generally also involve negotiating the security before the connection is first used, this has the potential to become a major performance drain especially if the management load is high (management can be everything from updating the model to querying metrics). This task is to ensure we keep the connections alive where it makes sense. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

3
3
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 September 2011