[JBoss JIRA] (HIBERNATE-169) provide better error log for BigDecimal when creating column failed
by nimo stephan (Jira)
nimo stephan created HIBERNATE-169:
--------------------------------------
Summary: provide better error log for BigDecimal when creating column failed
Key: HIBERNATE-169
URL: https://issues.jboss.org/browse/HIBERNATE-169
Project: Hibernate Integration
Issue Type: Enhancement
Reporter: nimo stephan
Assignee: Steve Ebersole
Steps to reproduce:
Create a column
{code:java}
@Column(name = "price", precision = 7, scale = 10)
private BigDecimal price;
{code}
and run the schema generation.
Schema generation by Hibernate failed without pointing to the error.
In this case the precision is lower than the scale, which is not right, hence the schema generation failed. Please provide better error logging, for example:
{code:java}
"Schema generation failed: field "price" the precision must be not lower than the scale"
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
1 year, 8 months
[JBoss JIRA] (WFLY-12610) Provide a proper :recover management operation for transactions
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFLY-12610?page=com.atlassian.jira.plugin... ]
Ondrej Chaloupka commented on WFLY-12610:
-----------------------------------------
I'm cloning the JBEAP-17611 to track the {{:recover}} call as a WFLY feature request.
> Provide a proper :recover management operation for transactions
> ---------------------------------------------------------------
>
> Key: WFLY-12610
> URL: https://issues.jboss.org/browse/WFLY-12610
> Project: WildFly
> Issue Type: Enhancement
> Components: Transactions
> Affects Versions: 18.0.0.Beta1
> Reporter: Ondrej Chaloupka
> Assignee: Ondrej Chaloupka
> Priority: Major
>
> Based on the operator work at https://github.com/wildfly/wildfly-operator it seems that the operations required by the admin to perform recovery are quite complex.
> It seems that the customer must to:
> 1. make sure that tx recovery listener is enabled in the tx subsystem
> 1.a read the correct port from the socket binding, don't forget to also read the portOffset and take it into account
> 2. connect to this tx-recovery-port opened by the server and send a SCAN command
> 3. read the Pod log with a regexp "ERROR.*Periodic Recovery"
> 3.a don't forget to timestamp the logs
> 4. read recursively all tx logs to check that there are no in-doubts tx
> Oh and if you want to configure the tx recovery process, please add the correct system properties om.arjuna.ats.arjuna.common.Recovery*
> This creates a lot of complexities for the customer (and the operator code) that should be encapsulated by the transactions subsystem.
> Tthe subsystem should provide a :recover management operation
> that deals with connecting with Narayana (no need to open a socket since Narayana is IN-VM) and perform the scan / logs checking / etc. and return the useful information to the user (the in-doubt TX)
> Likewise, any recovery configuration should be handled by the transactions and not through System properties.
> [1] https://github.com/wildfly/wildfly-operator/blob/master/pkg/controller/wi...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
1 year, 8 months
[JBoss JIRA] (WFLY-12610) Provide a proper :recover management operation for transactions
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFLY-12610?page=com.atlassian.jira.plugin... ]
Ondrej Chaloupka moved JBEAP-17671 to WFLY-12610:
-------------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-12610 (was: JBEAP-17671)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Transactions
(was: Transactions)
Affects Version/s: 18.0.0.Beta1
(was: 7.3.0.CD17)
> Provide a proper :recover management operation for transactions
> ---------------------------------------------------------------
>
> Key: WFLY-12610
> URL: https://issues.jboss.org/browse/WFLY-12610
> Project: WildFly
> Issue Type: Enhancement
> Components: Transactions
> Affects Versions: 18.0.0.Beta1
> Reporter: Ondrej Chaloupka
> Assignee: Ondrej Chaloupka
> Priority: Major
>
> Based on the operator work at https://github.com/wildfly/wildfly-operator it seems that the operations required by the admin to perform recovery are quite complex.
> It seems that the customer must to:
> 1. make sure that tx recovery listener is enabled in the tx subsystem
> 1.a read the correct port from the socket binding, don't forget to also read the portOffset and take it into account
> 2. connect to this tx-recovery-port opened by the server and send a SCAN command
> 3. read the Pod log with a regexp "ERROR.*Periodic Recovery"
> 3.a don't forget to timestamp the logs
> 4. read recursively all tx logs to check that there are no in-doubts tx
> Oh and if you want to configure the tx recovery process, please add the correct system properties om.arjuna.ats.arjuna.common.Recovery*
> This creates a lot of complexities for the customer (and the operator code) that should be encapsulated by the transactions subsystem.
> Tthe subsystem should provide a :recover management operation
> that deals with connecting with Narayana (no need to open a socket since Narayana is IN-VM) and perform the scan / logs checking / etc. and return the useful information to the user (the in-doubt TX)
> Likewise, any recovery configuration should be handled by the transactions and not through System properties.
> [1] https://github.com/wildfly/wildfly-operator/blob/master/pkg/controller/wi...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
1 year, 8 months
[JBoss JIRA] (WFWIP-206) scale down isn't successful when there are in-doubt transaction on pod
by Martin Simka (Jira)
[ https://issues.jboss.org/browse/WFWIP-206?page=com.atlassian.jira.plugin.... ]
Martin Simka commented on WFWIP-206:
------------------------------------
with {{quay.io/ochaloup/wildfly-operator:20190930}} test {{testTxStatelessClientSecondCommitThrowRmFail}} passes, but {{testTxStatelessServerSecondCommitThrowRmFail}} fails
> scale down isn't successful when there are in-doubt transaction on pod
> ----------------------------------------------------------------------
>
> Key: WFWIP-206
> URL: https://issues.jboss.org/browse/WFWIP-206
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Environment: operator, built from [1984d98154f11a7473be065e4ae7f54b1812c9b0|https://github.com/wildfly/wildf...] :
> {noformat}
> docker-registry.engineering.redhat.com/jbossqe-eap/wildfly-operator:latest
> {noformat}
> EAP image:
> {noformat}
> docker-registry.engineering.redhat.com/ochaloup/wildfly18-snapshot:190909...
> {noformat}
> Reporter: Martin Simka
> Assignee: Ondrej Chaloupka
> Priority: Blocker
> Labels: operator
>
> While testing tx recovery in OpenShift I see that scale down of pod that has transaction in-doubt on it isn't successful
> Scenario:
> *ejb client* (app tx-client, pod tx-client-0):
> * EJB business method
> ** lookup remote EJB
> ** enlist XA resource 1 to transaction
> ** enlist XA resource 2 to transaction
> ** call remote EJB
> *ejb server* (app tx-server, pod tx-server-0):
> * EJB business method
> ** enlist XA resource 1 to transaction
> ** enlist XA resource 2 to transaction
> ejb server XA resource 2 fails with {{XAException(XAException.XAER_RMFAIL)}}
> Then the test calls scale down (size from 1 to 0) on tx-server pod. But scale down never completes.
> Log from operator:
> {noformat}
> {"level":"info","ts":1568905676.6303623,"logger":"controller_wildflyserver","msg":"Transaction recovery scaledown processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod Name":"tx-server-0","IP Address":"172.17.0.10"}
> {"level":"info","ts":1568905676.7313502,"logger":"controller_wildflyserver","msg":"Enabling recovery listener for processing scaledown at tx-server-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-server"}
> {"level":"info","ts":1568905679.4325309,"logger":"controller_wildflyserver","msg":"Query to find the transaction recovery port to force scan at pod tx-server-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-server"}
> {"level":"info","ts":1568905686.7914035,"logger":"controller_wildflyserver","msg":"Executing recovery scan at tx-server-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod IP":"172.17.0.10","Recovery port":4712}
> {"level":"info","ts":1568905702.0583296,"logger":"controller_wildflyserver","msg":"In-doubt transactions in object store","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod Name":"tx-server-0","Message":"Recovery scan to be invoked as the transaction log storage is not empty for pod scaling down pod tx-server-0, transaction list: map[0:ffffac11000a:991c183:5d8399a1:13:map[age-in-seconds:23 id:0:ffffac11000a:991c183:5d8399a1:13 jmx-name:<nil> participants:map[java:/MockXAResource:map[eis-product-name:MockXAResource Test eis-product-version:0.1.Mock jmx-name:<nil> jndi-name:java:/MockXAResource status:PREPARED type:/StateManager/AbstractRecord/XAResourceRecord]] type:StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA]]"}
> {"level":"info","ts":1568905711.1034026,"logger":"controller_wildflyserver","msg":"Reconciling WildFlyServer","Request.Namespace":"msimka-namespace","Request.Name":"tx-server"}
> {"level":"info","ts":1568905711.103548,"logger":"controller_wildflyserver","msg":"Transaction recovery scaledown processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod Name":"tx-server-0","IP Address":"172.17.0.10"}
> {"level":"info","ts":1568905711.109706,"logger":"controller_wildflyserver","msg":"Executing recovery scan at tx-server-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod IP":"172.17.0.10","Recovery port":4712}
> {"level":"error","ts":1568905711.2608829,"logger":"controller_wildflyserver","msg":"Failures during scaling down recovery processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Desired replica size":0,"Number of pods to be removed":1,"error":"Found 1 errors:\n [[Failed to run transaction recovery scan for scaling down pod tx-server-0. Please, verify the pod log file. Error: Error to get response for command SCAN sending to 172.17.0.10:4712, error: EOF]],","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/go/pkg/mod/github.com/go-l..."}
> {"level":"info","ts":1568905711.2609518,"logger":"controller_wildflyserver","msg":"Scaling down statefulset by verification if pods are clean by recovery","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server"}
> {"level":"info","ts":1568905711.2609615,"logger":"controller_wildflyserver","msg":"Statefulset was not fully scaled to the desired replica size 0 while StatefulSet is to be at size 1. Some pods were not cleaned by recovery. Verify status of the WildflyServer tx-server","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server"}
> {"level":"info","ts":1568905711.2795022,"logger":"controller_wildflyserver","msg":"Updating StatefulSet to be up to date with the WildFlyServer Spec","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server"}
> {"level":"info","ts":1568905711.2795491,"logger":"controller_wildflyserver","msg":"Reconciling WildFlyServer","Request.Namespace":"msimka-namespace","Request.Name":"tx-server"}
> {"level":"info","ts":1568905711.2796504,"logger":"controller_wildflyserver","msg":"Transaction recovery scaledown processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod Name":"tx-server-0","IP Address":"172.17.0.10"}
> {"level":"info","ts":1568905711.2937052,"logger":"controller_wildflyserver","msg":"Executing recovery scan at tx-server-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod IP":"172.17.0.10","Recovery port":4712}
> {"level":"error","ts":1568905711.294249,"logger":"controller_wildflyserver","msg":"Failures during scaling down recovery processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Desired replica size":0,"Number of pods to be removed":1,"error":"Found 1 errors:\n [[Failed to run transaction recovery scan for scaling down pod tx-server-0. Please, verify the pod log file. Error: Cannot process TCP connection to 172.17.0.10:4712, error: dial tcp 172.17.0.10:4712: connect: connection refused]],","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/go/pkg/mod/github.com/go-l..."}
> {"level":"info","ts":1568905711.294342,"logger":"controller_wildflyserver","msg":"Scaling down statefulset by verification if pods are clean by recovery","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server"}
> {"level":"info","ts":1568905711.294417,"logger":"controller_wildflyserver","msg":"Statefulset was not fully scaled to the desired replica size 0 while StatefulSet is to be at size 1. Some pods were not cleaned by recovery. Verify status of the WildflyServer tx-server","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server"}
> {"level":"error","ts":1568905711.311673,"logger":"controller_wildflyserver","msg":"Failed to Update StatefulSet.","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server","error":"Operation cannot be fulfilled on statefulsets.apps \"tx-server\": the object has been modified; please apply your changes to the latest version and try again","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/go/pkg/mod/github.com/go-l..."}
> {"level":"error","ts":1568905711.311745,"logger":"kubebuilder.controller","msg":"Reconciler error","controller":"wildflyserver-controller","request":"msimka-namespace/tx-server","error":"Operation cannot be fulfilled on statefulsets.apps \"tx-server\": the object has been modified; please apply your changes to the latest version and try again","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/go/pkg/mod/github.com/go-l..."}
> {"level":"info","ts":1568905712.3137681,"logger":"controller_wildflyserver","msg":"Reconciling WildFlyServer","Request.Namespace":"msimka-namespace","Request.Name":"tx-server"}
> {"level":"info","ts":1568905712.3139439,"logger":"controller_wildflyserver","msg":"Transaction recovery scaledown processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod Name":"tx-server-0","IP Address":"172.17.0.10"}
> {"level":"info","ts":1568905712.3253288,"logger":"controller_wildflyserver","msg":"Executing recovery scan at tx-server-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod IP":"172.17.0.10","Recovery port":4712}
> {"level":"error","ts":1568905712.3255754,"logger":"controller_wildflyserver","msg":"Failures during scaling down recovery processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Desired replica size":0,"Number of pods to be removed":1,"error":"Found 1 errors:\n [[Failed to run transaction recovery scan for scaling down pod tx-server-0. Please, verify the pod log file. Error: Cannot process TCP connection to 172.17.0.10:4712, error: dial tcp 172.17.0.10:4712: connect: connection refused]],","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/go/pkg/mod/github.com/go-l..."}
> {"level":"info","ts":1568905712.3256311,"logger":"controller_wildflyserver","msg":"Scaling down statefulset by verification if pods are clean by recovery","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server"}
> {"level":"info","ts":1568905712.3256419,"logger":"controller_wildflyserver","msg":"Statefulset was not fully scaled to the desired replica size 0 while StatefulSet is to be at size 1. Some pods were not cleaned by recovery. Verify status of the WildflyServer tx-server","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server"}
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
1 year, 8 months
[JBoss JIRA] (WFLY-12596) Hibernate bytecode transformer needs to pass classloader into ASM ClassWriter for super classes that are in a different classloader
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-12596?page=com.atlassian.jira.plugin... ]
Scott Marlow updated WFLY-12596:
--------------------------------
Summary: Hibernate bytecode transformer needs to pass classloader into ASM ClassWriter for super classes that are in a different classloader (was: Hibernate bytecode transformer needs to pass classloader into ASM ClassWriter to avoid ClassNotFoundException that causes super classes to be ignored if in a different classloader)
> Hibernate bytecode transformer needs to pass classloader into ASM ClassWriter for super classes that are in a different classloader
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-12596
> URL: https://issues.jboss.org/browse/WFLY-12596
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Priority: Major
> Fix For: 19.0.0.Beta1
>
>
> Some users have reported seeing warnings like:
> {quote}
> WARN [org.jboss.modules.define] (MSC service thread 1-4) Failed to define class BGP in Module "deployment.mine.ear" from Service Module Loader: java.lang.ClassFormatError: Failed to link SuperClassInDifferentEarClassLoader (Module "deployment.mine.ear" from Service Module Loader): Type EntityBean not present
> {quote}
> Where class SuperClassInDifferentEarClassLoader, is a super class that is contained in a different EAR classloader than the subclass.
> The workaround should be passing the classloader to use in to the ASM ClassWriter class, by extending the ClassWriter class and providing an implementation of getClassLoader() method.
> {code}
> 12:56:09,573 ERROR [stderr] (MSC service thread 1-4) at org.objectweb.asm.ClassWriter.getCommonSuperClass(ClassWriter.java:937)
> 12:56:09,574 ERROR [stderr] (MSC service thread 1-4) at org.objectweb.asm.SymbolTable.addMergedType(SymbolTable.java:1200)
> 12:56:09,574 ERROR [stderr] (MSC service thread 1-4) at org.objectweb.asm.Frame.merge(Frame.java:1299)
> 12:56:09,574 ERROR [stderr] (MSC service thread 1-4) at org.objectweb.asm.Frame.merge(Frame.java:1197)
> 12:56:09,574 ERROR [stderr] (MSC service thread 1-4) at org.objectweb.asm.MethodWriter.computeAllFrames(MethodWriter.java:1607)
> 12:56:09,574 ERROR [stderr] (MSC service thread 1-4) at org.objectweb.asm.MethodWriter.visitMaxs(MethodWriter.java:1543)
> 12:56:09,575 ERROR [stderr] (MSC service thread 1-4) at org.objectweb.asm.MethodVisitor.visitMaxs(MethodVisitor.java:762)
> 12:56:09,575 ERROR [stderr] (MSC service thread 1-4) at org.objectweb.asm.ClassReader.readCode(ClassReader.java:2431)
> 12:56:09,575 ERROR [stderr] (MSC service thread 1-4) at org.objectweb.asm.ClassReader.readMethod(ClassReader.java:1283)
> 12:56:09,575 ERROR [stderr] (MSC service thread 1-4) at org.objectweb.asm.ClassReader.accept(ClassReader.java:688)
> 12:56:09,575 ERROR [stderr] (MSC service thread 1-4) at org.objectweb.asm.ClassReader.accept(ClassReader.java:400)
> 12:56:09,575 ERROR [stderr] (MSC service thread 1-4) at org.jboss.as.hibernate.Hibernate51CompatibilityTransformer.transform(Hibernate51CompatibilityTransformer.java:102)
> 12:56:09,575 ERROR [stderr] (MSC service thread 1-4) at org.jboss.as.server.deployment.module.DelegatingClassFileTransformer.transform(DelegatingClassFileTransformer.java:60)
> 12:56:09,575 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.JLIClassTransformer.transform(JLIClassTransformer.java:55)
> 12:56:09,576 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:539)
> 12:56:09,576 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:339)
> 12:56:09,576 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:126)
> 12:56:09,576 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.Module.loadModuleClass(Module.java:731)
> 12:56:09,576 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:247)
> 12:56:09,576 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
> 12:56:09,576 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> 12:56:09,576 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> 12:56:09,577 ERROR [stderr] (MSC service thread 1-4) at java.lang.ClassLoader.defineClass1(Native Method)
> 12:56:09,577 ERROR [stderr] (MSC service thread 1-4) at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
> 12:56:09,577 ERROR [stderr] (MSC service thread 1-4) at java.lang.ClassLoader.defineClass(ClassLoader.java:839)
> 12:56:09,577 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:424)
> 12:56:09,577 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:555)
> 12:56:09,577 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:339)
> 12:56:09,577 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:126)
> 12:56:09,578 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.Module.loadModuleClass(Module.java:731)
> 12:56:09,578 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:247)
> 12:56:09,578 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
> 12:56:09,578 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> 12:56:09,578 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> 12:56:09,578 ERROR [stderr] (MSC service thread 1-4) at java.lang.ClassLoader.defineClass1(Native Method)
> 12:56:09,578 ERROR [stderr] (MSC service thread 1-4) at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
> 12:56:09,578 ERROR [stderr] (MSC service thread 1-4) at java.lang.ClassLoader.defineClass(ClassLoader.java:839)
> 12:56:09,579 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:424)
> 12:56:09,579 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:555)
> 12:56:09,579 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:339)
> 12:56:09,579 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:126)
> 12:56:09,579 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.Module.loadModuleClass(Module.java:731)
> 12:56:09,579 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:247)
> 12:56:09,580 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
> 12:56:09,580 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> 12:56:09,580 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> 12:56:09,580 ERROR [stderr] (MSC service thread 1-4) at java.lang.ClassLoader.defineClass1(Native Method)
> 12:56:09,580 ERROR [stderr] (MSC service thread 1-4) at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
> 12:56:09,580 ERROR [stderr] (MSC service thread 1-4) at java.lang.ClassLoader.defineClass(ClassLoader.java:839)
> 12:56:09,580 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:424)
> 12:56:09,580 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:555)
> 12:56:09,581 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:339)
> 12:56:09,581 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:126)
> 12:56:09,581 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.Module.loadModuleClass(Module.java:731)
> 12:56:09,581 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:247)
> 12:56:09,581 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
> 12:56:09,581 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> 12:56:09,581 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> 12:56:09,582 ERROR [stderr] (MSC service thread 1-4) at java.lang.Class.forName0(Native Method)
> 12:56:09,582 ERROR [stderr] (MSC service thread 1-4) at java.lang.Class.forName(Class.java:348)
> 12:56:09,582 ERROR [stderr] (MSC service thread 1-4) at org.jboss.as.ee.utils.ClassLoadingUtils.loadClass(ClassLoadingUtils.java:21)
> 12:56:09,582 ERROR [stderr] (MSC service thread 1-4) at org.jboss.as.ee.utils.ClassLoadingUtils.loadClass(ClassLoadingUtils.java:14)
> 12:56:09,582 ERROR [stderr] (MSC service thread 1-4) at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.processComponentConfig(InterceptorAnnotationProcessor.java:84)
> 12:56:09,582 ERROR [stderr] (MSC service thread 1-4) at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.deploy(InterceptorAnnotationProcessor.java:76)
> 12:56:09,582 ERROR [stderr] (MSC service thread 1-4) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:176)
> 12:56:09,583 ERROR [stderr] (MSC service thread 1-4) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> 12:56:09,583 ERROR [stderr] (MSC service thread 1-4) at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> 12:56:09,583 ERROR [stderr] (MSC service thread 1-4) at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> 12:56:09,583 ERROR [stderr] (MSC service thread 1-4) at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> 12:56:09,583 ERROR [stderr] (MSC service thread 1-4) at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> 12:56:09,583 ERROR [stderr] (MSC service thread 1-4) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> 12:56:09,584 ERROR [stderr] (MSC service thread 1-4) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> 12:56:09,584 ERROR [stderr] (MSC service thread 1-4) at java.lang.Thread.run(Thread.java:748)
> 12:56:09,584 ERROR [stderr] (MSC service thread 1-4) Caused by: java.lang.ClassNotFoundException: SuperClassInDifferentEarClassLoader from [Module "asm.asm" version 7.1 from local module loader @636be97c (finder: local module finder @50a638b5 (roots: /home/smarlow/work/wildfly/dist/target/wildfly-18.0.0.Final-SNAPSHOT/modules,/home/smarlow/work/wildfly/dist/target/wildfly-18.0.0.Final-SNAPSHOT/modules/system/layers/base))]
> 12:56:09,584 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:255)
> 12:56:09,584 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
> 12:56:09,584 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> 12:56:09,585 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> 12:56:09,585 ERROR [stderr] (MSC service thread 1-4) at java.lang.Class.forName0(Native Method)
> 12:56:09,585 ERROR [stderr] (MSC service thread 1-4) at java.lang.Class.forName(Class.java:348)
> 12:56:09,585 ERROR [stderr] (MSC service thread 1-4) at org.objectweb.asm.ClassWriter.getCommonSuperClass(ClassWriter.java:935)
> 12:56:09,585 ERROR [stderr] (MSC service thread 1-4) ... 72 more
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
1 year, 8 months