[JBoss JIRA] (WFLY-13837) Undertow WebParsingDeploymentProcessor#deploy needs to also handle Jakarta EE 9 web-app_5_0.xsd
by Scott Marlow (Jira)
[ https://issues.redhat.com/browse/WFLY-13837?page=com.atlassian.jira.plugi... ]
Scott Marlow edited comment on WFLY-13837 at 9/16/20 10:53 AM:
---------------------------------------------------------------
Thanks Brian, I will do stop setting system property org.jboss.metadata.parser.validate to true as a workaround.
was (Author: smarlow):
Thanks Brian, I will do stop setting the system property as a workaround.
> Undertow WebParsingDeploymentProcessor#deploy needs to also handle Jakarta EE 9 web-app_5_0.xsd
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-13837
> URL: https://issues.redhat.com/browse/WFLY-13837
> Project: WildFly
> Issue Type: Sub-task
> Components: EE
> Reporter: Scott Marlow
> Assignee: Flavia Rainone
> Priority: Major
> Labels: EE9
>
> I'm not exactly sure yet where the reference to "DTD Web Application 2.2" is coming from in the follow deployment error that occurring during JSP TCK testing:
> {quote}
> 2020-09-09 16:48:42,512 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "jsp_arrayelresolver_web.war" (runtime-name: "jsp_arrayelresolver_web.war")
> 2020-09-09 16:48:42,625 ERROR [org.jboss.metadata.parser.util.XMLSchemaValidator] (MSC service thread 1-1) Cannot get schema for location: -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN: org.xml.sax.SAXParseException; systemId: file:///mnt/hudson_workspace/customWorkspaceName/wildfly/bin/-//Sun%20Microsystems,%20Inc.//DTD%20Web%20Application%202.2//EN; lineNumber: 81; columnNumber: 3; The markup in the document preceding the root element must be well-formed.
> at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:201)
> at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:175)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:398)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:325)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:282)
> at org.apache.xerces.impl.XMLScanner.reportFatalError(XMLScanner.java:1496)
> at org.apache.xerces.impl.XMLDocumentScannerImpl$PrologDispatcher.dispatch(XMLDocumentScannerImpl.java:784)
> at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324)
> at org.apache.xerces.impl.xs.opti.SchemaParsingConfig.parse(SchemaParsingConfig.java:623)
> at org.apache.xerces.impl.xs.opti.SchemaParsingConfig.parse(SchemaParsingConfig.java:679)
> at org.apache.xerces.impl.xs.opti.SchemaDOMParser.parse(SchemaDOMParser.java:527)
> at org.apache.xerces.impl.xs.traversers.XSDHandler.getSchemaDocument(XSDHandler.java:2168)
> at org.apache.xerces.impl.xs.traversers.XSDHandler.parseSchema(XSDHandler.java:558)
> at org.apache.xerces.impl.xs.XMLSchemaLoader.loadSchema(XMLSchemaLoader.java:580)
> at org.apache.xerces.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:547)
> at org.apache.xerces.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:513)
> at org.apache.xerces.jaxp.validation.XMLSchemaFactory.newSchema(XMLSchemaFactory.java:234)
> at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.java:638) [rt.jar:1.8.0_191]
> at __redirected.__SchemaFactory.newSchema(__SchemaFactory.java:115) [jboss-modules.jar:1.10.2.Final]
> at org.jboss.metadata.parser.util.XMLSchemaValidator.getSchemaForLocation(XMLSchemaValidator.java:117) [jboss-metadata-common-14.0.0.Alpha1.jar:14.0.0.Alpha1]
> at org.jboss.metadata.parser.util.XMLSchemaValidator.validate(XMLSchemaValidator.java:85) [jboss-metadata-common-14.0.0.Alpha1.jar:14.0.0.Alpha1]
> at org.wildfly.extension.undertow.deployment.WebParsingDeploymentProcessor.deploy(WebParsingDeploymentProcessor.java:117)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:182)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_191]
> 2020-09-09 16:48:42,631 WARN [org.jboss.metadata.parser.util.XMLSchemaValidator] (MSC service thread 1-1) Cannot get schema for location: -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN
> 2020-09-09 16:48:42,896 WARN [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0047: Could not find Extension-List entry ExtensionListEntry [implementationVendorId=com.sun, implementationVersion=1.4, name=tsharness, specificationVersion=1.4, title=tsharness] referenced from ResourceRoot [root="/content/jsp_arrayelresolver_web.war"]
> 2020-09-09 16:48:42,896 WARN [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0047: Could not find Extension-List entry ExtensionListEntry [implementationVendorId=com.sun, implementationVersion=1.4, name=cts, specificationVersion=1.4, title=cts] referenced from ResourceRoot [root="/content/jsp_arrayelresolver_web.war"]
> 2020-09-09 16:48:43,243 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "jsp_arrayelresolver_web.war")]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.naming.context.java.jboss.DefaultJMSConnectionFactory"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.module.jsp_arrayelresolver_web.jsp_arrayelresolver_web.DefaultJMSConnectionFactory is missing [jboss.naming.context.java.jboss.DefaultJMSConnectionFactory]"]
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-13837) Undertow WebParsingDeploymentProcessor#deploy needs to also handle Jakarta EE 9 web-app_5_0.xsd
by Scott Marlow (Jira)
[ https://issues.redhat.com/browse/WFLY-13837?page=com.atlassian.jira.plugi... ]
Scott Marlow edited comment on WFLY-13837 at 9/16/20 10:53 AM:
---------------------------------------------------------------
Thanks Brian, I will stop setting system property org.jboss.metadata.parser.validate to true as a workaround.
was (Author: smarlow):
Thanks Brian, I will do stop setting system property org.jboss.metadata.parser.validate to true as a workaround.
> Undertow WebParsingDeploymentProcessor#deploy needs to also handle Jakarta EE 9 web-app_5_0.xsd
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-13837
> URL: https://issues.redhat.com/browse/WFLY-13837
> Project: WildFly
> Issue Type: Sub-task
> Components: EE
> Reporter: Scott Marlow
> Assignee: Flavia Rainone
> Priority: Major
> Labels: EE9
>
> I'm not exactly sure yet where the reference to "DTD Web Application 2.2" is coming from in the follow deployment error that occurring during JSP TCK testing:
> {quote}
> 2020-09-09 16:48:42,512 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "jsp_arrayelresolver_web.war" (runtime-name: "jsp_arrayelresolver_web.war")
> 2020-09-09 16:48:42,625 ERROR [org.jboss.metadata.parser.util.XMLSchemaValidator] (MSC service thread 1-1) Cannot get schema for location: -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN: org.xml.sax.SAXParseException; systemId: file:///mnt/hudson_workspace/customWorkspaceName/wildfly/bin/-//Sun%20Microsystems,%20Inc.//DTD%20Web%20Application%202.2//EN; lineNumber: 81; columnNumber: 3; The markup in the document preceding the root element must be well-formed.
> at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:201)
> at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:175)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:398)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:325)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:282)
> at org.apache.xerces.impl.XMLScanner.reportFatalError(XMLScanner.java:1496)
> at org.apache.xerces.impl.XMLDocumentScannerImpl$PrologDispatcher.dispatch(XMLDocumentScannerImpl.java:784)
> at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324)
> at org.apache.xerces.impl.xs.opti.SchemaParsingConfig.parse(SchemaParsingConfig.java:623)
> at org.apache.xerces.impl.xs.opti.SchemaParsingConfig.parse(SchemaParsingConfig.java:679)
> at org.apache.xerces.impl.xs.opti.SchemaDOMParser.parse(SchemaDOMParser.java:527)
> at org.apache.xerces.impl.xs.traversers.XSDHandler.getSchemaDocument(XSDHandler.java:2168)
> at org.apache.xerces.impl.xs.traversers.XSDHandler.parseSchema(XSDHandler.java:558)
> at org.apache.xerces.impl.xs.XMLSchemaLoader.loadSchema(XMLSchemaLoader.java:580)
> at org.apache.xerces.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:547)
> at org.apache.xerces.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:513)
> at org.apache.xerces.jaxp.validation.XMLSchemaFactory.newSchema(XMLSchemaFactory.java:234)
> at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.java:638) [rt.jar:1.8.0_191]
> at __redirected.__SchemaFactory.newSchema(__SchemaFactory.java:115) [jboss-modules.jar:1.10.2.Final]
> at org.jboss.metadata.parser.util.XMLSchemaValidator.getSchemaForLocation(XMLSchemaValidator.java:117) [jboss-metadata-common-14.0.0.Alpha1.jar:14.0.0.Alpha1]
> at org.jboss.metadata.parser.util.XMLSchemaValidator.validate(XMLSchemaValidator.java:85) [jboss-metadata-common-14.0.0.Alpha1.jar:14.0.0.Alpha1]
> at org.wildfly.extension.undertow.deployment.WebParsingDeploymentProcessor.deploy(WebParsingDeploymentProcessor.java:117)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:182)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_191]
> 2020-09-09 16:48:42,631 WARN [org.jboss.metadata.parser.util.XMLSchemaValidator] (MSC service thread 1-1) Cannot get schema for location: -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN
> 2020-09-09 16:48:42,896 WARN [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0047: Could not find Extension-List entry ExtensionListEntry [implementationVendorId=com.sun, implementationVersion=1.4, name=tsharness, specificationVersion=1.4, title=tsharness] referenced from ResourceRoot [root="/content/jsp_arrayelresolver_web.war"]
> 2020-09-09 16:48:42,896 WARN [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0047: Could not find Extension-List entry ExtensionListEntry [implementationVendorId=com.sun, implementationVersion=1.4, name=cts, specificationVersion=1.4, title=cts] referenced from ResourceRoot [root="/content/jsp_arrayelresolver_web.war"]
> 2020-09-09 16:48:43,243 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "jsp_arrayelresolver_web.war")]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.naming.context.java.jboss.DefaultJMSConnectionFactory"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.module.jsp_arrayelresolver_web.jsp_arrayelresolver_web.DefaultJMSConnectionFactory is missing [jboss.naming.context.java.jboss.DefaultJMSConnectionFactory]"]
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-13837) Undertow WebParsingDeploymentProcessor#deploy needs to also handle Jakarta EE 9 web-app_5_0.xsd
by Scott Marlow (Jira)
[ https://issues.redhat.com/browse/WFLY-13837?page=com.atlassian.jira.plugi... ]
Scott Marlow edited comment on WFLY-13837 at 9/16/20 10:50 AM:
---------------------------------------------------------------
Thanks Brian, I will do stop setting the system property as a workaround.
was (Author: smarlow):
Thanks Brian, I will do step setting the system property as a workaround.
> Undertow WebParsingDeploymentProcessor#deploy needs to also handle Jakarta EE 9 web-app_5_0.xsd
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-13837
> URL: https://issues.redhat.com/browse/WFLY-13837
> Project: WildFly
> Issue Type: Sub-task
> Components: EE
> Reporter: Scott Marlow
> Assignee: Flavia Rainone
> Priority: Major
> Labels: EE9
>
> I'm not exactly sure yet where the reference to "DTD Web Application 2.2" is coming from in the follow deployment error that occurring during JSP TCK testing:
> {quote}
> 2020-09-09 16:48:42,512 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "jsp_arrayelresolver_web.war" (runtime-name: "jsp_arrayelresolver_web.war")
> 2020-09-09 16:48:42,625 ERROR [org.jboss.metadata.parser.util.XMLSchemaValidator] (MSC service thread 1-1) Cannot get schema for location: -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN: org.xml.sax.SAXParseException; systemId: file:///mnt/hudson_workspace/customWorkspaceName/wildfly/bin/-//Sun%20Microsystems,%20Inc.//DTD%20Web%20Application%202.2//EN; lineNumber: 81; columnNumber: 3; The markup in the document preceding the root element must be well-formed.
> at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:201)
> at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:175)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:398)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:325)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:282)
> at org.apache.xerces.impl.XMLScanner.reportFatalError(XMLScanner.java:1496)
> at org.apache.xerces.impl.XMLDocumentScannerImpl$PrologDispatcher.dispatch(XMLDocumentScannerImpl.java:784)
> at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324)
> at org.apache.xerces.impl.xs.opti.SchemaParsingConfig.parse(SchemaParsingConfig.java:623)
> at org.apache.xerces.impl.xs.opti.SchemaParsingConfig.parse(SchemaParsingConfig.java:679)
> at org.apache.xerces.impl.xs.opti.SchemaDOMParser.parse(SchemaDOMParser.java:527)
> at org.apache.xerces.impl.xs.traversers.XSDHandler.getSchemaDocument(XSDHandler.java:2168)
> at org.apache.xerces.impl.xs.traversers.XSDHandler.parseSchema(XSDHandler.java:558)
> at org.apache.xerces.impl.xs.XMLSchemaLoader.loadSchema(XMLSchemaLoader.java:580)
> at org.apache.xerces.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:547)
> at org.apache.xerces.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:513)
> at org.apache.xerces.jaxp.validation.XMLSchemaFactory.newSchema(XMLSchemaFactory.java:234)
> at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.java:638) [rt.jar:1.8.0_191]
> at __redirected.__SchemaFactory.newSchema(__SchemaFactory.java:115) [jboss-modules.jar:1.10.2.Final]
> at org.jboss.metadata.parser.util.XMLSchemaValidator.getSchemaForLocation(XMLSchemaValidator.java:117) [jboss-metadata-common-14.0.0.Alpha1.jar:14.0.0.Alpha1]
> at org.jboss.metadata.parser.util.XMLSchemaValidator.validate(XMLSchemaValidator.java:85) [jboss-metadata-common-14.0.0.Alpha1.jar:14.0.0.Alpha1]
> at org.wildfly.extension.undertow.deployment.WebParsingDeploymentProcessor.deploy(WebParsingDeploymentProcessor.java:117)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:182)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_191]
> 2020-09-09 16:48:42,631 WARN [org.jboss.metadata.parser.util.XMLSchemaValidator] (MSC service thread 1-1) Cannot get schema for location: -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN
> 2020-09-09 16:48:42,896 WARN [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0047: Could not find Extension-List entry ExtensionListEntry [implementationVendorId=com.sun, implementationVersion=1.4, name=tsharness, specificationVersion=1.4, title=tsharness] referenced from ResourceRoot [root="/content/jsp_arrayelresolver_web.war"]
> 2020-09-09 16:48:42,896 WARN [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0047: Could not find Extension-List entry ExtensionListEntry [implementationVendorId=com.sun, implementationVersion=1.4, name=cts, specificationVersion=1.4, title=cts] referenced from ResourceRoot [root="/content/jsp_arrayelresolver_web.war"]
> 2020-09-09 16:48:43,243 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "jsp_arrayelresolver_web.war")]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.naming.context.java.jboss.DefaultJMSConnectionFactory"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.module.jsp_arrayelresolver_web.jsp_arrayelresolver_web.DefaultJMSConnectionFactory is missing [jboss.naming.context.java.jboss.DefaultJMSConnectionFactory]"]
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-13871) Re-implement correct suspend/resume behaviour for EJB client
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFLY-13871?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz edited comment on WFLY-13871 at 9/16/20 10:49 AM:
----------------------------------------------------------------------
For each EJBServerChannel which is created on the server side, there is a separate instance of ClusterTopologyListener and ModuleAvailabilityListener created. In the case of ModuleAvailabilityListener, it provides an API with methods such as moduleAvailable(List<EJBModuleIdentifier> modules) and moduleUnavailable(List<EJBModuleIdentifier> modules) which permit notifying the client on the other end of which modules are or are not available.
Due to the way individual EJBServerChannels (which unpack and pack messages) are tied into the single AssociationImpl (which processes unpacked invocations and returns unpacked results), these listeners are defined in the EJBServerChannel and instances of them are registered by the AssociationImpl by methods registerClusterTopologyListener and registerModuleAvailabilityListener.
The registration methods function as middle men between the source of the events and the client: for example, registerModuleAvailabilityListener defines an inline listener for the DeploymentRepository which responds to deployment repository events (deployment added, deployment removed,...); the inline listener processes these events and then uses the ModuleAvailabilityListener instance parameter to send those events on to the client.
This issue can be solved by creating a third listener, SuspendResumeListener and registering it using a method registerSuspendResumeListener in exactly the same way as the others.
was (Author: rachmato):
For each EJBServerChannel which is created on the server side, there is a separate instance of ClusterTopologyListener and ModuleAvailabilityListener created. In the case of ModuleAvailabilityListener, it provides an API with methods such as moduleAvailable(List<EJBModuleIdentifier> modules) and moduleUnavailable(List<EJBModuleIdentifier> modules) which permit notifying the client on the other end of which modules are or are not available.
Due to the way individual EJBServerChannels (which unpack and pack messages) are tied into the single AssociationImpl (which processes unpacked invocations and returns unpacked results), these listeners are defined in the EJBServerChannel and instances of them are registered by the AssociationImpl by methods registerClusterTopologyListener and registerModuleAvailabilityListener.
The registration methods function as middle men between the source of the events and the client: for example, registerModuleAvailabilityListener defines an inline listener for the DeploymentRepository which responds to deployment repository events (deployment added, deployment removed,...); the listener processes these events and then uses the ModuleAvailabilityListener instance parameter to send those events on to the client.
This issue can be solved by creating a third listener, SuspendResumeListener and registering it using a method registerSuspendResumeListener in exactly the same way as the others.
> Re-implement correct suspend/resume behaviour for EJB client
> ------------------------------------------------------------
>
> Key: WFLY-13871
> URL: https://issues.redhat.com/browse/WFLY-13871
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 21.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
> Fix For: 21.0.0.Beta1
>
>
> When a server is suspended, in order to avoid receipt of invocations which will never be correctly processed, all connected clients should be notified that all modules on that server are now unavailable; when the server is resumed, all connected clients should be notified that all modules on that server are now again available so that the server may again take part in processing invocations.
> This behaviour was present in versions of EAP before EAP 7.1 but was not ported over to the new EJB client server-side classes which were substantially refactored.
> This issue will re-instante that behaviour. The two cases of standalone and clustered deployments should be considered.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-13871) Re-implement correct suspend/resume behaviour for EJB client
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFLY-13871?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz edited comment on WFLY-13871 at 9/16/20 10:45 AM:
----------------------------------------------------------------------
The option described above says: introduce a new listener type for the association to register, SuspendResumeListener, which involves changing the Association interface, the AssociationImpl and then cause that new listener to be registered in the EJBRemoteService. However, there is a short cut here that could simplify things considerably.
Because the SuspendResumeListener depends on being able to send module updates back to the client, it will depend on having access to a ModuleAvailabilityListener, which *could* be the same instance as passed to the method registerModuleAvailabilityListener.
The short cut is to not add in a new listener type to the Association, but simply register the SuspendResumeListener in the registerModuleAvailabilityListener method of AssociationImpl, at the same time that we register the "middleman listener" that uses the ModuleAvailabilityListener parameter. It makes sense because module availability is determined now by two things: what is happening in the deployment repository, as well as whether or not the server is suspended. It avoids complicating the Association interface with an extra method as well as the RemoteEJBService with an extra registration.
The only possible negative side effect is that it doesn't make explicit the fact that a suspend resume listener is being registered, at the Association interface level.
was (Author: rachmato):
The option described above says: introduce a new listener type for the association to register, SuspendResumeListener, which involves changing the Association interface, the AssociationImpl and then cause that new listener to be registered in the EJBRemoteService. However, there is a short cut here that could simplify things considerably.
Because the SuspendResumeListener depends on being able to send module updates back to the client, it will depend on having access to a ModuleAvailabilityListener, which *could* be the same instance as passed to the method registerModuleAvailabilityListener.
The short cut is to not add in a new listener type to the Association, but simply register the SuspendResumeListener in the registerModuleAvailabilityListener method of AssociationImpl, at the same time that we register the ModuleAvailabilityListener. It makes sense because module availability is determined now by two things: what is happening in the deployment repository, as well as whether or not the server is suspended. It avoids complicating the Association interface with an extra method as well as the RemoteEJBService with an extra registration.
The only possible negative side effect is that it doesn't make explicit the fact that a suspend resume listener is being registered, at the Association interface level.
> Re-implement correct suspend/resume behaviour for EJB client
> ------------------------------------------------------------
>
> Key: WFLY-13871
> URL: https://issues.redhat.com/browse/WFLY-13871
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 21.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
> Fix For: 21.0.0.Beta1
>
>
> When a server is suspended, in order to avoid receipt of invocations which will never be correctly processed, all connected clients should be notified that all modules on that server are now unavailable; when the server is resumed, all connected clients should be notified that all modules on that server are now again available so that the server may again take part in processing invocations.
> This behaviour was present in versions of EAP before EAP 7.1 but was not ported over to the new EJB client server-side classes which were substantially refactored.
> This issue will re-instante that behaviour. The two cases of standalone and clustered deployments should be considered.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-13837) Undertow WebParsingDeploymentProcessor#deploy needs to also handle Jakarta EE 9 web-app_5_0.xsd
by Scott Marlow (Jira)
[ https://issues.redhat.com/browse/WFLY-13837?page=com.atlassian.jira.plugi... ]
Scott Marlow commented on WFLY-13837:
-------------------------------------
Thanks Brian, I will do step setting the system property as a workaround.
> Undertow WebParsingDeploymentProcessor#deploy needs to also handle Jakarta EE 9 web-app_5_0.xsd
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-13837
> URL: https://issues.redhat.com/browse/WFLY-13837
> Project: WildFly
> Issue Type: Sub-task
> Components: EE
> Reporter: Scott Marlow
> Assignee: Flavia Rainone
> Priority: Major
> Labels: EE9
>
> I'm not exactly sure yet where the reference to "DTD Web Application 2.2" is coming from in the follow deployment error that occurring during JSP TCK testing:
> {quote}
> 2020-09-09 16:48:42,512 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "jsp_arrayelresolver_web.war" (runtime-name: "jsp_arrayelresolver_web.war")
> 2020-09-09 16:48:42,625 ERROR [org.jboss.metadata.parser.util.XMLSchemaValidator] (MSC service thread 1-1) Cannot get schema for location: -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN: org.xml.sax.SAXParseException; systemId: file:///mnt/hudson_workspace/customWorkspaceName/wildfly/bin/-//Sun%20Microsystems,%20Inc.//DTD%20Web%20Application%202.2//EN; lineNumber: 81; columnNumber: 3; The markup in the document preceding the root element must be well-formed.
> at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:201)
> at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:175)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:398)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:325)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:282)
> at org.apache.xerces.impl.XMLScanner.reportFatalError(XMLScanner.java:1496)
> at org.apache.xerces.impl.XMLDocumentScannerImpl$PrologDispatcher.dispatch(XMLDocumentScannerImpl.java:784)
> at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324)
> at org.apache.xerces.impl.xs.opti.SchemaParsingConfig.parse(SchemaParsingConfig.java:623)
> at org.apache.xerces.impl.xs.opti.SchemaParsingConfig.parse(SchemaParsingConfig.java:679)
> at org.apache.xerces.impl.xs.opti.SchemaDOMParser.parse(SchemaDOMParser.java:527)
> at org.apache.xerces.impl.xs.traversers.XSDHandler.getSchemaDocument(XSDHandler.java:2168)
> at org.apache.xerces.impl.xs.traversers.XSDHandler.parseSchema(XSDHandler.java:558)
> at org.apache.xerces.impl.xs.XMLSchemaLoader.loadSchema(XMLSchemaLoader.java:580)
> at org.apache.xerces.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:547)
> at org.apache.xerces.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:513)
> at org.apache.xerces.jaxp.validation.XMLSchemaFactory.newSchema(XMLSchemaFactory.java:234)
> at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.java:638) [rt.jar:1.8.0_191]
> at __redirected.__SchemaFactory.newSchema(__SchemaFactory.java:115) [jboss-modules.jar:1.10.2.Final]
> at org.jboss.metadata.parser.util.XMLSchemaValidator.getSchemaForLocation(XMLSchemaValidator.java:117) [jboss-metadata-common-14.0.0.Alpha1.jar:14.0.0.Alpha1]
> at org.jboss.metadata.parser.util.XMLSchemaValidator.validate(XMLSchemaValidator.java:85) [jboss-metadata-common-14.0.0.Alpha1.jar:14.0.0.Alpha1]
> at org.wildfly.extension.undertow.deployment.WebParsingDeploymentProcessor.deploy(WebParsingDeploymentProcessor.java:117)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:182)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_191]
> 2020-09-09 16:48:42,631 WARN [org.jboss.metadata.parser.util.XMLSchemaValidator] (MSC service thread 1-1) Cannot get schema for location: -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN
> 2020-09-09 16:48:42,896 WARN [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0047: Could not find Extension-List entry ExtensionListEntry [implementationVendorId=com.sun, implementationVersion=1.4, name=tsharness, specificationVersion=1.4, title=tsharness] referenced from ResourceRoot [root="/content/jsp_arrayelresolver_web.war"]
> 2020-09-09 16:48:42,896 WARN [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0047: Could not find Extension-List entry ExtensionListEntry [implementationVendorId=com.sun, implementationVersion=1.4, name=cts, specificationVersion=1.4, title=cts] referenced from ResourceRoot [root="/content/jsp_arrayelresolver_web.war"]
> 2020-09-09 16:48:43,243 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "jsp_arrayelresolver_web.war")]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.naming.context.java.jboss.DefaultJMSConnectionFactory"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.module.jsp_arrayelresolver_web.jsp_arrayelresolver_web.DefaultJMSConnectionFactory is missing [jboss.naming.context.java.jboss.DefaultJMSConnectionFactory]"]
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-13871) Re-implement correct suspend/resume behaviour for EJB client
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFLY-13871?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz commented on WFLY-13871:
--------------------------------------------
The option described above says: introduce a new listener type for the association to register, SuspendResumeListener, which involves changing the Association interface, the AssociationImpl and then cause that new listener to be registered in the EJBRemoteService. However, there is a short cut here that could simplify things considerably.
Because the SuspendResumeListener depends on being able to send module updates back to the client, it will depend on having access to a ModuleAvailabilityListener, which *could* be the same instance as passed to the method registerModuleAvailabilityListener.
The short cut is to not add in a new listener type to the Association, but simply register the SuspendResumeListener in the registerModuleAvailabilityListener method of AssociationImpl, at the same time that we register the ModuleAvailabilityListener. It makes sense because module availability is determined now by two things: what is happening in the deployment repository, as well as whether or not the server is suspended. It avoids complicating the Association interface with an extra method as well as the RemoteEJBService with an extra registration.
The only possible negative side effect is that it doesn't make explicit the fact that a suspend resume listener is being registered, at the Association interface level.
> Re-implement correct suspend/resume behaviour for EJB client
> ------------------------------------------------------------
>
> Key: WFLY-13871
> URL: https://issues.redhat.com/browse/WFLY-13871
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 21.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
> Fix For: 21.0.0.Beta1
>
>
> When a server is suspended, in order to avoid receipt of invocations which will never be correctly processed, all connected clients should be notified that all modules on that server are now unavailable; when the server is resumed, all connected clients should be notified that all modules on that server are now again available so that the server may again take part in processing invocations.
> This behaviour was present in versions of EAP before EAP 7.1 but was not ported over to the new EJB client server-side classes which were substantially refactored.
> This issue will re-instante that behaviour. The two cases of standalone and clustered deployments should be considered.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-13871) Re-implement correct suspend/resume behaviour for EJB client
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFLY-13871?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz edited comment on WFLY-13871 at 9/16/20 10:35 AM:
----------------------------------------------------------------------
For each EJBServerChannel which is created on the server side, there is a separate instance of ClusterTopologyListener and ModuleAvailabilityListener created. In the case of ModuleAvailabilityListener, it provides an API with methods such as moduleAvailable(List<EJBModuleIdentifier> modules) and moduleUnavailable(List<EJBModuleIdentifier> modules) which permit notifying the client on the other end of which modules are or are not available.
Due to the way individual EJBServerChannels (which unpack and pack messages) are tied into the single AssociationImpl (which processes unpacked invocations and returns unpacked results), these listeners are defined in the EJBServerChannel and instances of them are registered by the AssociationImpl by methods registerClusterTopologyListener and registerModuleAvailabilityListener.
The registration methods function as middle men between the source of the events and the client: for example, registerModuleAvailabilityListener defines an inline listener for the DeploymentRepository which responds to deployment repository events (deployment added, deployment removed,...); the listener processes these events and then uses the ModuleAvailabilityListener instance parameter to send those events on to the client.
This issue can be solved by creating a third listener, SuspendResumeListener and registering it using a method registerSuspendResumeListener in exactly the same way as the others.
was (Author: rachmato):
For each EJBServerChannel which is created on the server side, there is a separate instance of ClusterTopologyListener and ModuleAvailabilityListener created. In the case of ModuleAvailabilityListener, it provides an API with methods such as moduleAvailable(List<EJBModuleIdentifier> modules) and moduleUnavailable(List<EJBModuleIdentifier> modules) which permit notifying the client on the other end of which modules are or are not available.
Due to the way individual EJBServerChannels (which unpack and pack messages) are tied into the single AssociationImpl (which processes unpacked invocations and returns unpacked results), these listeners are defined in the EJBServerChannel and instances of them are registered by the AssociationImpl by methods registerClusterTopologyListener and registerModuleAvailabilityListener.
This issue can be solved by creating a third listener, SuspendResumeListener and registering it using a method registerSuspendResumeListener in exactly the same way as the others.
> Re-implement correct suspend/resume behaviour for EJB client
> ------------------------------------------------------------
>
> Key: WFLY-13871
> URL: https://issues.redhat.com/browse/WFLY-13871
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 21.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
> Fix For: 21.0.0.Beta1
>
>
> When a server is suspended, in order to avoid receipt of invocations which will never be correctly processed, all connected clients should be notified that all modules on that server are now unavailable; when the server is resumed, all connected clients should be notified that all modules on that server are now again available so that the server may again take part in processing invocations.
> This behaviour was present in versions of EAP before EAP 7.1 but was not ported over to the new EJB client server-side classes which were substantially refactored.
> This issue will re-instante that behaviour. The two cases of standalone and clustered deployments should be considered.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months