[JBoss JIRA] (WFLY-1303) metadata-complete="true" not honored for ServletContainerInitializer's annotated with @HandlesTypes
by Aaron Whiteside (JIRA)
[ https://issues.jboss.org/browse/WFLY-1303?page=com.atlassian.jira.plugin.... ]
Aaron Whiteside commented on WFLY-1303:
---------------------------------------
What about Servlet 3.0 and 2.5? If the web.xml specifies one of those versions, how should the container behavior? If the container supports 3.1 does that mean it does not support 3.0 or 2.5 in regard to compatibility? If I deploy this on a 2.5 servlet container I wouldn't see the same error?
> metadata-complete="true" not honored for ServletContainerInitializer's annotated with @HandlesTypes
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-1303
> URL: https://issues.jboss.org/browse/WFLY-1303
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Alpha1
> Reporter: Aaron Whiteside
> Assignee: Tomaz Cerar
>
> metadata-complete="true" not honored for ServletContainerInitializer's annotated with @HandlesTypes
> web.xml:
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <web-app xmlns="http://java.sun.com/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
> version="3.0"
> metadata-complete="true">
> <listener>
> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
> </listener>
> <context-param>
> <param-name>contextConfigLocation</param-name>
> <param-value>WEB-INF/spring/root-context.xml</param-value>
> </context-param>
> </web-app>
> {code}
> Server.log output when deploying a war that contains the lib jersey-container-servlet-2.0-rc1.jar.
> {code}
> awhiteside@localhost jboss-as-8.0.0.Alpha1-SNAPSHOT# ./bin/standalone.sh
> =========================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: /home/awhiteside/Downloads/jboss-as-8.0.0.Alpha1-SNAPSHOT
> JAVA: /usr/local/java/bin/java
> JAVA_OPTS: -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 19:20:03,372 INFO [org.jboss.modules] (main) JBoss Modules version 1.2.0.Final
> 19:20:03,516 INFO [org.jboss.msc] (main) JBoss MSC version 1.1.2.Final
> 19:20:03,567 INFO [org.jboss.as] (MSC service thread 1-7) JBAS015899: JBoss AS 8.0.0.Alpha1-SNAPSHOT "TBD" starting
> 19:20:04,293 INFO [org.xnio] (MSC service thread 1-4) XNIO Version 3.1.0.CR2
> 19:20:04,296 INFO [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
> 19:20:04,297 INFO [org.xnio.nio] (MSC service thread 1-4) XNIO NIO Implementation Version 3.1.0.CR2
> 19:20:04,311 INFO [org.jboss.remoting] (MSC service thread 1-4) JBoss Remoting version 3.2.16.GA
> 19:20:04,354 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 31) JBAS010280: Activating Infinispan subsystem.
> 19:20:04,357 INFO [org.jboss.as.connector.logging] (MSC service thread 1-6) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar 1.0.16.Final)
> 19:20:04,385 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 37) JBAS012605: Activated the following JSF Implementations: [main]
> 19:20:04,389 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 39) JBAS011800: Activating Naming Subsystem
> 19:20:04,398 INFO [org.jboss.as.security] (ServerService Thread Pool -- 44) JBAS013171: Activating Security Subsystem
> 19:20:04,405 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 26) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 19:20:04,413 INFO [org.jboss.as.undertow] (MSC service thread 1-8) JBAS017502: Undertow 1.0.0.Alpha9 starting
> 19:20:04,414 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-4) JBAS010417: Started Driver service with driver-name = h2
> 19:20:04,428 INFO [org.jboss.as.naming] (MSC service thread 1-1) JBAS011802: Starting Naming Service
> 19:20:04,430 INFO [org.jboss.as.security] (MSC service thread 1-3) JBAS013170: Current PicketBox version=4.0.16.Final
> 19:20:04,436 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 48) JBAS015537: Activating WebServices Extension
> 19:20:04,439 INFO [org.jboss.as.undertow] (ServerService Thread Pool -- 47) JBAS017502: Undertow 1.0.0.Alpha9 starting
> 19:20:04,440 INFO [org.jboss.as.mail.extension] (MSC service thread 1-4) JBAS015400: Bound mail session [java:jboss/mail/Default]
> 19:20:04,581 INFO [io.undertow] (ServerService Thread Pool -- 47) Creating file handler for path /home/awhiteside/Downloads/jboss-as-8.0.0.Alpha1-SNAPSHOT/welcome-content
> 19:20:04,611 INFO [org.jboss.as.undertow] (MSC service thread 1-1) Starting server server service: service jboss.undertow.server.default-server
> 19:20:04,619 INFO [org.jboss.as.undertow] (MSC service thread 1-3) Starting host default-host
> 19:20:04,619 INFO [org.jboss.as.undertow] (MSC service thread 1-3) registering handler io.undertow.server.handlers.resource.ResourceHandler@4155a5c7 under path '/'
> 19:20:04,624 INFO [org.jboss.ws.common.management] (MSC service thread 1-5) JBWS022052: Starting JBoss Web Services - Stack CXF Server 4.2.0.Alpha1
> 19:20:04,692 INFO [org.jboss.as.undertow] (MSC service thread 1-1) JBAS017519: Undertow HTTP listener default listening on /127.0.0.1:8080
> 19:20:04,815 INFO [org.jboss.as.remoting] (MSC service thread 1-4) JBAS017100: Listening on 127.0.0.1:9999
> 19:20:04,815 INFO [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on 127.0.0.1:4447
> 19:20:04,825 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-4) JBAS015012: Started FileSystemDeploymentService for directory /home/awhiteside/Downloads/jboss-as-8.0.0.Alpha1-SNAPSHOT/standalone/deployments
> 19:20:04,831 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015876: Starting deployment of "hawtio.war" (runtime-name: "hawtio.war")
> 19:20:04,850 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-6) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> 19:20:05,466 INFO [io.undertow.servlet] (MSC service thread 1-1) jolokia-agent: Using access restrictor classpath:/jolokia-access.xml
> 19:20:05,520 INFO [org.jboss.as.undertow] (MSC service thread 1-1) JBAS018210: Register web context: /hawtio
> 19:20:05,547 INFO [org.jboss.as.server] (ServerService Thread Pool -- 27) JBAS018559: Deployed "hawtio.war" (runtime-name : "hawtio.war")
> 19:20:05,627 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
> 19:20:05,627 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
> 19:20:05,627 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 8.0.0.Alpha1-SNAPSHOT "TBD" started in 2545ms - Started 198 of 234 services (55 services are lazy, passive or on-demand)
> 19:20:15,567 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "messaging-gateway.war" (runtime-name: "messaging-gateway.war")
> 19:20:17,769 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015960: Class Path entry jaxb-api.jar in /content/messaging-gateway.war/WEB-INF/lib/jaxb-impl-2.2.6.jar does not point to a valid jar for a Class-Path reference.
> 19:20:17,770 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015960: Class Path entry webservices-api.jar in /content/messaging-gateway.war/WEB-INF/lib/webservices-rt-2.2.1-1.jar does not point to a valid jar for a Class-Path reference.
> 19:20:17,771 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015960: Class Path entry webservices-extra.jar in /content/messaging-gateway.war/WEB-INF/lib/webservices-rt-2.2.1-1.jar does not point to a valid jar for a Class-Path reference.
> 19:20:17,771 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015960: Class Path entry webservices-rt_l10n.jar in /content/messaging-gateway.war/WEB-INF/lib/webservices-rt-2.2.1-1.jar does not point to a valid jar for a Class-Path reference.
> 19:20:17,771 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015960: Class Path entry webservices-rt_ja.jar in /content/messaging-gateway.war/WEB-INF/lib/webservices-rt-2.2.1-1.jar does not point to a valid jar for a Class-Path reference.
> 19:20:17,772 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015960: Class Path entry webservices-rt_zh.jar in /content/messaging-gateway.war/WEB-INF/lib/webservices-rt-2.2.1-1.jar does not point to a valid jar for a Class-Path reference.
> 19:20:17,772 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015960: Class Path entry webservices-rt_fr.jar in /content/messaging-gateway.war/WEB-INF/lib/webservices-rt-2.2.1-1.jar does not point to a valid jar for a Class-Path reference.
> 19:20:17,772 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015960: Class Path entry webservices-rt_de.jar in /content/messaging-gateway.war/WEB-INF/lib/webservices-rt-2.2.1-1.jar does not point to a valid jar for a Class-Path reference.
> 19:20:17,772 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015960: Class Path entry webservices-rt_es.jar in /content/messaging-gateway.war/WEB-INF/lib/webservices-rt-2.2.1-1.jar does not point to a valid jar for a Class-Path reference.
> 19:20:17,773 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015960: Class Path entry webservices-rt_it.jar in /content/messaging-gateway.war/WEB-INF/lib/webservices-rt-2.2.1-1.jar does not point to a valid jar for a Class-Path reference.
> 19:20:17,773 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015960: Class Path entry webservices-rt_sw.jar in /content/messaging-gateway.war/WEB-INF/lib/webservices-rt-2.2.1-1.jar does not point to a valid jar for a Class-Path reference.
> 19:20:17,773 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015960: Class Path entry webservices-rt_ko.jar in /content/messaging-gateway.war/WEB-INF/lib/webservices-rt-2.2.1-1.jar does not point to a valid jar for a Class-Path reference.
> 19:20:17,773 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015960: Class Path entry webservices-rt_zh_TW.jar in /content/messaging-gateway.war/WEB-INF/lib/webservices-rt-2.2.1-1.jar does not point to a valid jar for a Class-Path reference.
> 19:20:17,777 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015960: Class Path entry webservices-rt.jar in /content/messaging-gateway.war/WEB-INF/lib/webservices-tools-2.2.1-1.jar does not point to a valid jar for a Class-Path reference.
> 19:20:17,806 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015893: Encountered invalid class name 'org.kxml2.io.KXmlParser,org.kxml2.io.KXmlSerializer' for service type 'org.xmlpull.v1.XmlPullParserFactory'
> 19:20:17,810 INFO [org.jboss.as.pojo] (MSC service thread 1-3) JBAS017000: Found legacy bean/pojo namespace: urn:jboss:bean-deployer:2.0 - might be missing some xml features (potential exceptions).
> 19:20:17,936 WARN [org.jboss.as.ee] (MSC service thread 1-4) JBAS011006: Not installing optional component org.springframework.web.context.request.async.StandardServletAsyncWebRequest due to exception: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011054: Could not find default constructor for class org.springframework.web.context.request.async.StandardServletAsyncWebRequest
> at org.jboss.as.ee.component.DefaultInterceptorConfigurator.configure(DefaultInterceptorConfigurator.java:93) [jboss-as-ee-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:80) [jboss-as-ee-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1974)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1907)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_13]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_13]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13]
> 19:20:17,942 WARN [org.jboss.as.ee] (MSC service thread 1-4) JBAS011006: Not installing optional component org.eclipse.jetty.server.handler.StatisticsHandler$1 due to exception: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011054: Could not find default constructor for class org.eclipse.jetty.server.handler.StatisticsHandler$1
> at org.jboss.as.ee.component.DefaultInterceptorConfigurator.configure(DefaultInterceptorConfigurator.java:93) [jboss-as-ee-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:80) [jboss-as-ee-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1974)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1907)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_13]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_13]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13]
> 19:20:17,944 WARN [org.jboss.as.ee] (MSC service thread 1-4) JBAS011006: Not installing optional component com.sun.xml.ws.transport.http.servlet.WSAsyncListener$1 due to exception: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011054: Could not find default constructor for class com.sun.xml.ws.transport.http.servlet.WSAsyncListener$1
> at org.jboss.as.ee.component.DefaultInterceptorConfigurator.configure(DefaultInterceptorConfigurator.java:93) [jboss-as-ee-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:80) [jboss-as-ee-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1974)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1907)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_13]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_13]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13]
> 19:20:17,972 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.undertow.deployment.default-host./messaging-gateway: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-host./messaging-gateway: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1930) [jboss-msc-1.1.2.Final.jar:1.1.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_13]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_13]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13]
> Caused by: java.lang.RuntimeException: java.lang.NullPointerException
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:176)
> at org.jboss.as.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:129)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1974) [jboss-msc-1.1.2.Final.jar:1.1.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1907) [jboss-msc-1.1.2.Final.jar:1.1.2.Final]
> ... 3 more
> Caused by: java.lang.NullPointerException
> at io.undertow.servlet.spec.ServletRegistrationImpl.getClassName(ServletRegistrationImpl.java:152)
> at org.glassfish.jersey.servlet.init.JerseyServletContainerInitializer.addServletWithExistingRegistration(JerseyServletContainerInitializer.java:222)
> at org.glassfish.jersey.servlet.init.JerseyServletContainerInitializer.onStartup(JerseyServletContainerInitializer.java:136)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:153)
> ... 6 more
> 19:20:17,987 ERROR [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS015870: Deploy of deployment "messaging-gateway.war" was rolled back with the following failure message:
> {"JBAS014671: Failed services" => {"jboss.undertow.deployment.default-host./messaging-gateway" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-host./messaging-gateway: Failed to start service
> Caused by: java.lang.RuntimeException: java.lang.NullPointerException
> Caused by: java.lang.NullPointerException"}}
> 19:20:18,035 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015877: Stopped deployment messaging-gateway.war (runtime-name: messaging-gateway.war) in 48ms
> 19:20:18,037 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report
> JBAS014775: New missing/unsatisfied dependencies:
> service jboss.deployment.unit."messaging-gateway.war".component."javax.faces.webapp.FacetTag".START (missing) dependents: [service jboss.deployment.unit."messaging-gateway.war".deploymentCompleteService]
> service jboss.deployment.unit."messaging-gateway.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.deployment.unit."messaging-gateway.war".deploymentCompleteService]
> JBAS014777: Services which failed to start: service jboss.undertow.deployment.default-host./messaging-gateway
> {code}
> jboss-deployment-structure.xml
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
> <deployment>
> <exclude-subsystems>
> <subsystem name="jaxrs"/>
> <subsystem name="webservices"/>
> </exclude-subsystems>
> <exclusions>
> <module name="org.slf4j"/>
> <module name="org.slf4j.impl"/>
> <module name="org.slf4j.ext"/>
> <module name="org.slf4j.jcl-over-slf4j"/>
> <module name="org.apache.commons.logging"/>
> <module name="org.apache.log4j"/>
> <!--<module name="org.hibernate"/>-->
> </exclusions>
> </deployment>
> </jboss-deployment-structure>
> {code}
> The class in question it is trying to instantiate..
> {code}
> package org.glassfish.jersey.servlet.init;
> ...
> @HandlesTypes({Path.class, Provider.class, Application.class, ApplicationPath.class})
> public class JerseyServletContainerInitializer implements ServletContainerInitializer {
> .....
> {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, 2 months
[JBoss JIRA] (WFLY-1305) a file-scanner deployment that fails on boot will not be undeployed after failure
by Toby Crawley (JIRA)
[ https://issues.jboss.org/browse/WFLY-1305?page=com.atlassian.jira.plugin.... ]
Toby Crawley updated WFLY-1305:
-------------------------------
Summary: a file-scanner deployment that fails on boot will not be undeployed after failure (was: A failed deployment that is retried on boot will always succeed)
> a file-scanner deployment that fails on boot will not be undeployed after failure
> ---------------------------------------------------------------------------------
>
> Key: WFLY-1305
> URL: https://issues.jboss.org/browse/WFLY-1305
> Project: WildFly
> Issue Type: Bug
> Reporter: Toby Crawley
>
> When an app is deployed via the deployments/ dir, but fails for some reason, it is marked as failed with a .failed marker and undeployed. When the AS is rebooted, it tries to redeploy the failure. If this deploy also fails, this new deployment *isn't* undeployed, and a .deployed marker is written to deployments.
> This is with the 7.2.0.Final used in Immutant, I've yet to try to build Immutant on top of 8.x.
--
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, 2 months
[JBoss JIRA] (WFLY-1305) A failed deployment that is retried on boot will always succeed
by Toby Crawley (JIRA)
[ https://issues.jboss.org/browse/WFLY-1305?page=com.atlassian.jira.plugin.... ]
Toby Crawley commented on WFLY-1305:
------------------------------------
To confirm this is still an issue and is unrelated to the Immutant changes, I tried this with a build of wildfly (build from https://github.com/wildfly/wildfly/commit/d72bc66db32b299c1f898005467cefe...) and a broken war file. In doing so, I discovered that any file-scanner-based deployment that fails at startup will succeed, not just prior failed deployments that are retried (I'll update the ticket title to reflect this). I gisted the output and steps I used to recreate at: https://gist.github.com/tobias/8566f990c252cd6cc947
Let me know if I can do anything else to help.
> A failed deployment that is retried on boot will always succeed
> ---------------------------------------------------------------
>
> Key: WFLY-1305
> URL: https://issues.jboss.org/browse/WFLY-1305
> Project: WildFly
> Issue Type: Bug
> Reporter: Toby Crawley
>
> When an app is deployed via the deployments/ dir, but fails for some reason, it is marked as failed with a .failed marker and undeployed. When the AS is rebooted, it tries to redeploy the failure. If this deploy also fails, this new deployment *isn't* undeployed, and a .deployed marker is written to deployments.
> This is with the 7.2.0.Final used in Immutant, I've yet to try to build Immutant on top of 8.x.
--
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, 2 months
[JBoss JIRA] (JGRP-1625) MPerfRpc: perf test for RPCs
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1625?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on JGRP-1625:
-------------------------------------------
Thanks for creating this test.
The rational for the test is to be able to spot regressions in RPC performance between JGroups release versions. Significant changes to protocol layers can be identified by changed protocol names (MERGE -> MERGE2, for example), so in trying to isolate the effect of changes to JGroups, we can revert back to the original protocol stack layers. But not so for changes to RPC components. Given the dependence of the AS clustering code on SYNC and ASYNC RPCs, comparative tests on the RPC level will increase confidence in version changes.
> MPerfRpc: perf test for RPCs
> ----------------------------
>
> Key: JGRP-1625
> URL: https://issues.jboss.org/browse/JGRP-1625
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> Similar to MPerf, but measures perf for invoking sync/async RPCs (rather than sending messages).
--
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, 2 months
[JBoss JIRA] (WFLY-1309) CLI: creating a server on a domain slave followed by setting a system property fails when done in batch mode
by Tom Fonteyne (JIRA)
Tom Fonteyne created WFLY-1309:
----------------------------------
Summary: CLI: creating a server on a domain slave followed by setting a system property fails when done in batch mode
Key: WFLY-1309
URL: https://issues.jboss.org/browse/WFLY-1309
Project: WildFly
Issue Type: Feature Request
Components: Domain Management
Affects Versions: 8.0.0.Alpha1
Environment: wildfly build from a git clone on 2013-05-02
Reporter: Tom Fonteyne
Assignee: Brian Stansberry
Setup two boxes:
- on one, run domain mode (full-ha) -> domain controller
- on the other, configure host.xml to point to the DC, and run the host controller
Now in CLI:
# add the group:
/server-group=slaves:add(profile=full-ha,socket-binding-group=full-ha-sockets)
# create server and set a prop
batch
/host=slave1/server-config=i1:add(group=slaves,auto-start=false)
/host=slave1/server-config=i1/system-property=env:add(value=dev)
run-batch
results in:
JBAS010839: Operation failed or was rolled back on all servers.
Debugging (on EAP 6.0.1) showed the real reason:
activeStep.response = (org.jboss.dmr.ModelNode) {
"outcome" => "failed",
"failure-description" => "JBAS010850: No handler for operation
composite at address [
(\"host\" => \"slave1\"),
(\"server\" => \"test\")
]",
"rolled-back" => true
}
More debugging led to :
org.jboss.as.controller.AbstractOperationContext
seems to be where the rollback is set. When debugging, I found that the constructor always sets
ModelController.OperationTransactionControl transactionControl
but at line 332 (eap 6.0.1) / line 372 (wildfly), the end of doCompleteStep() :
// Allow any containing TransactionControl to vote
final AtomicReference<ResultAction> ref = new AtomicReference<ResultAction>(transactionControl == null ? ResultAction.KEEP : ResultAction.ROLLBACK);
and ref becomes a rollback.
I "walked" pretty much of all the code going on in between. The bit where the config is getting persisted is successful.
But I'm afraid I'm out of my depth as there is *a lot* going on to execute such a composite command :)
--
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, 2 months
[JBoss JIRA] (WFLY-1309) CLI: creating a server on a domain slave followed by setting a system property fails when done in batch mode
by Tom Fonteyne (JIRA)
[ https://issues.jboss.org/browse/WFLY-1309?page=com.atlassian.jira.plugin.... ]
Tom Fonteyne updated WFLY-1309:
-------------------------------
Issue Type: Bug (was: Feature Request)
> CLI: creating a server on a domain slave followed by setting a system property fails when done in batch mode
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1309
> URL: https://issues.jboss.org/browse/WFLY-1309
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 8.0.0.Alpha1
> Environment: wildfly build from a git clone on 2013-05-02
> Reporter: Tom Fonteyne
> Assignee: Brian Stansberry
>
> Setup two boxes:
> - on one, run domain mode (full-ha) -> domain controller
> - on the other, configure host.xml to point to the DC, and run the host controller
> Now in CLI:
> # add the group:
> /server-group=slaves:add(profile=full-ha,socket-binding-group=full-ha-sockets)
> # create server and set a prop
> batch
> /host=slave1/server-config=i1:add(group=slaves,auto-start=false)
> /host=slave1/server-config=i1/system-property=env:add(value=dev)
> run-batch
> results in:
> JBAS010839: Operation failed or was rolled back on all servers.
> Debugging (on EAP 6.0.1) showed the real reason:
> activeStep.response = (org.jboss.dmr.ModelNode) {
> "outcome" => "failed",
> "failure-description" => "JBAS010850: No handler for operation
> composite at address [
> (\"host\" => \"slave1\"),
> (\"server\" => \"test\")
> ]",
> "rolled-back" => true
> }
> More debugging led to :
> org.jboss.as.controller.AbstractOperationContext
> seems to be where the rollback is set. When debugging, I found that the constructor always sets
> ModelController.OperationTransactionControl transactionControl
> but at line 332 (eap 6.0.1) / line 372 (wildfly), the end of doCompleteStep() :
> // Allow any containing TransactionControl to vote
> final AtomicReference<ResultAction> ref = new AtomicReference<ResultAction>(transactionControl == null ? ResultAction.KEEP : ResultAction.ROLLBACK);
> and ref becomes a rollback.
> I "walked" pretty much of all the code going on in between. The bit where the config is getting persisted is successful.
> But I'm afraid I'm out of my depth as there is *a lot* going on to execute such a composite command :)
--
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, 2 months
[JBoss JIRA] (AS7-6079) EJB 2.1 CMP configuration options missing (sync-on-commit-only, insert-after-ejb-post-create, call-ejb-store-on-clean)
by Wolf-Dieter Fink (JIRA)
[ https://issues.jboss.org/browse/AS7-6079?page=com.atlassian.jira.plugin.s... ]
Wolf-Dieter Fink commented on AS7-6079:
---------------------------------------
You might give EAP6.1.Alpha/Beta (which is AS7.2) a try.
There are some EJB2/CMP fixes included which might help. As it looks at the moment there are no more improvements for EJB2/CMP as AS8 will not support CMP.
> EJB 2.1 CMP configuration options missing (sync-on-commit-only, insert-after-ejb-post-create, call-ejb-store-on-clean)
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-6079
> URL: https://issues.jboss.org/browse/AS7-6079
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Affects Versions: 7.1.0.Alpha1, 7.1.3.Final (EAP)
> Reporter: Brad Maxwell
> Assignee: Brad Maxwell
> Fix For: EAP 6.1.0.Alpha (7.2.0.Final), 7.1.4.Final (EAP)
>
>
> In JBoss AS 7, EJB 2.1 CMP beans cannot configure some options such as sync-on-commit-only and insert-after-ejb-post which were configurable in previous versions of JBoss.
> Should also confirm how to configure the rest of the options that were available previously.
> <container-configuration>
> <container-name>Clustered CMP 2.x EntityBean</container-name>
> <call-logging>false</call-logging>
> <invoker-proxy-binding-name>clustered-entity-rmi-invoker</invoker-proxy-binding-name>
> <sync-on-commit-only>false</sync-on-commit-only>
> <insert-after-ejb-post-create>false</insert-after-ejb-post-create>
> <container-interceptors>
> ...
> </container-interceptors>
> <instance-pool>org.jboss.ejb.plugins.EntityInstancePool</instance-pool>
> <instance-cache>org.jboss.ejb.plugins.EntityInstanceCache</instance-cache>
> <persistence-manager>org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager</persistence-manager>
> <locking-policy>org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock</locking-policy>
> <container-cache-conf>
> <cache-policy>org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy</cache-policy>
> <cache-policy-conf>
> <min-capacity>50</min-capacity>
> <max-capacity>1000000</max-capacity>
> <overager-period>300</overager-period>
> <max-bean-age>600</max-bean-age>
> <resizer-period>400</resizer-period>
> <max-cache-miss-period>60</max-cache-miss-period>
> <min-cache-miss-period>1</min-cache-miss-period>
> <cache-load-factor>0.75</cache-load-factor>
> </cache-policy-conf>
> </container-cache-conf>
> <container-pool-conf>
> <MaximumSize>100</MaximumSize>
> </container-pool-conf>
> <commit-option>B</commit-option>
> </container-configuration>
--
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, 2 months
[JBoss JIRA] (WFLY-1308) EJB invocation from a remote client when the deployment is being undeployed doesn't trigger a retry on a different node
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1308?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-1308:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=957171
> EJB invocation from a remote client when the deployment is being undeployed doesn't trigger a retry on a different node
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1308
> URL: https://issues.jboss.org/browse/WFLY-1308
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: jaikiran pai
> Assignee: jaikiran pai
>
> Consider the following case:
> 1) Same bean deployed on a server A and server B
> 2) Remote EJB client which is aware of both server A and server B, in its EJBClientContext, invokes on the bean
> 3) EJB client API selects server A as the target node and lets it handle it.
> 4) In the meantime, after the request has been sent, but before it has been handled on the server A, the deployment on server A is triggered for undeployment.
> 5) This causes the EJB component on server A to throw an exception telling the client that the bean is in shutdown mode and no more invocations are accepted.
> The exception thrown in #5 should really trigger a retry of the invocation, from the client side, on other eligible nodes (in this case Server B), because this failure is as good as the bean not being available in first place on Server A.
> Currently, the client isn't retrying the invocation on a different node, because it has no idea that this specific exception is no different than other potential exceptions that can be thrown by the server for a EJB invocation. To fix this, the method invocation handler on the server side should send back a "no such bean" message to the client, when the server sees that the bean is in shutdown mode.
--
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, 2 months