Ok checked out and github got me with its autoformatting, +1 from me Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mar. 18 avr. 2023 à 13:41, Romain Manni-Bucau <rmannibu...@gmail.com> a écrit : > Hi Mark, > > The lock is more than fine but the first block which was forcing the cdi > and lifecycle classes to be loaded from this particular classloader and not > a parent one was commented so the launching from environment with complex > classloader is now broken. > If your issue is gone re-enabling this block all good (I assume if it was > commented it can be an issue and I would suspect the "else super.loadClass" > to not help more than the first if part). > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/application-development/java-ee-8-high-performance> > > > Le mar. 18 avr. 2023 à 13:37, Mark Struberg via dev < > dev@geronimo.apache.org> a écrit : > >> Hi Romain! >> >> Can you please explain what you think is now broken? >> >> This basically is just a lock using the method the JDK intends exactly >> for this situation. See the JavaDoc of getClassLoadingLock. >> >> txs and LieGrue, >> strub >> >> Am 18.04.2023 um 13:13 schrieb Romain Manni-Bucau <rmannibu...@gmail.com >> >: >> >> Hi, >> >> Looks like ChildFirstURLClassLoader got broken and forced loading in this >> particular classloader for standalone launcher is now up to the way it is >> launched (so from memory some use cases will be broken) so tempted to -1 to >> try to really fix #168 instead of breaking other things. >> >> Romain Manni-Bucau >> @rmannibucau <https://twitter.com/rmannibucau> | Blog >> <https://rmannibucau.metawerx.net/> | Old Blog >> <http://rmannibucau.wordpress.com/> | Github >> <https://github.com/rmannibucau> | LinkedIn >> <https://www.linkedin.com/in/rmannibucau> | Book >> <https://www.packtpub.com/application-development/java-ee-8-high-performance> >> >> >> Le mar. 18 avr. 2023 à 12:27, Mark Struberg via dev < >> dev@geronimo.apache.org> a écrit : >> >>> Hi! >>> >>> I'd like to call a VOTE on releasing BatchEE-1.0.3. >>> >>> This is mostly an update to the latest TomEE version and a fix in the >>> ChildFirstURLClassLoader >>> >>> >>> - [BATCHEE-162 <https://issues.apache.org/jira/browse/BATCHEE-162>] >>> - improve reproducible builds >>> - [BATCHEE-167 <https://issues.apache.org/jira/browse/BATCHEE-167>] >>> - upgrade to TomEE 8.0.9 >>> - [BATCHEE-168 <https://issues.apache.org/jira/browse/BATCHEE-168>] >>> - duplicate class definition issue within ChildFirstURLClassLoader >>> >>> >>> The staging repo can be found here: >>> https://repository.apache.org/content/repositories/orgapachebatchee-1010/ >>> >>> The sources are here: >>> >>> https://repository.apache.org/content/repositories/orgapachebatchee-1010/org/apache/batchee/batchee/1.0.3/ >>> >>> sha512 is >>> >>> 564ff0ab3602d87202aa7764084d03af60d64f6900d85e99ad8ad2843d0e4804383bd58ae3a516acef550c237325c2c4f808caaebaace7d0645a0071c889c831 >>> >>> Please VOTE: >>> >>> [+1] yup, ship it! >>> [+0] I don't care >>> [-1] Stop, I found a ${showstopper} >>> >>> The VOTE is open for 72h. >>> >>> >>> txs and LieGrue, >>> strub >>> >> >>
