Thanks for the update and taking action !
Regards
JB
On 7/21/21 10:58 AM, Francois Papon wrote:
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
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
