January 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-3878) text in "add file logging handler" dialog is a bit confusing.

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/AS7-3878?page=com.atlassian.jira.plugin.s... ] James Perkins closed AS7-3878. ------------------------------ Fix Version/s: (was: 7.1.4.Final (EAP)) Resolution: Out of Date This doesn't seem to be an issue anymore. > text in "add file logging handler" dialog is a bit confusing. > -------------------------------------------------------------- > > Key: AS7-3878 > URL: https://issues.jboss.org/browse/AS7-3878 > Project: Application Server 7 > Issue Type: Enhancement > Components: Logging > Affects Versions: 7.1.0.Final > Environment: ubuntu 11.10 , AS 7.1 Final > Reporter: shay Matasaro > Assignee: James Perkins > Priority: Minor > > adding a new file handler , without a specific path , fails with no indication of error. > Also since the dialog does contain a generic path for log files, not specifying a new one should work > here is the trace from log file > 11:28:25,030 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 21) JBAS014616: Operation ("add") failed - address: ([ > ("subsystem" => "logging"), > ("file-handler" => "hw.log") > ]) - failure description: "JBAS014704: '' is an invalid value for parameter file. Values must have a minimum length of 1 characters" -- 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

1
0
0 / 0

[JBoss JIRA] (JASSIST-178) Binary on Maven Central requires Java 7

by Joern Huxhorn (JIRA)

[ https://issues.jboss.org/browse/JASSIST-178?page=com.atlassian.jira.plugi... ] Joern Huxhorn edited comment on JASSIST-178 at 1/3/13 6:19 PM: --------------------------------------------------------------- Are you sure that 1.6 is correct? I just checked and javassist_3.17.0.jar from the download page requires only 1.4 while 3.17.0 from Maven Central requires 1.7 as reported. Now both javassist_3.17.1.jar from the download page and MC require 1.6. This is fine by me but I wanted to holler anyway since it may have been a mistake that source and target have been set to 1.6 instead of 1.4. was (Author: huxi): Are you sure that 1.6 is correct? I just checked and javassist_3.17.0.jar from the download page required only 1.4 while 3.17.0 from Maven Central requires 1.7 as reported. Now both javassist_3.17.1.jar from the download page and MC require 1.6. This is fine by me but I wanted to holler anyway since it may have been a mistake that source and target have been set to 1.6 instead of 1.4. > Binary on Maven Central requires Java 7 > --------------------------------------- > > Key: JASSIST-178 > URL: https://issues.jboss.org/browse/JASSIST-178 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.17.0-GA > Reporter: Dan Fabulich > Assignee: Shigeru Chiba > Fix For: 3.17.1-GA > > > As discussed in https://issues.jboss.org/browse/JASSIST-163?focusedCommentId=12734189&pag... > The binary uploaded to Maven central http://repo2.maven.org/maven2/org/javassist/javassist/3.17.0-GA/ requires Java 7, breaking backward compatibility with Java 6 and lower. -- 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

1
0
0 / 0

[JBoss JIRA] (JASSIST-178) Binary on Maven Central requires Java 7

by Joern Huxhorn (JIRA)

[ https://issues.jboss.org/browse/JASSIST-178?page=com.atlassian.jira.plugi... ] Joern Huxhorn commented on JASSIST-178: --------------------------------------- Are you sure that 1.6 is correct? I just checked and javassist_3.17.0.jar from the download page required only 1.4 while 3.17.0 from Maven Central requires 1.7 as reported. Now both javassist_3.17.1.jar from the download page and MC require 1.6. This is fine by me but I wanted to holler anyway since it may have been a mistake that source and target have been set to 1.6 instead of 1.4. > Binary on Maven Central requires Java 7 > --------------------------------------- > > Key: JASSIST-178 > URL: https://issues.jboss.org/browse/JASSIST-178 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.17.0-GA > Reporter: Dan Fabulich > Assignee: Shigeru Chiba > Fix For: 3.17.1-GA > > > As discussed in https://issues.jboss.org/browse/JASSIST-163?focusedCommentId=12734189&pag... > The binary uploaded to Maven central http://repo2.maven.org/maven2/org/javassist/javassist/3.17.0-GA/ requires Java 7, breaking backward compatibility with Java 6 and lower. -- 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

1
0
0 / 0

[JBoss JIRA] (AS7-6139) ModelTypeValidator is overly lenient about numeric types

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/AS7-6139?page=com.atlassian.jira.plugin.s... ] Jason Greene commented on AS7-6139: ----------------------------------- IMO we should be exceptionally lenient with floating point conversions. The DMR models were intended to be very liberal about type conversion which makes it easier for various programming languages to access these routines. I think the only additional checking we should consider is just integral ranges. E.g if someone sends a long > MAX_INT || < MIN_INT it's probably ok to error. > 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

1
0
0 / 0

[JBoss JIRA] (AS7-6271) AttributeDefinition subclasses for collection attributes don't handle expressions correctly in validateOperation

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-6271?page=com.atlassian.jira.plugin.s... ] Brian Stansberry reassigned AS7-6271: ------------------------------------- Assignee: Brian Stansberry > AttributeDefinition subclasses for collection attributes don't handle expressions correctly in validateOperation > ---------------------------------------------------------------------------------------------------------------- > > Key: AS7-6271 > URL: https://issues.jboss.org/browse/AS7-6271 > Project: Application Server 7 > Issue Type: Sub-task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 7.2.0.Alpha1 > > > PropertiesAttributeDefinition is inheriting the base AD behavior, which will only convert a String to a ModelType.EXPRESSION if the param ModelNode is ModelType.STRING. This will fail for collection types. -- 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

1
0
0 / 0

[JBoss JIRA] (AS7-6271) AttributeDefinition subclasses for collection attributes don't handle expressions correctly in validateOperation

by Brian Stansberry (JIRA)

Brian Stansberry created AS7-6271: ------------------------------------- Summary: AttributeDefinition subclasses for collection attributes don't handle expressions correctly in validateOperation Key: AS7-6271 URL: https://issues.jboss.org/browse/AS7-6271 Project: Application Server 7 Issue Type: Sub-task Reporter: Brian Stansberry PropertiesAttributeDefinition is inheriting the base AD behavior, which will only convert a String to a ModelType.EXPRESSION if the param ModelNode is ModelType.STRING. This will fail for collection types. -- 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

1
0
0 / 0

[JBoss JIRA] (AS7-6270) DuplicateServiceException when loading different EARs with same embedded WAR name

by Wayne Schroeder (JIRA)

[ https://issues.jboss.org/browse/AS7-6270?page=com.atlassian.jira.plugin.s... ] Wayne Schroeder updated AS7-6270: --------------------------------- Issue Type: Bug (was: Feature Request) > DuplicateServiceException when loading different EARs with same embedded WAR name > --------------------------------------------------------------------------------- > > Key: AS7-6270 > URL: https://issues.jboss.org/browse/AS7-6270 > Project: Application Server 7 > Issue Type: Bug > Components: Web > Affects Versions: 7.1.1.Final > Environment: OSX Lion > Reporter: Wayne Schroeder > Assignee: Remy Maucherat > > Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.security.jacc."web.war" is already registered > I have three EARs, all of which have their own application.xml declaring a contained web.war file in DIFFERENT context roots. The contents of web.war in each EAR are different, it's just our packaging standard to put all the servlets for our projects in web.war. This particular server holds three projects that have a web tier. Now, this can change as a work around (I can change the name of the archive), but I was under the impression, after searching, that you COULD have the same WAR name in different EARs as long as their context roots were declared to be different, which in my case, they definitely are. It seems that the name of the archive is being used as a unique identifier when it should not. > This looks to be an exact duplicate of issue AS7-1281, but it is claimed to be fixed in 7.1.1.Final, but it seems to remain an issue. As a work around, I just renamed the wars in my deployments. -- 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

1
0
0 / 0

[JBoss JIRA] (AS7-4793) Convert ConfigAdmin subsystem to ResourceDefinition

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/AS7-4793?page=com.atlassian.jira.plugin.s... ] Tomaz Cerar updated AS7-4793: ----------------------------- Fix Version/s: 7.2.0.Alpha1 (was: 7.2.0.CR1) > Convert ConfigAdmin subsystem to ResourceDefinition > --------------------------------------------------- > > Key: AS7-4793 > URL: https://issues.jboss.org/browse/AS7-4793 > Project: Application Server 7 > Issue Type: Sub-task > Components: ConfigAdmin, OSGi > Affects Versions: 7.1.1.Final, 7.1.2.Final (EAP) > Reporter: Tomaz Cerar > Assignee: Kabir Khan > Fix For: 7.2.0.Alpha1 > > > Convert ConfigAdmin subsystem to use ResourceDefinition and AttributeDefinition -- 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

1
0
0 / 0

[JBoss JIRA] (AS7-4801) Convert osgi subsystem to ResourceDefinition

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/AS7-4801?page=com.atlassian.jira.plugin.s... ] Tomaz Cerar updated AS7-4801: ----------------------------- Fix Version/s: 7.2.0.Alpha1 (was: 7.2.0.CR1) > Convert osgi subsystem to ResourceDefinition > -------------------------------------------- > > Key: AS7-4801 > URL: https://issues.jboss.org/browse/AS7-4801 > Project: Application Server 7 > Issue Type: Sub-task > Components: OSGi > Affects Versions: 7.1.1.Final, 7.1.2.Final (EAP) > Reporter: Tomaz Cerar > Assignee: Kabir Khan > Fix For: 7.2.0.Alpha1 > > > Convert subsystem to use ResourceDefinition and AttributeDefinition -- 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

1
0
0 / 0

[JBoss JIRA] (AS7-6270) DuplicateServiceException when loading different EARs with same embedded WAR name

by Wayne Schroeder (JIRA)

Wayne Schroeder created AS7-6270: ------------------------------------ Summary: DuplicateServiceException when loading different EARs with same embedded WAR name Key: AS7-6270 URL: https://issues.jboss.org/browse/AS7-6270 Project: Application Server 7 Issue Type: Feature Request Components: Web Affects Versions: 7.1.1.Final Environment: OSX Lion Reporter: Wayne Schroeder Assignee: Remy Maucherat Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.security.jacc."web.war" is already registered I have three EARs, all of which have their own application.xml declaring a contained web.war file in DIFFERENT context roots. The contents of web.war in each EAR are different, it's just our packaging standard to put all the servlets for our projects in web.war. This particular server holds three projects that have a web tier. Now, this can change as a work around (I can change the name of the archive), but I was under the impression, after searching, that you COULD have the same WAR name in different EARs as long as their context roots were declared to be different, which in my case, they definitely are. It seems that the name of the archive is being used as a unique identifier when it should not. This looks to be an exact duplicate of issue AS7-1281, but it is claimed to be fixed in 7.1.1.Final, but it seems to remain an issue. As a work around, I just renamed the wars in my deployments. -- 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

1
0
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 January 2013