July 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBBUILD-718) archetype-catalog.xml is empty

by Fred Bricon (JIRA)

Fred Bricon created JBBUILD-718: ----------------------------------- Summary: archetype-catalog.xml is empty Key: JBBUILD-718 URL: https://issues.jboss.org/browse/JBBUILD-718 Project: JBoss Build System Issue Type: Bug Components: Artifact Repositories Reporter: Fred Bricon For some reason, https://repository.jboss.org/nexus/content/repositories/releases/archetyp... is empty. We can not use the catalog from m2e anymore. -- 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, 9 months

1
1
0 / 0

[JBoss JIRA] (AS7-3816) Expansion of variables in ejb-jar.xml

by Ed Keen (JIRA)

Ed Keen created AS7-3816: ---------------------------- Summary: Expansion of variables in ejb-jar.xml Key: AS7-3816 URL: https://issues.jboss.org/browse/AS7-3816 Project: Application Server 7 Issue Type: Feature Request Affects Versions: 7.1.0.Final Reporter: Ed Keen Expansion of variables was supported in ejb-jar.xml in previous versions of JBoss. This does not appear to be supported in 7.1. Reference this discussion in the AS forum: https://community.jboss.org/message/717509 -- 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, 9 months

10
16
0 / 0

[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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 months

2
3
0 / 0

[JBoss JIRA] (AS7-5168) IllegalArgumentException when using tab-completion with a wildcard in the path

by Jeff Mesnil (JIRA)

Jeff Mesnil created AS7-5168: -------------------------------- Summary: IllegalArgumentException when using tab-completion with a wildcard in the path Key: AS7-5168 URL: https://issues.jboss.org/browse/AS7-5168 Project: Application Server 7 Issue Type: Bug Components: Console Environment: AS7 master branch Reporter: Jeff Mesnil Assignee: Heiko Braun I wanted to get all the values of jms-queues' attribute core-address from the CLI and it works as expected: {noformat} [standalone@localhost:9999 /] /subsystem=messaging/hornetq-server=default/jms-queue=*:read-attribute(name="queue-address") { "outcome" => "success", "result" => [ { "address" => [ ("subsystem" => "messaging"), ("hornetq-server" => "default"), ("jms-queue" => "myQueue") ], "outcome" => "success", "result" => "jms.queue.myQueue" }, { "address" => [ ("subsystem" => "messaging"), ("hornetq-server" => "default"), ("jms-queue" => "HELLOWORLDMDBQueue2") ], "outcome" => "success", "result" => "jms.queue.HELLOWORLDMDBQueue2" } ] } {noformat} However when I tried to tab-complete the name of the attribute, I got an IllegalArgumentException and the console exited. {noformat} [standalone@localhost:9999 /] /subsystem=messaging/hornetq-server=default/jms-queue=*:read-attribute(name=java.lang.IllegalArgumentException at org.jboss.dmr.ModelValue.getChild(ModelValue.java:108) at org.jboss.dmr.ModelNode.get(ModelNode.java:798) at org.jboss.as.cli.operation.impl.PropertyNameCompleter$1.getAllCandidates(PropertyNameCompleter.java:62) at org.jboss.as.cli.impl.DefaultCompleter.complete(DefaultCompleter.java:64) at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:222) at org.jboss.as.cli.CommandCompleter.complete(CommandCompleter.java:93) at org.jboss.as.cli.impl.Console$Factory$1$1.complete(Console.java:96) at org.jboss.jreadline.console.Console.complete(Console.java:809) at org.jboss.jreadline.console.Console.read(Console.java:383) at org.jboss.jreadline.console.Console.read(Console.java:221) at org.jboss.as.cli.impl.Console$Factory$1.readLine(Console.java:166) at org.jboss.as.cli.impl.CommandContextImpl.interact(CommandContextImpl.java:1140) at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:243) at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.jboss.modules.Module.run(Module.java:270) at org.jboss.modules.Main.main(Main.java:294) {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, 9 months

4
6
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, 9 months

5
16
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 July 2012