Thanks! François fpa...@apache.org
Le 21/07/2021 à 11:59, Zowalla, Richard a écrit : > Ok. Will do! > > Am Mittwoch, den 21.07.2021, 11:58 +0200 schrieb Francois Papon: >> Hi, >> >> I think it's better if you can push a PR via github. >> >> regards, >> >> François >> fpa...@apache.org >> >> Le 21/07/2021 à 11:01, Zowalla, Richard a écrit : >>> Hi François, >>> >>> thanks for the update. >>> >>> Shall I migrate my SVN patch files towards GitHub Pull Requests or >>> is >>> the plan to apply them directly? >>> >>> Gruss >>> Richard >>> >>> >>> Am Mittwoch, den 21.07.2021, 10:58 +0200 schrieb Francois Papon: >>>> Hi all, >>>> >>>> This 3 repo has moved successfuly to gitbox: >>>> >>>> https://github.com/apache/geronimo-xbean >>>> https://github.com/apache/geronimo-javamail >>>> https://github.com/apache/geronimo-txmanager >>>> >>>> We can now merge the pending PRs. >>>> >>>> regards, >>>> >>>> François >>>> fpa...@apache.org >>>> >>>> Le 08/06/2021 à 14:15, Richard Zowalla a écrit : >>>>> Thx for the ticket id ! >>>>> >>>>> Am Dienstag, den 08.06.2021, 14:07 +0200 schrieb Francois >>>>> Papon: >>>>>> Hi, >>>>>> >>>>>> Migration is still pending, waiting for infra: >>>>>> >>>>>> https://issues.apache.org/jira/browse/INFRA-21908 >>>>>> <https://issues.apache.org/jira/browse/INFRA-21908> >>>>>> >>>>>> regards, >>>>>> >>>>>> François >>>>>> fpa...@apache.org >>>>>> >>>>>> Le 08/06/2021 à 13:56, Richard Zowalla a écrit : >>>>>>> Hi François, >>>>>>> >>>>>>> any updates from INFRA on this? Couldnt find the ticket id >>>>>>> anymore, >>>>>>> sry. >>>>>>> >>>>>>> Gruss >>>>>>> Richard >>>>>>> >>>>>>> Am Mittwoch, den 19.05.2021, 09:38 +0200 schrieb Francois >>>>>>> Papon: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Yes, we plan to do this just after the migration to git >>>>>>>> ;) >>>>>>>> >>>>>>>> regards, >>>>>>>> >>>>>>>> François >>>>>>>> fpa...@apache.org >>>>>>>> >>>>>>>> Le 19/05/2021 à 09:09, Zowalla, Richard a écrit : >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> thanks for your response! I think, that [1] might also >>>>>>>>> affect >>>>>>>>> the >>>>>>>>> hard- >>>>>>>>> coded TLS1.0 in GERONIMO-6792 [2], so the pending patch >>>>>>>>> would >>>>>>>>> be >>>>>>>>> very >>>>>>>>> appreciated. >>>>>>>>> >>>>>>>>> Maybe after the migration to git? ;) >>>>>>>>> >>>>>>>>> Gruss >>>>>>>>> Richard >>>>>>>>> >>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8202343 >>>>>>>>> [2] https://issues.apache.org/jira/browse/GERONIMO-6792 >>>>>>>>> >>>>>>>>> Am Samstag, den 01.05.2021, 08:20 +0200 schrieb >>>>>>>>> fpa...@apache.org: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I think I can take a look to the Jira and merge the >>>>>>>>>> PRs. >>>>>>>>>> >>>>>>>>>> regards, >>>>>>>>>> >>>>>>>>>> François >>>>>>>>>> fpa...@apache.org >>>>>>>>>> >>>>>>>>>> Le 28/04/2021 à 11:09, Zowalla, Richard a écrit : >>>>>>>>>>> Just to follow up on this thread: >>>>>>>>>>> >>>>>>>>>>> Do we have any plans for moving forward with the >>>>>>>>>>> mail- >>>>>>>>>>> related >>>>>>>>>>> patches? >>>>>>>>>>> The hard-coded TLS config in mail is a bit "pain" >>>>>>>>>>> ;) >>>>>>>>>>> >>>>>>>>>>> Gruss >>>>>>>>>>> Richard >>>>>>>>>>> >>>>>>>>>>> Am Dienstag, den 23.03.2021, 08:50 +0100 schrieb >>>>>>>>>>> Romain >>>>>>>>>>> Manni- >>>>>>>>>>> Bucau: >>>>>>>>>>>> Well it can use a singleton but from a factory >>>>>>>>>>>> method. So >>>>>>>>>>>> immediate >>>>>>>>>>>> solution is to add a public static X >>>>>>>>>>>> getInstance();. >>>>>>>>>>>> But as mentionned it means, to keep the >>>>>>>>>>>> pluggability >>>>>>>>>>>> we >>>>>>>>>>>> should >>>>>>>>>>>> target >>>>>>>>>>>> with such a spi, you will enforce all other impl >>>>>>>>>>>> to >>>>>>>>>>>> use >>>>>>>>>>>> such >>>>>>>>>>>> a >>>>>>>>>>>> pattern (you cant' just switch with -D easily >>>>>>>>>>>> since >>>>>>>>>>>> adding is >>>>>>>>>>>> easy >>>>>>>>>>>> but dropping system props is almost impossible). >>>>>>>>>>>> A noarg public constructor is trivial and more >>>>>>>>>>>> natural >>>>>>>>>>>> with >>>>>>>>>>>> resources >>>>>>>>>>>> IMHO - but once again tomee can does all the work >>>>>>>>>>>> to >>>>>>>>>>>> makes it >>>>>>>>>>>> equivalent, just requires to duplicate/wrap the >>>>>>>>>>>> impls >>>>>>>>>>>> of >>>>>>>>>>>> the >>>>>>>>>>>> SPI >>>>>>>>>>>> in >>>>>>>>>>>> tomee codebase which sounds weird to me ("we have >>>>>>>>>>>> an >>>>>>>>>>>> impl >>>>>>>>>>>> but >>>>>>>>>>>> you >>>>>>>>>>>> need to use another one"). >>>>>>>>>>>> >>>>>>>>>>>> On a more personal note I think this pattern is >>>>>>>>>>>> no >>>>>>>>>>>> more >>>>>>>>>>>> relevant >>>>>>>>>>>> and >>>>>>>>>>>> has more pitfalls since you enforce a static >>>>>>>>>>>> instance >>>>>>>>>>>> as >>>>>>>>>>>> soon >>>>>>>>>>>> as >>>>>>>>>>>> the >>>>>>>>>>>> class is loaded whereas it is not needed >>>>>>>>>>>> depending >>>>>>>>>>>> the >>>>>>>>>>>> lifecycle >>>>>>>>>>>> of >>>>>>>>>>>> your main - it is not much but still, I see it as >>>>>>>>>>>> a >>>>>>>>>>>> leak >>>>>>>>>>>> in >>>>>>>>>>>> terms >>>>>>>>>>>> of >>>>>>>>>>>> design (indeed this one is not important and not >>>>>>>>>>>> a >>>>>>>>>>>> blocker >>>>>>>>>>>> but >>>>>>>>>>>> all >>>>>>>>>>>> implies to move to the noarg public constructor >>>>>>>>>>>> on my >>>>>>>>>>>> side). >>>>>>>>>>>> Maybe a habit and personal choice so would be >>>>>>>>>>>> great >>>>>>>>>>>> to >>>>>>>>>>>> have >>>>>>>>>>>> another >>>>>>>>>>>> opinion to move forward :). >>>>>>>>>>>> >>>>>>>>>>>> Le mar. 23 mars 2021 à 08:38, Zowalla, Richard < >>>>>>>>>>>> richard.zowa...@hs-heilbronn.de> a écrit : >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I think, it is about the configuration >>>>>>>>>>>>> flexibility >>>>>>>>>>>>> in >>>>>>>>>>>>> tomee's >>>>>>>>>>>>> <resource> definitions, which wouldn't allow >>>>>>>>>>>>> the >>>>>>>>>>>>> use of >>>>>>>>>>>>> a >>>>>>>>>>>>> singleton >>>>>>>>>>>>> instance. Hence, the consuming project would >>>>>>>>>>>>> need >>>>>>>>>>>>> to >>>>>>>>>>>>> implement >>>>>>>>>>>>> the >>>>>>>>>>>>> interface to make it possible. But I am not >>>>>>>>>>>>> that >>>>>>>>>>>>> deep >>>>>>>>>>>>> as >>>>>>>>>>>>> Romain >>>>>>>>>>>>> in >>>>>>>>>>>>> the >>>>>>>>>>>>> TomEE codebase, so it is still a guess from my >>>>>>>>>>>>> side. >>>>>>>>>>>>> >>>>>>>>>>>>> Gruss >>>>>>>>>>>>> Richard >>>>>>>>>>>>> >>>>>>>>>>>>> Am Montag, den 22.03.2021, 23:14 +0100 schrieb >>>>>>>>>>>>> Florent >>>>>>>>>>>>> Guillaume: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I can drop the private constructor if you >>>>>>>>>>>>>> want. >>>>>>>>>>>>>> I'm surprised it's needed though, as the >>>>>>>>>>>>>> default >>>>>>>>>>>>>> instance >>>>>>>>>>>>>> is >>>>>>>>>>>>> already >>>>>>>>>>>>>> used by the code if no value is provided for >>>>>>>>>>>>>> the >>>>>>>>>>>>>> timeProvider >>>>>>>>>>>>>> parameter of TransactionImpl. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Florent >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 5:49 PM Romain Manni- >>>>>>>>>>>>>> Bucau < >>>>>>>>>>>>>> rmannibu...@gmail.com> wrote: >>>>>>>>>>>>>>> Hi Richard, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I still think SystemCurrentTime should have >>>>>>>>>>>>>>> a >>>>>>>>>>>>>>> public >>>>>>>>>>>>>>> noarg >>>>>>>>>>>>>>> constructor (or just drop the private one) >>>>>>>>>>>>>>> since it >>>>>>>>>>>>>>> will >>>>>>>>>>>>>>> enable >>>>>>>>>>>>>>> tomee to fully configure dynamically the tx >>>>>>>>>>>>>>> mgr >>>>>>>>>>>>>>> with >>>>>>>>>>>>>>> this >>>>>>>>>>>>>>> new >>>>>>>>>>>>>>> feature but otherwise +1 to apply them all. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>>>>> @rmannibucau | Blog | Old Blog | Github | >>>>>>>>>>>>>>> LinkedIn >>>>>>>>>>>>>>> Book >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Le lun. 22 mars 2021 à 17:03, Zowalla, >>>>>>>>>>>>>>> Richard >>>>>>>>>>>>>>> < >>>>>>>>>>>>>>> richard.zowa...@hs-heilbronn.de> a écrit : >>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> wanted to raise attention on this again. >>>>>>>>>>>>>>>> 6792 >>>>>>>>>>>>>>>> would >>>>>>>>>>>>>>>> be >>>>>>>>>>>>>>>> very >>>>>>>>>>>>> nice >>>>>>>>>>>>>>>> as we >>>>>>>>>>>>>>>> should allow TLS/SSL protocol versions >>>>>>>>>>>>>>>> for a >>>>>>>>>>>>>>>> given >>>>>>>>>>>>>>>> mail >>>>>>>>>>>>> server >>>>>>>>>>>>>>>> instead >>>>>>>>>>>>>>>> of falling back to some hard-coded >>>>>>>>>>>>>>>> default. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Gruss >>>>>>>>>>>>>>>> Richard >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Am Mittwoch, den 24.02.2021, 09:33 +0100 >>>>>>>>>>>>>>>> schrieb >>>>>>>>>>>>>>>> Romain >>>>>>>>>>>>> Manni- >>>>>>>>>>>>>>>> Bucau: >>>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> AFAIK we have a few pending patches to >>>>>>>>>>>>>>>>> apply/issue >>>>>>>>>>>>>>>>> to >>>>>>>>>>>>> close: >>>>>>>>>>>>>>>>> - [mail] >>>>>>>>>>>>> https://issues.apache.org/jira/browse/GERONIMO-6792 >>>>>>>>>>>>> : >>>>>>>>>>>>>>>> update >>>>>>>>>>>>>>>>> some defaults and config capacity >>>>>>>>>>>>>>>>> - [mail] >>>>>>>>>>>>> https://issues.apache.org/jira/browse/GERONIMO-6801 >>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/GERONIMO-6800 >>>>>>>>>>>>> (setText) >>>>>>>>>>>>>>>>> - [transaction-manager] >>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/GERONIMO-6805 >>>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>> enable >>>>>>>>>>>>> to >>>>>>>>>>>>>>>> change >>>>>>>>>>>>>>>>> the time evaluator impl >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> If someone else can have a review it >>>>>>>>>>>>>>>>> would >>>>>>>>>>>>>>>>> be >>>>>>>>>>>>>>>>> great >>>>>>>>>>>>>>>>> (feel >>>>>>>>>>>>> free >>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>> apply the patch or I can do it after). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> note: some of the patches are waiting >>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>> some >>>>>>>>>>>>>>>>> feedback >>>>>>>>>>>>>>>>> - >>>>>>>>>>>>> in >>>>>>>>>>>>>>>>> particular txmgr one, wonder about >>>>>>>>>>>>>>>>> tomee >>>>>>>>>>>>>>>>> <resource> >>>>>>>>>>>>>>>>> usage >>>>>>>>>>>>> which >>>>>>>>>>>>>>>> can >>>>>>>>>>>>>>>>> need to remove the private constructor >>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> default >>>>>>>>>>>>>>>>> impl >>>>>>>>>>>>> to >>>>>>>>>>>>>>>> enable >>>>>>>>>>>>>>>>> to configure the impl completely. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>>>>>>> @rmannibucau | Blog | Old Blog | >>>>>>>>>>>>>>>>> Github | >>>>>>>>>>>>>>>>> LinkedIn >>>>>>>>>>>>>>>>> Book
