June 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-4296) Support overriding deployment descriptors at deployment time

by Stuart Douglas (JIRA)

Stuart Douglas created AS7-4296: ----------------------------------- Summary: Support overriding deployment descriptors at deployment time Key: AS7-4296 URL: https://issues.jboss.org/browse/AS7-4296 Project: Application Server 7 Issue Type: Feature Request Components: Domain Management, Server Affects Versions: 7.1.1.Final Reporter: Stuart Douglas Assignee: Stuart Douglas We need to be able to specify alternate jboss-*.xml descriptors (or indeed any descriptor) at deployment, and have them override the descriptors physically present in the deployment archive. -- 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, 7 months

3
6
0 / 0

[JBoss JIRA] (AS7-3016) Lazy enlistment of JMS Session does not work - UserTransaction implementation does not support it

by Jiri Pechanec (Created) (JIRA)

Lazy enlistment of JMS Session does not work - UserTransaction implementation does not support it ------------------------------------------------------------------------------------------------- Key: AS7-3016 URL: https://issues.jboss.org/browse/AS7-3016 Project: Application Server 7 Issue Type: Bug Components: Transactions Affects Versions: 7.1.0.Beta1b Reporter: Jiri Pechanec Assignee: Jonathan Halliday Priority: Critical This test case was identified in TCK6. There is a MDB with CMT configured - com/sun/ts/tests/jms/ee/mdb/xa The testsuite sends a message to MDB MDB 1) creates a QueueSession 2) Start UT 3) Send a message 4) Rollback UT 5) Start UT 6) Send a message 7) commit UT Unfortunately the semantics is broken as QueueSession is not enlisted into transactions. The enlistment is done when UserTransaction emits a notification org/jboss/tm/usertx/UserTransactionRegistry. The enlistment is done by JCA component which receives the notification and enlists all active XAResources. Unfortunately the notification is emitted by org/jboss/tm/usertx/client/ServerVMClientUserTransaction. Unfortunately org/jboss/as/txn/service/ArjunaTransactionManagerService hard-codes com.arjuna.ats.internal.jta.transaction.arjunacore.UserTransactionImple which does not have this capability. It is necessary to support this scenario as it is tested in TCKs. -- 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, 7 months

11
11
0 / 0

[JBoss JIRA] (JBWEB-239) Convert project to use i18n logging and exceptions

by James Perkins (JIRA)

James Perkins created JBWEB-239: ----------------------------------- Summary: Convert project to use i18n logging and exceptions Key: JBWEB-239 URL: https://issues.jboss.org/browse/JBWEB-239 Project: JBoss Web Issue Type: Task Security Level: Public (Everyone can see) Reporter: James Perkins Assignee: Remy Maucherat As per [ANDIAMO-7|https://issues.jboss.org/browse/ANDIAMO-7] all messages (logged and exceptions) need a unique id. This need to be done using JBoss Logging, [ANDIAMO-2|https://issues.jboss.org/browse/ANDIAMO-2]. See [https://community.jboss.org/docs/DOC-18453] for information on configuring the loggers and message bundles. -- 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, 7 months

2
1
0 / 0

[JBoss JIRA] (JBEE-97) See if the jstl dependency on xalan can be refactored out

by Paul Gier (Created) (JIRA)

See if the jstl dependency on xalan can be refactored out --------------------------------------------------------- Key: JBEE-97 URL: https://issues.jboss.org/browse/JBEE-97 Project: JBoss JavaEE Spec APIs Issue Type: Enhancement Components: jboss-jstl-api Affects Versions: JavaEE 6 Spec APIs 3.0.0.Beta1 Reporter: Paul Gier Assignee: Paul Gier Fix For: JavaEE 6 Spec APIs 3.0.0 The JSTL api has a dependency on the xalan fork which is only available in the JBoss repository. If this can be refactored out, then the complete set of dependencies will be available in central. -- 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, 7 months

3
4
0 / 0

[JBoss JIRA] Created: (AS7-1268) Can't update subhandler on async handler

by Stan Silvert (JIRA)

Can't update subhandler on async handler ---------------------------------------- Key: AS7-1268 URL: https://issues.jboss.org/browse/AS7-1268 Project: Application Server 7 Issue Type: Bug Components: Logging Affects Versions: 7.1.0.Alpha1 Reporter: Stan Silvert Assignee: David Lloyd David, sorry if I'm assigning to the wrong person. I guess this could be a CLI bug. [standalone@localhost:9999 /] cd subsystem=logging/async-handler=ASYNC [standalone@localhost:9999 async-handler=ASYNC] :read-resource(recursive=true) { "outcome" => "success", "result" => { "level" => "INFO", "overflow-action" => "BLOCK", "queue-length" => 1024, "subhandlers" => ["FILE"] } } [standalone@localhost:9999 async-handler=ASYNC] :update-properties(subhandlers=["CONSOLE"]) {"outcome" => "success"} [standalone@localhost:9999 async-handler=ASYNC] :read-resource(recursive=true) { "outcome" => "success", "result" => { "level" => "INFO", "overflow-action" => "BLOCK", "queue-length" => 1024, "subhandlers" => ["FILE"] } } -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

3
3
0 / 0

[JBoss JIRA] (JBRULES-3496) kbase.removeKnowledgePackage() aparent infinite loop

by Mariano De Maio (JIRA)

Mariano De Maio created JBRULES-3496: ---------------------------------------- Summary: kbase.removeKnowledgePackage() aparent infinite loop Key: JBRULES-3496 URL: https://issues.jboss.org/browse/JBRULES-3496 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 5.4.0.CR1 Environment: Unix based (Ubuntu 10) Core i5 with 4GB RAM Reporter: Mariano De Maio Assignee: Mark Proctor Attachments: Proj.tar.gz I have attached a simple project containing just 1 rule and some declared classes. The rule is compiled ok, but when after adding the generated package to a kbase, when trying to remove it, an infinite-loop (or what it seems like an infinite-loop) occurs. If you remove some of the patterns in the rule, everything works fine. I have debugged up to ReteooBuilder.resetMarks(). The execution never returns from that method. -- 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, 7 months

2
3
0 / 0

[JBoss JIRA] (AS7-4274) Remoting deadlock after deserialization exception of a large object graph returned from EJB.

by Daniel Bevenius (JIRA)

Daniel Bevenius created AS7-4274: ------------------------------------ Summary: Remoting deadlock after deserialization exception of a large object graph returned from EJB. Key: AS7-4274 URL: https://issues.jboss.org/browse/AS7-4274 Project: Application Server 7 Issue Type: Bug Components: EJB, Remoting Affects Versions: 7.1.1.Final Environment: JBoss AS 7.1.1.Final Reporter: Daniel Bevenius Assignee: jaikiran pai The use case is a remote EJB client that calls an EJB which returns a large object graph. Due to a configuration error on our part a class that is part of this object graph is not available in the clients classpath. This causes a ClassNotFoundException to be thrown when deserializing, and after this exception is thrown the client "freezes" but can be interrupted by CTRL+C, but the server will deadlock and will not respond and has to be shutdown by killing the server process. Below is part of the thread dump (the complete thread dump will be attached to this jira) {noformat} "Remoting "beve-7719" read-1" prio=5 tid=00000000028cc800 nid=0xb56ab000 waiting for monitor entry [00000000b56aa000] java.lang.Thread.State: BLOCKED (on object monitor) at org.xnio.streams.BufferPipeOutputStream.close(BufferPipeOutputStream.java:156) - waiting to lock <0000000005697300> (a org.xnio.streams.BufferPipeOutputStream) at org.xnio.IoUtils.safeClose(IoUtils.java:137) at org.jboss.remoting3.remote.OutboundMessage.closeAsync(OutboundMessage.java:158) at org.jboss.remoting3.remote.RemoteConnectionChannel.handleAsyncClose(RemoteConnectionChannel.java:502) at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:259) at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:45) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) at org.xnio.nio.NioHandle.run(NioHandle.java:90) at org.xnio.nio.WorkerThread.run(WorkerThread.java:184) Locked ownable synchronizers: - None "EJB default - 4" prio=5 tid=0000000002a10c00 nid=0xb3971000 in Object.wait() [00000000b3970000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <00000000056972d0> (a org.jboss.remoting3.remote.OutboundMessage) at java.lang.Object.wait(Object.java:485) at org.jboss.remoting3.remote.OutboundMessage$1.accept(OutboundMessage.java:91) - locked <00000000056972d0> (a org.jboss.remoting3.remote.OutboundMessage) at org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:125) at org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:113) at org.xnio.streams.BufferPipeOutputStream.getBuffer(BufferPipeOutputStream.java:77) at org.xnio.streams.BufferPipeOutputStream.write(BufferPipeOutputStream.java:86) - locked <0000000005697300> (a org.xnio.streams.BufferPipeOutputStream) at org.jboss.remoting3.remote.OutboundMessage.write(OutboundMessage.java:168) at java.io.DataOutputStream.write(DataOutputStream.java:71) - locked <00000000056972b8> (a java.io.DataOutputStream) at org.jboss.as.ejb3.remote.protocol.versionone.AbstractMessageHandler$1.write(AbstractMessageHandler.java:188) at java.io.OutputStream.write(OutputStream.java:99) at org.jboss.marshalling.OutputStreamByteOutput.write(OutputStreamByteOutput.java:56) at org.jboss.marshalling.SimpleDataOutput.flush(SimpleDataOutput.java:311) at org.jboss.marshalling.SimpleDataOutput.write(SimpleDataOutput.java:82) at org.jboss.marshalling.river.BlockMarshaller.flush(BlockMarshaller.java:306) at org.jboss.marshalling.river.RiverMarshaller.writeEndBlock(RiverMarshaller.java:961) at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1008) at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885) at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:825) at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063) at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019) at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885) at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62) at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119) at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.writeMethodInvocationResponse(MethodInvocationMessageHandler.java:338) at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$500(MethodInvocationMessageHandler.java:64) at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:226) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) 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:680) at org.jboss.threads.JBossThread.run(JBossThread.java:122) Locked ownable synchronizers: - <0000000008350f48> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) {noformat} -- 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, 7 months

5
16
0 / 0

[JBoss JIRA] (JGRP-1475) Convert project to use i18n logging and exceptions

by James Perkins (JIRA)

James Perkins created JGRP-1475: ----------------------------------- Summary: Convert project to use i18n logging and exceptions Key: JGRP-1475 URL: https://issues.jboss.org/browse/JGRP-1475 Project: JGroups Issue Type: Task Reporter: James Perkins Assignee: Bela Ban As per [ANDIAMO-7|https://issues.jboss.org/browse/ANDIAMO-7] all messages (logged and exceptions) need a unique id. This need to be done using JBoss Logging, [ANDIAMO-2|https://issues.jboss.org/browse/ANDIAMO-2]. See [https://community.jboss.org/docs/DOC-18453] for information on configuring the loggers and message bundles. -- 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, 7 months

2
12
0 / 0

[JBoss JIRA] (JBRULES-3515) Getting runtime exception while I remove a validation Rule in version 5.4

by Premasis S (JIRA)

Premasis S created JBRULES-3515: ----------------------------------- Summary: Getting runtime exception while I remove a validation Rule in version 5.4 Key: JBRULES-3515 URL: https://issues.jboss.org/browse/JBRULES-3515 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.4.0.Final Reporter: Premasis S Assignee: Mark Proctor I am getting the following exception while removing/disabling a Drool Validation Rule, using Drools Version 5.4.FINAL i.e when I call - knowledgeBase.removeRule("pkg.trade", "2.8.I23"); java.util.NoSuchElementException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:980) at java.util.HashMap$EntryIterator.next(HashMap.java:1018) at java.util.HashMap$EntryIterator.next(HashMap.java:1016) at org.drools.reteoo.EvalConditionNode.doRemove(EvalConditionNode.java:302) at org.drools.common.BaseNode.remove(BaseNode.java:109) at org.drools.reteoo.FromNode.doRemove(FromNode.java:440) at org.drools.common.BaseNode.remove(BaseNode.java:109) at org.drools.reteoo.RightInputAdapterNode.doRemove(RightInputAdapterNode.java:285) at org.drools.common.BaseNode.remove(BaseNode.java:109) at org.drools.reteoo.BetaNode.doRemove(BetaNode.java:499) at org.drools.common.BaseNode.remove(BaseNode.java:109) at org.drools.reteoo.RuleTerminalNode.doRemove(RuleTerminalNode.java:358) at org.drools.common.BaseNode.remove(BaseNode.java:109) at org.drools.reteoo.ReteooBuilder.removeRule(ReteooBuilder.java:261) at org.drools.reteoo.ReteooRuleBase.removeRule(ReteooRuleBase.java:460) at org.drools.common.AbstractRuleBase.removeRule(AbstractRuleBase.java:1107) at org.drools.common.AbstractRuleBase.removeRule(AbstractRuleBase.java:1085) at org.drools.impl.KnowledgeBaseImpl.removeRule(KnowledgeBaseImpl.java:210) Here is the Rule: package pkg.trade; rule "2.8.I23" when $trade : Trade() $trdDeskId : Id() from mediator.getTradingDeskId($trade) eval(isPositiveId($trdDeskId)) eval($trdDeskId != null && !mediator.isValidTradingDesk($trdDeskId)) then raiseException(kcontext, $trade, "tradingDeskId", stringValue($trdDeskId)); end -- 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, 7 months

2
2
0 / 0

[JBoss JIRA] (AS7-3975) EJB client invocations sometimes hang indefinitely

by Radoslav Husar (JIRA)

Radoslav Husar created AS7-3975: ----------------------------------- Summary: EJB client invocations sometimes hang indefinitely Key: AS7-3975 URL: https://issues.jboss.org/browse/AS7-3975 Project: Application Server 7 Issue Type: Bug Components: Clustering, EJB Affects Versions: 7.1.0.Final Reporter: Radoslav Husar Assignee: jaikiran pai Priority: Critical Fix For: 7.1.1.Final When running a EJB stress test when the test is over some clients hang indefinitely. This is a positive test, there are no failures being injected in the test. {noformat} "Runner - 16" daemon prio=10 tid=0x00007fb7a0025000 nid=0x4d7a in Object.wait() [0x00007fb78b3f2000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:485) at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:330) - locked <0x00000006c013ae50> (a java.lang.Object) at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:140) at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:121) at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104) at $Proxy0.getSerialAndIncrement(Unknown Source) at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.processRequest(StatefulSBProcessorFactoryImpl.java:68) at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51) at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87) at java.lang.Thread.run(Thread.java:662) {noformat} I originally filed a feature request to implement a timeout AS7-3811, needless to say this needs to get fixed first. -- 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, 7 months

6
20
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