January 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-3201) CLI: rollout-plan add command with malformed plan crashes CLI

by Dominik Pospisil (Created) (JIRA)

CLI: rollout-plan add command with malformed plan crashes CLI ------------------------------------------------------------- Key: AS7-3201 URL: https://issues.jboss.org/browse/AS7-3201 Project: Application Server 7 Issue Type: Bug Components: CLI Affects Versions: 7.1.0.CR1b Reporter: Dominik Pospisil Assignee: Alexey Loubyansky The rollout-plan add command with malformed plan crashes CLI. Steps to reproduce. 1) connect to a domain 2) rollout-plan add --name=testPlan --content=test Console crashes with: java.lang.IllegalArgumentException: newValue is null at org.jboss.dmr.ModelNode.set(ModelNode.java:503) at org.jboss.as.cli.handlers.GenericTypeOperationHandler.buildOperationRequest(GenericTypeOperationHandler.java:514) at org.jboss.as.cli.handlers.GenericTypeOperationHandler.buildRequest(GenericTypeOperationHandler.java:358) at org.jboss.as.cli.handlers.BaseOperationCommand.doHandle(BaseOperationCommand.java:183) at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:84) at org.jboss.as.cli.impl.CommandContextImpl.processLine(CommandContextImpl.java:449) at org.jboss.as.cli.impl.CommandContextImpl.interact(CommandContextImpl.java:983) at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:174) 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:248) at org.jboss.modules.Main.main(Main.java:313) -- 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

12 years, 9 months

2
1
0 / 0

[JBoss JIRA] Created: (AS7-1920) Support non-Zip based archives for deployment

by Jesper Pedersen (JIRA)

Support non-Zip based archives for deployment --------------------------------------------- Key: AS7-1920 URL: https://issues.jboss.org/browse/AS7-1920 Project: Application Server 7 Issue Type: Task Reporter: Jesper Pedersen Assignee: Jason Greene We need to support file deployments that aren't a ZIP based archive. These deployments should also be passed through the DUPs. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

6
17
0 / 0

[JBoss JIRA] (AS7-2269) HornetQ Restful inteface does not work when queues are configured in AS7 config files

by Mitchell Ackerman (Created) (JIRA)

HornetQ Restful inteface does not work when queues are configured in AS7 config files ------------------------------------------------------------------------------------- Key: AS7-2269 URL: https://issues.jboss.org/browse/AS7-2269 Project: Application Server 7 Issue Type: Bug Components: JMS, REST Affects Versions: 7.0.2.Final Environment: Windows 7, Java 1.6.0_26, JBoss AS 7.0.2.Final, HornetQ 2.2.7, HornetQRest 2.2.6 Reporter: Mitchell Ackerman Assignee: Clebert Suconic When HornetQ queues are configured in AS7 config files (i.e., standalone.xml), The HornetQ Restful inteface does not work. Upon examining the AS7 modules, the rest interface libraries are not even included, so it is not surprising that it does not work. If the libraries are bundled with a webapp, REST still does not work. The workaround I have is to remove HornetQ from the AS7 configuration, configure HornetQ using the standard HornetQ configuration files (hornetq-configuration.xml, hornetq-jms, ...), and bundle the HornetQ libraries with the webapp. When doing that, however, the HornetQ queues/topics are not shown in the AS7 console JNDI. As an example, you can use HornetQRestExamples/jms-to-rest, and change configuration of the queues to AS7, in which case REST will not work. -- 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

12 years, 9 months

2
1
0 / 0

[JBoss JIRA] (AS7-3358) CLONE - NullPointerException when HQ backup server is shutting down after clean shutdown

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-3358?page=com.atlassian.jira.plugin.s... ] Brian Stansberry reassigned AS7-3358: ------------------------------------- Assignee: Andy Taylor (was: Clebert Suconic) > CLONE - NullPointerException when HQ backup server is shutting down after clean shutdown > ---------------------------------------------------------------------------------------- > > Key: AS7-3358 > URL: https://issues.jboss.org/browse/AS7-3358 > Project: Application Server 7 > Issue Type: Bug > Components: JMS > Affects Versions: 7.1.0.CR1 > Reporter: Pavel Slavicek > Assignee: Andy Taylor > Priority: Minor > Fix For: 7.1.0.Final > > > This issue is also in AS7. > Cloned from JBPAPP-6137: > Hi Clebert, > I hit NullPointerException when dedicated backup server was shutting down after clean shutdown command. Live server was stopped (clean shutdown too) several seconds before backup server. It seems that backup tried to take its role. NullPointerException is ugly and it should not occur. > I am putting it on minor priority. > Thank you. > 10:42:42,071 INFO [ClusterManagerImpl] announcing backup > 10:42:42,072 INFO [HornetQServerImpl] HornetQ Backup Server version 2.2.1.GA (Zmmmmmmmm, 121) [e9d8059a-5140-11e0-8830-005056c00008] started, waiting live to fail before it gets active > 10:42:49,387 INFO [ClusterManagerImpl] backup announced > ^C10:51:03,362 INFO [ServerImpl] Runtime shutdown hook called, forceHalt: true > 10:51:03,423 WARN [RemotingConnectionImpl] Connection failure has been detected: The connection was disconnected because of server shutdown [code=4] > 10:51:03,628 WARN [ClientSessionFactoryImpl] Failed to connect to server. > 10:51:03,634 SEVERE [HornetQServerImpl] Failure in initialisation > java.lang.NullPointerException > at org.hornetq.core.server.impl.HornetQServerImpl.initialisePart2(HornetQServerImpl.java:1436) > at org.hornetq.core.server.impl.HornetQServerImpl.access$100(HornetQServerImpl.java:130) > at org.hornetq.core.server.impl.HornetQServerImpl$SharedStoreBackupActivation.run(HornetQServerImpl.java:398) > at java.lang.Thread.run(Thread.java:636) > 10:51:04,634 INFO [HornetQServerImpl] HornetQ Server version 2.2.1.GA (Zmmmmmmmm, 121) [e9d8059a-5140-11e0-8830-005056c00008] stopped -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBLOGGING-71) The JMX Bean associated with a LogContext must be made available

by Leonid Kosmylev (JIRA)

The JMX Bean associated with a LogContext must be made available ---------------------------------------------------------------- Key: JBLOGGING-71 URL: https://issues.jboss.org/browse/JBLOGGING-71 Project: JBoss Logging Issue Type: Enhancement Security Level: Public (Everyone can see) Environment: JBoss AS 6.0.0 Reporter: Leonid Kosmylev Assignee: David Lloyd Class org.jboss.logmanager.LogContext has an associated instance of LoggingMXBeanImpl. If per-application logging is enabled a new instances of LogContext and LoggingMXBeanImpl are created. But the LoggingMXBeanImpl is not registered as an MBean. It is therefore not possible to change log levels dynamically. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

2
5
0 / 0

[JBoss JIRA] Created: (JBAS-9246) Create test to verify messages are not delivered to MDBs before EJB container is started.

by Dimitris Andreadis (JIRA)

Create test to verify messages are not delivered to MDBs before EJB container is started. ----------------------------------------------------------------------------------------- Key: JBAS-9246 URL: https://issues.jboss.org/browse/JBAS-9246 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB Affects Versions: JBossAS-5.1.0.GA Environment: Version info: JBoss 5.1.0 GA (we use a local build, and have updated JBoss Cache to 3.2.1.GA, JBossTS to 4.6.1.GA_CP03 and JGroups to 2.6.13.GA to pick up bug fixes for issues we have encountered in production) ActiveMQ 5.3.0 GA HornetQ 2.0.0 GA Java 1.6.0_17 Mac OS 10.6.2 Reporter: Robert West Assignee: Carlo de Wolf Priority: Critical Fix For: No Release Testing scenario: Deployed JBoss 5.1.0.GA (with tweaks to the pom during build, see Environment) with a JCA adapter for an external JMS broker, used both ActiveMQ 5.3.0 and HornetQ 2.0.0, both clustered and standalone. Also tried an embedded HornetQ broker with the same results. Deployed an ear that has a simple MDB requiring container managed transactions listening to a queue with max sessions set to 2 and a simple jsp to publish an arbitrary number of text messages to that queue. The MDB simply prints the text information provided by the message, but also has a hard-coded 1 second pause for every even numbered message. When I shut down JBoss while messages are still being consumed, the BlockContainerShutdownInterceptor starts throwing DispatcherConnectExceptions, as the EJB container has been stopped or is in the process of being stopped. However, it doesn't mark the transaction for rollback itself, and MessageInflowLocalProxy.delivery() only marks the transaction for rollback if the invocation chain throws an Error or RuntimeException. Thus, in this case, JBoss failed to deliver the message to the MDB, but committed the transaction. According to the spec, for an MDB with a container managed transaction, the message should be ACK'd to the broker if the transaction successfully commits, and both the ActiveMQ and HornetQ JCA implementations dutifully do this, resulting in all messages that were attempted to be delivered after the EJB container shutdown being lost. When the BlockContainerShutdownInterceptor detects that the EJB container has been shutdown, it needs to take an action that will ensure the transaction is marked for rollback. After parsing through the code involved in the interceptor chain, I can see a few potential solutions: * Have BlockContainerShutdownInterceptor.invoke() call TxUtil.getTransactionManager().setRollbackOnly() before it would throw a DispatcherConnectException. Probably need to consume any exception thrown from setRollbackOnly() and log it first I suppose, although it's always a bit odd when you get an exception thrown when you intend to throw an exception anyway for a different reason. * Have BlockContainerShutdownInterceptor.invoke() put some state on the Invocation to indicate that delivery is being blocked. MessagingContainer.localInvoke() could then take some action based on this state to ensure the transaction is rolled back, either rolling it back itself or notifying its caller that the transaction should be rolled back. A bit odd here if BlockContainerShutdownInterceptor.invoke() continues to throw an exception, as there would be data about the exception being passed back outside the exception though. * Have MessageInflowLocalProxy handle DispatcherConnectExceptions. It might be better to introduce an additional class, say InvocationInterruptedException that DispatcherConnectException could extend, to allow for the possibility that invocations may be interrupted for other reasons, allowing MessageInflowLocalProxy to not care as much about the particular reason invocation was halted, but still be able to roll back the transaction whenever it is. I slightly favor the third approach based on what I've seen of that portion of the code so far, so I will probably work to put together a patch file along those lines. This is the first time I've delved deeply into the JBoss source code though. If I can find some examples of test cases in this part of the code base, I'll attempt to put together a verifying test case as well. I marked the priority as Critical, based on the guidelines, as this is resulting in data loss and as far as I best understand the spec is a violation of the spec. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

5
6
0 / 0

[JBoss JIRA] (JBJCA-735) Add id attribute to <resource-adapter>

by Jesper Pedersen (JIRA)

Jesper Pedersen created JBJCA-735: ------------------------------------- Summary: Add id attribute to <resource-adapter> Key: JBJCA-735 URL: https://issues.jboss.org/browse/JBJCA-735 Project: IronJacamar Issue Type: Task Components: Common Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: 1.1.0.Alpha5 Add an optional id attribute to the <resource-adapter> definition such that an unique identifier can be given -- 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

12 years, 9 months

1
1
0 / 0

[JBoss JIRA] (JBRULES-3344) MVEL Constraints do not support floating point literals in scientific notation

by Davide Sottara (JIRA)

Davide Sottara created JBRULES-3344: --------------------------------------- Summary: MVEL Constraints do not support floating point literals in scientific notation Key: JBRULES-3344 URL: https://issues.jboss.org/browse/JBRULES-3344 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler Affects Versions: 5.4.0.Beta1 Reporter: Davide Sottara Assignee: Mario Fusco It is not possible to use literals such as 2.5E-3 in constraints, whereas it would be possible if MVEL constraints were disabled. -- 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

12 years, 9 months

2
1
0 / 0

[JBoss JIRA] (AS7-3091) Missing modules for all major sun.jdk paths

by Gary Lamperillo (Created) (JIRA)

Missing modules for all major sun.jdk paths ------------------------------------------- Key: AS7-3091 URL: https://issues.jboss.org/browse/AS7-3091 Project: Application Server 7 Issue Type: Feature Request Affects Versions: 7.1.0.Beta1b Reporter: Gary Lamperillo David Lloyd has a patch which filled in all of the major sun.jdk paths into the System Modules. This patch has never made it upstream. This needs to be brought into AS 7.1 CR1(see Rich Sharples). There is a Customer waiting for this. -- 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

12 years, 9 months

2
1
0 / 0

[JBoss JIRA] (JBLOGGING-77) FileHandler which rolls the file when a system property changes.

by Ondrej Zizka (Created) (JIRA)

FileHandler which rolls the file when a system property changes. ---------------------------------------------------------------- Key: JBLOGGING-77 URL: https://issues.jboss.org/browse/JBLOGGING-77 Project: JBoss Logging Issue Type: Feature Request Security Level: Public (Everyone can see) Components: jboss-logging-jdk Reporter: Ondrej Zizka Assignee: David Lloyd I'd make use of a FileHandler which would roll the file when a system property changes. For use case, see ARQ-710. The handler would have a property called, say, fileNameFormat, which would be a string like: {code} my-server-log-${arq.currentTest}-${arq.containerId}.txt {code} The handler would replace the string every time and compare with previous; when different, it would roll the file. It would not be super efficient but good enough for the purposes of testing. (It would not be the default handler, only configured on demand.) -- 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

12 years, 9 months

6
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2012