July 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (LOGMGR-42) StringIndexOutOfBoundsException in exceptionFormatStep

by Marcus Klimstra (JIRA)

Marcus Klimstra created LOGMGR-42: ------------------------------------- Summary: StringIndexOutOfBoundsException in exceptionFormatStep Key: LOGMGR-42 URL: https://issues.jboss.org/browse/LOGMGR-42 Project: JBoss Log Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: core Affects Versions: 1.3.1.Final Reporter: Marcus Klimstra Assignee: David Lloyd StringIndexOutOfBoundsException is thrown when the path does not contain a jarName. In my case path is "/com/.../Foo.class" (from a custom classloader). Stacktrace: java.util.logging.ErrorManager: 5: Formatting error java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.charAt(String.java:686) at org.jboss.logmanager.formatters.Formatters$12.renderExtended(Formatters.java:524) at org.jboss.logmanager.formatters.Formatters$12.renderRaw(Formatters.java:388) at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:150) at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:86) at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:35) at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:49) at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76) at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:290) at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298) at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298) at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298) at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298) at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298) at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298) at org.jboss.logmanager.Logger.logRaw(Logger.java:721) at org.jboss.logmanager.Logger.log(Logger.java:539) The exception occurs here: (last line with while) if (jarName == null) { // OK, that would have been too easy. Next let's just grab the last piece before the class name int endIdx = path.lastIndexOf(classResourceName); if (endIdx != -1) { do { endIdx--; } while (path.charAt(endIdx) == '/' || path.charAt(endIdx) == '\\' || path.charAt(endIdx) == '?'); Since there is nothing before the initial /, endIdx becomes -1. -- 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, 8 months

3
5
0 / 0

[JBoss JIRA] (AS7-2642) No way to grep/more or find a line in the CLI

by Jim Tyrrell (Created) (JIRA)

No way to grep/more or find a line in the CLI --------------------------------------------- Key: AS7-2642 URL: https://issues.jboss.org/browse/AS7-2642 Project: Application Server 7 Issue Type: Feature Request Components: CLI Reporter: Jim Tyrrell Assignee: Alexey Loubyansky In the CLI I should be able to page through the pages of information that are presenting using | more or equivalent. By the same token I should be able to grep to find the one line that I am looking for, when I know what it is I am looking for. -- 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, 8 months

2
1
0 / 0

[JBoss JIRA] (AS7-4985) setting default-web-module from CLI add special chars in xml

by Samuel Tauil (JIRA)

13 years, 8 months

3
5
0 / 0

[JBoss JIRA] (AS7-4479) Expansion of variables in XML descriptors

by Bartosz Baranowski (JIRA)

Bartosz Baranowski created AS7-4479: --------------------------------------- Summary: Expansion of variables in XML descriptors Key: AS7-4479 URL: https://issues.jboss.org/browse/AS7-4479 Project: Application Server 7 Issue Type: Feature Request Affects Versions: 7.1.1.Final Reporter: Bartosz Baranowski Fix For: 7.1.2.Final-redhat1 Currently variable expansion is not supported in all xml descriptors. Some parsers/deployers support this, but each does it on its own. This should be fixed as AS5 and AS6 supports that. Preferably this feature should be centralized in one place. -- 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, 8 months

6
7
0 / 0

[JBoss JIRA] (AS7-4960) JMS destinations' underlying core queues are not manageable

by Jeff Mesnil (JIRA)

Jeff Mesnil created AS7-4960: -------------------------------- Summary: JMS destinations' underlying core queues are not manageable Key: AS7-4960 URL: https://issues.jboss.org/browse/AS7-4960 Project: Application Server 7 Issue Type: Bug Components: JMS Affects Versions: 7.1.2.Final (EAP) Reporter: Jeff Mesnil Assignee: Jeff Mesnil Priority: Minor When a JMS destination is created, we expose it in the management model (in jms-queue) However, creating a JMS destination may also result in the creation of core-queues resources (1 for JMS queues, 1 per subscribers for JMS topics). This core queues are not exposed in the management model. Only those configured in config files or CLI are present. (However we make sure that we add core _addresses_ (1 for each JMS destination) at runtime to the management model) This means that AS7 messaging subsystem is not a "correct" reflection of the HornetQ runtime. I can't make my mind whether it is a problem. Afaict, most operations on these underlying queues can be also done at the JMS destination level through their management operations. -- 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, 8 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-9416) EJB3 SFSB performace problem: parallel calls are sequenced

by Radim Hanus (JIRA)

EJB3 SFSB performace problem: parallel calls are sequenced ---------------------------------------------------------- Key: JBAS-9416 URL: https://issues.jboss.org/browse/JBAS-9416 Project: Legacy JBoss Application Server 6 Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 6.0.0.Final Reporter: Radim Hanus When a client looks up more SFSB of given type in dedicated threads and subsequently calls business methods then such calls are always sequenced. Works fine in jboss-5.1.0 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

9
26
0 / 0

[JBoss JIRA] Created: (AS7-1581) tomcatAuthentication attribute on the AJP connector

by Brett Prucha (JIRA)

tomcatAuthentication attribute on the AJP connector --------------------------------------------------- Key: AS7-1581 URL: https://issues.jboss.org/browse/AS7-1581 Project: Application Server 7 Issue Type: Feature Request Components: Server Affects Versions: 7.0.0.Final Environment: Windows Server 2003 32 bit, IIS 6, tomcat connector 1.2.28 used as an extension Reporter: Brett Prucha Assignee: Jason Greene Priority: Minor In JBoss 5.1.0 I could set the tomcatAuthentication attribute of the AJP connector to false to allow IIS to handle the authentication and pass that along to JBoss. I'm wanting to upgrade to JBoss 7 but unable to set this attribute in version 7.0.0 final to make this work. This attribute is descibed in the tomcat documentation at http://tomcat.apache.org/tomcat-7.0-doc/config/ajp.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

6
8
0 / 0

[JBoss JIRA] Created: (JBAS-9245) Passivation of a @Stateful session bean with an @Inject'ed @Stateless session bean fails with not-serializable error.

by Felix Ullrich (JIRA)

Passivation of a @Stateful session bean with an @Inject'ed @Stateless session bean fails with not-serializable error. --------------------------------------------------------------------------------------------------------------------- Key: JBAS-9245 URL: https://issues.jboss.org/browse/JBAS-9245 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB Affects Versions: 6.0.0.Final Reporter: Felix Ullrich Assignee: Carlo de Wolf I've the same problem described in this issue https://issues.jboss.org/browse/JBAS-8384 Could you please resolve it (maybe in 6.1.0) and dont just close it. Thank you -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

2
7
0 / 0

[JBoss JIRA] Created: (JBAS-9433) JBoss-6.1.0-SNAPSHOT - Adding @WebService causes EJBException "Named query not found"

by Ralf Battenfeld (JIRA)

JBoss-6.1.0-SNAPSHOT - Adding @WebService causes EJBException "Named query not found" ------------------------------------------------------------------------------------- Key: JBAS-9433 URL: https://issues.jboss.org/browse/JBAS-9433 Project: Legacy JBoss Application Server 6 Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB Affects Versions: 6.0.0.Final Environment: Windows Vista 32-bit, JDK 1.6.0_21-b07 Reporter: Ralf Battenfeld Assignee: Carlo de Wolf Attachments: TestNamedQueryException.zip We faced an issue when a webservice annotation is added to a session bean and there are two persistence units defined. All of them are in the same ejb module defined and packed in an ear. The behaviour is not predictable, some times it works but most of the times, not. Without the @Webservice annotation, we don't have deployment issues. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-9391) EJB3.1 spec 4.8.4: destroying singleton because of error during initialization is not honored

by Pierre Kobylanski (JIRA)

EJB3.1 spec 4.8.4: destroying singleton because of error during initialization is not honored --------------------------------------------------------------------------------------------- Key: JBAS-9391 URL: https://issues.jboss.org/browse/JBAS-9391 Project: Legacy JBoss Application Server 6 Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB Affects Versions: 6.0.0.Final Environment: $ uname -a Linux tumlatum 2.6.38-2-686-bigmem #1 SMP Sun May 8 15:43:39 UTC 2011 i686 GNU/Linux Reporter: Pierre Kobylanski Assignee: Carlo de Wolf ejb 3.1 spec [4.8.4 Singleton Error Handling] says that "Errors occurring during Singleton initialization are considered fatal and must result in the discarding of the Singleton instance." I tried to raise a system exception in the @PostConstruct method of a singleton bean. Logs show the deployment error. But I then can access and call the singleton methods. -- Full paragraph 4.8.4: ----------------------------- Errors occurring during Singleton initialization are considered fatal and must result in the discarding of the Singleton instance. Possible initialization errors include injection failure, a system exception thrown from a PostConstruct method, or the failure of a PostConstruct method container-managed transaction to successfully commit. If a singleton fails to initialize, attempted invocations on the Singleton result in an exception as defined by Section 3.4.3 and Section 3.4.4. ------------------------------------------------------ I tested to raise a system exception (throw new RuntimeException()) in the @PostConstruct method. -- Logs show the error ------------------------------- ERROR [AbstractKernelController] Error installing to Start: name=startup-singleton-initiator:topLevelUnit=ts.ear,unit=testSingletonEjb.jar,bean=counter aliases=[startup-singleton-initiator:bean=counter,topLevelUnit=ts.ear,unit=testSingletonEjb.jar] state=Create: java.lang.RuntimeException: Could not invoke PostConstruct on the newly created bean instance at org.jboss.ejb3.singleton.impl.container.SingletonEJBInstanceManagerImpl.create(SingletonEJBInstanceManagerImpl.java:137) [:1.0.0-alpha-28] ... Caused by: testsingleton.exn.SE // class SE extends RuntimeException{} at testsingleton.ejb.CounterEjb.pc(CounterEjb.java:28) DEPLOYMENTS IN ERROR: Deployment "startup-singleton-initiator:topLevelUnit=ts.ear,unit=testSingletonEjb.jar,bean=counter" is in error due to the following reason(s): testsingleton.exn.SE at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:1228) [:2.2.0.GA] ------------------------------------------------------ However, it is after that possible to access the singleton through a JNDI lookup and successfully call its methods. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

2
1
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