[Red Hat JIRA] (WFLY-14219) Utilize JBoss Modules version 1.9 in module descriptors
by Boris Unckel (Jira)
[ https://issues.redhat.com/browse/WFLY-14219?page=com.atlassian.jira.plugi... ]
Boris Unckel commented on WFLY-14219:
-------------------------------------
[~smarlow] Please give me 45min for a call, after that I'll prepare a fix. The message is very "javax.xml.namespace.QName from [Module "javax.ws.rs.api". I just need a few min.
> Utilize JBoss Modules version 1.9 in module descriptors
> -------------------------------------------------------
>
> Key: WFLY-14219
> URL: https://issues.redhat.com/browse/WFLY-14219
> Project: WildFly
> Issue Type: Task
> Components: Server
> Affects Versions: 22.0.0.Alpha1
> Reporter: Boris Unckel
> Assignee: Boris Unckel
> Priority: Major
> Fix For: 23.0.0.Beta1
>
> Attachments: 2020-12-13_wildfly-22.0.0.Beta1-SNAPSHOT_modules_15_16_17.txt, 2020-12-16_wfjdep2_22.0.0.Beta1-SNAPSHOT.7z, 2020-12-16_wfjdep_22.0.0.Beta1-SNAPSHOT.7z
>
>
> There are still modules which use 1.5, 1.6 or 1.7 and do not need that. The idea is to run jdeps on each artifact of a modul, add the relevant java.* and jdk.* modules to the dependencies of the module and upgrade to version 1.8. In a first change only none-jdk modules and none which depend on system dependency.
> List in 2020-12-13_wildfly-22.0.0.Beta1-SNAPSHOT_modules_15_16_17.txt
> Changes in a first set of modules in WildFly-Core [WFCORE-5229|https://issues.redhat.com/browse/WFCORE-5229] integration tests were successful.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14249) Ensure java.time/sql ProtoStream marshallers generate valid protobuf messages
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-14249?page=com.atlassian.jira.plugi... ]
Paul Ferraro updated WFLY-14249:
--------------------------------
Summary: Ensure java.time/sql ProtoStream marshallers generate valid protobuf messages (was: Ensure java.time ProtoStream marshallers generate valid protobuf messages)
> Ensure java.time/sql ProtoStream marshallers generate valid protobuf messages
> -----------------------------------------------------------------------------
>
> Key: WFLY-14249
> URL: https://issues.redhat.com/browse/WFLY-14249
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 22.0.0.Beta1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
>
> Protobuf messages generated by the Externalizers from the org.wildfly.clustering.marshalling.spi module are not necessarily valid protobuf messages.
> Additionally, many java.time classes can be marshalled more efficiently using native protostream marshallers, which can optimize for loose precision and positive/future values.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14249) Ensure java.time ProtoStream marshallers generate valid protobuf messages
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-14249?page=com.atlassian.jira.plugi... ]
Paul Ferraro updated WFLY-14249:
--------------------------------
Description:
Protobuf messages generated by the Externalizers from the org.wildfly.clustering.marshalling.spi module are not necessarily valid protobuf messages.
Additionally, many java.time classes can be marshalled more efficiently using native protostream marshallers, which can optimize for loose precision and positive/future values.
was:Many java.time classes can be marshalled more efficiently using native protostream marshallers, which can optimize for loose precision and positive/future values.
> Ensure java.time ProtoStream marshallers generate valid protobuf messages
> -------------------------------------------------------------------------
>
> Key: WFLY-14249
> URL: https://issues.redhat.com/browse/WFLY-14249
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 22.0.0.Beta1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
>
> Protobuf messages generated by the Externalizers from the org.wildfly.clustering.marshalling.spi module are not necessarily valid protobuf messages.
> Additionally, many java.time classes can be marshalled more efficiently using native protostream marshallers, which can optimize for loose precision and positive/future values.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14219) Utilize JBoss Modules version 1.9 in module descriptors
by Scott Marlow (Jira)
[ https://issues.redhat.com/browse/WFLY-14219?page=com.atlassian.jira.plugi... ]
Scott Marlow commented on WFLY-14219:
-------------------------------------
We are seeing a TCK failure running the Jakarta EE 8 Platform TCK test {quote}test=com/sun/ts/tests/jaxrs/api/rs/core/linkjaxbadapter/JAXRSClient.java#marshallTest_from_servlet{quote} that started failing with recent changes which include this change.
The failure is:
{quote}
VR-ERROR: java.lang.NoClassDefFoundError: javax/xml/namespace/QName
at javax.ws.rs.core.Link$JaxbAdapter.marshal(Link.java:589)
at com.sun.ts.tests.jaxrs.api.rs.core.linkjaxbadapter.JaxbAdapterEx.marshal(JaxbAdapterEx.java:48)
at com.sun.ts.tests.jaxrs.api.rs.core.linkjaxbadapter.JaxbAdapterEx.marshal(JaxbAdapterEx.java:24)
at com.sun.xml.bind.v2.runtime.reflect.AdaptedAccessor.get(AdaptedAccessor.java:46)
at com.sun.xml.bind.v2.runtime.property.SingleElementNodeProperty.serializeBody(SingleElementNodeProperty.java:103)
at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:329)
at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsSoleContent(XMLSerializer.java:563)
at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeRoot(ClassBeanInfoImpl.java:310)
at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:464)
at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:298)
at com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:226)
at javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshallerImpl.java:80)
at com.sun.ts.tests.jaxrs.api.rs.core.linkjaxbadapter.JAXRSClient.marshallTest(JAXRSClient.java:84)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.sun.ts.lib.harness.EETest.run(EETest.java:596)
at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:115)
at com.sun.ts.tests.common.vehicle.servlet.ServletVehicle.runTest(ServletVehicle.java:116)
at com.sun.ts.tests.common.vehicle.servlet.ServletVehicle.doGet(ServletVehicle.java:88)
at com.sun.ts.tests.common.vehicle.servlet.ServletVehicle.doPost(ServletVehicle.java:108)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:523)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:590)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:117)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.SendErrorPageHandler.handleRequest(SendErrorPageHandler.java:52)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.SessionRestoringHandler.handleRequest(SessionRestoringHandler.java:119)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:387)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:841)
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 org.xnio.XnioWorker$WorkerThreadFactory$1$1.run(XnioWorker.java:1280)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.ClassNotFoundException: javax.xml.namespace.QName from [Module "javax.ws.rs.api" version 2.0.1.Final from local module loader @7cd62f43 (finder: local module finder @6d4b1c02 (roots: /mnt/hudson_workspace/customWorkspaceName/wildfly/modules,/mnt/hudson_workspace/customWorkspaceName/wildfly/modules/system/layers/base))]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:255)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
... 68 more
{quote}
> Utilize JBoss Modules version 1.9 in module descriptors
> -------------------------------------------------------
>
> Key: WFLY-14219
> URL: https://issues.redhat.com/browse/WFLY-14219
> Project: WildFly
> Issue Type: Task
> Components: Server
> Affects Versions: 22.0.0.Alpha1
> Reporter: Boris Unckel
> Assignee: Boris Unckel
> Priority: Major
> Fix For: 23.0.0.Beta1
>
> Attachments: 2020-12-13_wildfly-22.0.0.Beta1-SNAPSHOT_modules_15_16_17.txt, 2020-12-16_wfjdep2_22.0.0.Beta1-SNAPSHOT.7z, 2020-12-16_wfjdep_22.0.0.Beta1-SNAPSHOT.7z
>
>
> There are still modules which use 1.5, 1.6 or 1.7 and do not need that. The idea is to run jdeps on each artifact of a modul, add the relevant java.* and jdk.* modules to the dependencies of the module and upgrade to version 1.8. In a first change only none-jdk modules and none which depend on system dependency.
> List in 2020-12-13_wildfly-22.0.0.Beta1-SNAPSHOT_modules_15_16_17.txt
> Changes in a first set of modules in WildFly-Core [WFCORE-5229|https://issues.redhat.com/browse/WFCORE-5229] integration tests were successful.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (DROOLS-5960) GDST V&V should support Dates
by Toni Rikkola (Jira)
[ https://issues.redhat.com/browse/DROOLS-5960?page=com.atlassian.jira.plug... ]
Toni Rikkola moved RHDM-1585 to DROOLS-5960:
--------------------------------------------
Docs QE Status: NEW
Key: DROOLS-5960 (was: RHDM-1585)
QE Status: NEW
QEStatus: ToDo
Workflow: GIT Pull Request workflow (was: CDW with docs v1)
Issue Type: Bug (was: Feature Request)
Project: Drools (was: Red Hat Decision Manager)
> GDST V&V should support Dates
> -----------------------------
>
> Key: DROOLS-5960
> URL: https://issues.redhat.com/browse/DROOLS-5960
> Project: Drools
> Issue Type: Bug
> Reporter: Toni Rikkola
> Assignee: Toni Rikkola
> Priority: Major
> Labels: drools-tools
>
> Looks like when Date ranges are compared an error occurs. The fix makes sure any comparable can be compared for range.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14284) WildFly doesn't stop while waiting for PeriodicRecovery
by Adriano Teixeira de Souza (Jira)
[ https://issues.redhat.com/browse/WFLY-14284?page=com.atlassian.jira.plugi... ]
Adriano Teixeira de Souza updated WFLY-14284:
---------------------------------------------
Attachment: jboss-ejb-client.xml
> WildFly doesn't stop while waiting for PeriodicRecovery
> -------------------------------------------------------
>
> Key: WFLY-14284
> URL: https://issues.redhat.com/browse/WFLY-14284
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 18.0.1.Final, 20.0.1.Final
> Reporter: Adriano Teixeira de Souza
> Assignee: Michael Musgrove
> Priority: Major
> Attachments: ejb-configs.sh, jboss-ejb-client.xml, server(transaction).log, thread-dump-stop-1.txt
>
>
> I'm testing wildfly 20.0.1 (and 21.0.2 was tested too) for replace our old version of Wildfly 10.
> it happens that frequently we have seen that the stop function of server does not work and we need to kill the process by manual operation on the OS.
> It sounds like a dead look.
> I attatch the thread dump on this.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14284) WildFly doesn't stop while waiting for PeriodicRecovery
by Adriano Teixeira de Souza (Jira)
[ https://issues.redhat.com/browse/WFLY-14284?page=com.atlassian.jira.plugi... ]
Adriano Teixeira de Souza commented on WFLY-14284:
--------------------------------------------------
[^jboss-ejb-client.xml]
> WildFly doesn't stop while waiting for PeriodicRecovery
> -------------------------------------------------------
>
> Key: WFLY-14284
> URL: https://issues.redhat.com/browse/WFLY-14284
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 18.0.1.Final, 20.0.1.Final
> Reporter: Adriano Teixeira de Souza
> Assignee: Michael Musgrove
> Priority: Major
> Attachments: ejb-configs.sh, jboss-ejb-client.xml, server(transaction).log, thread-dump-stop-1.txt
>
>
> I'm testing wildfly 20.0.1 (and 21.0.2 was tested too) for replace our old version of Wildfly 10.
> it happens that frequently we have seen that the stop function of server does not work and we need to kill the process by manual operation on the OS.
> It sounds like a dead look.
> I attatch the thread dump on this.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months