[JBoss JIRA] (AS7-5631) add-user script confusing error: Password must not have atleast one digit.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/AS7-5631?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated AS7-5631:
----------------------------------
Comment: was deleted
(was: yes jboss requires at least a numeric value in the password)
> add-user script confusing error: Password must not have atleast one digit.
> --------------------------------------------------------------------------
>
> Key: AS7-5631
> URL: https://issues.jboss.org/browse/AS7-5631
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 7.2.0.Alpha1
> Reporter: Cheng Fang
> Assignee: Ondrej Zizka
> Fix For: 7.2.0.CR1
>
>
> when running add-user.sh to add an application user, and entering a weal password, got the following error:
> Password :
> Re-enter Password :
> What roles do you want this user to belong to? (Please enter a comma separated list, or leave blank for none)[ ]:
> * Error *
> JBAS015266: Password must not have atleast one digit.
> I guess what it meant is password must have at least one digit.
> A search showed the following files referencing this message:
> ./domain-management/src/main/java/org/jboss/as/domain/management/DomainManagementMessages.java
> This file also contains some other typo like "atleast".
--
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-6254) Memory leak caused by retained connection ids in RemotingConnectorServer superclass
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/AS7-6254?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated AS7-6254:
----------------------------------
Fix Version/s: 7.2.0.Alpha1
> Memory leak caused by retained connection ids in RemotingConnectorServer superclass
> ------------------------------------------------------------------------------------
>
> Key: AS7-6254
> URL: https://issues.jboss.org/browse/AS7-6254
> Project: Application Server 7
> Issue Type: Bug
> Components: JMX
> Affects Versions: 7.1.1.Final, 7.1.3.Final (EAP)
> Reporter: Taras Tielkes
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 7.2.0.Alpha1
>
>
> We're running 7.1.1, with a patch applied for REMJMX-45 to limit the worst leaks coming from the JMX subsystem.
> However, even with this patch applied we can only survive for a few days in a production-like scenario.
> It seems that {{org.jboss.remotingjmx.RemotingConnectorServer}} never calls the {{connectionClosed()}}/{{connectionFailed()}} methods in its superclass.
> As such, the connection ids that are stored in the field {{javax.management.remote.JMXConnectorServer#connectionIds}} are never released.
> Given sufficient connections made to a running instance of 7.1.1 (for example, various monitoring tools), an out-of-memory end-state is inevitable.
--
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 reassigned AS7-6139:
------------------------------
Assignee: Chao Wang
> 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] (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:
--------------------------------
thanks for these tips, I'll change it and send a pull request soon.
> 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
> 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] (AS7-6254) Memory leak caused by retained connection ids in RemotingConnectorServer superclass
by Taras Tielkes (JIRA)
[ https://issues.jboss.org/browse/AS7-6254?page=com.atlassian.jira.plugin.s... ]
Taras Tielkes commented on AS7-6254:
------------------------------------
The compressed hprof heap snapshot is ~80 MB. If there is a Jboss FTP server I ca upload it to, let me know where to find it.
> Memory leak caused by retained connection ids in RemotingConnectorServer superclass
> ------------------------------------------------------------------------------------
>
> Key: AS7-6254
> URL: https://issues.jboss.org/browse/AS7-6254
> Project: Application Server 7
> Issue Type: Bug
> Components: JMX
> Affects Versions: 7.1.1.Final, 7.1.3.Final (EAP)
> Reporter: Taras Tielkes
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> We're running 7.1.1, with a patch applied for REMJMX-45 to limit the worst leaks coming from the JMX subsystem.
> However, even with this patch applied we can only survive for a few days in a production-like scenario.
> It seems that {{org.jboss.remotingjmx.RemotingConnectorServer}} never calls the {{connectionClosed()}}/{{connectionFailed()}} methods in its superclass.
> As such, the connection ids that are stored in the field {{javax.management.remote.JMXConnectorServer#connectionIds}} are never released.
> Given sufficient connections made to a running instance of 7.1.1 (for example, various monitoring tools), an out-of-memory end-state is inevitable.
--
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-6254) Memory leak caused by retained connection ids in RemotingConnectorServer superclass
by Taras Tielkes (JIRA)
[ https://issues.jboss.org/browse/AS7-6254?page=com.atlassian.jira.plugin.s... ]
Taras Tielkes edited comment on AS7-6254 at 1/2/13 3:32 PM:
------------------------------------------------------------
The compressed hprof heap snapshot is ~80 MB. If there is a Jboss FTP server I can upload it to, let me know how to reach it.
was (Author: taras.tielkes):
The compressed hprof heap snapshot is ~80 MB. If there is a Jboss FTP server I ca upload it to, let me know where to find it.
> Memory leak caused by retained connection ids in RemotingConnectorServer superclass
> ------------------------------------------------------------------------------------
>
> Key: AS7-6254
> URL: https://issues.jboss.org/browse/AS7-6254
> Project: Application Server 7
> Issue Type: Bug
> Components: JMX
> Affects Versions: 7.1.1.Final, 7.1.3.Final (EAP)
> Reporter: Taras Tielkes
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> We're running 7.1.1, with a patch applied for REMJMX-45 to limit the worst leaks coming from the JMX subsystem.
> However, even with this patch applied we can only survive for a few days in a production-like scenario.
> It seems that {{org.jboss.remotingjmx.RemotingConnectorServer}} never calls the {{connectionClosed()}}/{{connectionFailed()}} methods in its superclass.
> As such, the connection ids that are stored in the field {{javax.management.remote.JMXConnectorServer#connectionIds}} are never released.
> Given sufficient connections made to a running instance of 7.1.1 (for example, various monitoring tools), an out-of-memory end-state is inevitable.
--
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 Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6139?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry commented on AS7-6139:
---------------------------------------
That should work, yes. Some suggestions:
1) The matches() method should immediately return 'true' if validType == value.getType(). That would be more efficient even with the current code, but with the string manipulation this patch adds, it becomes more important. This method gets invoked a lot during boot, so we want high performance.
With this change, the default case can be changed to return false; since the if test will have already done what the default case is doing now.
2) Minor: Please convert the
if (x.compareTo(y) != 0) return false;
return true;
to
return x.compareTo(y) == 0;
Otherwise our IDEs will suggest we make that change and won't give us the nice "Green" icon for the file until we do. :)
3) Really minor: checkNumericType(value, type); can get the type from "value"; it doesn't need to be a param. Or, if you keep the type from the test in my 1) above you can just use it and not get it again in each case of the switch.
> 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
> 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] (AS7-6254) Memory leak caused by retained connection ids in RemotingConnectorServer superclass
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6254?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-6254:
----------------------------------
Priority: Blocker (was: Major)
Assignee: Darran Lofthouse (was: Stuart Douglas)
> Memory leak caused by retained connection ids in RemotingConnectorServer superclass
> ------------------------------------------------------------------------------------
>
> Key: AS7-6254
> URL: https://issues.jboss.org/browse/AS7-6254
> Project: Application Server 7
> Issue Type: Bug
> Components: JMX
> Affects Versions: 7.1.1.Final, 7.1.3.Final (EAP)
> Reporter: Taras Tielkes
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> We're running 7.1.1, with a patch applied for REMJMX-45 to limit the worst leaks coming from the JMX subsystem.
> However, even with this patch applied we can only survive for a few days in a production-like scenario.
> It seems that {{org.jboss.remotingjmx.RemotingConnectorServer}} never calls the {{connectionClosed()}}/{{connectionFailed()}} methods in its superclass.
> As such, the connection ids that are stored in the field {{javax.management.remote.JMXConnectorServer#connectionIds}} are never released.
> Given sufficient connections made to a running instance of 7.1.1 (for example, various monitoring tools), an out-of-memory end-state is inevitable.
--
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-3177) Method expression parameters causes MethodNotFoundException
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-3177?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry commented on AS7-3177:
---------------------------------------
If you are seeing what looks like a regression in 7.1.3, please file a separate JIRA. Thanks.
> Method expression parameters causes MethodNotFoundException
> -----------------------------------------------------------
>
> Key: AS7-3177
> URL: https://issues.jboss.org/browse/AS7-3177
> Project: Application Server 7
> Issue Type: Bug
> Affects Versions: 7.1.0.CR1b
> Reporter: Stian Thorgersen
> Assignee: Remy Maucherat
> Fix For: 7.1.0.Final
>
>
> I have a web app that works in 7.0.2.Final, but doesn't work in 7.1.0.CR1b. The problem seems to be that method expression parameters no longer works. When trying to invoke a method with parameters the following exception is thrown:
> {code}
> 21:08:22,931 WARNING [javax.enterprise.resource.webcontainer.jsf.lifecycle] (http-localhost-127.0.0.1-8080-5) #{activeActions.select(active.parentId)}: java.lang.NullPointerException: javax.faces.FacesException: #{activeActions.select(active.serviceAgreement.parentId)}: java.lang.NullPointerException
> at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:110) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]
> at javax.faces.component.UICommand.broadcast(UICommand.java:315) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
> at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:794) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
> at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1259) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
> at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]
> at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.7.Final.jar:]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.7.Final.jar:]
> at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:62) [weld-core-1.1.4.Final.jar:2011-11-22 20:01]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.7.Final.jar:]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.7.Final.jar:]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.7.Final.jar:]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.7.Final.jar:]
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:489) [jbossweb-7.0.7.Final.jar:]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:151) [jboss-as-web-7.1.0.CR1b.jar:7.1.0.CR1b]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.7.Final.jar:]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.7.Final.jar:]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.7.Final.jar:]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.7.Final.jar:]
> at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:897) [jbossweb-7.0.7.Final.jar:]
> at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626) [jbossweb-7.0.7.Final.jar:]
> at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2033) [jbossweb-7.0.7.Final.jar:]
> at java.lang.Thread.run(Thread.java:679) [:1.6.0_23]
> Caused by: javax.faces.el.MethodNotFoundException: java.lang.NullPointerException
> at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:104) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
> at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]
> ... 24 more
> Caused by: java.lang.NullPointerException
> at java.lang.Class.isAssignableFrom(Native Method) [:1.6.0_23]
> at org.apache.el.util.ReflectionUtil.isAssignableFrom(ReflectionUtil.java:299) [jbossweb-7.0.7.Final.jar:]
> at org.apache.el.util.ReflectionUtil.getMethod(ReflectionUtil.java:172) [jbossweb-7.0.7.Final.jar:]
> at org.apache.el.parser.AstValue.invoke(AstValue.java:251) [jbossweb-7.0.7.Final.jar:]
> at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:278) [jbossweb-7.0.7.Final.jar:]
> at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:39) [weld-core-1.1.4.Final.jar:2011-11-22 20:01]
> at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-1.1.4.Final.jar:2011-11-22 20:01]
> at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]
> at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:88) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
> ... 25 more
> {code}
--
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-6264) AS7.1 Class loading causes an issue with netty and application deployment
by Michael Erdmann (JIRA)
[ https://issues.jboss.org/browse/AS7-6264?page=com.atlassian.jira.plugin.s... ]
Michael Erdmann closed AS7-6264.
--------------------------------
Most likely i will come back but for time beeing closed.
> AS7.1 Class loading causes an issue with netty and application deployment
> -------------------------------------------------------------------------
>
> Key: AS7-6264
> URL: https://issues.jboss.org/browse/AS7-6264
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Class Loading
> Affects Versions: 7.1.1.Final
> Environment: Linux Open Suse
> Reporter: Michael Erdmann
> Assignee: David Lloyd
> Labels: jboss
>
> I am intending to deploy an application which uses some third party library available as jar. The application server is based on netty which is expected to call the final application code using a pipe line handler.
> The handler is not able to load any class which is located in the third party library.
--
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