[JBoss JIRA] (AS7-6273) Unable to start jboss AS on windows if installed on path containig non-ascii characters
by Ales Kolenc (JIRA)
Ales Kolenc created AS7-6273:
--------------------------------
Summary: Unable to start jboss AS on windows if installed on path containig non-ascii characters
Key: AS7-6273
URL: https://issues.jboss.org/browse/AS7-6273
Project: Application Server 7
Issue Type: Bug
Components: Server
Affects Versions: 7.1.1.Final
Environment: windows 2008 x64
Reporter: Ales Kolenc
Assignee: Jason Greene
1.) Install jboss into a folder containing non-ascii characters. (i.e. "C:\Testチ").
2.) run standalone.bat
C:\Test?\jboss-as-7.1.1.Final\bin>set JAVA_HOME=C:\Program Files\Java\jre7
C:\Test?\jboss-as-7.1.1.Final\bin>standalone.bat
Calling "C:\Test?\jboss-as-7.1.1.Final\bin\standalone.conf.bat"
===============================================================================
JBoss Bootstrap Environment
JBOSS_HOME: C:\Test?\jboss-as-7.1.1.Final
JAVA: C:\Program Files\Java\jre7\bin\java
JAVA_OPTS: -XX:+TieredCompilation -Dprogram.name=standalone.bat -Xms64M -Xmx512M -XX:MaxPermSize=256M -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djb
oss.server.default.config=standalone.xml
===============================================================================
Error: Unable to access jarfile C:\Test?\jboss-as-7.1.1.Final\jboss-modules.jar
Press any key to continue . . .
C:\Test?\jboss-as-7.1.1.Final\bin>
3.) pleas note that: "Testチ" used in path -> 'チ' does not bellong to system locale code page. E.g.: char 'チ' is in CP 932, system locale code page used 437/1252,..
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-6272) It is not possible to enable AtomicActionExpiryScanner in EAP 6.x
by Tom Ross (JIRA)
[ https://issues.jboss.org/browse/AS7-6272?page=com.atlassian.jira.plugin.s... ]
Tom Ross updated AS7-6272:
--------------------------
Description:
It should be possible to add AtomicActionExpiryScanner to the EAP 6 configuration as outline below:
{noformat}
<system-properties>
<property name="RecoveryEnvironmentBean.expiryScannerClassNames" value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner\\s+com.arjuna.ats.internal.arjuna.recovery.AtomicActionExpiryScanner"/>
</system-properties>
{noformat}
Unfortunately the value of the RecoveryEnvironmentBean.expiryScannerClassNames seems to be overwritten in the ArjunaRecoveryManagerService class. As a result there is no way easy way of removing transaction manager debris from object store.
was:
It should be possible to add AtomicActionExpiryScanner to the EAP 6 configuration as outline below:
{noformat}
<system-properties>
<property name="RecoveryEnvironmentBean.expiryScannerClassNames" value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner\\s+com.arjuna.ats.internal.arjuna.recovery.AtomicActionExpiryScanner"/>
</system-properties>
{noformat}
Unfortunately it seems that the value of the RecoveryEnvironmentBean.expiryScannerClassNames seems to be overwritten in the ArjunaRecoveryManagerService class. As a result there is no way easy way of removing transaction manager debris from object store.
> It is not possible to enable AtomicActionExpiryScanner in EAP 6.x
> -----------------------------------------------------------------
>
> Key: AS7-6272
> URL: https://issues.jboss.org/browse/AS7-6272
> Project: Application Server 7
> Issue Type: Bug
> Components: ConfigAdmin
> Affects Versions: 7.1.3.Final (EAP)
> Environment: JBoss EAP 6.01
> Reporter: Tom Ross
> Assignee: David Bosschaert
>
> It should be possible to add AtomicActionExpiryScanner to the EAP 6 configuration as outline below:
> {noformat}
> <system-properties>
> <property name="RecoveryEnvironmentBean.expiryScannerClassNames" value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner\\s+com.arjuna.ats.internal.arjuna.recovery.AtomicActionExpiryScanner"/>
> </system-properties>
> {noformat}
> Unfortunately the value of the RecoveryEnvironmentBean.expiryScannerClassNames seems to be overwritten in the ArjunaRecoveryManagerService class. As a result there is no way easy way of removing transaction manager debris from object store.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-6272) It is not possible to enable AtomicActionExpiryScanner in EAP 6.x
by Tom Ross (JIRA)
[ https://issues.jboss.org/browse/AS7-6272?page=com.atlassian.jira.plugin.s... ]
Tom Ross updated AS7-6272:
--------------------------
Description:
It should be possible to add AtomicActionExpiryScanner to the EAP 6 configuration as outline below:
{noformat}
<system-properties>
<property name="RecoveryEnvironmentBean.expiryScannerClassNames" value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner\\s+com.arjuna.ats.internal.arjuna.recovery.AtomicActionExpiryScanner"/>
</system-properties>
{noformat}
Unfortunately the value of the RecoveryEnvironmentBean.expiryScannerClassNames seems to be overwritten in the ArjunaRecoveryManagerService class. As a result there is no easy way of removing transaction manager debris from object store.
was:
It should be possible to add AtomicActionExpiryScanner to the EAP 6 configuration as outline below:
{noformat}
<system-properties>
<property name="RecoveryEnvironmentBean.expiryScannerClassNames" value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner\\s+com.arjuna.ats.internal.arjuna.recovery.AtomicActionExpiryScanner"/>
</system-properties>
{noformat}
Unfortunately the value of the RecoveryEnvironmentBean.expiryScannerClassNames seems to be overwritten in the ArjunaRecoveryManagerService class. As a result there is no way easy way of removing transaction manager debris from object store.
> It is not possible to enable AtomicActionExpiryScanner in EAP 6.x
> -----------------------------------------------------------------
>
> Key: AS7-6272
> URL: https://issues.jboss.org/browse/AS7-6272
> Project: Application Server 7
> Issue Type: Bug
> Components: ConfigAdmin
> Affects Versions: 7.1.3.Final (EAP)
> Environment: JBoss EAP 6.01
> Reporter: Tom Ross
> Assignee: David Bosschaert
>
> It should be possible to add AtomicActionExpiryScanner to the EAP 6 configuration as outline below:
> {noformat}
> <system-properties>
> <property name="RecoveryEnvironmentBean.expiryScannerClassNames" value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner\\s+com.arjuna.ats.internal.arjuna.recovery.AtomicActionExpiryScanner"/>
> </system-properties>
> {noformat}
> Unfortunately the value of the RecoveryEnvironmentBean.expiryScannerClassNames seems to be overwritten in the ArjunaRecoveryManagerService class. As a result there is no easy way of removing transaction manager debris from object store.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-6272) It is not possible to enable AtomicActionExpiryScanner in EAP 6.x
by Tom Ross (JIRA)
[ https://issues.jboss.org/browse/AS7-6272?page=com.atlassian.jira.plugin.s... ]
Tom Ross updated AS7-6272:
--------------------------
Description:
It should be possible to add AtomicActionExpiryScanner to the EAP 6 configuration as outline below:
{noformat}
<system-properties>
<property name="RecoveryEnvironmentBean.expiryScannerClassNames" value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner\\s+com.arjuna.ats.internal.arjuna.recovery.AtomicActionExpiryScanner"/>
</system-properties>
{noformat}
Unfortunately it seems that the value of the RecoveryEnvironmentBean.expiryScannerClassNames seems to be overwritten in the ArjunaRecoveryManagerService class. As a result there is no way easy way of removing transaction manager debris from object store.
was:
It should be possible to add AtomicActionExpiryScanner to the EAP 6 configuration as outline below:
<system-properties>
<property name="RecoveryEnvironmentBean.expiryScannerClassNames" value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner\\s+com.arjuna.ats.internal.arjuna.recovery.AtomicActionExpiryScanner"/>
</system-properties>
Unfortunately it seems that the value of the RecoveryEnvironmentBean.expiryScannerClassNames seems to be overwritten in the ArjunaRecoveryManagerService class. As a result there is no way easy way of removing transaction manager debris from object store.
> It is not possible to enable AtomicActionExpiryScanner in EAP 6.x
> -----------------------------------------------------------------
>
> Key: AS7-6272
> URL: https://issues.jboss.org/browse/AS7-6272
> Project: Application Server 7
> Issue Type: Bug
> Components: ConfigAdmin
> Affects Versions: 7.1.3.Final (EAP)
> Environment: JBoss EAP 6.01
> Reporter: Tom Ross
> Assignee: David Bosschaert
>
> It should be possible to add AtomicActionExpiryScanner to the EAP 6 configuration as outline below:
> {noformat}
> <system-properties>
> <property name="RecoveryEnvironmentBean.expiryScannerClassNames" value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner\\s+com.arjuna.ats.internal.arjuna.recovery.AtomicActionExpiryScanner"/>
> </system-properties>
> {noformat}
> Unfortunately it seems that the value of the RecoveryEnvironmentBean.expiryScannerClassNames seems to be overwritten in the ArjunaRecoveryManagerService class. As a result there is no way easy way of removing transaction manager debris from object store.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-6272) It is not possible to enable AtomicActionExpiryScanner in EAP 6.x
by Tom Ross (JIRA)
Tom Ross created AS7-6272:
-----------------------------
Summary: It is not possible to enable AtomicActionExpiryScanner in EAP 6.x
Key: AS7-6272
URL: https://issues.jboss.org/browse/AS7-6272
Project: Application Server 7
Issue Type: Bug
Components: ConfigAdmin
Affects Versions: 7.1.3.Final (EAP)
Environment: JBoss EAP 6.01
Reporter: Tom Ross
Assignee: David Bosschaert
It should be possible to add AtomicActionExpiryScanner to the EAP 6 configuration as outline below:
<system-properties>
<property name="RecoveryEnvironmentBean.expiryScannerClassNames" value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner\\s+com.arjuna.ats.internal.arjuna.recovery.AtomicActionExpiryScanner"/>
</system-properties>
Unfortunately it seems that the value of the RecoveryEnvironmentBean.expiryScannerClassNames seems to be overwritten in the ArjunaRecoveryManagerService class. As a result there is no way easy way of removing transaction manager debris from object store.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-6139) ModelTypeValidator is overly lenient about numeric types
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/AS7-6139?page=com.atlassian.jira.plugin.s... ]
Chao Wang commented on AS7-6139:
--------------------------------
As we don't know the exact typed value, I have to use a double swtich-case clause to get the real value and boundary value for checking for each validType and value.type, or should we detect it from DMR asXXX() method before cast values and return?
> ModelTypeValidator is overly lenient about numeric types
> --------------------------------------------------------
>
> Key: AS7-6139
> URL: https://issues.jboss.org/browse/AS7-6139
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Brian Stansberry
> Assignee: Chao Wang
> Priority: Minor
> Attachments: AS7-6139.patch
>
>
> ModelTypeValidator does some conversion checks to see if a passed in ModelNode meets the requirements of the valid type. These checks are overly lenient when it comes to numeric types as they rely only on the ModelNode.asXXX() methods not failing. But those methods don't fail even if the conversion involves a narrowing.
> For example, calling new ModelNode(Long.MAX_LONG).asInt() will not fail, but if the user passed in such a value for use in an attribute of type INT the stored value would not be what was expected.
> Note this is minor as in many, many cases ModelTypeValidator subclasses like IntRangeValidator are used, and those subclasses enforce ranges.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (JBJCA-955) Add an interface to allow end-user to have a second chance to create a normal database connection after failling to get connection because of database password error
by Yaguo Zhou (JIRA)
Yaguo Zhou created JBJCA-955:
--------------------------------
Summary: Add an interface to allow end-user to have a second chance to create a normal database connection after failling to get connection because of database password error
Key: JBJCA-955
URL: https://issues.jboss.org/browse/JBJCA-955
Project: IronJacamar
Issue Type: Feature Request
Components: JDBC
Reporter: Yaguo Zhou
Assignee: Jesper Pedersen
When an application can't get a database connection through jca layer due to database password error, it's better to add an extension point in IronJacamar's datasource implementation to allow user'program to "implements". user can get the correct password from another server(our own server which stores the correct password), and then get and return a normal database connection to IronJacamar. This solution's advantage is that we don't need to restart jboss application server when database password is changed (may be due to security reasons)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-5991) It’s impossible to set a custom pattern string for the handler’s formatter via CLI or native configuration API
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/AS7-5991?page=com.atlassian.jira.plugin.s... ]
James Perkins closed AS7-5991.
------------------------------
Fix Version/s: 7.2.0.Alpha1
(was: 7.2.0.CR1)
Resolution: Out of Date
This is fixed with removing the services from the logging subsystem. If a patch needs to be made for older version, please reopen and I will work up a fix for it.
> It’s impossible to set a custom pattern string for the handler’s formatter via CLI or native configuration API
> --------------------------------------------------------------------------------------------------------------
>
> Key: AS7-5991
> URL: https://issues.jboss.org/browse/AS7-5991
> Project: Application Server 7
> Issue Type: Bug
> Components: Logging
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Radoslav Rangelov
> Assignee: James Perkins
> Fix For: 7.2.0.Alpha1
>
>
> It’s impossible to set a custom pattern string for the handler’s formatter via CLI or native configuration API. The default value for the pattern is always used - not the specified one. The stored configuration in domain.xml is ok but runtime setting of the pattern doesn’t work. I need to restart JBoss to apply the changes.
> The configuration in domain.xml file works fine during startup:
> <formatter>
> <pattern-formatter pattern="custom pattern string"/>
> </formatter>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months