WELD-862 and Seam Cron
by Peter Royle
Hi,
I'm aiming to make a release of Seam Cron available within the next two weeks. Currently there is an outstanding issue (https://issues.jboss.org/browse/WELD-862) which prevents Cron from running properly with Weld. I have been able to carry on developing Cron by testing it against OpenWebBeans, but obviously if we are to release a Seam module it should work against Weld.
It would be nice if WELD-862 could be fixed as soon a possible so that all future versions will work well with Cron.
But more importantly I also probably need to do something special in Cron so that it will work with the version of Weld already deployed in JBoss AS and Glassfish, which will contain the bug. The workaround mentioned in the bug report is to deep copy the InvocationContext. I attempted to do this by serialising and unserialising the InvocationContext but couldn't due to UnserializableExceptions. Does anyone have any advice for me about how I might be able to work around this bug to support existing versions of Weld?
Cheers,
Pete R
2 months
Re: UnsupportedOperationException in CombinedInterceptorAndDecoratorStackMethodHandler.invoke
by Benjamin Confino
My apologies, the below is outdated. I sent it a couple of days ago and
for some reason it only reached the mailing list today.
Since I wrote it I have acquired the source files, and with them I was
able to create an app that reproduces the issue. Thus I have opened
https://issues.redhat.com/browse/WELD-2638 - the app and details can be
found there.
Regards
Benjamin
From: Benjamin Confino/UK/IBM
To: weld-dev(a)lists.jboss.org
Cc: eb92769(a)jp.ibm.com
Date: 16/09/2020 12:43
Subject: UnsupportedOperationException in
CombinedInterceptorAndDecoratorStackMethodHandler.invoke
Hello Everyone
I have a customer with the following exception
Caused by: org.jboss.weld.exceptions.UnsupportedOperationException:
at
org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:49)
at jp.co
.jfe_steel.JAX01.persistence.shared.dao.impl.multiDs.RefNoxa_DaoImpl$Proxy$_$$_WeldSubclass.create(Unknown
Source)
at jp.co.jfe_steel.JAX01.biz
.A1.logic.SqlDaoConnect_Test_Logic.connectRefNoxaTest(SqlDaoConnect_Test_Logic.java:73)
I'm still trying to get source for the customer's classes. In the
meanwhile my attention was drawn to
https://issues.redhat.com/browse/WELD-2407 - which looks relevant but it
says it was fixed on 2.4.5 and my customer is running with weld 2.4.8
The customer is on a tight deadline, so while I am waiting for source I am
going to try and see if I can recreate that error in any way at all. And I
thought I would ask if you have any suggestions, questions you think I
should ask, or juts general background on what causes this problem?
Regards
Benjamin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
5 years, 6 months
UnsupportedOperationException in CombinedInterceptorAndDecoratorStackMethodHandler.invoke
by Benjamin Confino
Hello Everyone
I have a customer with the following exception
Caused by: org.jboss.weld.exceptions.UnsupportedOperationException:
at
org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:49)
at jp.co
.jfe_steel.JAX01.persistence.shared.dao.impl.multiDs.RefNoxa_DaoImpl$Proxy$_$$_WeldSubclass.create(Unknown
Source)
at jp.co.jfe_steel.JAX01.biz
.A1.logic.SqlDaoConnect_Test_Logic.connectRefNoxaTest(SqlDaoConnect_Test_Logic.java:73)
I'm still trying to get source for the customer's classes. In the
meanwhile my attention was drawn to
https://issues.redhat.com/browse/WELD-2407 - which looks relevant but it
says it was fixed on 2.4.5 and my customer is running with weld 2.4.8
The customer is on a tight deadline, so while I am waiting for source I am
going to try and see if I can recreate that error in any way at all. And I
thought I would ask if you have any suggestions, questions you think I
should ask, or juts general background on what causes this problem?
Regards
Benjamin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
5 years, 6 months
Two versions of CDI lite spec?
by Scott Stark
Another thought that came up in responding to a Ladislav question on why I
was creating a PR that was updating to use EE9 apis in CDI lite was that we
could have a version of the spec that extends EE8 and another for EE9. That
would be a more direct path to getting Quarkus to pass a CDI based TCK.
The minimal EE8 dependencies that would have to be updated in EE9 are the
following 5:
[INFO] +- jakarta.enterprise:jakarta.enterprise.cdi-api:jar:3.0.0:compile
[INFO] | +- jakarta.el:jakarta.el-api:jar:4.0.0:compile
[INFO] | +- jakarta.interceptor:jakarta.interceptor-api:jar:2.0.0:compile
[INFO] | \- jakarta.inject:jakarta.inject-api:jar:2.0.0:compile
[INFO] +- jakarta.annotation:jakarta.annotation-api:jar:2.0.0:compile
Another question is whether to have explicit support for aliasing the
corresponding EE8 apis in the EE9 version.
5 years, 6 months
Initial work to get arc to build and run on Ladislav's fork
by Scott Stark
I did a fork of Ladislav's fork to start looking into what would be
required to move quarkus to the CDI 3.0.0 apis using the jakarta package
name. The initial effort just gets the quarkus/independent-projects/arc
subtree to build and pass its tests. It includes some hacks to alias the
following jakarata ee8 classes:
javax.annotation.Priority
javax.enterprise.inject.Alternative
javax.enterprise.inject.Stereotype
The reason for this is that
the io.quarkus.arc.test.stereotypes.StereotypeAlternativeTest test makes
use of a io.quarkus.test.Mock stereotype that comes from the
quarkus-test-common module, and I did not want to go overboard with a
complete replacement of ee8 to start.
This does bring up the question of how to handle aliasing in general. Right
now the aliases require duplication of the DotNames being checked. Instead
of code like:
if (DotNames.PRIORITY.equals(annotation.name())||
DotNames.PRIORITY_JAVAX.equals(annotation.name())) {
alternativePriority = annotation.value().asInt();
}
One could assign an alias to the DotName:
public static final DotName PRIORITY = create(Priority.class,
"javax.annotation.Priority");
And have the DotName.equals deal with names that have assigned aliases?
My fork:
https://github.com/starksm64/quarkus-fork.git
The PR just to show the diffs:
https://github.com/Ladicek/quarkus-fork/pull/6
Note you have to build/run using the staging profile as many of the jakarta
ee 9 apis only exist in the jakarta nexus staging repo.
*Scotts-iMacPro:arc starksm$ mvn -Pstaging clean verify*
*...*
*[**INFO**] *
*------------------------------------------------------------------------*
*[**INFO**] **Reactor Summary for ArC - Parent pom 999-SNAPSHOT:*
*[**INFO**] *
*[**INFO**] ArC - Parent pom ................................... **SUCCESS**
[ 1.308 s]*
*[**INFO**] CDI Lite Extensions - API .......................... **SUCCESS**
[ 2.606 s]*
*[**INFO**] ArC - Runtime ...................................... **SUCCESS**
[ 1.670 s]*
*[**INFO**] ArC - Processor .................................... **SUCCESS**
[ 3.441 s]*
*[**INFO**] ArC - Tests ........................................ **SUCCESS**
[ 7.037 s]*
*[**INFO**] *
*------------------------------------------------------------------------*
*[**INFO**] **BUILD SUCCESS*
*[**INFO**] *
*------------------------------------------------------------------------*
*[**INFO**] Total time: 16.202 s*
*[**INFO**] Finished at: 2020-09-12T13:29:13-05:00*
*[**INFO**] *
*------------------------------------------------------------------------*
5 years, 6 months
