[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
11 years, 5 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
11 years, 5 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
11 years, 5 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
11 years, 5 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 commented on AS7-6264:
--------------------------------------
I guess the fact that i can loads classes from my deployment and i can't load the same classes
from the netty handler i would have considered as an issue which could be a bug. Or is this normal that two parts of a deployment are seeing different class pathes?
> 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
11 years, 5 months
[JBoss JIRA] (AS7-6264) AS7.1 Class loading causes an issue with netty and application deployment
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/AS7-6264?page=com.atlassian.jira.plugin.s... ]
David Lloyd commented on AS7-6264:
----------------------------------
I am not sure why this is a pertinent reply. Please bring your problem to the user forums.
> 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
11 years, 5 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 commented on AS7-6264:
--------------------------------------
18:05:34,538 INFO [site.boavista.jboss.view.NettyEJB] (MSC service thread 1-7) NettyServer: Server startup done.
18:05:34,582 INFO [org.jboss.web] (MSC service thread 1-7) JBAS018210: Registering web context: /MyCommunityJBoss
18:05:34,740 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018565: Replaced deployment "MyCommunityJBoss.war" with deployment "MyCommunityJBoss.war"
18:05:52,767 INFO [site.boavista.jboss.view.NettyEJB] (New I/O server boss #32 ([id: 0x20307667, /0.0.0.0:8887])) Channel state changed: [id: 0x32a1811f, /84.189.40.180:38629 => /213.73.112.26:8887] OPEN
18:05:52,774 INFO [site.boavista.jboss.view.NettyEJB] (New I/O server worker #32-1) Channel state changed: [id: 0x32a1811f, /84.189.40.180:38629 => /213.73.112.26:8887] BOUND: /213.73.112.26:8887
18:05:52,780 INFO [site.boavista.jboss.view.NettyEJB] (New I/O server worker #32-1) Channel state changed: [id: 0x32a1811f, /84.189.40.180:38629 => /213.73.112.26:8887] CONNECTED: /84.189.40.180:38629
18:05:52,864 ERROR [stderr] (New I/O server worker #32-1) java.lang.NoClassDefFoundError: com/db4o/ObjectContainer
18:05:52,867 ERROR [stderr] (New I/O server worker #32-1) at site.boavista.jboss.view.EchoServerHandler.messageReceived(EchoServerHandler.java:21)
18:05:52,871 ERROR [stderr] (New I/O server worker #32-1) at site.boavista.jboss.view.MyChannelHandler.handleUpstream(MyChannelHandler.java:21)
18:05:52,874 ERROR [stderr] (New I/O server worker #32-1) at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:274)
18:05:52,878 ERROR [stderr] (New I/O server worker #32-1) at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:261)
18:05:52,881 ERROR [stderr] (New I/O server worker #32-1) at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:351)
18:05:52,884 ERROR [stderr] (New I/O server worker #32-1) at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:282)
18:05:52,888 ERROR [stderr] (New I/O server worker #32-1) at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:202)
18:05:52,891 ERROR [stderr] (New I/O server worker #32-1) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
18:05:52,894 ERROR [stderr] (New I/O server worker #32-1) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
18:05:52,897 ERROR [stderr] (New I/O server worker #32-1) at java.lang.Thread.run(Thread.java:679)
18:05:52,900 ERROR [stderr] (New I/O server worker #32-1) Caused by: java.lang.ClassNotFoundException: com.db4o.ObjectContainer from [Module "deployment.MyCommunityJBoss.war:main" from Service Module Loader]
18:05:52,904 ERROR [stderr] (New I/O server worker #32-1) at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
18:05:52,907 ERROR [stderr] (New I/O server worker #32-1) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
18:05:52,911 ERROR [stderr] (New I/O server worker #32-1) at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
18:05:52,914 ERROR [stderr] (New I/O server worker #32-1) at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423)
18:05:52,917 ERROR [stderr] (New I/O server worker #32-1) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
18:05:52,921 ERROR [stderr] (New I/O server worker #32-1) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
18:05:52,925 ERROR [stderr] (New I/O server worker #32-1) ... 10 more
18:05:52,927 INFO [site.boavista.jboss.view.NettyEJB] (New I/O server worker #32-1) Channel state changed: [id: 0x32a1811f, /84.189.40.180:38629 :> /213.73.112.26:8887] DISCONNECTED
18:05:52,932 INFO [site.boavista.jboss.view.NettyEJB] (New I/O server worker #32-1) Channel state changed: [id: 0x32a1811f, /84.189.40.180:38629 :> /213.73.112.26:8887] UNBOUND
18:05:52,936 INFO [site.boavista.jboss.view.NettyEJB] (New I/O server worker #32-1) Channel state changed: [id: 0x32a1811f, /84.189.40.180:38629 :> /213.73.112.26:8887] 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
11 years, 5 months
[JBoss JIRA] (AS7-5871) The default redirect port for the 8080 connector is current 8433. Should be 8443 instead.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-5871?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry commented on AS7-5871:
---------------------------------------
Hi Wolf,
What's the status in this? Will you be able to submit a patch this week? If not, please assign this to me.
Thanks.
> The default redirect port for the 8080 connector is current 8433. Should be 8443 instead.
> ------------------------------------------------------------------------------------------
>
> Key: AS7-5871
> URL: https://issues.jboss.org/browse/AS7-5871
> Project: Application Server 7
> Issue Type: Bug
> Components: Web
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Wolf-Dieter Fink
> Assignee: Wolf-Dieter Fink
> Fix For: 7.2.0.Alpha1
>
>
> The default redirect port for the 8080 connector is 8433. Seems that this is wrong as socket-bindings use 8443 (and former releases also)
> [standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource
> {
> "outcome" => "success",
> "result" => {
> ...,
> "name" => "http",
> "protocol" => "HTTP/1.1",
> "redirect-port" => 8433,
> "scheme" => "http",
> "secure" => false,
> "socket-binding" => "http",
> "ssl" => undefined,
> "virtual-server" => undefined
> }
> }
> The pre-configured "https" socket binding conversely is 8443:
> [standalone@localhost:9999 socket-binding=https] /socket-binding-group=standard-sockets/socket-binding=https:read-resource
> {
> "outcome" => "success",
> "result" => {
> "client-mappings" => undefined,
> "fixed-port" => false,
> "interface" => undefined,
> "multicast-address" => undefined,
> "multicast-port" => undefined,
> "name" => "https",
> "port" => 8443
> }
> }
--
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
11 years, 5 months