February 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (AS7-1000) One thousand issues!

by David Lloyd (JIRA)

One thousand issues! -------------------- Key: AS7-1000 URL: https://issues.jboss.org/browse/AS7-1000 Project: Application Server 7 Issue Type: Epic Reporter: David Lloyd Happy birthday? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

3
4
0 / 0

[JBoss JIRA] (JBJCA-731) Eclipse plugin for Ironjacamar

by Jeff Zhang (JIRA)

Jeff Zhang created JBJCA-731: -------------------------------- Summary: Eclipse plugin for Ironjacamar Key: JBJCA-731 URL: https://issues.jboss.org/browse/JBJCA-731 Project: IronJacamar Issue Type: Task Components: Eclipse Reporter: Jeff Zhang Assignee: Jeff Zhang Fix For: 1.0.8.Final -- 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, 10 months

2
3
0 / 0

[JBoss JIRA] (JBCLUSTER-297) HASingleton custom election policy isn't called with only one member

by James Livingston (JIRA)

James Livingston created JBCLUSTER-297: ------------------------------------------ Summary: HASingleton custom election policy isn't called with only one member Key: JBCLUSTER-297 URL: https://issues.jboss.org/browse/JBCLUSTER-297 Project: JBoss Clustering Issue Type: Bug Security Level: Public (Everyone can see) Components: HA-Server-API Affects Versions: HA-Server-API 1.2.0.Final Reporter: James Livingston Assignee: Paul Ferraro This is a backport of AS7-3295 to 5.x's clustering code. A custom HASingleton election policy is not called when there is only one member in the cluster. The hard-coded check for size == 1 should be removed, and the custom policy should always be called. This bug prevents policies that do not start HASingletons if a quorum is not reached. -- 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, 10 months

2
3
0 / 0

[JBoss JIRA] Created: (JGRP-1355) Enhance ExecutionRunner to allow for better extensibility and safe shut down

by William Burns (JIRA)

Enhance ExecutionRunner to allow for better extensibility and safe shut down ---------------------------------------------------------------------------- Key: JGRP-1355 URL: https://issues.jboss.org/browse/JGRP-1355 Project: JGroups Issue Type: Enhancement Affects Versions: 2.12.1 Reporter: William Burns Assignee: Bela Ban Fix For: 3.0 The ExecutionRunner class which is used for running distributed tasks currently doesn't allow for nice extensibility. This is caused due to no real hook points or callbacks to add additional local functionality if a user desires. One such functionality may be to automatically rollback or commit a local database transaction after the task is finished. This would allow for calling code to not have to care about transactional awareness and be more usuable across a target suite. Also today there is no nice way of shutting down an ExecutionRunner, it is done today purely with interrupts, and if a task is currently running this will receive an interrupt request which could be problematic. We should have a way so that when an ExecutionRunner is interrupted that it will shutdown only after finishing the current request or immediately if there is no request. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

3
8
0 / 0

[JBoss JIRA] Created: (JBVFS-166) Deployment archives that are symlinks do not get cached properly when jboss.vfs.forceCanonical is set to 'true'

by Mike Clark (JIRA)

Deployment archives that are symlinks do not get cached properly when jboss.vfs.forceCanonical is set to 'true' --------------------------------------------------------------------------------------------------------------- Key: JBVFS-166 URL: https://jira.jboss.org/browse/JBVFS-166 Project: JBoss VFS Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.0.GA Reporter: Mike Clark Assignee: John Bailey When a deployment, such as an .ear file, is a symlink and the jboss.vfs.forceCanonical property is set to "true" to address JBVFS-137, the deployment fails to be properly cached leading to an ever increasing vfs-nested.tmp directory. JBVFS-137 addresses the problem that permanentRoots in the VFSCache get set according to their canonical path by the URL PropertyEditor. Without the fix, if the deployment directory is a symlink, it will be stored in the cache using a different path than lookups will use. To correct this, when checking for items in the cache, the canonical path must be used, or else there will not be a match. Setting the jboss.vfs.forceCanonical property enables conversion of the deployment's path to a canonical path for this purpose. However, in the case of a deployment that is a symbolic link within the deploy directory (i.e., someApp.ear is itself a symbolic link), there is no initial modification of the path to a canonical path. (Because the URL is not being set via a PropertyEditor.) So, it is stored based on the non-canonical path. But, with jboss.vfs.forceCanonical set to true, the lookup is based on the canonical path, which doesn't match. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

3
7
0 / 0

[JBoss JIRA] Created: (JBRULES-3229) Stack overflow using recursive types

by Michael Anstis (JIRA)

Stack overflow using recursive types ------------------------------------ Key: JBRULES-3229 URL: https://issues.jboss.org/browse/JBRULES-3229 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Michael Anstis Assignee: Edson Tirelli The following DRL produces a stack overflow in org.drools.compiler.PackageBuilder$Node.accept(PackageBuilder.java:2684):- package com.sample declare Type child: Type end rule "test" when Type( ) then end -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

3
13
0 / 0

[JBoss JIRA] (AS7-3950) Add role handling with --silent mode into AddPropertiesUser (add-user.sh)

by Tomohisa igarashi (JIRA)

Tomohisa igarashi created AS7-3950: -------------------------------------- Summary: Add role handling with --silent mode into AddPropertiesUser (add-user.sh) Key: AS7-3950 URL: https://issues.jboss.org/browse/AS7-3950 Project: Application Server 7 Issue Type: Feature Request Components: Domain Management Affects Versions: 7.1.0.Final Reporter: Tomohisa igarashi Assignee: Brian Stansberry When I add a user using AddPropertiesUser with --silent, there is no way to handle the role of that user right now. -- 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, 10 months

5
16
0 / 0

[JBoss JIRA] (AS7-3641) Lock down HornetQ default cluster user

by Justin Bertram (JIRA)

Justin Bertram created AS7-3641: ----------------------------------- Summary: Lock down HornetQ default cluster user Key: AS7-3641 URL: https://issues.jboss.org/browse/AS7-3641 Project: Application Server 7 Issue Type: Bug Reporter: Justin Bertram Assignee: Justin Bertram The HornetQ default cluster user is a security hole. AS7 should plug this hole when it starts HornetQ. -- 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, 10 months

2
5
0 / 0

[JBoss JIRA] Created: (AS7-1877) cd to subsystems that don't exist

by Bill Meyer (JIRA)

cd to subsystems that don't exist --------------------------------- Key: AS7-1877 URL: https://issues.jboss.org/browse/AS7-1877 Project: Application Server 7 Issue Type: Bug Components: CLI Affects Versions: 7.0.1.Final Environment: JBoss AS 7.0.1 CLI interface Reporter: Bill Meyer Assignee: Alexey Loubyansky The CLI utility allows you to cd to subsystems (one example) that don't exist. For example, (yes the jms subsystem was merged into the messaging subsystem), if I execute the following: [standalone@localhost:9999 /] pwd / [standalone@localhost:9999 /] cd /subsystem=jms [standalone@localhost:9999 subsystem=jms] ls [standalone@localhost:9999 subsystem=jms] I get no error message that I've cd'd into something that doesn't exist. Internal JBoss SAs have done some useability testing and agree that this is very confusing functionality. Either an error message should be displayed preventing you from executing the cd command, or some sort of feedback needs to be provided as to why this is expected behavior. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

3
2
0 / 0

[JBoss JIRA] (JBLOGGING-78) SMTPAppender Not sending mails

by Nisha Suresh (JIRA)

Nisha Suresh created JBLOGGING-78: ------------------------------------- Summary: SMTPAppender Not sending mails Key: JBLOGGING-78 URL: https://issues.jboss.org/browse/JBLOGGING-78 Project: JBoss Logging Issue Type: Task Security Level: Public (Everyone can see) Components: jboss-logging-log4j Environment: JDK1.6 Reporter: Nisha Suresh Assignee: David Lloyd I have enabled the SMTPAppender for threshold level "ERROR". After that when an error occurs in the application the server.log is showing like: 2012-01-27 14:20:58,565 FINE [javax.activation] (http-127.0.0.1-8090-1) MailcapCommandMap: createDataContentHandler for text/plain 2012-01-27 14:20:58,565 FINE [javax.activation] (http-127.0.0.1-8090-1) search DB #1 2012-01-27 14:20:58,565 FINE [javax.activation] (http-127.0.0.1-8090-1) got content-handler 2012-01-27 14:20:58,565 FINE [javax.activation] (http-127.0.0.1-8090-1) class com.sun.mail.handlers.text_plain No other mail sending errors are shown. What does this log actually means? Why the mails are not getting send? -- 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, 10 months

2
2
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 February 2012