On Tue, Dec 8, 2020 at 4:52 PM Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:
Hi Arjan,
Sounds like a Soteria issue I assume that means you will need to do a point release of Soteria? Btw you didn’t cc in Matej unless via BCC.
Hmmm, Matej does show up in the CC in the email in my sent folder, but not in this reply. Strange. I added him again.
Technically it's not Soteria itself, but the separate jar for the bean decorator SPI implementation. For consistency though, might be better to do a point release for the full soteria project indeed.
Btw, I've been trying to get a public API for this added to CDI, so GlassFish (and other servers using both Soteria and Weld) don't have to rely on these very deep internals, which are very fragile and difficult to use (
https://github.com/eclipse-ee4j/cdi/issues/459).
Kind regards,
Arjan Tijms
Steve
Hi,
I found the issue. Between RC2 and RC3 I had to rework the Weld Bean Decorator SPI implementation, since Weld no longer exports EnhancedAnnotated and from the top of my head ImmutableBeanAttributes.
So there's a few solutions possible here:
1. Do a PR to Weld to include those exports and revert the Soteria SPI for Weld to the original version
2. Drop the SPI implementation entirely. This would stop Jakarta Security build-in beans to be decorable (a regression), but the TCK doesn't have tests for this, so it will pass.
3. Debug the new Weld SPI implementation to see why it fails.
I cc'ed Matej from Red Hat who might have some input/advice on this.
Sorry, I didn't look carefully. The separate run fails there too. Although Soteria itself is the same between the failing run against GF RC3 and the passing run against GF RC2.
_______________________________________________
glassfish-dev mailing list
glassfish-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/glassfish-dev