[JBoss JIRA] (AS7-4292) Invalid bundle deployment does not fail in domain
by Thomas Diesler (JIRA)
Thomas Diesler created AS7-4292:
-----------------------------------
Summary: Invalid bundle deployment does not fail in domain
Key: AS7-4292
URL: https://issues.jboss.org/browse/AS7-4292
Project: Application Server 7
Issue Type: Bug
Components: Domain Management, OSGi
Reporter: Thomas Diesler
Assignee: Brian Stansberry
Fix For: 7.1.2.Final
Running org.jboss.as.test.integration.domain.suites.OSGiBundleLifecyleTestCase
Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 35.653 sec <<< FAILURE!
on the server I see
{code}
15:20:28,619 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.deployment.unit.bad-bundle.STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit.bad-bundle.STRUCTURE: Failed to process phase STRUCTURE of deployment "bad-bundle"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) [jboss-as-server-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
Caused by: java.lang.NumberFormatException: For input string: "bogus"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) [rt.jar:1.6.0_29]
at java.lang.Integer.parseInt(Integer.java:449) [rt.jar:1.6.0_29]
at java.lang.Integer.parseInt(Integer.java:499) [rt.jar:1.6.0_29]
at org.osgi.framework.Version.<init>(Version.java:125)
at org.osgi.framework.Version.parseVersion(Version.java:218)
at org.jboss.osgi.spi.BundleInfo.validateBundleManifest(BundleInfo.java:204)
at org.jboss.osgi.spi.BundleInfo.isValidBundleManifest(BundleInfo.java:153)
at org.jboss.as.osgi.deployment.OSGiManifestStructureProcessor.deploy(OSGiManifestStructureProcessor.java:63)
{code}
--
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, 5 months
[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, 5 months
[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, 5 months