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
3 months
Propagation of org.jboss.weld.context.ConversationContext.conversations through session failover
by Benjamin Confino
Hello weld
I had a customer report that they were getting conversation not found
exceptions when restarting their server and visiting a url with a ?cid=1
suffix.
After investigation I believe the issue is that weld was acquiring it's
ConversationContext.conversations from the session database via
com.ibm.ws.session.store.db.DatabaseSession.getMultiRowAppData(). Once
weld had retrieved the conversations map it would then decide that since
the map was already in the session attributes there was no need to put it
back into the attributes.
This means that Liberty did not realise the conversations map had been
updated, and did not store it's updated state into the database when the
server shut down again.
I have submitted a pair of pull requests that asks weld to mark the
conversation map as dirty upon access - this behaviour is gated behind
ConfigurationKey.RESET_HTTP_SESSION_ATTR_ON_BEAN_ACCESS - I have tested
it locally and it works. The next step is to prepare a test fix for the
customer to verify. However I wanted to send you this quick note to keep
you in the loop.
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, 11 months
Re: [weld-dev] Odd type assignability test
by Matej Novotny
Forwarding this email to weld-dev to make it public
So, the Foo<String> is the required parameterized type here and Foo<E> is parameterized bean type.
And from CDI spec[1]:
> A parameterized bean type is considered assignable to a parameterized required type if they have identical raw type and for each parameter:
> * the required type parameter is an actual type, the bean type parameter is a type variable and the actual type is assignable to the upper bound, if any, of the type variable, or
Isn't that the same case? Or am I just running low on caffeine? :)
Matej
_________________________________________________________________________________
[1] https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#assignable_parameters
----- Original Message -----
> From: "Laird Nelson" <ljnelson(a)gmail.com>
> To: "Matej Novotny" <manovotn(a)redhat.com>
> Sent: Sunday, April 26, 2020 10:52:57 PM
> Subject: Odd type assignability test
>
> Hello; I ran across this test during some code reading to better understand
> type assignability. It's in BeanTypeAssignabilityTest.java:
>
> @Test
> public <E> void testStringFooMatchesVariableFoo() throws Exception {
> Type stringFooType = new TypeLiteral<Foo<String>>() {
> }.getType();
> Type variableFooType = new TypeLiteral<Foo<E>>() {
> }.getType();
> Assert.assertTrue("Foo<String> should match Foo<E>",
> getRules().matches(stringFooType, variableFooType));
> }
>
> Am I reading this right? Is this saying that a reference of type
> Foo<String> should be able to receive a Foo<E>, where E doesn't extend
> String?
>
> I understand that any method that declares a type variable E and returns a
> Foo<E> will happen to produce a compatible reference. That is:
>
> public <E> Foo<E> blatz() { /* ... */ }
>
> can be called like this:
>
> final Foo<String> foo = blatz(); // should work; E's upper bounds will be
> String here
>
> But in this test, E has no upper bounds, so how does it work?
>
> Thanks,
> Laird
>
5 years, 11 months
Re: [weld-dev] [cdi-dev] How would I go about getting a snapshot build of Weld out?
by Matej Novotny
Hmm, arq. test enricher has some ancient dependencies. In fact, they rely on CDI 1.0 (and therefore Weld 1.x). Looking closely at the code, it looks like Weld dependency is only needed for tests, for actual impl, CDI will do.
And the test can be re-written to avoid using Weld internal completely assuming we are on CDI 2.0+, here is how - https://github.com/arquillian/arquillian-core/pull/239. With this change you only need to pass in CDI SE impl as test dependency and it will work (still means you need one release for another though, so one has to release without tests passing).
However, the actual issue in Arq. is that it now looks for now outdated annotation[1].
Which I presume is something you have fixed locally? I did check your repos but couldn't find fork of Arq. core. I can fix that as well if you don't have it already.
I've also checked other repos:
* The core PR[2] you closed was built from Weld's 3.0 branch which is wrong, we need that against current master to be up to date
- on the PR you said you have something else already, can you push it please? If you don't have it, I can do that as well; I just don't want to duplicate work
* API PR[3] misses one commit from current master, otherwise it's good
Regards
Matej
______________________________________________________________________________________________
[1] https://github.com/arquillian/arquillian-core/blob/master/testenrichers/c...
[2] https://github.com/weld/core/pull/1956
[3] https://github.com/weld/api/pull/91
----- Original Message -----
> From: "Scott Stark" <sstark(a)redhat.com>
> To: "Matej Novotny" <manovotn(a)redhat.com>
> Cc: "cdi-dev" <cdi-dev(a)lists.jboss.org>, "weld-dev" <weld-dev(a)lists.jboss.org>
> Sent: Wednesday, April 15, 2020 8:44:37 PM
> Subject: Re: [cdi-dev] How would I go about getting a snapshot build of Weld out?
>
> So I have gotten all of the Weld test passing after creating updates to the
> arquillian-core and arquillian-weld-embedded projects. We will need a
> release of the arquillian-core which in turn needs a release of
> weld-core-impl, so a bit of circularity there due to the testenricher-cdi
> dependency.
>
> *[**INFO**] *
> *------------------------------------------------------------------------*
>
> *[**INFO**] **Reactor Summary for Weld Parent 4.0.0-SNAPSHOT:*
>
> *[**INFO**] *
>
> *[**INFO**] Weld Parent ........................................ **SUCCESS**
> [ 1.804 s]*
>
> *[**INFO**] Weld Implementation (Core) ......................... **SUCCESS**
> [ 4.674 s]*
>
> *[**INFO**] Weld EJB ........................................... **SUCCESS**
> [ 0.421 s]*
>
> *[**INFO**] Weld JSF ........................................... **SUCCESS**
> [ 0.969 s]*
>
> *[**INFO**] Weld JTA ........................................... **SUCCESS**
> [ 0.244 s]*
>
> *[**INFO**] Weld Web ........................................... **SUCCESS**
> [ 0.889 s]*
>
> *[**INFO**] Weld Probe Parent .................................. **SUCCESS**
> [ 0.119 s]*
>
> *[**INFO**] Weld Probe Core .................................... **SUCCESS**
> [ 2.204 s]*
>
> *[**INFO**] Weld Test Utilities ................................ **SUCCESS**
> [ 0.320 s]*
>
> *[**INFO**] weld-probe-tests ................................... **SUCCESS**
> [ 0.989 s]*
>
> *[**INFO**] Weld Core BOM ...................................... **SUCCESS**
> [ 0.023 s]*
>
> *[**INFO**] Weld Unit Tests .................................... **SUCCESS**
> [ 3.693 s]*
>
> *[**INFO**] AtInject TCK runner for Weld ....................... **SUCCESS**
> [ 1.721 s]*
>
> *[**INFO**] Weld Environment Common ............................ **SUCCESS**
> [ 0.930 s]*
>
> *[**INFO**] Weld SE Parent ..................................... **SUCCESS**
> [ 0.110 s]*
>
> *[**INFO**] Weld SE (Core) ..................................... **SUCCESS**
> [ 12.869 s]*
>
> *[**INFO**] Weld SE (Uber Jar) ................................. **SUCCESS**
> [ 0.712 s]*
>
> *[**INFO**] Weld SE Tests ...................................... **SUCCESS**
> [01:15 min]*
>
> *[**INFO**] *
> *------------------------------------------------------------------------*
>
> *[**INFO**] **BUILD SUCCESS*
>
> *[**INFO**] *
> *------------------------------------------------------------------------*
>
> *[**INFO**] Total time: 01:48 min*
>
> *[**INFO**] Finished at: 2020-04-15T13:26:42-05:00*
>
> *[**INFO**] *
> *------------------------------------------------------------------------*
>
>
>
>
>
> On Wed, Apr 15, 2020 at 9:25 AM Scott Stark <sstark(a)redhat.com> wrote:
>
> > Ok thanks, I'll replace the current PR as I started over and have been
> > trying to fix some of the current arquillian and weld test failures.
> >
> > The GF team uses the glassfish-dev(a)eclipse.org mailing list for their
> > communications.
> >
> > On Wed, Apr 15, 2020 at 4:41 AM Matej Novotny <manovotn(a)redhat.com> wrote:
> >
> >> Hi Scott,
> >>
> >> this question is a better fit for weld-dev mailing list, so adding that
> >> to Cc.
> >>
> >> I was about to start a conversation on something similar as this has been
> >> on my TODO list for some time.
> >> I am after information on how to get in touch with GF team - about how
> >> they execute TCKs (namely CDI ofc) and how to replace various weld
> >> versions
> >> inside it so that we can verify things work. Do you happen to know what
> >> channels we can use to coordinate there?
> >>
> >> As for Weld, I will be creating 3.x branch to host current version as
> >> that will linger for some time. Then I can look into your PRs and get
> >> master to 4.x.
> >> We do not have a CI setup to publish snapshots, but I can do Alpha/Beta
> >> releases as needed. We should get it into somewhat stable state before we
> >> do that though, a release that doesn't even know if it's tests work is not
> >> very useful.
> >> Therefore, I think we should start with those test failures and possibly
> >> arq container fix.
> >> However, I do not know how to release arq container; looks like Bartosz
> >> did the last release, so he might know once we find out what's wrong
> >> there.
> >>
> >> Later this week or early next week I should be able to pay full attention
> >> to this and help you with it.
> >>
> >> Regards
> >> Matej
> >>
> >> ----- Original Message -----
> >> > From: "Scott Stark" <sstark(a)redhat.com>
> >> > To: "cdi-dev" <cdi-dev(a)lists.jboss.org>
> >> > Sent: Friday, April 10, 2020 8:10:53 PM
> >> > Subject: [cdi-dev] How would I go about getting a snapshot build of
> >> Weld out?
> >> >
> >> > Other Jakarta projects are in need of a Jakarta EE 9 based weld
> >> > implementation to even compile some aspects of their project it seems.
> >> Both
> >> > Glassfish and Batch have asked about it. We also need it to fully test
> >> > Hibernate Validator.
> >> >
> >> > I have done another round of updates to new Jakarta EE 9 api releases
> >> and
> >> > updated additional API uses. There are still issues with errors in core
> >> and
> >> > SE tests due to problems with the arquillian weld container that I'll
> >> start
> >> > looking into, but I would like to get a snapshot build out. Is there a
> >> CI
> >> > environment I can use for that?
> >> >
> >> > Current info on the changes and how to build the snapshot:
> >> > https://github.com/starksm64/core/blob/4.0/JakartaEE9.adoc
> >> >
> >> > [INFO]
> >> > ------------------------------------------------------------------------
> >> >
> >> > [INFO] Reactor Summary for Weld Parent 4.0.0-SNAPSHOT:
> >> >
> >> > [INFO]
> >> >
> >> > [INFO] Weld Parent ........................................ SUCCESS [
> >> 1.636
> >> > s]
> >> >
> >> > [INFO] Weld Implementation (Core) ......................... SUCCESS [
> >> 3.756
> >> > s]
> >> >
> >> > [INFO] Weld EJB ........................................... SUCCESS [
> >> 0.287
> >> > s]
> >> >
> >> > [INFO] Weld JSF ........................................... SUCCESS [
> >> 0.978
> >> > s]
> >> >
> >> > [INFO] Weld JTA ........................................... SUCCESS [
> >> 0.182
> >> > s]
> >> >
> >> > [INFO] Weld Web ........................................... SUCCESS [
> >> 0.906
> >> > s]
> >> >
> >> > [INFO] Weld Probe Parent .................................. SUCCESS [
> >> 0.107
> >> > s]
> >> >
> >> > [INFO] Weld Probe Core .................................... SUCCESS [
> >> 2.104
> >> > s]
> >> >
> >> > [INFO] Weld Test Utilities ................................ SUCCESS [
> >> 0.254
> >> > s]
> >> >
> >> > [INFO] weld-probe-tests ................................... SUCCESS [
> >> 1.091
> >> > s]
> >> >
> >> > [INFO] Weld Core BOM ...................................... SUCCESS [
> >> 0.001
> >> > s]
> >> >
> >> > [INFO] Weld Unit Tests .................................... SUCCESS [
> >> 3.268
> >> > s]
> >> >
> >> > [INFO] AtInject TCK runner for Weld ....................... SUCCESS [
> >> 1.596
> >> > s]
> >> >
> >> > [INFO] Weld Environment Common ............................ SUCCESS [
> >> 0.912
> >> > s]
> >> >
> >> > [INFO] Weld SE Parent ..................................... SUCCESS [
> >> 0.101
> >> > s]
> >> >
> >> > [INFO] Weld SE (Core) ..................................... FAILURE [
> >> 7.875
> >> > s]
> >> >
> >> > [INFO] Weld SE (Uber Jar) ................................. SUCCESS [
> >> 0.165
> >> > s]
> >> >
> >> > [INFO] Weld SE Tests ...................................... FAILURE [
> >> 1.070
> >> > s]
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > cdi-dev mailing list
> >> > cdi-dev(a)lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >> >
> >> > Note that for all code provided on this list, the provider licenses the
> >> code
> >> > under the Apache License, Version 2
> >> > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> >> > provided on this list, the provider waives all patent and other
> >> intellectual
> >> > property rights inherent in such information.
> >>
> >>
>
5 years, 12 months
test
by Scott Stark
seem to be having some issues subscribing to this list..testing
6 years
Validating for fields that are annotated with both EJB and Inject
by Benjamin Confino
Hello weld
I had a customer with an issue that I believe occurred because they
annotated a field with both @Inject and @EJB. This has given me two
questions:
1) Should weld throw an error when a field is annotated with both
annotations?
2) If so is the correct way to add something like
if (ij.getAnnotated().isAnnotationPresent(Inject.class) &&
ij.getAnnotated().isAnnotationPresent(EJB.class)) {
throw ...
}
to Validator.validateInjectionPointForDefinitionErrors()
If so I'm willing to create a pull request, all I'd need is for you to
tell me what the error message should say and please point me to which
test I should expand to cover this case.
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
6 years
Re: [weld-dev] [cdi-dev] How would I go about getting a snapshot build of Weld out?
by Matej Novotny
Hi Scott,
this question is a better fit for weld-dev mailing list, so adding that to Cc.
I was about to start a conversation on something similar as this has been on my TODO list for some time.
I am after information on how to get in touch with GF team - about how they execute TCKs (namely CDI ofc) and how to replace various weld versions inside it so that we can verify things work. Do you happen to know what channels we can use to coordinate there?
As for Weld, I will be creating 3.x branch to host current version as that will linger for some time. Then I can look into your PRs and get master to 4.x.
We do not have a CI setup to publish snapshots, but I can do Alpha/Beta releases as needed. We should get it into somewhat stable state before we do that though, a release that doesn't even know if it's tests work is not very useful.
Therefore, I think we should start with those test failures and possibly arq container fix.
However, I do not know how to release arq container; looks like Bartosz did the last release, so he might know once we find out what's wrong there.
Later this week or early next week I should be able to pay full attention to this and help you with it.
Regards
Matej
----- Original Message -----
> From: "Scott Stark" <sstark(a)redhat.com>
> To: "cdi-dev" <cdi-dev(a)lists.jboss.org>
> Sent: Friday, April 10, 2020 8:10:53 PM
> Subject: [cdi-dev] How would I go about getting a snapshot build of Weld out?
>
> Other Jakarta projects are in need of a Jakarta EE 9 based weld
> implementation to even compile some aspects of their project it seems. Both
> Glassfish and Batch have asked about it. We also need it to fully test
> Hibernate Validator.
>
> I have done another round of updates to new Jakarta EE 9 api releases and
> updated additional API uses. There are still issues with errors in core and
> SE tests due to problems with the arquillian weld container that I'll start
> looking into, but I would like to get a snapshot build out. Is there a CI
> environment I can use for that?
>
> Current info on the changes and how to build the snapshot:
> https://github.com/starksm64/core/blob/4.0/JakartaEE9.adoc
>
> [INFO]
> ------------------------------------------------------------------------
>
> [INFO] Reactor Summary for Weld Parent 4.0.0-SNAPSHOT:
>
> [INFO]
>
> [INFO] Weld Parent ........................................ SUCCESS [ 1.636
> s]
>
> [INFO] Weld Implementation (Core) ......................... SUCCESS [ 3.756
> s]
>
> [INFO] Weld EJB ........................................... SUCCESS [ 0.287
> s]
>
> [INFO] Weld JSF ........................................... SUCCESS [ 0.978
> s]
>
> [INFO] Weld JTA ........................................... SUCCESS [ 0.182
> s]
>
> [INFO] Weld Web ........................................... SUCCESS [ 0.906
> s]
>
> [INFO] Weld Probe Parent .................................. SUCCESS [ 0.107
> s]
>
> [INFO] Weld Probe Core .................................... SUCCESS [ 2.104
> s]
>
> [INFO] Weld Test Utilities ................................ SUCCESS [ 0.254
> s]
>
> [INFO] weld-probe-tests ................................... SUCCESS [ 1.091
> s]
>
> [INFO] Weld Core BOM ...................................... SUCCESS [ 0.001
> s]
>
> [INFO] Weld Unit Tests .................................... SUCCESS [ 3.268
> s]
>
> [INFO] AtInject TCK runner for Weld ....................... SUCCESS [ 1.596
> s]
>
> [INFO] Weld Environment Common ............................ SUCCESS [ 0.912
> s]
>
> [INFO] Weld SE Parent ..................................... SUCCESS [ 0.101
> s]
>
> [INFO] Weld SE (Core) ..................................... FAILURE [ 7.875
> s]
>
> [INFO] Weld SE (Uber Jar) ................................. SUCCESS [ 0.165
> s]
>
> [INFO] Weld SE Tests ...................................... FAILURE [ 1.070
> s]
>
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code
> under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other intellectual
> property rights inherent in such information.
6 years
