[JBoss JIRA] (WFLY-3704) WebSocket Sessions must be manually closed
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3704?page=com.atlassian.jira.plugin.... ]
Stuart Douglas updated WFLY-3704:
---------------------------------
Component/s: Web Sockets
> WebSocket Sessions must be manually closed
> ------------------------------------------
>
> Key: WFLY-3704
> URL: https://issues.jboss.org/browse/WFLY-3704
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web Sockets
> Affects Versions: 8.1.0.Final
> Reporter: Cody Lerum
> Assignee: Jason Greene
> Labels: websockets
>
> Currently if a WebSocket session goes inactive due to the browser shutting down or the user closing a tab the browser does not send a close event to the server. This behavior seems the same with Chrome and IE.
> The underlying TCP socket is however inactive and can be confirmed by calling a Session#isOpen which returns false. This will cause a build up of sessions unless the user does something like
> {code}
> for (Session session : sessions) {
> if (!session.isOpen()) {
> session.close();
> }
> }
> {code}
> This would need to be done periodically by the application. Shouldn't the server automatically close these sessions when the underlying socket goes inactive?
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3704) WebSocket Sessions must be manually closed
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3704?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-3704:
------------------------------------
Assignee: Stuart Douglas (was: Jason Greene)
> WebSocket Sessions must be manually closed
> ------------------------------------------
>
> Key: WFLY-3704
> URL: https://issues.jboss.org/browse/WFLY-3704
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web Sockets
> Affects Versions: 8.1.0.Final
> Reporter: Cody Lerum
> Assignee: Stuart Douglas
> Labels: websockets
>
> Currently if a WebSocket session goes inactive due to the browser shutting down or the user closing a tab the browser does not send a close event to the server. This behavior seems the same with Chrome and IE.
> The underlying TCP socket is however inactive and can be confirmed by calling a Session#isOpen which returns false. This will cause a build up of sessions unless the user does something like
> {code}
> for (Session session : sessions) {
> if (!session.isOpen()) {
> session.close();
> }
> }
> {code}
> This would need to be done periodically by the application. Shouldn't the server automatically close these sessions when the underlying socket goes inactive?
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (JASSIST-231) ProxyFactory.createClass throws RuntimeException caused by CannotCompileException caused by NoClassDefFoundError
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-231?page=com.atlassian.jira.plugi... ]
Shigeru Chiba commented on JASSIST-231:
---------------------------------------
This bug seems that the class loader given to Javassist is wrong and so loading ProtocolBuffer failed.
So I don't think it's a bug of Javassist...
Caused by: java.lang.ClassNotFoundException: platform.server.core.general.protocol.ProtocolBuffer
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:501)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
... 66 more
> ProxyFactory.createClass throws RuntimeException caused by CannotCompileException caused by NoClassDefFoundError
> ----------------------------------------------------------------------------------------------------------------
>
> Key: JASSIST-231
> URL: https://issues.jboss.org/browse/JASSIST-231
> Project: Javassist
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.18.2-GA
> Environment: Windows 8.1, Eclipse OSGi
> Reporter: Ilia Sretenskii
> Assignee: Shigeru Chiba
> Labels: class, classloader, factory, osgi, proxy
>
> This appears to be a very old bug which happens on Eclipse OSGi projects.
> I have found the same issue filed at 2012.
> http://www.coderanch.com/t/563250/vc/Tomcat-Startup-Error-Javassist
> It still happens on the latest javassist release 3.18.2-GA
> {noformat}
> 14-07-31 15:25:37 [ WARN] org.hibernate.type.TypeFactory {main}
> HHH000233: Scoping types to session factory org.hibernate.internal.SessionFactoryImpl@6e710b23 after already scoped org.hibernate.internal.SessionFactoryImpl@3f925f7a
> java.lang.RuntimeException: by java.lang.NoClassDefFoundError: platform/server/core/general/protocol/ProtocolBuffer
> at javassist.util.proxy.ProxyFactory.createClass3(ProxyFactory.java:515)
> at javassist.util.proxy.ProxyFactory.createClass2(ProxyFactory.java:492)
> at javassist.util.proxy.ProxyFactory.createClass1(ProxyFactory.java:428)
> at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:400)
> at platform.server.core.general.system.service.cache.impl.checker.CacheReusableCheckerBuilderImpl.createClass(CacheReusableCheckerBuilderImpl.java:110)
> at platform.server.core.general.system.service.cache.impl.checker.CacheReusableCheckerBuilderImpl.buildChecker(CacheReusableCheckerBuilderImpl.java:55)
> at platform.server.core.general.system.service.cache.impl.CacheWithReusableCorrect.newInstance(CacheWithReusableCorrect.java:19)
> at platform.server.core.general.system.service.cache.impl.Cache.getInstance(Cache.java:44)
> at platform.server.core.general.system.service.cache.impl.CacheWithReusableCorrect.getInstance(CacheWithReusableCorrect.java:25)
> at platform.server.core.general.protocol.impl.Protocol.newProtocolBuffer(Protocol.java:374)
> at platform.server.core.general.redis.api.codec.RedisCodec.decodeStruct(RedisCodec.java:134)
> at platform.server.core.general.redis.api.codec.RedisCodec.decode(RedisCodec.java:72)
> at platform.server.core.general.redis.api.protocol.decoders.BinaryDecoder.decodeBinary(BinaryDecoder.java:64)
> at platform.server.core.general.redis.api.protocol.decoders.BinaryDecoder.decode(BinaryDecoder.java:95)
> at platform.server.core.general.redis.api.protocol.decoders.BlockDecoder.decode(BlockDecoder.java:40)
> at platform.server.core.general.redis.api.protocol.ResultDecoder.decode(ResultDecoder.java:41)
> at platform.server.core.general.redis.api.RedisConnection.decodeItem(RedisConnection.java:186)
> at platform.server.core.general.redis.api.RedisConnection.readResult(RedisConnection.java:168)
> at platform.server.core.general.redis.api.RedisConnection.call(RedisConnection.java:146)
> at platform.server.core.general.redis.api.RedisConnection._doCommand(RedisConnection.java:114)
> at platform.server.core.general.redis.api.RedisAPI.doCommand(RedisAPI.java:45)
> at platform.server.core.general.redis.api.SelectorConnection.doCommand(SelectorConnection.java:131)
> at platform.server.core.general.redis.api.RedisClient.map_hgetall(RedisClient.java:509)
> at platform.server.core.general.statistics.charts.impl.ChartStorage.getCharts(ChartStorage.java:69)
> at platform.server.core.general.statistics.charts.impl.ChartRegistryImpl.loadChartFromStorage(ChartRegistryImpl.java:40)
> at platform.server.core.general.statistics.charts.impl.ChartRegistryImpl.<init>(ChartRegistryImpl.java:36)
> at platform.server.core.general.statistics.osgi.Activator.start_plugin(Activator.java:47)
> at platform.server.core.general.system.service.ServiceAccessor.start(ServiceAccessor.java:119)
> at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702)
> at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683)
> at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381)
> at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:341)
> at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:333)
> at platform.equinox.runner.RunnerMojo.runOSGiFramework(RunnerMojo.java:207)
> at platform.equinox.runner.RunnerMojo.execute(RunnerMojo.java:89)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:47)
> Caused by: javassist.CannotCompileException: by java.lang.NoClassDefFoundError: platform/server/core/general/protocol/ProtocolBuffer
> at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:170)
> at javassist.util.proxy.ProxyFactory.createClass3(ProxyFactory.java:507)
> ... 58 more
> Caused by: java.lang.NoClassDefFoundError: platform/server/core/general/protocol/ProtocolBuffer
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
> at sun.reflect.GeneratedMethodAccessor29.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at javassist.util.proxy.FactoryHelper.toClass2(FactoryHelper.java:182)
> at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:164)
> ... 59 more
> Caused by: java.lang.ClassNotFoundException: platform.server.core.general.protocol.ProtocolBuffer
> at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:501)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412)
> at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> ... 66 more
> org.osgi.framework.BundleException: Exception in platform.server.core.general.statistics.osgi.Activator.start() of bundle platform.server.core.general.Statistics.
> at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:734)
> at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683)
> at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381)
> at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:341)
> at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:333)
> at platform.equinox.runner.RunnerMojo.runOSGiFramework(RunnerMojo.java:207)
> at platform.equinox.runner.RunnerMojo.execute(RunnerMojo.java:89)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:47)
> Caused by: java.lang.RuntimeException: java.lang.RuntimeException: by java.lang.NoClassDefFoundError: platform/server/core/general/protocol/ProtocolBuffer
> at platform.server.core.general.system.service.cache.impl.checker.CacheReusableCheckerBuilderImpl.buildChecker(CacheReusableCheckerBuilderImpl.java:103)
> at platform.server.core.general.system.service.cache.impl.CacheWithReusableCorrect.newInstance(CacheWithReusableCorrect.java:19)
> at platform.server.core.general.system.service.cache.impl.Cache.getInstance(Cache.java:44)
> at platform.server.core.general.system.service.cache.impl.CacheWithReusableCorrect.getInstance(CacheWithReusableCorrect.java:25)
> at platform.server.core.general.protocol.impl.Protocol.newProtocolBuffer(Protocol.java:374)
> at platform.server.core.general.redis.api.codec.RedisCodec.decodeStruct(RedisCodec.java:134)
> at platform.server.core.general.redis.api.codec.RedisCodec.decode(RedisCodec.java:72)
> at platform.server.core.general.redis.api.protocol.decoders.BinaryDecoder.decodeBinary(BinaryDecoder.java:64)
> at platform.server.core.general.redis.api.protocol.decoders.BinaryDecoder.decode(BinaryDecoder.java:95)
> at platform.server.core.general.redis.api.protocol.decoders.BlockDecoder.decode(BlockDecoder.java:40)
> at platform.server.core.general.redis.api.protocol.ResultDecoder.decode(ResultDecoder.java:41)
> at platform.server.core.general.redis.api.RedisConnection.decodeItem(RedisConnection.java:186)
> at platform.server.core.general.redis.api.RedisConnection.readResult(RedisConnection.java:168)
> at platform.server.core.general.redis.api.RedisConnection.call(RedisConnection.java:146)
> at platform.server.core.general.redis.api.RedisConnection._doCommand(RedisConnection.java:114)
> at platform.server.core.general.redis.api.RedisAPI.doCommand(RedisAPI.java:45)
> at platform.server.core.general.redis.api.SelectorConnection.doCommand(SelectorConnection.java:131)
> at platform.server.core.general.redis.api.RedisClient.map_hgetall(RedisClient.java:509)
> at platform.server.core.general.statistics.charts.impl.ChartStorage.getCharts(ChartStorage.java:69)
> at platform.server.core.general.statistics.charts.impl.ChartRegistryImpl.loadChartFromStorage(ChartRegistryImpl.java:40)
> at platform.server.core.general.statistics.charts.impl.ChartRegistryImpl.<init>(ChartRegistryImpl.java:36)
> at platform.server.core.general.statistics.osgi.Activator.start_plugin(Activator.java:47)
> at platform.server.core.general.system.service.ServiceAccessor.start(ServiceAccessor.java:119)
> at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702)
> ... 28 more
> Caused by: java.lang.RuntimeException: by java.lang.NoClassDefFoundError: platform/server/core/general/protocol/ProtocolBuffer
> at javassist.util.proxy.ProxyFactory.createClass3(ProxyFactory.java:515)
> at javassist.util.proxy.ProxyFactory.createClass2(ProxyFactory.java:492)
> at javassist.util.proxy.ProxyFactory.createClass1(ProxyFactory.java:428)
> at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:400)
> at platform.server.core.general.system.service.cache.impl.checker.CacheReusableCheckerBuilderImpl.createClass(CacheReusableCheckerBuilderImpl.java:110)
> at platform.server.core.general.system.service.cache.impl.checker.CacheReusableCheckerBuilderImpl.buildChecker(CacheReusableCheckerBuilderImpl.java:55)
> ... 53 more
> Caused by: javassist.CannotCompileException: by java.lang.NoClassDefFoundError: platform/server/core/general/protocol/ProtocolBuffer
> at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:170)
> at javassist.util.proxy.ProxyFactory.createClass3(ProxyFactory.java:507)
> ... 58 more
> Caused by: java.lang.NoClassDefFoundError: platform/server/core/general/protocol/ProtocolBuffer
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
> at sun.reflect.GeneratedMethodAccessor29.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at javassist.util.proxy.FactoryHelper.toClass2(FactoryHelper.java:182)
> at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:164)
> ... 59 more
> Caused by: java.lang.ClassNotFoundException: platform.server.core.general.protocol.ProtocolBuffer
> at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:501)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412)
> at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> ... 66 more
> {noformat}
> CacheReusableCheckerBuilderImpl.buildChecker
> {code}
> final Class<?> objectClass = object.getClass();
> ProxyFactory proxyFactory = new ProxyFactory() {
> @Override
> protected ClassLoader getClassLoader() {
> return CacheReusableCheckerBuilderImpl.class.getClassLoader();
> }
> };
> proxyFactory.setSuperclass(objectClass);
> List<Class> interfaces = new ArrayList<>();
> interfaces.addAll(Arrays.asList(objectClass.getInterfaces()));
> interfaces.add(CacheReusableChecker.class);
> proxyFactory.setInterfaces(interfaces.toArray(new Class[interfaces.size()]));
> Class<T> proxyFactoryClass = createClass(proxyFactory);
> {code}
> CacheReusableCheckerBuilderImpl.createClass
> {code}
> @SuppressWarnings("unchecked")
> private <T> Class<T> createClass(ProxyFactory proxyFactory) {
> return proxyFactory.createClass();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3699) Missing param-name in a web.xml causes NullPointerException during deployment
by Jay Kumar SenSharma (JIRA)
[ https://issues.jboss.org/browse/WFLY-3699?page=com.atlassian.jira.plugin.... ]
Jay Kumar SenSharma updated WFLY-3699:
--------------------------------------
Attachment: ContextParamNullDemo.war
> Missing param-name in a web.xml causes NullPointerException during deployment
> ------------------------------------------------------------------------------
>
> Key: WFLY-3699
> URL: https://issues.jboss.org/browse/WFLY-3699
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JSF, Web (Undertow)
> Affects Versions: 9.0.0.Beta1
> Reporter: Jay Kumar SenSharma
> Assignee: Farah Juma
> Attachments: ContextParamNullDemo.war
>
>
> - While deploying a WAR, If the web.xml file is used which has context <param-value> defined, However it has missing <param-name> then it causes NullPointerException as following:
> {code}
> 00:12:09,583 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0027: Starting deployment of "ContextParamNullDemo.war" (runtime-name: "ContextParamNullDemo.war")
> 00:12:09,591 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."ContextParamNullDemo.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."ContextParamNullDemo.war".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "ContextParamNullDemo.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) [wildfly-server-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: java.lang.NullPointerException
> at org.jboss.as.jsf.deployment.JSFVersionProcessor.deploy(JSFVersionProcessor.java:91)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) [wildfly-server-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> ... 5 more
> 00:12:09,598 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "ContextParamNullDemo.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"ContextParamNullDemo.war\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"ContextParamNullDemo.war\".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment \"ContextParamNullDemo.war\"
> Caused by: java.lang.NullPointerException"}}
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3699) Missing param-name in a web.xml causes NullPointerException during deployment
by Jay Kumar SenSharma (JIRA)
[ https://issues.jboss.org/browse/WFLY-3699?page=com.atlassian.jira.plugin.... ]
Jay Kumar SenSharma commented on WFLY-3699:
-------------------------------------------
Wildfly [wildfly-9.0.0.Alpha1-SNAPSHOT] uses jboss meta data 8.0.0.Final. So after this fix rather than showing "NullPointerException". It will start showing the actual cause of the failure with a user friendly message :
{code}
17:33:37,515 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0027: Starting deployment of "ContextParamNullDemo.war" (runtime-name: "ContextParamNullDemo.war")
17:33:37,645 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."ContextParamNullDemo.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."ContextParamNullDemo.war".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "ContextParamNullDemo.war"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) [wildfly-server-1.0.0.Alpha3.jar:1.0.0.Alpha3]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYUT0027: Failed to parse XML descriptor "/content/ContextParamNullDemo.war/WEB-INF/web.xml" at [16,7]
at org.wildfly.extension.undertow.deployment.WebParsingDeploymentProcessor.deploy(WebParsingDeploymentProcessor.java:120)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) [wildfly-server-1.0.0.Alpha3.jar:1.0.0.Alpha3]
... 5 more
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[16,7]
Message: <param-name> OR <param-value> are not defined properly in pair inside the web.xml
at org.jboss.metadata.parser.ee.ParamValueMetaDataParser.parse(ParamValueMetaDataParser.java:88)
at org.jboss.metadata.parser.servlet.WebCommonMetaDataParser.parse(WebCommonMetaDataParser.java:70)
at org.jboss.metadata.parser.servlet.WebMetaDataParser.parse(WebMetaDataParser.java:184)
at org.jboss.metadata.parser.servlet.WebMetaDataParser.parse(WebMetaDataParser.java:57)
at org.wildfly.extension.undertow.deployment.WebParsingDeploymentProcessor.deploy(WebParsingDeploymentProcessor.java:93)
... 6 more
17:33:37,651 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "ContextParamNullDemo.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"ContextParamNullDemo.war\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"ContextParamNullDemo.war\".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment \"ContextParamNullDemo.war\"
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYUT0027: Failed to parse XML descriptor \"/content/ContextParamNullDemo.war/WEB-INF/web.xml\" at [16,7]
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[16,7]
Message: <param-name> OR <param-value> are not defined properly in pair inside the web.xml"}}
17:33:37,806 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0010: Deployed "ContextParamNullDemo.war" (runtime-name : "ContextParamNullDemo.war")
{code}
> Missing param-name in a web.xml causes NullPointerException during deployment
> ------------------------------------------------------------------------------
>
> Key: WFLY-3699
> URL: https://issues.jboss.org/browse/WFLY-3699
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JSF, Web (Undertow)
> Affects Versions: 9.0.0.Beta1
> Reporter: Jay Kumar SenSharma
> Assignee: Farah Juma
>
> - While deploying a WAR, If the web.xml file is used which has context <param-value> defined, However it has missing <param-name> then it causes NullPointerException as following:
> {code}
> 00:12:09,583 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0027: Starting deployment of "ContextParamNullDemo.war" (runtime-name: "ContextParamNullDemo.war")
> 00:12:09,591 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."ContextParamNullDemo.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."ContextParamNullDemo.war".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "ContextParamNullDemo.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) [wildfly-server-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: java.lang.NullPointerException
> at org.jboss.as.jsf.deployment.JSFVersionProcessor.deploy(JSFVersionProcessor.java:91)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) [wildfly-server-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> ... 5 more
> 00:12:09,598 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "ContextParamNullDemo.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"ContextParamNullDemo.war\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"ContextParamNullDemo.war\".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment \"ContextParamNullDemo.war\"
> Caused by: java.lang.NullPointerException"}}
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3699) Missing param-name in a web.xml causes NullPointerException during deployment
by Jay Kumar SenSharma (JIRA)
[ https://issues.jboss.org/browse/WFLY-3699?page=com.atlassian.jira.plugin.... ]
Jay Kumar SenSharma commented on WFLY-3699:
-------------------------------------------
Yes, a fix was supposed to be made in the jboss metadata project.
I have sent a pull request for the same : https://github.com/jboss/metadata/pull/64
> Missing param-name in a web.xml causes NullPointerException during deployment
> ------------------------------------------------------------------------------
>
> Key: WFLY-3699
> URL: https://issues.jboss.org/browse/WFLY-3699
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JSF, Web (Undertow)
> Affects Versions: 9.0.0.Beta1
> Reporter: Jay Kumar SenSharma
> Assignee: Farah Juma
>
> - While deploying a WAR, If the web.xml file is used which has context <param-value> defined, However it has missing <param-name> then it causes NullPointerException as following:
> {code}
> 00:12:09,583 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0027: Starting deployment of "ContextParamNullDemo.war" (runtime-name: "ContextParamNullDemo.war")
> 00:12:09,591 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."ContextParamNullDemo.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."ContextParamNullDemo.war".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "ContextParamNullDemo.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) [wildfly-server-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: java.lang.NullPointerException
> at org.jboss.as.jsf.deployment.JSFVersionProcessor.deploy(JSFVersionProcessor.java:91)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) [wildfly-server-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> ... 5 more
> 00:12:09,598 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "ContextParamNullDemo.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"ContextParamNullDemo.war\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"ContextParamNullDemo.war\".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment \"ContextParamNullDemo.war\"
> Caused by: java.lang.NullPointerException"}}
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3705) read-resource recursive-depth has no effect when recursive=true
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-3705?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov edited comment on WFLY-3705 at 8/3/14 5:05 AM:
--------------------------------------------------------------
Judging by a massive test failure related to the pull request, the behavior every test expects from the system is that recursive-depth > 1 overrides recursive=false and recursive=true ignores recursive-depth in contravention of the docs: https://docs.jboss.org/author/display/WFLY8/Global+operations
This needs to be converted to a doc bug then?
was (Author: arcivanov):
Judging by a massive test failure related to checking, the behavior every test expects from the system is that recursive-depth > 1 overrides recursive=false and recursive=true ignores recursive-depth in contravention of the docs: https://docs.jboss.org/author/display/WFLY8/Global+operations
This needs to be converted to a doc bug then?
> read-resource recursive-depth has no effect when recursive=true
> ---------------------------------------------------------------
>
> Key: WFLY-3705
> URL: https://issues.jboss.org/browse/WFLY-3705
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.1.0.Final
> Environment: Linux aimobile-sm.servicemesh.com 3.15.7-200.fc20.x86_64 #1 SMP Mon Jul 28 18:50:26 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Arcadiy Ivanov
> Assignee: Brian Stansberry
>
> The code inside ReadResourceHandler.doExecuteInternal(OperationContext context, ModelNode operation) goes as follows:
> {noformat}
> final int recursiveDepth = operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).asInt(0);
> final boolean recursive = recursiveDepth > 0 || operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false);
> {noformat}
> The [documentation|https://docs.jboss.org/author/display/WFLY8/Global+operations] states:
> recursive-depth – (int) – The depth to which information about child resources should be included *if recursive is {{true}*. If not set, the depth will be unlimited; i.e. all descendant resources will be included.
> The logic, however, as implemented goes - either recursive-depth is greater than zero OR recursive is true.
> The proper implementation should be:
> {noformat}
> final int recursiveDepth = operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).asInt(0);
> final boolean recursive = operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false) &&
> (!operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).isDefined() || recursiveDepth > 0);
> {noformat}
> The above snippet works as follows: recurs IF recursive is set AND (either recursive-depth is not defined OR recursive-depth is greater than 0).
>
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3705) read-resource recursive-depth has no effect when recursive=true
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-3705?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov updated WFLY-3705:
---------------------------------
Summary: read-resource recursive-depth has no effect when recursive=true (was: read-resource recursive-depth has no effect)
> read-resource recursive-depth has no effect when recursive=true
> ---------------------------------------------------------------
>
> Key: WFLY-3705
> URL: https://issues.jboss.org/browse/WFLY-3705
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.1.0.Final
> Environment: Linux aimobile-sm.servicemesh.com 3.15.7-200.fc20.x86_64 #1 SMP Mon Jul 28 18:50:26 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Arcadiy Ivanov
> Assignee: Brian Stansberry
>
> The code inside ReadResourceHandler.doExecuteInternal(OperationContext context, ModelNode operation) goes as follows:
> {noformat}
> final int recursiveDepth = operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).asInt(0);
> final boolean recursive = recursiveDepth > 0 || operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false);
> {noformat}
> The [documentation|https://docs.jboss.org/author/display/WFLY8/Global+operations] states:
> recursive-depth – (int) – The depth to which information about child resources should be included *if recursive is {{true}*. If not set, the depth will be unlimited; i.e. all descendant resources will be included.
> The logic, however, as implemented goes - either recursive-depth is greater than zero OR recursive is true.
> The proper implementation should be:
> {noformat}
> final int recursiveDepth = operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).asInt(0);
> final boolean recursive = operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false) &&
> (!operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).isDefined() || recursiveDepth > 0);
> {noformat}
> The above snippet works as follows: recurs IF recursive is set AND (either recursive-depth is not defined OR recursive-depth is greater than 0).
>
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3705) read-resource recursive-depth has no effect
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-3705?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov commented on WFLY-3705:
--------------------------------------
Judging by a massive test failure related to checking, the behavior every test expects from the system is that recursive-depth > 1 overrides recursive=false and recursive=true ignores recursive-depth in contravention of the docs: https://docs.jboss.org/author/display/WFLY8/Global+operations
This needs to be converted to a doc bug then?
> read-resource recursive-depth has no effect
> -------------------------------------------
>
> Key: WFLY-3705
> URL: https://issues.jboss.org/browse/WFLY-3705
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.1.0.Final
> Environment: Linux aimobile-sm.servicemesh.com 3.15.7-200.fc20.x86_64 #1 SMP Mon Jul 28 18:50:26 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Arcadiy Ivanov
> Assignee: Brian Stansberry
>
> The code inside ReadResourceHandler.doExecuteInternal(OperationContext context, ModelNode operation) goes as follows:
> {noformat}
> final int recursiveDepth = operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).asInt(0);
> final boolean recursive = recursiveDepth > 0 || operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false);
> {noformat}
> The [documentation|https://docs.jboss.org/author/display/WFLY8/Global+operations] states:
> recursive-depth – (int) – The depth to which information about child resources should be included *if recursive is {{true}*. If not set, the depth will be unlimited; i.e. all descendant resources will be included.
> The logic, however, as implemented goes - either recursive-depth is greater than zero OR recursive is true.
> The proper implementation should be:
> {noformat}
> final int recursiveDepth = operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).asInt(0);
> final boolean recursive = operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false) &&
> (!operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).isDefined() || recursiveDepth > 0);
> {noformat}
> The above snippet works as follows: recurs IF recursive is set AND (either recursive-depth is not defined OR recursive-depth is greater than 0).
>
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months