Re: Release?

2021-10-06 Thread Romain Manni-Bucau 
+1 to get a *new* SPI for the allocation (ok if we test if definingService
is an instanceof it and reuse the same instance but should stay split)
+1 to port the logic of tomee to OWB around unsafe with new method handles
if it does not trigger any warning by default (was the reason to bypass
Unsafe constructor when defining service is set).

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 6 oct. 2021 à 14:25, Jean-Louis MONTEIRO  a
écrit :

> For the sake of clarity here is our problem.
> We want to support JDK 17 in TomEE.
>
> For our proxy creation, we were used to using Unsafe (like OWB and a lot
> more).
> We changed that to use a method handles lookup, but still from JDK 17+ it
> does not work either.
> We have a similar service ClassDefiner in TomEE where we do the switch
> automatically to ClassLoader.defineClass when it's available to create the
> proxy from the byte array.
>
> OWB does that using explicit configuration but overall it is the same.
> Where it becomes different is after ...
>
> As soon as you have created the Class with the byte array, you somehow need
> to instantiate it.
> In TomEE, we still by default use Unsafe.allocateInstance because there is
> no replacement for now and it is still working under JDK17.
>
> For OWB, if you switch to using ClassLoader.defineClass for JDK 17, then
> the default constructor is used and Unsafe is totally bypassed.
>
> I'm not questioning the choice made, but the fact we need to be able to
> override that behavior in TomEE at least.
> We can't always use the default constructor. Using Unsafe.allocateInstance
> won't call the default constructor.
>
> If we can override OWB default behavior, then CDI beans managed by OWB and
> beans managed by TomEE will work the same way and users can switch from one
> to the other without side effects.
>
> So functionally it's the same with my change.
> I'm almost sure no one is creating it's own DefiningClassService
> implementation but the user facing interface argument is acceptable. I'd go
> with a default method in the interface or create an
> InstanciatingClassService even though it's overkill in my opinion.
>
> The comments in the tests should have been removed. I first wanted to add a
> test to reproduce the issue we had in TomEE, but actually
> InterceptionOfBeanWithConstructorInjectionTest already shows that using
> default constructor instead of Unsafe.allocateInstance breaks OWB itself.
> It also breaks a couple of other things in TomEE like the security
> extension.
>
>
>
>
>
>
> Le mer. 6 oct. 2021 à 11:17, Romain Manni-Bucau  a
> écrit :
>
> > Hi JL,
> >
> > It looks weird because we already had a fallback to use the constructor -
> > and BTW i'm not sure the commented part of the test should be.
> > So this shouldn't help TomEE.
> >
> > Do you have a test where this change helps?
> >
> > side note: we likely don't want to break the SPI since it is an user
> facing
> > part.
> > I saw you mentionned a default method but we should probably check we
> need
> > it at all before (not sure how tomee is different there on java 17 since
> > the extension points were already set up IIRC).
> >
> > Happy to discuss on slack if it is easier - know mails can be complicated
> > for such things ;).
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le mer. 6 oct. 2021 à 10:14, Jean-Louis MONTEIRO  a
> > écrit :
> >
> > > Thanks Thomas
> > >
> > > I've created https://issues.apache.org/jira/browse/OWB-1392
> > > And I pushed
> > >
> > >
> >
> https://github.com/apache/openwebbeans/commit/2af6184ee5ec6b474f037b3c5768c82bba136722
> > >
> > > I'd appreciate feedback, review and comments. Should have created a PR
> > > sorry.
> > > Functionally, it's the same as previously, but it allows TomEE to
> > override
> > > the instanciation part to be consistent.
> > >
> > >
> > > Le mar. 5 oct. 2021 à 23:11, Thomas Andraschko <
> > > andraschko.tho...@gmail.com>
> > > a écrit :
> > >
> > > > AFAIK we didnt start the process yet, so we can wait for your fix
> > > >
> > > > Am Di., 5. Okt. 2021 um 22:27 Uhr schrieb Jean-Louis MONTEIRO <
> > > > jeano...@gmail.com>:
> > > >
> > > > > I have an issue with OWB in TomEE under JDK 17
> > > > > I think I can workaround it, but I'd need a small change in OWB.
> > > > >
> > > > > Can we reroll it after my fix?
> > > > >
> > > > > Le lun. 4 oct. 2021 à 09:29,

Re: Release?

2021-10-06 Thread Jean-Louis MONTEIRO 
For the sake of clarity here is our problem.
We want to support JDK 17 in TomEE.

For our proxy creation, we were used to using Unsafe (like OWB and a lot
more).
We changed that to use a method handles lookup, but still from JDK 17+ it
does not work either.
We have a similar service ClassDefiner in TomEE where we do the switch
automatically to ClassLoader.defineClass when it's available to create the
proxy from the byte array.

OWB does that using explicit configuration but overall it is the same.
Where it becomes different is after ...

As soon as you have created the Class with the byte array, you somehow need
to instantiate it.
In TomEE, we still by default use Unsafe.allocateInstance because there is
no replacement for now and it is still working under JDK17.

For OWB, if you switch to using ClassLoader.defineClass for JDK 17, then
the default constructor is used and Unsafe is totally bypassed.

I'm not questioning the choice made, but the fact we need to be able to
override that behavior in TomEE at least.
We can't always use the default constructor. Using Unsafe.allocateInstance
won't call the default constructor.

If we can override OWB default behavior, then CDI beans managed by OWB and
beans managed by TomEE will work the same way and users can switch from one
to the other without side effects.

So functionally it's the same with my change.
I'm almost sure no one is creating it's own DefiningClassService
implementation but the user facing interface argument is acceptable. I'd go
with a default method in the interface or create an
InstanciatingClassService even though it's overkill in my opinion.

The comments in the tests should have been removed. I first wanted to add a
test to reproduce the issue we had in TomEE, but actually
InterceptionOfBeanWithConstructorInjectionTest already shows that using
default constructor instead of Unsafe.allocateInstance breaks OWB itself.
It also breaks a couple of other things in TomEE like the security
extension.






Le mer. 6 oct. 2021 à 11:17, Romain Manni-Bucau  a
écrit :

> Hi JL,
>
> It looks weird because we already had a fallback to use the constructor -
> and BTW i'm not sure the commented part of the test should be.
> So this shouldn't help TomEE.
>
> Do you have a test where this change helps?
>
> side note: we likely don't want to break the SPI since it is an user facing
> part.
> I saw you mentionned a default method but we should probably check we need
> it at all before (not sure how tomee is different there on java 17 since
> the extension points were already set up IIRC).
>
> Happy to discuss on slack if it is easier - know mails can be complicated
> for such things ;).
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mer. 6 oct. 2021 à 10:14, Jean-Louis MONTEIRO  a
> écrit :
>
> > Thanks Thomas
> >
> > I've created https://issues.apache.org/jira/browse/OWB-1392
> > And I pushed
> >
> >
> https://github.com/apache/openwebbeans/commit/2af6184ee5ec6b474f037b3c5768c82bba136722
> >
> > I'd appreciate feedback, review and comments. Should have created a PR
> > sorry.
> > Functionally, it's the same as previously, but it allows TomEE to
> override
> > the instanciation part to be consistent.
> >
> >
> > Le mar. 5 oct. 2021 à 23:11, Thomas Andraschko <
> > andraschko.tho...@gmail.com>
> > a écrit :
> >
> > > AFAIK we didnt start the process yet, so we can wait for your fix
> > >
> > > Am Di., 5. Okt. 2021 um 22:27 Uhr schrieb Jean-Louis MONTEIRO <
> > > jeano...@gmail.com>:
> > >
> > > > I have an issue with OWB in TomEE under JDK 17
> > > > I think I can workaround it, but I'd need a small change in OWB.
> > > >
> > > > Can we reroll it after my fix?
> > > >
> > > > Le lun. 4 oct. 2021 à 09:29, Jean-Baptiste Onofré 
> a
> > > > écrit :
> > > >
> > > > > +1
> > > > >
> > > > > Regards
> > > > > JB
> > > > >
> > > > > On 03/10/2021 20:56, Romain Manni-Bucau wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > We fixed a few issues:
> > > > > >
> > > > > > PTKeySummaryAssigneeStatus
> > > > > > [image: Major] [image: Bug] OWB-1298
> > > > > > 
> > > WebsocketUserManager
> > > > > > ambigious resolution Jakarta Faces
> > > > > >  Unassigned
> > RESOLVED
> > > > > > [image: Major] [image: Bug] OWB-1387
> > > > > > 
> > > > > > @Destroyed(ApplicationScoped.class)
> > > > > > not thrown when @Destroyed(RequestScoped.class) exists
> > > > > >  Arne Limburg
> > > > > > <
> https://issues.apache.org/jira/secure/ViewProfile.jspa?name=arne>
> > > > > CLOSED
> > >

Re: Switching from Unsafe to ClassLoaderProxyService

2021-10-06 Thread Romain Manni-Bucau 
it is because the quick and dirty change leds to use 2 services instance so
test is right there and quick and dirty change is wrong ;)

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 6 oct. 2021 à 10:21, Jean-Louis MONTEIRO  a
écrit :

> Quick and dirty change in AbstractProxyFactory
>
> definingService = new ClassLoaderProxyService(webBeansContext); //
> webBeansContext.getService(DefiningClassService.class);
>
> `mvn clean install` under JDK8
>
> [ERROR] Failures:
> > [ERROR]   ClassLoaderProxyServiceTest.defineInProxy:45
> >
> expected: >
> > but
> >
> was: > >
> > [ERROR]   InterceptorAnnotatedDiscoveryTest.discover:62 expected:<[foo]>
> > but was:<[bar]>
> > [ERROR]   NormalScopeProxyFactoryTest.testProtectedMethod:321
> > expected:<42> but was:<0>
> > [ERROR] Errors:
> > [ERROR]
> >
> InterceptionOfBeanWithConstructorInjectionTest.checkBeanWasBuiltWithItsConstructorAndIntercepted:54->AbstractUnitTest.startContainer:231->AbstractUnitTest.inject:251
> > » IllegalState
> > [INFO]
> > [ERROR] Tests run: 589, Failures: 3, Errors: 1, Skipped: 5
> > [
>
>
>  Haven't got time to debug and look at why yet
>
> Le mer. 6 oct. 2021 à 10:14, Jean-Louis MONTEIRO  a
> écrit :
>
> > Haven't look quickly but I can easily change the default again and run
> the
> > build again.
> >
> > Le mer. 6 oct. 2021 à 08:10, Romain Manni-Bucau 
> a
> > écrit :
> >
> >> It is the only identified/expected one at least, did you spot another
> one?
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau  |  Blog
> >>  | Old Blog
> >>  | Github <
> >> https://github.com/rmannibucau> |
> >> LinkedIn  | Book
> >> <
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >> >
> >>
> >>
> >> Le mar. 5 oct. 2021 à 22:07, Jean-Louis MONTEIRO  a
> >> écrit :
> >>
> >> > I'm not sure it's only package scope methods ...
> >> >
> >> > Le mar. 5 oct. 2021 à 21:59, Romain Manni-Bucau <
> rmannibu...@gmail.com>
> >> a
> >> > écrit :
> >> >
> >> > > Well it is a config in owb.properties but as mentionned it will not
> >> > support
> >> > > package scope methods proxying by design (but it is in the spec).
> >> > >
> >> > > For this, add-opens are required (or a fake module-info workaround).
> >> > >
> >> > > Le mar. 5 oct. 2021 à 21:48, Jean-Louis MONTEIRO <
> jeano...@gmail.com>
> >> a
> >> > > écrit :
> >> > >
> >> > > > Here is what I have done 
> >> > > >
> >> > > > Switch from Unsafe to ClassLoaderProxyService in the
> >> > > AbstractProxyFactory.
> >> > > > Then, command line and run `mvn clean install`
> >> > > >
> >> > > > It fails under JDK 8 and under JDK17
> >> > > >
> >> > > > Le mar. 5 oct. 2021 à 20:40, Romain Manni-Bucau <
> >> rmannibu...@gmail.com
> >> > >
> >> > > a
> >> > > > écrit :
> >> > > >
> >> > > > > Hi,
> >> > > > >
> >> > > > > Not sure what you mean but we should build on jdk 8 and run on
> >> 8-18.
> >> > > > >
> >> > > > > Le mar. 5 oct. 2021 à 20:29, Jean-Louis Monteiro <
> >> > > > jlmonte...@tomitribe.com
> >> > > > > >
> >> > > > > a écrit :
> >> > > > >
> >> > > > > > Hi,
> >> > > > > >
> >> > > > > > While investigating some OWB issues, I tried moving default
> >> Unsafe
> >> > to
> >> > > > > > ClassLoaderProxyService, but it looks like I can't build OWB
> >> > anymore,
> >> > > > on
> >> > > > > > JDK8 or even JDK17.
> >> > > > > >
> >> > > > > > Isn't it supposed to be working out of the box?
> >> > > > > >
> >> > > > > >
> >> > > > > > --
> >> > > > > > Jean-Louis Monteiro
> >> > > > > > http://twitter.com/jlouismonteiro
> >> > > > > > http://www.tomitribe.com
> >> > > > > >
> >> > > > >
> >> > > >
> >> > > >
> >> > > > --
> >> > > > Jean-Louis
> >> > > >
> >> > >
> >> >
> >> >
> >> > --
> >> > Jean-Louis
> >> >
> >>
> >
> >
> > --
> > Jean-Louis
> >
>
>
> --
> Jean-Louis
>

Re: Release?

2021-10-06 Thread Romain Manni-Bucau 
Hi JL,

It looks weird because we already had a fallback to use the constructor -
and BTW i'm not sure the commented part of the test should be.
So this shouldn't help TomEE.

Do you have a test where this change helps?

side note: we likely don't want to break the SPI since it is an user facing
part.
I saw you mentionned a default method but we should probably check we need
it at all before (not sure how tomee is different there on java 17 since
the extension points were already set up IIRC).

Happy to discuss on slack if it is easier - know mails can be complicated
for such things ;).

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 6 oct. 2021 à 10:14, Jean-Louis MONTEIRO  a
écrit :

> Thanks Thomas
>
> I've created https://issues.apache.org/jira/browse/OWB-1392
> And I pushed
>
> https://github.com/apache/openwebbeans/commit/2af6184ee5ec6b474f037b3c5768c82bba136722
>
> I'd appreciate feedback, review and comments. Should have created a PR
> sorry.
> Functionally, it's the same as previously, but it allows TomEE to override
> the instanciation part to be consistent.
>
>
> Le mar. 5 oct. 2021 à 23:11, Thomas Andraschko <
> andraschko.tho...@gmail.com>
> a écrit :
>
> > AFAIK we didnt start the process yet, so we can wait for your fix
> >
> > Am Di., 5. Okt. 2021 um 22:27 Uhr schrieb Jean-Louis MONTEIRO <
> > jeano...@gmail.com>:
> >
> > > I have an issue with OWB in TomEE under JDK 17
> > > I think I can workaround it, but I'd need a small change in OWB.
> > >
> > > Can we reroll it after my fix?
> > >
> > > Le lun. 4 oct. 2021 à 09:29, Jean-Baptiste Onofré  a
> > > écrit :
> > >
> > > > +1
> > > >
> > > > Regards
> > > > JB
> > > >
> > > > On 03/10/2021 20:56, Romain Manni-Bucau wrote:
> > > > > Hi all,
> > > > >
> > > > > We fixed a few issues:
> > > > >
> > > > > PTKeySummaryAssigneeStatus
> > > > > [image: Major] [image: Bug] OWB-1298
> > > > > 
> > WebsocketUserManager
> > > > > ambigious resolution Jakarta Faces
> > > > >  Unassigned
> RESOLVED
> > > > > [image: Major] [image: Bug] OWB-1387
> > > > > 
> > > > > @Destroyed(ApplicationScoped.class)
> > > > > not thrown when @Destroyed(RequestScoped.class) exists
> > > > >  Arne Limburg
> > > > > 
> > > > CLOSED
> > > > > [image: Major] [image: Improvement] OWB-1389
> > > > >  Remove destroyed
> > > > instance
> > > > > from memory  Mark
> > > > Struberg
> > > > > <
> > https://issues.apache.org/jira/secure/ViewProfile.jspa?name=struberg>
> > > > > RESOLVED
> > > > > [image: Major] [image: Task] OWB-1390
> > > > >  support
> > > > > javax.enterprise.inject.scan.implicit property
> > > > >  Romain
> Manni-Bucau
> > > > > <
> > > >
> > >
> >
> https://issues.apache.org/jira/secure/ViewProfile.jspa?name=romain.manni-bucau
> > > > >
> > > > > RESOLVED
> > > > > [image: Major] [image: Task] OWB-1391
> > > > > 
> > > > AbstractMetaDataDiscovery
> > > > > ignores classpath entries starting with a common path
> > > > >  Romain
> Manni-Bucau
> > > > > <
> > > >
> > >
> >
> https://issues.apache.org/jira/secure/ViewProfile.jspa?name=romain.manni-bucau
> > > > >
> > > > > RESOLVED
> > > > >
> > > > > I know Thomas can await a few of them so wonder if we should
> trigger
> > a
> > > > > release next week (starting on the 4th) or in the following days.
> > > > >
> > > > > I'd just like to highlight the 1391 changes the way we ignore
> > > duplicated
> > > > > jars/folders in in the classpath so can be worth some testing.
> > > > >
> > > > > No issue to delay from some days the release if it helps.
> > > > >
> > > > > Side note for our beloved tomee siblings: this shouldn't impact you
> > > since
> > > > > you don't reuse that scanning/lifecycle logic so should be a "noop
> > > > release"
> > > > > for you.
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau  |  Blog
> > > > >  | Old Blog
> > > > >  | Github <
> > > > https://github.com/rmannibucau> |
> > > > > LinkedIn  | Book
> > > > > <
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
>

Re: Switching from Unsafe to ClassLoaderProxyService

2021-10-06 Thread Jean-Louis MONTEIRO 
Quick and dirty change in AbstractProxyFactory

definingService = new ClassLoaderProxyService(webBeansContext); //
webBeansContext.getService(DefiningClassService.class);

`mvn clean install` under JDK8

[ERROR] Failures:
> [ERROR]   ClassLoaderProxyServiceTest.defineInProxy:45
> expected:
> but
> was: >
> [ERROR]   InterceptorAnnotatedDiscoveryTest.discover:62 expected:<[foo]>
> but was:<[bar]>
> [ERROR]   NormalScopeProxyFactoryTest.testProtectedMethod:321
> expected:<42> but was:<0>
> [ERROR] Errors:
> [ERROR]
> InterceptionOfBeanWithConstructorInjectionTest.checkBeanWasBuiltWithItsConstructorAndIntercepted:54->AbstractUnitTest.startContainer:231->AbstractUnitTest.inject:251
> » IllegalState
> [INFO]
> [ERROR] Tests run: 589, Failures: 3, Errors: 1, Skipped: 5
> [


 Haven't got time to debug and look at why yet

Le mer. 6 oct. 2021 à 10:14, Jean-Louis MONTEIRO  a
écrit :

> Haven't look quickly but I can easily change the default again and run the
> build again.
>
> Le mer. 6 oct. 2021 à 08:10, Romain Manni-Bucau  a
> écrit :
>
>> It is the only identified/expected one at least, did you spot another one?
>>
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn  | Book
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >
>>
>>
>> Le mar. 5 oct. 2021 à 22:07, Jean-Louis MONTEIRO  a
>> écrit :
>>
>> > I'm not sure it's only package scope methods ...
>> >
>> > Le mar. 5 oct. 2021 à 21:59, Romain Manni-Bucau 
>> a
>> > écrit :
>> >
>> > > Well it is a config in owb.properties but as mentionned it will not
>> > support
>> > > package scope methods proxying by design (but it is in the spec).
>> > >
>> > > For this, add-opens are required (or a fake module-info workaround).
>> > >
>> > > Le mar. 5 oct. 2021 à 21:48, Jean-Louis MONTEIRO 
>> a
>> > > écrit :
>> > >
>> > > > Here is what I have done 
>> > > >
>> > > > Switch from Unsafe to ClassLoaderProxyService in the
>> > > AbstractProxyFactory.
>> > > > Then, command line and run `mvn clean install`
>> > > >
>> > > > It fails under JDK 8 and under JDK17
>> > > >
>> > > > Le mar. 5 oct. 2021 à 20:40, Romain Manni-Bucau <
>> rmannibu...@gmail.com
>> > >
>> > > a
>> > > > écrit :
>> > > >
>> > > > > Hi,
>> > > > >
>> > > > > Not sure what you mean but we should build on jdk 8 and run on
>> 8-18.
>> > > > >
>> > > > > Le mar. 5 oct. 2021 à 20:29, Jean-Louis Monteiro <
>> > > > jlmonte...@tomitribe.com
>> > > > > >
>> > > > > a écrit :
>> > > > >
>> > > > > > Hi,
>> > > > > >
>> > > > > > While investigating some OWB issues, I tried moving default
>> Unsafe
>> > to
>> > > > > > ClassLoaderProxyService, but it looks like I can't build OWB
>> > anymore,
>> > > > on
>> > > > > > JDK8 or even JDK17.
>> > > > > >
>> > > > > > Isn't it supposed to be working out of the box?
>> > > > > >
>> > > > > >
>> > > > > > --
>> > > > > > Jean-Louis Monteiro
>> > > > > > http://twitter.com/jlouismonteiro
>> > > > > > http://www.tomitribe.com
>> > > > > >
>> > > > >
>> > > >
>> > > >
>> > > > --
>> > > > Jean-Louis
>> > > >
>> > >
>> >
>> >
>> > --
>> > Jean-Louis
>> >
>>
>
>
> --
> Jean-Louis
>


-- 
Jean-Louis

Re: Switching from Unsafe to ClassLoaderProxyService

2021-10-06 Thread Jean-Louis MONTEIRO 
Haven't look quickly but I can easily change the default again and run the
build again.

Le mer. 6 oct. 2021 à 08:10, Romain Manni-Bucau  a
écrit :

> It is the only identified/expected one at least, did you spot another one?
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mar. 5 oct. 2021 à 22:07, Jean-Louis MONTEIRO  a
> écrit :
>
> > I'm not sure it's only package scope methods ...
> >
> > Le mar. 5 oct. 2021 à 21:59, Romain Manni-Bucau 
> a
> > écrit :
> >
> > > Well it is a config in owb.properties but as mentionned it will not
> > support
> > > package scope methods proxying by design (but it is in the spec).
> > >
> > > For this, add-opens are required (or a fake module-info workaround).
> > >
> > > Le mar. 5 oct. 2021 à 21:48, Jean-Louis MONTEIRO 
> a
> > > écrit :
> > >
> > > > Here is what I have done 
> > > >
> > > > Switch from Unsafe to ClassLoaderProxyService in the
> > > AbstractProxyFactory.
> > > > Then, command line and run `mvn clean install`
> > > >
> > > > It fails under JDK 8 and under JDK17
> > > >
> > > > Le mar. 5 oct. 2021 à 20:40, Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >
> > > a
> > > > écrit :
> > > >
> > > > > Hi,
> > > > >
> > > > > Not sure what you mean but we should build on jdk 8 and run on
> 8-18.
> > > > >
> > > > > Le mar. 5 oct. 2021 à 20:29, Jean-Louis Monteiro <
> > > > jlmonte...@tomitribe.com
> > > > > >
> > > > > a écrit :
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > While investigating some OWB issues, I tried moving default
> Unsafe
> > to
> > > > > > ClassLoaderProxyService, but it looks like I can't build OWB
> > anymore,
> > > > on
> > > > > > JDK8 or even JDK17.
> > > > > >
> > > > > > Isn't it supposed to be working out of the box?
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Jean-Louis Monteiro
> > > > > > http://twitter.com/jlouismonteiro
> > > > > > http://www.tomitribe.com
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Jean-Louis
> > > >
> > >
> >
> >
> > --
> > Jean-Louis
> >
>


-- 
Jean-Louis

Re: Release?

2021-10-06 Thread Jean-Louis MONTEIRO 
Thanks Thomas

I've created https://issues.apache.org/jira/browse/OWB-1392
And I pushed
https://github.com/apache/openwebbeans/commit/2af6184ee5ec6b474f037b3c5768c82bba136722

I'd appreciate feedback, review and comments. Should have created a PR
sorry.
Functionally, it's the same as previously, but it allows TomEE to override
the instanciation part to be consistent.


Le mar. 5 oct. 2021 à 23:11, Thomas Andraschko 
a écrit :

> AFAIK we didnt start the process yet, so we can wait for your fix
>
> Am Di., 5. Okt. 2021 um 22:27 Uhr schrieb Jean-Louis MONTEIRO <
> jeano...@gmail.com>:
>
> > I have an issue with OWB in TomEE under JDK 17
> > I think I can workaround it, but I'd need a small change in OWB.
> >
> > Can we reroll it after my fix?
> >
> > Le lun. 4 oct. 2021 à 09:29, Jean-Baptiste Onofré  a
> > écrit :
> >
> > > +1
> > >
> > > Regards
> > > JB
> > >
> > > On 03/10/2021 20:56, Romain Manni-Bucau wrote:
> > > > Hi all,
> > > >
> > > > We fixed a few issues:
> > > >
> > > > PTKeySummaryAssigneeStatus
> > > > [image: Major] [image: Bug] OWB-1298
> > > > 
> WebsocketUserManager
> > > > ambigious resolution Jakarta Faces
> > > >  Unassigned RESOLVED
> > > > [image: Major] [image: Bug] OWB-1387
> > > > 
> > > > @Destroyed(ApplicationScoped.class)
> > > > not thrown when @Destroyed(RequestScoped.class) exists
> > > >  Arne Limburg
> > > > 
> > > CLOSED
> > > > [image: Major] [image: Improvement] OWB-1389
> > > >  Remove destroyed
> > > instance
> > > > from memory  Mark
> > > Struberg
> > > > <
> https://issues.apache.org/jira/secure/ViewProfile.jspa?name=struberg>
> > > > RESOLVED
> > > > [image: Major] [image: Task] OWB-1390
> > > >  support
> > > > javax.enterprise.inject.scan.implicit property
> > > >  Romain Manni-Bucau
> > > > <
> > >
> >
> https://issues.apache.org/jira/secure/ViewProfile.jspa?name=romain.manni-bucau
> > > >
> > > > RESOLVED
> > > > [image: Major] [image: Task] OWB-1391
> > > > 
> > > AbstractMetaDataDiscovery
> > > > ignores classpath entries starting with a common path
> > > >  Romain Manni-Bucau
> > > > <
> > >
> >
> https://issues.apache.org/jira/secure/ViewProfile.jspa?name=romain.manni-bucau
> > > >
> > > > RESOLVED
> > > >
> > > > I know Thomas can await a few of them so wonder if we should trigger
> a
> > > > release next week (starting on the 4th) or in the following days.
> > > >
> > > > I'd just like to highlight the 1391 changes the way we ignore
> > duplicated
> > > > jars/folders in in the classpath so can be worth some testing.
> > > >
> > > > No issue to delay from some days the release if it helps.
> > > >
> > > > Side note for our beloved tomee siblings: this shouldn't impact you
> > since
> > > > you don't reuse that scanning/lifecycle logic so should be a "noop
> > > release"
> > > > for you.
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau  |  Blog
> > > >  | Old Blog
> > > >  | Github <
> > > https://github.com/rmannibucau> |
> > > > LinkedIn  | Book
> > > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > > >
> > >
> >
> >
> > --
> > Jean-Louis
> >
>


-- 
Jean-Louis

[jira] [Created] (OWB-1392) Fully abstract defining class service

2021-10-06 Thread Jean-Louis Monteiro (Jira) 
Jean-Louis Monteiro created OWB-1392:


 Summary: Fully abstract defining class service
 Key: OWB-1392
 URL: https://issues.apache.org/jira/browse/OWB-1392
 Project: OpenWebBeans
  Issue Type: Improvement
Reporter: Jean-Louis Monteiro


Currently it does not allow to choose between the Unsafe.allocate and 
reflection call to constructor.

 

The allocate is important to not call the constructor.

For TomEE integration it does allow consistency between TomEE proxies and OWB 
proxies. And of course, it does allow to go back and forth from TomEE beans to 
OWB beans.

 

It does not functionaly change OWB behavior.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Switching from Unsafe to ClassLoaderProxyService

2021-10-06 Thread Romain Manni-Bucau 
It is the only identified/expected one at least, did you spot another one?

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mar. 5 oct. 2021 à 22:07, Jean-Louis MONTEIRO  a
écrit :

> I'm not sure it's only package scope methods ...
>
> Le mar. 5 oct. 2021 à 21:59, Romain Manni-Bucau  a
> écrit :
>
> > Well it is a config in owb.properties but as mentionned it will not
> support
> > package scope methods proxying by design (but it is in the spec).
> >
> > For this, add-opens are required (or a fake module-info workaround).
> >
> > Le mar. 5 oct. 2021 à 21:48, Jean-Louis MONTEIRO  a
> > écrit :
> >
> > > Here is what I have done 
> > >
> > > Switch from Unsafe to ClassLoaderProxyService in the
> > AbstractProxyFactory.
> > > Then, command line and run `mvn clean install`
> > >
> > > It fails under JDK 8 and under JDK17
> > >
> > > Le mar. 5 oct. 2021 à 20:40, Romain Manni-Bucau  >
> > a
> > > écrit :
> > >
> > > > Hi,
> > > >
> > > > Not sure what you mean but we should build on jdk 8 and run on 8-18.
> > > >
> > > > Le mar. 5 oct. 2021 à 20:29, Jean-Louis Monteiro <
> > > jlmonte...@tomitribe.com
> > > > >
> > > > a écrit :
> > > >
> > > > > Hi,
> > > > >
> > > > > While investigating some OWB issues, I tried moving default Unsafe
> to
> > > > > ClassLoaderProxyService, but it looks like I can't build OWB
> anymore,
> > > on
> > > > > JDK8 or even JDK17.
> > > > >
> > > > > Isn't it supposed to be working out of the box?
> > > > >
> > > > >
> > > > > --
> > > > > Jean-Louis Monteiro
> > > > > http://twitter.com/jlouismonteiro
> > > > > http://www.tomitribe.com
> > > > >
> > > >
> > >
> > >
> > > --
> > > Jean-Louis
> > >
> >
>
>
> --
> Jean-Louis
>