[JBoss JIRA] (WFLY-510) JSR-322 Java EE Connector Architecture 1.7
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFLY-510?page=com.atlassian.jira.plugin.s... ]
Eduardo Martins commented on WFLY-510:
--------------------------------------
If the work related with doing the parsing the annotations and doing the bindings for connection factories and administered objects (EE 7 5.18.7 & 5.18.8) is still to do, and you need a hand, please create subtask and assign it to me. JBoss Metadata 8 Alpha 3 supports these already.
> JSR-322 Java EE Connector Architecture 1.7
> ------------------------------------------
>
> Key: WFLY-510
> URL: https://issues.jboss.org/browse/WFLY-510
> Project: WildFly
> Issue Type: Sub-task
> Components: JCA
> Reporter: Jesper Pedersen
> Assignee: Stefano Maestri
> Fix For: 8.0.0.Alpha1
>
>
> * Integrate IronJacamar 1.1
> * Update :jca: to support DistributedWorkManager
> * Update :resource-adapters: to support new IronJacamar features
> * Update :datasources: to support new IronJacamar features
> * Deployer chain for new deployment annotations (minimum implementation - developer mode only)
--
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-1303) metadata-complete="true" not honored for ServletContainerInitializer's annotated with @HandlesTypes
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-1303?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-1303:
--------------------------------------
I belive this was a clarification, and they were always intended to work this way.
> 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] (JBSER-129) CLONE - Unable to deserialize Vector when using JDK 7
by Brad Maxwell (JIRA)
Brad Maxwell created JBSER-129:
----------------------------------
Summary: CLONE - Unable to deserialize Vector when using JDK 7
Key: JBSER-129
URL: https://issues.jboss.org/browse/JBSER-129
Project: JBoss Serialization
Issue Type: Bug
Affects Versions: 1.0.5.FINAL
Environment: JBoss EAP 5.2 on JDK 7
Reporter: Brad Maxwell
Assignee: Brad Maxwell
JDK 7 changed the writeObject of Vector,
ObjectOutputStreamProxy.writeFields is being called, which write the fields out not as a FinalContainer , writeMyself checks the type and for non FinalContainer it just writes the object in metho FieldsContainer.writeField as:
out.writeByte(DataContainerConstants.OBJECTREF);
out.writeObject(value);
When reading, RegularObjectPersister is expecting all FinalContainer.
So it looks like either FinalContainer.writeField may need to wrap the objects in a FinalContainer or on the reading side it needs to read the non wrapped fields before reading the wrapped fields.
public void writeFields() throws IOException {
if (currentContainer!=null)
{
currentContainer.writeMyself(this);
currentContainer=null;
}
JDK 6
--------------------------------------------------------------------------
public class Vector<E>
extends AbstractList<E>
private synchronized void writeObject(java.io.ObjectOutputStream s)
throws java.io.IOException
{
s.defaultWriteObject();
}
JDK 7
--------------------------------------------------------------------------
private void writeObject(java.io.ObjectOutputStream s)
throws java.io.IOException {
final java.io.ObjectOutputStream.PutField fields = s.putFields();
final Object[] data;
synchronized (this) {
fields.put("capacityIncrement", capacityIncrement);
fields.put("elementCount", elementCount);
data = elementData.clone();
}
fields.put("elementData", data);
s.writeFields();
}
org.jboss.serial.exception.SerializationException: Excepted to be int
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readInt(DataContainer.java:1050)
at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:333)
at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:290)
at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:258)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readObject(DataContainer.java:847)
at test.Serial.main(Serial.java:28)
Caused by: java.lang.ClassCastException: java.lang.Integer cannot be cast to org.jboss.serial.finalcontainers.IntegerContainer
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readInt(DataContainer.java:1046)
... 7 more
java.io.EOFException
at java.io.DataInputStream.readFully(DataInputStream.java:197)
at org.jboss.serial.util.StringUtil.pullDataToBuffer(StringUtil.java:191)
at org.jboss.serial.util.StringUtil.readString(StringUtil.java:238)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readUTF(DataContainer.java:757)
at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:322)
at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:290)
at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:258)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
at org.jboss.serial.io.JBossObjectInputStream.readObjectOverride(JBossObjectInputStream.java:163)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:363)
at test.Serial.main(Serial.java:48)
--
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] (DROOLS-126) Drools Verifier does not support Conditional Branches
by Davide Sottara (JIRA)
Davide Sottara created DROOLS-126:
-------------------------------------
Summary: Drools Verifier does not support Conditional Branches
Key: DROOLS-126
URL: https://issues.jboss.org/browse/DROOLS-126
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 6.0.0.Beta2, 5.5.0.Final
Reporter: Davide Sottara
Assignee: Mark Proctor
Priority: Blocker
Fix For: 5.5.1.Final, 6.0.0.CR1
Drools Verifier has not been updated since the introduction of the Conditional Branches.
Any rule with a ConditionalBranchDescr would generate an exception
when Verified.
--
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 Connor Penhale (JIRA)
[ https://issues.jboss.org/browse/WFLY-1305?page=com.atlassian.jira.plugin.... ]
Connor Penhale edited comment on WFLY-1305 at 5/2/13 2:49 PM:
--------------------------------------------------------------
I have run into this issue as well, reproduced using approximately the same steps:
# In an AS 7.2.0.Final installation, standalone/deployments/ contains no applications or markers
# AS 7.2.0.Final is started (bin/standalone.sh)
# application-war.war is added to standalone/deployments/
# AS 7.2.0.Final deploys the application, and creates a .deployed marker
# AS 7.2.0.Final is stopped (jboss-cli.sh> connect, shutdown)
# application-war.war is modified to contain, for example, a missing dependency in jboss-deployment-structure.xml
# application-war.war is overwritten in standalone/deployments/
# Per README.txt, application-war.war.failed is removed, application-war.war.dodeploy is created
# AS 7.2.0.Final is started
# AS 7.2.0.Final fails to deploy the modified war
# No .failed marker is created, and the .dodeploy marker changes to .deployed marker
# CLI reports proper status (jboss-cli.sh> connect, deployment-info : STATUS=FAILED)
Please let the community know if additional information is required to help address this issue.
Thanks!
Connor
was (Author: ol_cpenhale):
I have run into this issue as well, reproduced using approximately the same steps:
# In an AS 7.2.0.Final installation, standalone/deployments/ contains no applications or markers
# AS 7.2.0.Final is started
# application-war.war is added to standalone/deployments/
# AS 7.2.0.Final deploys the application, and creates a .deployed marker
# AS 7.2.0.Final is stopped (jboss-cli.sh> connect, shutdown)
# application-war.war is modified to contain, for example, a missing dependency in jboss-deployment-structure.xml
# application-war.war is overwritten in standalone/deployments/
# Per README.txt, application-war.war.failed is removed, application-war.war.dodeploy is created
# AS 7.2.0.Final is started
# AS 7.2.0.Final fails to deploy the modified war
# No .failed marker is created, and the .dodeploy marker changes to .deployed marker
# CLI reports proper status (jboss-cli.sh> connect, deployment-info : STATUS=FAILED)
Please let the community know if additional information is required to help address this issue.
Thanks!
Connor
> 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 file-scanner deployment that fails on boot will not be undeployed after failure
by Connor Penhale (JIRA)
[ https://issues.jboss.org/browse/WFLY-1305?page=com.atlassian.jira.plugin.... ]
Connor Penhale edited comment on WFLY-1305 at 5/2/13 2:48 PM:
--------------------------------------------------------------
I have run into this issue as well, reproduced using approximately the same steps:
# In an AS 7.2.0.Final installation, ${JBOSS_HOME}/standalone/deployments/ contains no applications or markers
# AS 7.2.0.Final is started
# application-war.war is added to ${JBOSS_HOME}/standalone/deployments/
# AS 7.2.0.Final deploys the application, and creates a .deployed marker
# AS 7.2.0.Final is stopped (jboss-cli.sh> connect, shutdown)
# application-war.war is modified to contain, for example, a missing dependency in jboss-deployment-structure.xml
# application-war.war is overwritten in ${JBOSS_HOME}/standalone/deployments/
# Per README.txt, application-war.war.failed is removed, application-war.war.dodeploy is created
# AS 7.2.0.Final is started
# AS 7.2.0.Final fails to deploy the modified war
# No .failed marker is created, and the .dodeploy marker changes to .deployed marker
# CLI reports proper status (jboss-cli.sh> connect, deployment-info : STATUS=FAILED)
Please let the community know if additional information is required to help address this issue.
Thanks!
Connor
was (Author: ol_cpenhale):
I have run into this issue as well, reproduced using approximately the same steps:
# ${JBOSS_HOME}/standalone/deployments/ contains no applications or markers
# AS 7.2.0.Final is started
# application-war.war is added to ${JBOSS_HOME}/standalone/deployments/
# AS 7.2.0.Final deploys the application, and creates a .deployed marker
# AS 7.2.0.Final is stopped (jboss-cli.sh> connect, shutdown)
# application-war.war is modified to contain, for example, a missing dependency in jboss-deployment-structure.xml
# application-war.war is overwritten in ${JBOSS_HOME}/standalone/deployments/
# Per README.txt, application-war.war.failed is removed, application-war.war.dodeploy is created
# AS 7.2.0.Final is started
# AS 7.2.0.Final fails to deploy the modified war
# No .failed marker is created, and the .dodeploy marker changes to .deployed marker
# CLI reports proper status (jboss-cli.sh> connect, deployment-info : STATUS=FAILED)
Please let the community know if additional information is required to help address this issue.
Thanks!
Connor
> 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 file-scanner deployment that fails on boot will not be undeployed after failure
by Connor Penhale (JIRA)
[ https://issues.jboss.org/browse/WFLY-1305?page=com.atlassian.jira.plugin.... ]
Connor Penhale edited comment on WFLY-1305 at 5/2/13 2:48 PM:
--------------------------------------------------------------
I have run into this issue as well, reproduced using approximately the same steps:
# In an AS 7.2.0.Final installation, ${JBOSS_HOME} / standalone / deployments / contains no applications or markers
# AS 7.2.0.Final is started
# application-war.war is added to ${JBOSS_HOME} / standalone / deployments /
# AS 7.2.0.Final deploys the application, and creates a .deployed marker
# AS 7.2.0.Final is stopped (jboss-cli.sh> connect, shutdown)
# application-war.war is modified to contain, for example, a missing dependency in jboss-deployment-structure.xml
# application-war.war is overwritten in ${JBOSS_HOME} / standalone /deployments /
# Per README.txt, application-war.war.failed is removed, application-war.war.dodeploy is created
# AS 7.2.0.Final is started
# AS 7.2.0.Final fails to deploy the modified war
# No .failed marker is created, and the .dodeploy marker changes to .deployed marker
# CLI reports proper status (jboss-cli.sh> connect, deployment-info : STATUS=FAILED)
Please let the community know if additional information is required to help address this issue.
Thanks!
Connor
was (Author: ol_cpenhale):
I have run into this issue as well, reproduced using approximately the same steps:
# In an AS 7.2.0.Final installation, ${JBOSS_HOME}/standalone/deployments/ contains no applications or markers
# AS 7.2.0.Final is started
# application-war.war is added to ${JBOSS_HOME}/standalone/deployments/
# AS 7.2.0.Final deploys the application, and creates a .deployed marker
# AS 7.2.0.Final is stopped (jboss-cli.sh> connect, shutdown)
# application-war.war is modified to contain, for example, a missing dependency in jboss-deployment-structure.xml
# application-war.war is overwritten in ${JBOSS_HOME}/standalone/deployments/
# Per README.txt, application-war.war.failed is removed, application-war.war.dodeploy is created
# AS 7.2.0.Final is started
# AS 7.2.0.Final fails to deploy the modified war
# No .failed marker is created, and the .dodeploy marker changes to .deployed marker
# CLI reports proper status (jboss-cli.sh> connect, deployment-info : STATUS=FAILED)
Please let the community know if additional information is required to help address this issue.
Thanks!
Connor
> 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 file-scanner deployment that fails on boot will not be undeployed after failure
by Connor Penhale (JIRA)
[ https://issues.jboss.org/browse/WFLY-1305?page=com.atlassian.jira.plugin.... ]
Connor Penhale edited comment on WFLY-1305 at 5/2/13 2:49 PM:
--------------------------------------------------------------
I have run into this issue as well, reproduced using approximately the same steps:
# In an AS 7.2.0.Final installation, standalone/deployments/ contains no applications or markers
# AS 7.2.0.Final is started
# application-war.war is added to standalone/deployments/
# AS 7.2.0.Final deploys the application, and creates a .deployed marker
# AS 7.2.0.Final is stopped (jboss-cli.sh> connect, shutdown)
# application-war.war is modified to contain, for example, a missing dependency in jboss-deployment-structure.xml
# application-war.war is overwritten in standalone/deployments/
# Per README.txt, application-war.war.failed is removed, application-war.war.dodeploy is created
# AS 7.2.0.Final is started
# AS 7.2.0.Final fails to deploy the modified war
# No .failed marker is created, and the .dodeploy marker changes to .deployed marker
# CLI reports proper status (jboss-cli.sh> connect, deployment-info : STATUS=FAILED)
Please let the community know if additional information is required to help address this issue.
Thanks!
Connor
was (Author: ol_cpenhale):
I have run into this issue as well, reproduced using approximately the same steps:
# In an AS 7.2.0.Final installation, ${JBOSS_HOME} / standalone / deployments / contains no applications or markers
# AS 7.2.0.Final is started
# application-war.war is added to ${JBOSS_HOME} / standalone / deployments /
# AS 7.2.0.Final deploys the application, and creates a .deployed marker
# AS 7.2.0.Final is stopped (jboss-cli.sh> connect, shutdown)
# application-war.war is modified to contain, for example, a missing dependency in jboss-deployment-structure.xml
# application-war.war is overwritten in ${JBOSS_HOME} / standalone /deployments /
# Per README.txt, application-war.war.failed is removed, application-war.war.dodeploy is created
# AS 7.2.0.Final is started
# AS 7.2.0.Final fails to deploy the modified war
# No .failed marker is created, and the .dodeploy marker changes to .deployed marker
# CLI reports proper status (jboss-cli.sh> connect, deployment-info : STATUS=FAILED)
Please let the community know if additional information is required to help address this issue.
Thanks!
Connor
> 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 file-scanner deployment that fails on boot will not be undeployed after failure
by Connor Penhale (JIRA)
[ https://issues.jboss.org/browse/WFLY-1305?page=com.atlassian.jira.plugin.... ]
Connor Penhale commented on WFLY-1305:
--------------------------------------
I have run into this issue as well, reproduced using approximately the same steps:
# ${JBOSS_HOME}/standalone/deployments/ contains no applications or markers
# AS 7.2.0.Final is started
# application-war.war is added to ${JBOSS_HOME}/standalone/deployments/
# AS 7.2.0.Final deploys the application, and creates a .deployed marker
# AS 7.2.0.Final is stopped (jboss-cli.sh> connect, shutdown)
# application-war.war is modified to contain, for example, a missing dependency in jboss-deployment-structure.xml
# application-war.war is overwritten in ${JBOSS_HOME}/standalone/deployments/
# Per README.txt, application-war.war.failed is removed, application-war.war.dodeploy is created
# AS 7.2.0.Final is started
# AS 7.2.0.Final fails to deploy the modified war
# No .failed marker is created, and the .dodeploy marker changes to .deployed marker
# CLI reports proper status (jboss-cli.sh> connect, deployment-info : STATUS=FAILED)
Please let the community know if additional information is required to help address this issue.
Thanks!
Connor
> 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 file-scanner deployment that fails on boot will not be undeployed after failure
by Connor Penhale (JIRA)
[ https://issues.jboss.org/browse/WFLY-1305?page=com.atlassian.jira.plugin.... ]
Connor Penhale edited comment on WFLY-1305 at 5/2/13 2:47 PM:
--------------------------------------------------------------
I have run into this issue as well, reproduced using approximately the same steps:
# ${JBOSS_HOME}/standalone/deployments/ contains no applications or markers
# AS 7.2.0.Final is started
# application-war.war is added to ${JBOSS_HOME}/standalone/deployments/
# AS 7.2.0.Final deploys the application, and creates a .deployed marker
# AS 7.2.0.Final is stopped (jboss-cli.sh> connect, shutdown)
# application-war.war is modified to contain, for example, a missing dependency in jboss-deployment-structure.xml
# application-war.war is overwritten in ${JBOSS_HOME}/standalone/deployments/
# Per README.txt, application-war.war.failed is removed, application-war.war.dodeploy is created
# AS 7.2.0.Final is started
# AS 7.2.0.Final fails to deploy the modified war
# No .failed marker is created, and the .dodeploy marker changes to .deployed marker
# CLI reports proper status (jboss-cli.sh> connect, deployment-info : STATUS=FAILED)
Please let the community know if additional information is required to help address this issue.
Thanks!
Connor
was (Author: ol_cpenhale):
I have run into this issue as well, reproduced using approximately the same steps:
# ${JBOSS_HOME}/standalone/deployments/ contains no applications or markers
# AS 7.2.0.Final is started
# application-war.war is added to ${JBOSS_HOME}/standalone/deployments/
# AS 7.2.0.Final deploys the application, and creates a .deployed marker
# AS 7.2.0.Final is stopped (jboss-cli.sh> connect, shutdown)
# application-war.war is modified to contain, for example, a missing dependency in jboss-deployment-structure.xml
# application-war.war is overwritten in ${JBOSS_HOME}/standalone/deployments/
# Per README.txt, application-war.war.failed is removed, application-war.war.dodeploy is created
# AS 7.2.0.Final is started
# AS 7.2.0.Final fails to deploy the modified war
# No .failed marker is created, and the .dodeploy marker changes to .deployed marker
# CLI reports proper status (jboss-cli.sh> connect, deployment-info : STATUS=FAILED)
Please let the community know if additional information is required to help address this issue.
Thanks!
Connor
> 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