Re: Moving Mail, Activation, Transaction and Connector to Apache TomEE (was Re: [DISCUSS] Move microprofile impl to Apache TomEE)

[Zowalla, Richard]

Hi all,

to summarize the current discussion:

From the discussion, it looks like, that there are no real objections /
blockers for a move?

However, a move of the packages / project might confuse users and
automated tools (like dependency update check tooling). We would need
to communicate / announce it accordingly, but haven't discussed this
aspect much atm?

It seems, that an open task is to complete the move from svn to git for
the repositories where it isn't already done. Guess, this should happen
first...

Gruß
Richard


Am Dienstag, dem 14.06.2022 um 22:09 -0700 schrieb David Jencks:
> I think each impl. needs to be in its own git repo, I’m not sure
> which already are.
> 
> I believe the tx manager is used in an OSGI spec impl in (I think)
> Aries. On the other hand they might have copied the implementation.
>  It might be confusing if the governing project and/or package names
> change. I don’t know if there are other uses, or how to find out.
> 
> It might possibly be simpler, after we get each subproject into
> appropriate git repos, to make people who want to work on these
> implementations geronimo committers.
> 
> David Jencks
> 
> > On Jun 14, 2022, at 9:36 AM, Romain Manni-Bucau <
> > rmannibu...@gmail.com> wrote:
> > 
> > No blocker from me (minor note being some are already on git so
> > don't start back from svn ;))
> > 
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> > 
> > 
> > Le mar. 14 juin 2022 à 18:29, David Blevins <
> > david.blev...@gmail.com> a écrit :
> > > Jumping off of this thread, is there any openness to discussing
> > > moving this code over to TomEE?
> > > 
> > >  - 
> > > http://svn.apache.org/repos/asf/geronimo/components/txmanager/trunk/
> > >  - 
> > > http://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-activation_2.0_spec/
> > >  - 
> > > http://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-jakartamail_2.1_spec/
> > >  - 
> > > http://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-mail_2.1_spec/
> > > 
> > > These are on the critical path for TomEE, being updated in
> > > Jakarta EE 10.  We're not working on Jakarta EE 10 yet, but we'll
> > > hopefully be doing that by early next year.
> > > 
> > > It's a bit painful to send people over from the TomEE project to
> > > here and submit patches against SVN repos.  It would be great if
> > > we could have them in git and under the TomEE PMC if possible.
> > > 
> > > Thoughts?
> > > 
> > > 
> > > -David
> > > 
> > > > On Jun 6, 2022, at 1:59 AM, fpapon  wrote:
> > > > 
> > > > Hi all,
> > > > 
> > > > I would like to start a thread to discuss about the future of
> > > the Apache Geronimo Microprofile implementation:
> > > > 
> > > > https://geronimo.apache.org/microprofile/
> > > > 
> > > > As we can see, we don't have a lot of traction about the
> > > maintenance of the implementation to be up-to-date with the
> > > Microprofile specification.
> > > > 
> > > > The J2EE Geronimo server is no longer exist and at Apache, the
> > > active EE server seems to be Apache TomEE.
> > > > 
> > > > May be it could make more sense to move the Microprofile
> > > implementation to the Apache TomEE umbrella.
> > > > 
> > > > WDYT?
> > > > 
> > > > regards,
> > > > 
> > > > -- 
> > > > --
> > > > François
> > > > 
> > > 
> 
> 


smime.p7s
Description: S/MIME cryptographic signature

Re: Moving Mail, Activation, Transaction and Connector to Apache TomEE (was Re: [DISCUSS] Move microprofile impl to Apache TomEE)

[Zowalla, Richard]

Am Dienstag, dem 14.06.2022 um 22:09 -0700 schrieb David Jencks:
> I believe the tx manager is used in an OSGI spec impl in (I think)
> Aries. On the other hand they might have copied the implementation.
>  It might be confusing if the governing project and/or package names
> change. I don’t know if there are other uses, or how to find out.

From a quick look at Apache Aries, I think, that you are right. In
addition, Apache ActiveMQ is using the tx manager in some modules too.


Gruß
Richard


smime.p7s
Description: S/MIME cryptographic signature

Re: Jakarta Mail TCK - Additional Thoughts? (was: TomEE 9.x - from javax to jakarta namespace)

[Zowalla, Richard]

Hi Romain,

thanks for the pointer - it sounds somehow familiar to what we
observed. Need to check though :)

Gruß
Richard

Am Donnerstag, dem 02.06.2022 um 09:17 +0200 schrieb Romain Manni-
Bucau:
> Hi,
> 
> Did you try handling LITERAL+ capability (1)? I don't think we do as
> of
> today.
> 
> (1)
> https://datatracker.ietf.org/doc/html/rfc7888#:~:text=LITERAL%2B%20allows%20the%20alternate%20form%20of%20literals%20(called%20%22non%2D,are%204096%20bytes%20or%20less
> .
> 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. 31 mai 2022 à 09:54, Zowalla, Richard <
> richard.zowa...@hs-heilbronn.de> a écrit :
> 
> > Hi,
> > 
> > short update on this:
> > 
> > Collaborated with JL and exchanged some ideas via Slack.
> > 
> > We now tested James + Greenmail as mail servers to rule out any
> > hard-
> > coded TCK assumption regarding James. Both fail with the same
> > exception
> > / issue on the same TCK mail:
> > https://github.com/eclipse-ee4j/mail-tck/blob/2.0.0/tests/mailboxes/test1/9
> > 
> > The difference between the RI and our impl is basically the literal
> > header:
> > 
> > a5 APPEND test1 () "8-Dec-1996 15:30:12 +0100" {150432}
> > a5 BAD APPEND failed. Illegal arguments.
> > 
> > vs (RI):
> > 
> > A6 APPEND test1 () "08-Dec-1996 15:30:12 +0100" {153113+}
> > A6 OK [APPENDUID 466034631 1] APPEND completed.
> >   Copied 1 messages
> > 
> > I pushed a configured Jakarta Mail TCK 2.0.1 setup with updated
> > instructions into this repository: https://github.com/rzo1/mail-tck
> > 
> > In addition, I am CC'ing the geronimo list, in case some people
> > there
> > have additional ideas. Otherwise, we will need to take a dive into
> > the
> > imap spec / server-side impl to get any clues :)
> > 
> > Gruß
> > Richard
> > 
> > 
> > Am Dienstag, dem 24.05.2022 um 19:46 + schrieb Zowalla,
> > Richard:
> > > Hi,
> > > 
> > > I spend some more time on the mail tck and got some additional
> > > insights:
> > > 
> > > There is one specific mail from the TCK mailbox (test1, mail no.
> > > 9),
> > > which breaks the current Geronimo mail impl. This happens, if you
> > > try
> > > to bootstrap / setup the test mailbox before running the TCK
> > > according
> > > ti their documentation. The same procedere just works, if the
> > > reference
> > > impl is used.
> > > 
> > > The failing tests in the mail tck report similar issues regarding
> > > failed IMAP commands. Therefore, I assume, that the underlying
> > > issue
> > > is
> > > similar, i.e. if we solve that, we likely fix some of the TCK
> > > tests
> > > too.
> > > 
> > > I added some instructions to
> > > https://issues.apache.org/jira/browse/GERONIMO-6835 to reproduce
> > > the
> > > issue without actually running the TCK, so we might have the
> > > chance
> > > to
> > > debug it easily.
> > > 
> > > Basically:
> > > 
> > > - Checkout 
> > > https://github.com/rzo1/geronimo-javamail/tree/tck-issues
> > > - Follow the instructions in tck.adoc to start up a mail server
> > > (docker-compose + docker exec)
> > > - Run "fpopulate" with arguments "-s test1 -d
> > > imap://user01%40james.local:1234@localhost:1143 -D" from within
> > > your
> > > IDE
> > > - Observe the debug output on the console
> > > 
> > > 
> > > There is a difference between the message length between the RI
> > > and
> > > the
> > > Geronimo impl (as reported by the { } literal). This might be the
> > > cause
> > > (??), but I have no idea what is going on or why it is happening.
> > > 
> > > Maybe someone has an idea what is going on here? Or has a pointer
> > > where
> > > to look at? I might be "lost in the tck madness" for today :)
> > > 
> > > Gruß
> > > Richard
> > > 
> > > 
> > > 
> > > Am Dienstag, dem 24.05.2022 um 17:13 + sc

Re: Jakarta Mail TCK - Additional Thoughts? (was: TomEE 9.x - from javax to jakarta namespace)

[Zowalla, Richard]

Hi,

short update on this:

Collaborated with JL and exchanged some ideas via Slack.

We now tested James + Greenmail as mail servers to rule out any hard-
coded TCK assumption regarding James. Both fail with the same exception
/ issue on the same TCK mail: 
https://github.com/eclipse-ee4j/mail-tck/blob/2.0.0/tests/mailboxes/test1/9

The difference between the RI and our impl is basically the literal
header:

a5 APPEND test1 () "8-Dec-1996 15:30:12 +0100" {150432}
a5 BAD APPEND failed. Illegal arguments.

vs (RI):

A6 APPEND test1 () "08-Dec-1996 15:30:12 +0100" {153113+}
A6 OK [APPENDUID 466034631 1] APPEND completed.
  Copied 1 messages

I pushed a configured Jakarta Mail TCK 2.0.1 setup with updated
instructions into this repository: https://github.com/rzo1/mail-tck 

In addition, I am CC'ing the geronimo list, in case some people there
have additional ideas. Otherwise, we will need to take a dive into the
imap spec / server-side impl to get any clues :)

Gruß
Richard


Am Dienstag, dem 24.05.2022 um 19:46 +0000 schrieb Zowalla, Richard:
> Hi,
> 
> I spend some more time on the mail tck and got some additional
> insights:
> 
> There is one specific mail from the TCK mailbox (test1, mail no. 9),
> which breaks the current Geronimo mail impl. This happens, if you try
> to bootstrap / setup the test mailbox before running the TCK
> according
> ti their documentation. The same procedere just works, if the
> reference
> impl is used.
> 
> The failing tests in the mail tck report similar issues regarding
> failed IMAP commands. Therefore, I assume, that the underlying issue
> is
> similar, i.e. if we solve that, we likely fix some of the TCK tests
> too.
> 
> I added some instructions to 
> https://issues.apache.org/jira/browse/GERONIMO-6835 to reproduce the
> issue without actually running the TCK, so we might have the chance
> to
> debug it easily. 
> 
> Basically:
> 
> - Checkout https://github.com/rzo1/geronimo-javamail/tree/tck-issues
> - Follow the instructions in tck.adoc to start up a mail server
> (docker-compose + docker exec)
> - Run "fpopulate" with arguments "-s test1 -d
> imap://user01%40james.local:1234@localhost:1143 -D" from within your
> IDE
> - Observe the debug output on the console
> 
> 
> There is a difference between the message length between the RI and
> the
> Geronimo impl (as reported by the { } literal). This might be the
> cause
> (??), but I have no idea what is going on or why it is happening.
> 
> Maybe someone has an idea what is going on here? Or has a pointer
> where
> to look at? I might be "lost in the tck madness" for today :)
> 
> Gruß
> Richard
> 
> 
> 
> Am Dienstag, dem 24.05.2022 um 17:13 + schrieb Zowalla, Richard:
> > To give a more detailed view / update from the spec tck party
> > regarding
> > activation and mail:
> > 
> > (A) Geronimo Activation 2.0
> > 
> > After a first milestone (M1) and some additional fixes after
> > running
> > the activation TCK [1] and related signatures tests, we are now
> > passing
> > them. 
> > 
> > JL prepared a release artifact (1.0.0), which is currently under
> > vote.
> > 
> > During the tck work, we found some inconsistency / unspecified
> > behaviour of "normalizeMimeTypeParameter" of ActivationDataFlavor.
> > While this method is tested in the TCK on the basis of the
> > reference
> > implementation neither the spec itself nor the javadoc are really
> > clear
> > about the "right" return value. At the moment, we adjusted it to
> > pass
> > the TCK test in question.
> > 
> > There is an ongoing discussion at dev@geronimo if this is a desired
> > behaviour or if a system property should be introduced in order to
> > reduce the possibility of breaking some users.
> > 
> > (B) Geronimo Mail 2.0 / 2.1
> > 
> > The current mail impl has some TCK failures. It seems, that we need
> > to
> > do some additional work to get it compliant with the standalone
> > mail
> > tck [3].
> > 
> > The signature tests are failing for Java 11 but are fine with Java
> > 8
> > [4] due to some usage of Object#finalize() and missing annotations
> > (only available in Java 9+) in the Geronimo implementation. While
> > it
> > is
> > not that important for EE9, we need to keep it in mind for EE10.
> > 
> > We currently pass 166 out of 321 mail tck tests [5]. I guess, we
> > need
> > to give it some more love to get the numbers up and finally get it
> > to
> > pass the mail tck. The good thing is, that we already pass the
> >

Re: Dealing with compliance disagreements (was Re: [VOTE] Geronimo activation_2.0_spec 1.0.0)

[Zowalla, Richard]

Hi,

JL wrote "Meanwhile, I'd create an issue on the TCK + Spec" in another
mail and as I want to learn something about the involved workflows /
processes (sorry - never had to deal with it):

- What would we need to do to challenge the TCK + Spec in this regard?
- Who can do this - I assume it is vendor-driven, so PMC?
- Is it something super time consuming? 
- Is it opening an issue and writing some elaborated text explaining
the situation / unclarity?

I guess, that the user community who already migrated to jakarta.*
isn't that big at the moment (my assumption), so perhaps there is
enought time to open a challenge and clarify the situation. If users
complain, we can go still do a "bug" fix release?

Gruß
Richard



Am Mittwoch, dem 25.05.2022 um 09:03 +0200 schrieb Romain Manni-Bucau:
> Hi
> 
> The small notes on that are:
> 
> - rare impl actually do (asf ones but also other vendors), it is
> always a compromise between users/customers/consumers and specs
> - there is always a blurry line on some defaults (trivial example is
> default impl or provider impl even when defined in spec)
> - another blurry line is for libs vs distros
> 
> So overall we are still free to choose in most cases even if we
> should tend to what you described.
> 
> Side note: I dont want to emphasize the disrespect of that rule but
> the fact *we* must choose at the end.
> 
> 
> Le mer. 25 mai 2022 à 03:20, David Blevins 
> a écrit :
> > > On May 24, 2022, at 6:14 PM, David Blevins <
> > david.blev...@gmail.com> wrote:
> > > 
> > > You could have flags that enabled non-compliant behavior, but
> > they would have to be off by default and require user action to
> > turn them on.
> > 
> > To be clear I could have used a better word than "flags."  You can
> > have any means you like to enable non-compliant behavior such as
> > annotations, alternate jars, etc.  Anything that must be done
> > explicitly by a user to put themselves knowingly in a non-compliant 
> > state.
> > 
> > 
> > -David
> > 


smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] Geronimo activation_2.0_spec 1.0.0

[Zowalla, Richard]

Romain mentioned the idea (via Slack) of introducing a (cheap) system
property, which a user can specifiy to get back the old behaviour. 

If we want to follow the compatibility appraoch, we should add that
flag as the spec / RI is really unclear.


Am Dienstag, dem 24.05.2022 um 13:01 +0200 schrieb Romain Manni-Bucau:
> I conclude the same thing thanks your pointers so back to the
> question: do we want to maintain the compat for our user base, do we
> want to align on the random spec behavior or do we don't care?
> Indeed I'm always in first team, in particular there since it will be
> deprecated so the least we touch the best it is but guess it is a 50-
> 50 case in terms of actual points :s.
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> 
> 
> Le mar. 24 mai 2022 à 12:57, Zowalla, Richard <
> richard.zowa...@hs-heilbronn.de> a écrit :
> > The test in question is 
> > https://github.com/eclipse-ee4j/jaf-tck/blob/2.0.1/tests/api/javasoft/sqe/tests/jakarta/activation/ActivationDataFlavor/normalizeMimeTypeParameter_Test.java
> > 
> > which expects the plain parameter value instead of
> > "parameter=value" as
> > a return value.
> > 
> > The JavaDoc is also not quite clear about it:
> > 
> > https://jakarta.ee/specifications/activation/2.0/apidocs/jakarta.activation/jakarta/activation/activationdataflavor#normalizeMimeTypeParameter(java.lang.String,java.lang.String)
> > 
> > with "This method is called for each parameter name/value pair and
> > should return the normalized representation of the
> > parameterValue.".
> > 
> > The spec document itself 
> > https://jakarta.ee/specifications/activation/2.0/jakarta-activation-spec-2.0.html
> >  doesn't mention anything about it.
> > 
> > Guess it is a relict from java.awt.DataFlavour (also @Deprecated
> > there)
> > to keep compatibility after removing the references to it.
> > 
> > Am Dienstag, dem 24.05.2022 um 12:42 +0200 schrieb Romain Manni-
> > Bucau:
> > > Hmm, before that the question is "are the TCK spec compliant", a
> > lot
> > > have a reference in the spec we maybe missed, do you have some
> > > pointers on them? If we were wrong let's fix it, if the TCK are
> > wrong
> > > then maybe ignore the TCK?
> > > 
> > > Romain Manni-Bucau
> > > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> > > 
> > > 
> > > Le mar. 24 mai 2022 à 12:33, Zowalla, Richard <
> > > richard.zowa...@hs-heilbronn.de> a écrit :
> > > > There is a TCK test regarding normalizeMimeTypeParameter which
> > > > broke with the current impl of normalizeMimeTypeParameter 
> > > > 
> > > > Therefore, I adjusted it but agree that it is mit really
> > specified.
> > > > Question would be, if it is "ok" to fail specific tests of the
> > TCK.
> > > > 
> > > > Gruß
> > > > Richard
> > > > Von: Romain Manni-Bucau 
> > > > Gesendet: Dienstag, 24. Mai 2022 11:53:37
> > > > An: dev@geronimo.apache.org
> > > > Betreff: Re: [VOTE] Geronimo activation_2.0_spec 1.0.0
> > > >  
> > > > Not voting negatively but seems we
> > > > broke normalizeMimeTypeParameter (I guess copying the RI?) and
> > I'm
> > > > not sure it should be done.
> > > > From my understanding this part is not well specified and
> > highly
> > > > depends on the impl but I don't see a reson to break existing
> > > > consumers which I always favor in regards of being aligned on
> > the
> > > > RI.
> > > > 
> > > > Romain Manni-Bucau
> > > > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> > > > 
> > > > 
> > > > Le mar. 24 mai 2022 à 11:45, Jean-Louis Monteiro <
> > > > jlmonte...@tomitribe.com> a écrit :
> > > > > Here we go
> > > > > 
> > > > > We now pass all TCK and signature tests. Thanks Richard.
> > > > > 
> > > > > This is essentially the same as the M1 David did last week
> > but
> > > > > with the fixes for compliance (See GERONIMO-6832)
> > > > > 
> > > > > Here is the link for sources
> > > > > 
> > https://dist.apache.org/repos/dist/dev/geronimo/activation_2.0_spec/
> > > > > 
> > > > > Here is the svn tag
> > > > > 
> > https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-activation_2.0_spec-1.0.0/
> > > > > 
> > > > > Here is the staging repo
> > > > > 
> > https://repository.apache.org/content/repositories/orgapachegeronimo-1155
> > > > > 
> > > > > Please vote to approve this release:
> > > > > [ ] +1 Approve the release
> > > > > [ ]  0 Abstain (please provide specific comments)
> > > > > [ ] -1 Don't approve the release (please provide specific
> > > > > comments)
> > > > > 
> > > > > This vote will be open for at least 72 hours.
> > > > > 
> > > > > Thanks
> > > > > 
> > > > > 
> > > > > 
> > > > > --
> > > > > Jean-Louis Monteiro
> > > > > http://twitter.com/jlouismonteiro
> > > > > http://www.tomitribe.com
> > > > > 


smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] Geronimo activation_2.0_spec 1.0.0

[Zowalla, Richard]

The test in question is 
https://github.com/eclipse-ee4j/jaf-tck/blob/2.0.1/tests/api/javasoft/sqe/tests/jakarta/activation/ActivationDataFlavor/normalizeMimeTypeParameter_Test.java

which expects the plain parameter value instead of "parameter=value" as
a return value.

The JavaDoc is also not quite clear about it:

https://jakarta.ee/specifications/activation/2.0/apidocs/jakarta.activation/jakarta/activation/activationdataflavor#normalizeMimeTypeParameter(java.lang.String,java.lang.String)

with "This method is called for each parameter name/value pair and
should return the normalized representation of the parameterValue.".

The spec document itself 
https://jakarta.ee/specifications/activation/2.0/jakarta-activation-spec-2.0.html
 doesn't mention anything about it.

Guess it is a relict from java.awt.DataFlavour (also @Deprecated there)
to keep compatibility after removing the references to it.

Am Dienstag, dem 24.05.2022 um 12:42 +0200 schrieb Romain Manni-Bucau:
> Hmm, before that the question is "are the TCK spec compliant", a lot
> have a reference in the spec we maybe missed, do you have some
> pointers on them? If we were wrong let's fix it, if the TCK are wrong
> then maybe ignore the TCK?
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> 
> 
> Le mar. 24 mai 2022 à 12:33, Zowalla, Richard <
> richard.zowa...@hs-heilbronn.de> a écrit :
> > There is a TCK test regarding normalizeMimeTypeParameter which
> > broke with the current impl of normalizeMimeTypeParameter 
> > 
> > Therefore, I adjusted it but agree that it is mit really specified.
> > Question would be, if it is "ok" to fail specific tests of the TCK.
> > 
> > Gruß
> > Richard
> > Von: Romain Manni-Bucau 
> > Gesendet: Dienstag, 24. Mai 2022 11:53:37
> > An: dev@geronimo.apache.org
> > Betreff: Re: [VOTE] Geronimo activation_2.0_spec 1.0.0
> >  
> > Not voting negatively but seems we
> > broke normalizeMimeTypeParameter (I guess copying the RI?) and I'm
> > not sure it should be done.
> > From my understanding this part is not well specified and highly
> > depends on the impl but I don't see a reson to break existing
> > consumers which I always favor in regards of being aligned on the
> > RI.
> > 
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> > 
> > 
> > Le mar. 24 mai 2022 à 11:45, Jean-Louis Monteiro <
> > jlmonte...@tomitribe.com> a écrit :
> > > Here we go
> > > 
> > > We now pass all TCK and signature tests. Thanks Richard.
> > > 
> > > This is essentially the same as the M1 David did last week but
> > > with the fixes for compliance (See GERONIMO-6832)
> > > 
> > > Here is the link for sources
> > > https://dist.apache.org/repos/dist/dev/geronimo/activation_2.0_spec/
> > > 
> > > Here is the svn tag
> > > https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-activation_2.0_spec-1.0.0/
> > > 
> > > Here is the staging repo
> > > https://repository.apache.org/content/repositories/orgapachegeronimo-1155
> > > 
> > > Please vote to approve this release:
> > > [ ] +1 Approve the release
> > > [ ]  0 Abstain (please provide specific comments)
> > > [ ] -1 Don't approve the release (please provide specific
> > > comments)
> > > 
> > > This vote will be open for at least 72 hours.
> > > 
> > > Thanks
> > > 
> > > 
> > > 
> > > --
> > > Jean-Louis Monteiro
> > > http://twitter.com/jlouismonteiro
> > > http://www.tomitribe.com
> > > 


smime.p7s
Description: S/MIME cryptographic signature

AW: [VOTE] Geronimo activation_2.0_spec 1.0.0

[Zowalla, Richard]

There is a TCK test regarding normalizeMimeTypeParameter which broke with the 
current impl of normalizeMimeTypeParameter

Therefore, I adjusted it but agree that it is mit really specified. Question 
would be, if it is "ok" to fail specific tests of the TCK.

Gruß
Richard

Von: Romain Manni-Bucau 
Gesendet: Dienstag, 24. Mai 2022 11:53:37
An: dev@geronimo.apache.org
Betreff: Re: [VOTE] Geronimo activation_2.0_spec 1.0.0

Not voting negatively but seems we broke normalizeMimeTypeParameter (I guess 
copying the RI?) and I'm not sure it should be done.
>From my understanding this part is not well specified and highly depends on 
>the impl but I don't see a reson to break existing consumers which I always 
>favor in regards of being aligned on the RI.

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


Le mar. 24 mai 2022 à 11:45, Jean-Louis Monteiro 
mailto:jlmonte...@tomitribe.com>> a écrit :
Here we go

We now pass all TCK and signature tests. Thanks Richard.

This is essentially the same as the M1 David did last week but with the fixes 
for compliance (See GERONIMO-6832)

Here is the link for sources
https://dist.apache.org/repos/dist/dev/geronimo/activation_2.0_spec/

Here is the svn tag
https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-activation_2.0_spec-1.0.0/

Here is the staging repo
https://repository.apache.org/content/repositories/orgapachegeronimo-1155

Please vote to approve this release:
[ ] +1 Approve the release
[ ]  0 Abstain (please provide specific comments)
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks



--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com

GERONIMO-6832 - SigTests + TCK Failures for Activation 2.0.0-M1

[Zowalla, Richard]

Hi all,

I gave it a try: the main issues were related to the change regarding
java.desktop.

I added a patch (svn diff) to 
https://issues.apache.org/jira/browse/GERONIMO-6832 with some changes.
With this changes, the TCK + Sigtests are now passing for Java 8 + Java
11:

[javatest.batch] Number of tests completed:  90 (90 pass, 0 fail, 0
errors)
[javatest.batch]
***
[javatest.batch] Completed running 90 tests.
[javatest.batch] Number of Tests Passed  = 90
[javatest.batch] Number of Tests Failed  = 0
[javatest.batch] Number of Tests with Errors = 0
[javatest.batch] Number of Tests Not Run = 0

If someone can have a look, it would be appreciated.

Gruß
Richard


Am Montag, dem 23.05.2022 um 18:47 + schrieb Zowalla, Richard:
> Hi all,
> 
> I did run the sig tests + tck on the 2.0.0-M1 and found some issues.
> Subsequently, I created 
> https://issues.apache.org/jira/browse/GERONIMO-6832 and will try to
> fix
> them.
> 
> Gruß
> Richard
> 

Re: [RESULT] Release Activation 2.0.0-M1

[Zowalla, Richard]

Hi all,

I did run the sig tests + tck on the 2.0.0-M1 and found some issues.
Subsequently, I created 
https://issues.apache.org/jira/browse/GERONIMO-6832 and will try to fix
them.

Gruß
Richard

Am Montag, dem 23.05.2022 um 08:55 -0700 schrieb David Blevins:
> Vote passes with 6 +1s (4 binding)
> 
> As noted I didn't go for a final as we still haven't run the full set
> of TCK tests which include the signature tests.  If someone would
> like to do that or propose a final without doing that, they're
> welcome to do so.
> 
> 
> -David
> 
> 
> > On May 14, 2022, at 2:00 PM, David Blevins  > > wrote:
> > 
> > Hey All,
> > 
> > We're thinking to do a release on the TomEE side and this is one of
> > the snapshot dependencies we have.  I've prepped a 2.0.0-M1 with
> > the idea that being a milestone it should be fairly non-
> > controversial to propose without a heads up and I haven't checked
> > the TCK status.  I know we're not yet actively running the
> > signature tests on the TomEE side.
> > 
> > I propose we release 2.0.0-M1 so we have some non-snapshots to work
> > with and come back to 2.0.0 as things look 100% on all fronts
> > 
> > Staging Maven repository:
> > 
> > - 
> > https://repository.apache.org/content/repositories/orgapachegeronimo-1153/
> > 
> > The only change is conversion from javax to the jakarta namespace
> > via contributor Richard Zowalla.
> > 
> > 
> > Please vote to approve this release:
> > [ ] +1 Approve the release
> > [ ]  0 Abstain (please provide specific comments)
> > [ ] -1 Don't approve the release (please provide specific comments)
> > 
> > This vote will be open for at least 72 hours.
> > 
> > -David
> > 

AW: [VOTE] Release Mail 2.0.0-M1

[Zowalla, Richard]

Side note: JL did run the mail tck: 
https://tck.work/tomee/tests?build=1651841331620=com.sun.ts.tests.javamail

Gruß
Richard

Von: David Blevins 
Gesendet: Samstag, 14. Mai 2022 23:27:29
An: dev@geronimo.apache.org
Betreff: [VOTE] Release Mail 2.0.0-M1

Hey All,

If I was thinking ahead I'd have put these both in the same staging repo and 
vote :)

Staging Maven repository:

- https://repository.apache.org/content/repositories/orgapachegeronimo-1153/

The only change is conversion from javax to the jakarta namespace via 
contributor Richard Zowalla and a change from "javamail" to simply "mail"


Please vote to approve this release:
[ ] +1 Approve the release
[ ]  0 Abstain (please provide specific comments)
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

-David

Re: TomEE MicroProfile and Jakarta

[Zowalla, Richard]

So we basically have to options (if I understand the discussion
correctly):

(A) Put some effort / resources into upgrade our MP impls to the latest
versions to fully support Jakarta namespace. From my understanding
maintaining these impls is a bit PITA as MP tends to break its API
every few months, right? It will take some time, effort and resources
to catch up.

(B) Use existing MP impls to make "fast" progress on the TomEE 9.x
side, which breaks the "we use apache impls"-credo but enables a faster
move forward. I see the danger here that we - due to lack of time /
resources - will not find the way back to our own Apache
implementations and will stick with smallrye for a long (?) time
perhaps.

People are eager to use EE9 / Jakarta namespace and TomEE isn't really
ready for it, yet. With the latest M7 version, users cannot start new
projects as testing possibilities are super limited.

Btw.: I am unsure, if we are still using Hibernate Validation in the
current TomEE 9-M8 Snapshot. But if we do, we already broke the
"everything from apache"-credo for the sake of getting the
certifaction. 

As I am too new to the whole context / strategy thing, I read this
discussion with great interest but do not have a strong opinion
regarding (A) or (B).

Gruß
Richard


Am Freitag, dem 01.04.2022 um 08:27 +0200 schrieb Romain Manni-Bucau:
> The risk for TomEE (IMHO indeed) is that, using smallrye, you break
> the
> core value "apache" or at least "owned by apache" and break the other
> core
> value "lightweight" since it comes with a tons of uneeded stuff and
> implementation is not even JAXRS friendly (it breaks literally jaxrs
> and
> cdi at multiple levels) so it can mean contributing to smallrye which
> means
> at the end asking mircoprofile to not be a spec but just an
> implementation
> and TomEE to stick to a dedicated MP distro (not in all others) to
> not kill
> itself - not saying it does not makes sense but it is what it means
> concretely.
> 
> 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 jeu. 31 mars 2022 à 21:36, David Blevins 
> a
> écrit :
> 
> > It would be great to see us have compliant MicroProfile
> > implementations
> > somewhere in Apache; Geronimo, TomEE, CXF.  It's still my personal
> > preference --  It makes very little sense to go through the effort
> > to
> > create a spec and tck to enable multiple implementations that can
> > compete/innovate and then wind up with just one implementation in
> > the
> > industry.
> > 
> > That said, from a TomEE perspective we're struggling to keep up
> > with all
> > specs, Jakarta EE and MicroProfile.  Part of that is we do try to
> > uniquely
> > implement specs, while everyone else just uses the exact same
> > implementation.  We're not really playing the same game.  We would
> > need
> > more resources than the competition to compete in the way we have
> > been
> > attempting.  However, because we're behind, we end up with fewer
> > resources
> > and larger gaps between implementations and over time our goals
> > becomes
> > harder, not easier.
> > 
> > I wonder if we should switch to the SmallRye implementations where
> > needed.  Not because we've given up hope of having Apache
> > implementations,
> > but because if we assume our desire to do the implementation work
> > here is a
> > constant and we know the time to get there will some number of
> > months and
> > that will likely be after complete our Jakarta EE spec work, which
> > is also
> > some number of months... we're basically talking sometime
> > 2023.  The
> > question then becomes, how do we want to spend our time till
> > then?  Do we
> > want to spend it in a compliant state or a non-compliant state?
> > 
> > If we spend the next year and change in a compliant state, using
> > the
> > SmallRye impls where needed until we've created compliant Apache
> > versions,
> > then we are competitive and will gain resources.  The date on which
> > we
> > would have resources to create those Apache implementations would
> > likely be
> > sooner.  If we spend the next year and change still not in a
> > compliant
> > state (as we've been since 2020), then we'l continue to take a
> > resource hit
> > and the date on which we would have resources to create those
> > Apache
> > implementations would likely be later.  There are also other risks
> > with
> > this approach.
> > 
> > So though it may seem backwards my gut says, unless we get a
> > dramatic
> > influx of resources from nowhere, we should use SmallRye where we
> > need
> > until we have the time to dedicate to the Apache implementations.
> > 
> > 
> > -David
> > 
> > 
> > > On Mar 31, 2022, at 12:44 AM, Jean-Louis Monteiro <

Re: µProfile Impl Status - Any information pointers?

[Zowalla, Richard]

Hi Romain,

thanks for the fast response and the pointers. It helps a lot!

Personally, I never used µProfile before, but was following up on
gathering some information as it was asked on the TomEE list. 

If I understand your response correctly, µProfile breaks it's API every
6 months - that is - imho - a bad thing as it generates costs for
enterprises (lol) and limits its use (from my perspective).

Gruß
Richard



Am Mittwoch, dem 02.02.2022 um 10:15 +0100 schrieb Romain Manni-Bucau:
> Hi Richard,
> 
> Entry point is https://geronimo.apache.org/microprofile/
> Guess supported version is kind of there 
> https://github.com/apache/geronimo-microprofile/blob/master/geronimo-microprofile-aggregator/pom.xml#L32
> 
> To check the matching it is mainly a dependency check - blame
> uprofile to break each 6 months their API ;).
> 
> On the future I'm not sure what it will be since their policy made it
> kind of rejected and hard to use in enterprises so not sure we would
> follow - at lest personally I dropped it all due to that and have no
> will to loose time in temporary half-baked solutions but our
> implementation is likely one os the lightest and most efficient in
> the ecosystem so it should be easy to update to the new API if anyone
> wants to play that vendor game.
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> 
> 
> Le mer. 2 févr. 2022 à 09:55, Zowalla, Richard <
> richard.zowa...@hs-heilbronn.de> a écrit :
> > Hi all,
> > 
> > is there an overview page of the current µProfile implementation
> > status
> > other than on the website [1] ?
> > 
> > Sorry - did not investigate the list discussions deeply but would
> > appreciate some pointers, if there is an ongoing discussion oin
> > this
> > section :)
> > 
> > I found some discussion regarding Metrics 3.0-M2 but the impl
> > references 3.0-RC2 spec version but there is 3.0 available and so
> > on,
> > so I am wondering, if there is some sort of common knowledge
> > somewhere,
> > to summarize the current impl state of µProfile 4.x at geronimo? :)
> > 
> > It is a bit hard (at least for users) to check, which 1.0.x impl
> > corresponds to which spec version (at least on the website) without
> > digging into the code. :)
> > 
> > Thanks & Gruß
> > Richard
> > 
> > 
> > [1] https://geronimo.apache.org/microprofile/
> > [2] 
> > https://github.com/apache/geronimo-metrics/blob/master/pom.xml#L45
-- 
Richard Zowalla, M.Sc.
Research Associate, PhD Student | Medical Informatics

Hochschule Heilbronn – University of Applied Sciences
Max-Planck-Str. 39 
D-74081 Heilbronn 
phone: +49 7131 504 6791 (zur Zeit nicht via Telefon erreichbar)
mail: richard.zowa...@hs-heilbronn.de
web: https://www.mi.hs-heilbronn.de/ 


smime.p7s
Description: S/MIME cryptographic signature

µProfile Impl Status - Any information pointers?

[Zowalla, Richard]

Hi all,

is there an overview page of the current µProfile implementation status
other than on the website [1] ?

Sorry - did not investigate the list discussions deeply but would
appreciate some pointers, if there is an ongoing discussion oin this
section :)

I found some discussion regarding Metrics 3.0-M2 but the impl
references 3.0-RC2 spec version but there is 3.0 available and so on,
so I am wondering, if there is some sort of common knowledge somewhere,
to summarize the current impl state of µProfile 4.x at geronimo? :)

It is a bit hard (at least for users) to check, which 1.0.x impl
corresponds to which spec version (at least on the website) without
digging into the code. :)

Thanks & Gruß
Richard


[1] https://geronimo.apache.org/microprofile/
[2] https://github.com/apache/geronimo-metrics/blob/master/pom.xml#L45


smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] geronimo-javamail_1.6_(provider|mail) 1.0.1 (reroll)

[Zowalla, Richard]

+1 (thx, JL)

Am Freitag, dem 15.10.2021 um 15:47 +0200 schrieb Jean-Louis MONTEIRO:
> Hi!
> 
> I’d like to call a VOTE on the geronimo-javamail_1.6_(provider|mail)
> 1.0.1 
> Importante note: we previously voted for the spec part. This vote is
> for the provider and the mail core.
> 
> This is a re-roll because we were missing the spec update. 
> 
> Here is the staging repo
> https://repository.apache.org/content/repositories/orgapachegeronimo-1143
> 
> And the source jar which is voted on
> https://dist.apache.org/repos/dist/dev/geronimo/javamail/geronimo-javamail_1.6-1.0.1-source-release.zip
> 
> Git tag
> https://github.com/apache/geronimo-javamail/tree/geronimo-javamail_1.6-1.0.1
> 
> My key can be found at
> https://svn.apache.org/repos/asf/geronimo/KEYS
> 
> please VOTE
> [+1] all fine, ship it
> [+0] don't care
> [-1] stop, because ${reason}
> 
> The VOTE is open for 72h.
> 
> 


smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] geronimo-javamail_1.6_(provider|mail) 1.0.1

[Zowalla, Richard]

Shouldn't it be spec v1.0.1 in the POM: 
https://github.com/apache/geronimo-javamail/blob/geronimo-javamail_1.6-1.0.1/geronimo-javamail_1.6/pom.xml#L46

I am just curios and might be wrong? :)


Am Dienstag, dem 12.10.2021 um 22:51 +0200 schrieb Jean-Louis MONTEIRO:
> Hi!
> 
> I’d like to call a VOTE on the geronimo-javamail_1.6_(provider|mail)
> 1.0.1 
> Importante note: we previously voted for the spec part. This vote is
> for the provider and the mail core.
> 
> Here is the staging repo
> https://repository.apache.org/content/repositories/orgapachegeronimo-1142
> 
> And the source jar which is voted on
> https://dist.apache.org/repos/dist/dev/geronimo/javamail/geronimo-javamail_1.6-1.0.1-source-release.zip
> 
> Git tag
> https://github.com/apache/geronimo-javamail/tree/geronimo-javamail_1.6-1.0.1
> 
> My key can be found at
> https://svn.apache.org/repos/asf/geronimo/KEYS
> 
> please VOTE
> [+1] all fine, ship it
> [+0] don't care
> [-1] stop, because ${reason}
> 
> The VOTE is open for 72h.
> Jean-Louis


smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] geronimo-javamail_1.6_(provider|mail) 1.0.1

[Zowalla, Richard]

+1

Am Dienstag, dem 12.10.2021 um 22:51 +0200 schrieb Jean-Louis MONTEIRO:
> Hi!
> 
> I’d like to call a VOTE on the geronimo-javamail_1.6_(provider|mail)
> 1.0.1 
> Importante note: we previously voted for the spec part. This vote is
> for the provider and the mail core.
> 
> Here is the staging repo
> https://repository.apache.org/content/repositories/orgapachegeronimo-1142
> 
> And the source jar which is voted on
> https://dist.apache.org/repos/dist/dev/geronimo/javamail/geronimo-javamail_1.6-1.0.1-source-release.zip
> 
> Git tag
> https://github.com/apache/geronimo-javamail/tree/geronimo-javamail_1.6-1.0.1
> 
> My key can be found at
> https://svn.apache.org/repos/asf/geronimo/KEYS
> 
> please VOTE
> [+1] all fine, ship it
> [+0] don't care
> [-1] stop, because ${reason}
> 
> The VOTE is open for 72h.
> Jean-Louis


smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] geronimo-javamail_1.6_spec 1.0.1

[Zowalla, Richard]

+1 (downstream mail & provider would be great in terms of TLS 1.2+
compatibility)

Am Freitag, dem 08.10.2021 um 15:05 +0200 schrieb Romain Manni-Bucau:
> +1 (I assume a follow up vote can be needed for 
> https://svn.apache.org/repos/asf/geronimo/javamail/trunk/geronimo-javamail_1.6/
> to get it fully out the door? if you want you can run both at the
> same time making downstream one dependent on this one ;))
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> 
> 
> Le ven. 8 oct. 2021 à 10:13, Jean-Baptiste Onofré  a
> écrit :
> > +1 (binding)
> > 
> > Regards
> > JB
> > 
> > On 07/10/2021 21:30, Jean-Louis MONTEIRO wrote:
> > > Hi!
> > > 
> > > I’d like to call a VOTE on the geronimo-javamail_1.6_spec 1.0.1
> > > 
> > > Here is the staging repo
> > > 
> > https://repository.apache.org/content/repositories/orgapachegeronimo-1141
> > <
> > https://repository.apache.org/content/repositories/orgapachegeronimo-1141
> > >
> > > 
> > > And the source jar which is voted on
> > > 
> > https://repository.apache.org/content/repositories/orgapachegeronimo-1141/org/apache/geronimo/specs/geronimo-javamail_1.6_spec/1.0.1/geronimo-javamail_1.6_spec-1.0.1-source-release.zip
> >  
> > > <
> > https://repository.apache.org/content/repositories/orgapachegeronimo-1141/org/apache/geronimo/specs/geronimo-javamail_1.6_spec/1.0.1/geronimo-javamail_1.6_spec-1.0.1-source-release.zip
> > >
> > > 
> > > SVN tag
> > > 
> > https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-javamail_1.6_spec-1.0.1/
> >  
> > > <
> > https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-javamail_1.6_spec-1.0.1/
> > >
> > > 
> > > My key can be found at
> > > https://svn.apache.org/repos/asf/geronimo/KEYS 
> > > 
> > > 
> > > please VOTE
> > > [+1] all fine, ship it
> > > [+0] don't care
> > > [-1] stop, because ${reason}
> > > 
> > > The VOTE is open for 72h.
> > > 
> > > -- 
> > > Jean-Louis
-- 
Richard Zowalla, M.Sc.
Research Associate, PhD Student | Medical Informatics

Hochschule Heilbronn – University of Applied Sciences
Max-Planck-Str. 39 
D-74081 Heilbronn 
phone: +49 7131 504 6791 (zur Zeit nicht via Telefon erreichbar)
mail: richard.zowa...@hs-heilbronn.de
web: https://www.mi.hs-heilbronn.de/ 


smime.p7s
Description: S/MIME cryptographic signature

Re: [javamail] - Branch version

[Zowalla, Richard]

I think, we shouldn't miss 
https://issues.apache.org/jira/browse/GERONIMO-6800 
for a release (no PR, but a patch file)

Gruss
Richard

Am Mittwoch, den 28.07.2021, 09:05 +0200 schrieb fpa...@apache.org:
> Ok thanks all!
> 
> I will move forward on this and merge the 2 pending PRs and prepare a
> release.
> 
> regards,
> 
> François
> fpa...@apache.org
> 
> Le 28/07/2021 à 08:25, Zowalla, Richard a écrit :
> > I like the idea (+1). 
> > 
> > Gruss
> > Richard 
> > 
> > Am Mittwoch, den 28.07.2021, 08:12 +0200 schrieb JB Onofré:
> > > +1
> > > 
> > > It makes sense. Thanks.
> > > Regards 
> > > JB
> > > 
> > > > Le 28 juil. 2021 à 07:38, Romain Manni-Bucau <
> > > > rmannibu...@gmail.com
> > > > > a écrit :
> > > > 
> > > > +1 (will also help upgrades ;))
> > > > 
> > > > Romain Manni-Bucau
> > > > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> > > > 
> > > > 
> > > > Le mer. 28 juil. 2021 à 00:51, Cesar Hernandez <
> > > > cesargu...@gmail.com> a écrit :
> > > > > Hi,
> > > > > I don't have the historical background about why the
> > > > > repository
> > > > > have folders, but +1 on having dedicated branches.
> > > > > 
> > > > > El mar, 27 jul 2021 a las 15:01, 
> > > > > escribió:
> > > > > > Hi,
> > > > > > 
> > > > > > Today we have 4 directories in the geronimo-javamail
> > > > > > repository
> > > > > > and I
> > > > > > would like to propose to use tags rather than directory to
> > > > > > manage 1.x
> > > > > > version.
> > > > > > 
> > > > > > We would have the latest current version on root (1.6) and
> > > > > > 1.3.1, 1.4,
> > > > > > 1.5 on a dedicated branch.
> > > > > > 
> > > > > > It will also help us for the release process.
> > > > > > 
> > > > > > Toughts?
> > > > > > 
> > > > > > https://github.com/apache/geronimo-javamail
> > > > > > <https://github.com/apache/geronimo-javamail>
> > > > > > 
> > > > > > regards,
> > > > > > 
> > > > > > -- 
> > > > > > François
> > > > > > fpa...@apache.org
> > > > > > 
-- 
Richard Zowalla, M.Sc.
Research Associate, PhD Student | Medical Informatics

Hochschule Heilbronn – University of Applied Sciences
Max-Planck-Str. 39 
D-74081 Heilbronn 
phone: +49 7131 504 6791 (zur Zeit nicht via Telefon erreichbar)
mail: richard.zowa...@hs-heilbronn.de
web: https://www.mi.hs-heilbronn.de/ 


smime.p7s
Description: S/MIME cryptographic signature

Re: [javamail] - Branch version

[Zowalla, Richard]

I like the idea (+1). 

Gruss
Richard 

Am Mittwoch, den 28.07.2021, 08:12 +0200 schrieb JB Onofré:
> +1
> 
> It makes sense. Thanks.
> Regards 
> JB
> 
> > Le 28 juil. 2021 à 07:38, Romain Manni-Bucau  > > a écrit :
> > 
> > 
> > +1 (will also help upgrades ;))
> > 
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> > 
> > 
> > Le mer. 28 juil. 2021 à 00:51, Cesar Hernandez <
> > cesargu...@gmail.com> a écrit :
> > > Hi,
> > > I don't have the historical background about why the repository
> > > have folders, but +1 on having dedicated branches.
> > > 
> > > El mar, 27 jul 2021 a las 15:01,  escribió:
> > > > Hi,
> > > > 
> > > > Today we have 4 directories in the geronimo-javamail repository
> > > > and I
> > > > would like to propose to use tags rather than directory to
> > > > manage 1.x
> > > > version.
> > > > 
> > > > We would have the latest current version on root (1.6) and
> > > > 1.3.1, 1.4,
> > > > 1.5 on a dedicated branch.
> > > > 
> > > > It will also help us for the release process.
> > > > 
> > > > Toughts?
> > > > 
> > > > https://github.com/apache/geronimo-javamail
> > > > 
> > > > 
> > > > regards,
> > > > 
> > > > -- 
> > > > François
> > > > fpa...@apache.org
> > > > 
> > > 
> > > 


smime.p7s
Description: S/MIME cryptographic signature

Re: Pending patches

[Zowalla, Richard]

Done.

- https://github.com/apache/geronimo-javamail/pull/2
- https://github.com/apache/geronimo-javamail/pull/3

Gruss
Richard

Am Mittwoch, den 21.07.2021, 09:59 + schrieb Zowalla, Richard:
> 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
> > > > > > > > > 
> > > &g

Re: Pending patches

[Zowalla, Richard]

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 threa

Re: Pending patches

[Zowalla, Richard]

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
> > > > > > > > >

Re: Pending patches

[Zowalla, Richard]

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
> > > >  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 :
&g

Re: [DISCUSS] - SVN to Gitbox

[Zowalla, Richard]

> 1. enable PR on github (today it is a mess for external users)

I can only give +1 to this point ;)


Am Dienstag, den 11.05.2021, 15:13 +0200 schrieb Romain Manni-Bucau:
> Guess we should stick to what we are used to.
> The most visible part is likely the release so I'm tempted to say we
> do one repo per atomic release.
> For specs it likely means one repo per spec (but we can automate it
> or work with infra to bulk migrate it).
> Will maybe hurt a bit right now but will:
> 
> 1. enable PR on github (today it is a mess for external users)
> 2. make releases easier (monorepo failed, happy we never moved to
> that ;))
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> 
> 
> Le mar. 11 mai 2021 à 14:00, Jean-Baptiste Onofre  a
> écrit :
> > Hi Mark,
> > 
> > I guess you mean for the release ? 
> > 
> > If we agree to have bunch of tag, we can have spec in a single repo
> > (it’s what I’m doing at ServiceMix).
> > 
> > But I guess it would be cleaner to have a dedicated repo per spec
> > (less convenient anyway).
> > 
> > Regards
> > JB
> > 
> > > Le 11 mai 2021 à 13:56, Mark Struberg  a écrit
> > :
> > > 
> > > specs could be tricky. We'd need to do every single spec as own
> > git repo, isn't?
> > > 
> > > LieGrue,
> > > strub
> > > 
> > > 
> > >> Am 11.05.2021 um 05:39 schrieb fpa...@apache.org:
> > >> 
> > >> Hi,
> > >> 
> > >> I would like to start a discussion about moving some of our
> > project
> > >> repositories from svn to gitbox.
> > >> 
> > >> 
> > >> I think we can start with this projects:
> > >> 
> > >> - http://svn.apache.org/repos/asf/geronimo/xbean/
> > >> 
> > >> - http://svn.apache.org/repos/asf/geronimo/javamail/
> > >> 
> > >> - http://svn.apache.org/repos/asf/geronimo/components/txmanager/
> > >> 
> > >> - http://svn.apache.org/repos/asf/geronimo/specs/
> > >> 
> > >> 
> > >> Here are the current Geronimo gitbox projects:
> > >> 
> > >> https://gitbox.apache.org/repos/asf#geronimo
> > >> 
> > >> 
> > >> Any objection? Don't hesitate to add other project you want to
> > move.
> > >> 
> > >> regards,
> > >> 
> > >> -- 
> > >> François
> > >> fpa...@apache.org
> > >> 
> > > 
> > 
-- 
Richard Zowalla, M.Sc.
Research Associate, PhD Student | Medical Informatics

Hochschule Heilbronn – University of Applied Sciences
Max-Planck-Str. 39 
D-74081 Heilbronn 
phone: +49 7131 504 6791 (zur Zeit nicht via Telefon erreichbar)
mail: richard.zowa...@hs-heilbronn.de
web: https://www.mi.hs-heilbronn.de/ 


smime.p7s
Description: S/MIME cryptographic signature

Re: Pending patches

[Zowalla, Richard]

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
> >  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  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
> > > > > 
> > > 
> > > 


smime.p7s
Description: S/MIME cryptographic signature

Re: Pending patches

[Zowalla, Richard]

Hi,

I think, it is about the configuration flexibility in tomee's
 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  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
> > > 
> 
> 
-- 
Richard Zowalla, M.Sc.
Research Associate, PhD Student | Medical Informatics

Hochschule Heilbronn – University of Applied Sciences
Max-Planck-Str. 39 
D-74081 Heilbronn 
phone: +49 7131 504 6791
mail: richard.zowa...@hs-heilbronn.de
web: https://www.mi.hs-heilbronn.de/ 


smime.p7s
Description: S/MIME cryptographic signature

Re: Pending patches

[Zowalla, Richard]

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  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



smime.p7s
Description: S/MIME cryptographic signature

Re: Geronimo Java Mail 1.6 in TomEE 8.0.5 -> TLS 1.2 / 1.3 Support?

[Zowalla, Richard]

Hi,

I filled a JIRA [1] to address the issues related to cypher suites. 

Yes, the original PR changes are related to STARTLS code, but I think,
that we are fine (at least for now).

Gruss
Richard


[1] https://issues.apache.org/jira/browse/GERONIMO-6793

Am Donnerstag, den 03.12.2020, 20:55 + schrieb Bernd Eckenfels:
> Hello,
> 
> Yes I agree, the ciphers would be its own (security) issue.
> 
>  and it might be not so simple to fix as Mail servers are notoriously
> outdated and TLS-sloppy. Luckily JDK has already some provisions for
> demoting old/deprecated ciphers and also disable most of the not
> useable insecure ones in the supported list (but still this weakening
> of the JDK defaults should be opt-in).
> 
> BTW i haven’t checked all of the code, if you are requesting TLS
> context, there might be another point to look out for protocol names
> (very unfortunate API design I must say). I imagine this might be
> needed for STARTLS code?
> 
> Gruss
> Bernd
> 
> 
> --
> http://bernd.eckenfels.net
> 
>  
> Von: Zowalla, Richard 
> Gesendet: Donnerstag, Dezember 3, 2020 1:48 PM
> An: dev@geronimo.apache.org
> Betreff: Re: Re: Geronimo Java Mail 1.6 in TomEE 8.0.5 -> TLS 1.2 /
> 1.3 Support?
>  
> 
> Hi Bernd,
> 
> @1: I think the original intention of the code (before the PR) was to
> disallow the use of sslv2 or sslv3 for the tls handling code thus the
> hard-coding to tlsv1 as ssl is handled in another part of the class.
> But I agree, that we could remove the "else" and consequently all
> kind
> of hard-coded TLS config. In this way, we would trust in the jdk
> defaults. 
> 
> @2: I think, that the aspect related to cyphers would be a separate
> issue / PR. I agree, that enabling all available cyphers (L602/L603)
> is
> not a good idea in general, but this code hasn't changed in the
> proposed PR :)
> 
> 
> wdyt?
> 
> Best
> Richard
> 
> Am Donnerstag, den 03.12.2020, 12:11 + schrieb Bernd Eckenfels:
> > Hello,
> > 
> > Allowing protocols to be configured is good, but I am not sure why
> > you fall back to a hand selected list of no configuration is given,
> > why not simply use the JDK defaults, they are frequently adjusted
> > (just recently the older TLS versions get removed).
> > 
> > Along this line, why enable all supported ciphers? There is a good
> > reason why the JDK disables many. I would stick to the default
> > ciphers (and protocols).
> > 
> > Gruss
> > Bernd
> > --
> > http://bernd.eckenfels.net
> >  
> > Von: Zowalla, Richard 
> > Gesendet: Mittwoch, Dezember 2, 2020 4:57 PM
> > An: dev@geronimo.apache.org
> > Betreff: Re: Re: Geronimo Java Mail 1.6 in TomEE 8.0.5 -> TLS 1.2 /
> > 1.3 Support?
> >  
> > Should be fixed now.
> > 
> > Am Mittwoch, den 02.12.2020, 15:32 + schrieb Zowalla, Richard:
> > > It is indeed
> > > 
> > > mail..ssl.socketFactory.class
> > > 
> > > (see line 88, MailConnection#MAIL_SSL_FACTORY_CLASS -> uses
> > > reflection to create an instance of the specified factory.
> > > 
> > > or
> > > 
> > > mail..ssl.socketFactory
> > > 
> > > (which requires adding a pre-configured and instantiated factory
> > > instance into the properties of the mail session)
> > > 
> > > To be complete, I will add this way to the README as well.
> > > 
> > > Am Mittwoch, den 02.12.2020, 16:24 +0100 schrieb Romain Manni-
> > Bucau:
> > > > Isnt the property mail..ssl.socketFactory ?
> > > > 
> > > > Romain Manni-Bucau
> > > > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> > > > 
> > > > 
> > > > Le mer. 2 déc. 2020 à 16:09, Zowalla, Richard <
> > > > richard.zowa...@hs-heilbronn.de> a écrit :
> > > > > Okay. Thanks for the feedback - today, I learned a lot about
> > the
> > > > > insides of Javamail :)
> > > > > 
> > > > > I have updated my PR:
> > > > > 
> > > > > - Updated README.txt to contain some documentation about
> > setting
> > > > > a
> > > > > custom ssl socket factory
> > > > > - Dropped TLSv1 in the fallback protocols (if no custom set
> > > > > properties
> > > > > are present)
> > > > > 
> > > > > Thanks,
> > > > > Richard
> > > > > 
> > > > > 
> > > > > Am Mittwoch, den 02.12.2020, 15:29 +0100 schrieb 

Re: Re: Geronimo Java Mail 1.6 in TomEE 8.0.5 -> TLS 1.2 / 1.3 Support?

[Zowalla, Richard]

Hi Bernd,

@1: I think the original intention of the code (before the PR) was to
disallow the use of sslv2 or sslv3 for the tls handling code thus the
hard-coding to tlsv1 as ssl is handled in another part of the class.
But I agree, that we could remove the "else" and consequently all kind
of hard-coded TLS config. In this way, we would trust in the jdk
defaults. 

@2: I think, that the aspect related to cyphers would be a separate
issue / PR. I agree, that enabling all available cyphers (L602/L603) is
not a good idea in general, but this code hasn't changed in the
proposed PR :)


wdyt?

Best
Richard

Am Donnerstag, den 03.12.2020, 12:11 + schrieb Bernd Eckenfels:
> Hello,
> 
> Allowing protocols to be configured is good, but I am not sure why
> you fall back to a hand selected list of no configuration is given,
> why not simply use the JDK defaults, they are frequently adjusted
> (just recently the older TLS versions get removed).
> 
> Along this line, why enable all supported ciphers? There is a good
> reason why the JDK disables many. I would stick to the default
> ciphers (and protocols).
> 
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
>  
> Von: Zowalla, Richard 
> Gesendet: Mittwoch, Dezember 2, 2020 4:57 PM
> An: dev@geronimo.apache.org
> Betreff: Re: Re: Geronimo Java Mail 1.6 in TomEE 8.0.5 -> TLS 1.2 /
> 1.3 Support?
>  
> Should be fixed now.
> 
> Am Mittwoch, den 02.12.2020, 15:32 + schrieb Zowalla, Richard:
> > It is indeed
> > 
> > mail..ssl.socketFactory.class
> > 
> > (see line 88, MailConnection#MAIL_SSL_FACTORY_CLASS -> uses
> > reflection to create an instance of the specified factory.
> > 
> > or
> > 
> > mail..ssl.socketFactory
> > 
> > (which requires adding a pre-configured and instantiated factory
> > instance into the properties of the mail session)
> > 
> > To be complete, I will add this way to the README as well.
> > 
> > Am Mittwoch, den 02.12.2020, 16:24 +0100 schrieb Romain Manni-
> Bucau:
> > > Isnt the property mail..ssl.socketFactory ?
> > > 
> > > Romain Manni-Bucau
> > > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> > > 
> > > 
> > > Le mer. 2 déc. 2020 à 16:09, Zowalla, Richard <
> > > richard.zowa...@hs-heilbronn.de> a écrit :
> > > > Okay. Thanks for the feedback - today, I learned a lot about
> the
> > > > insides of Javamail :)
> > > > 
> > > > I have updated my PR:
> > > > 
> > > > - Updated README.txt to contain some documentation about
> setting
> > > > a
> > > > custom ssl socket factory
> > > > - Dropped TLSv1 in the fallback protocols (if no custom set
> > > > properties
> > > > are present)
> > > > 
> > > > Thanks,
> > > > Richard
> > > > 
> > > > 
> > > > Am Mittwoch, den 02.12.2020, 15:29 +0100 schrieb Romain Manni-
> > > > Bucau:
> > > > > Guess you can just create a readme in the geronimo-javamail
> > > > root
> > > > > project, will be sufficient as a first step.
> > > > > Abou he default I wonder if dropping tlsv1 cant be good since
> > > > it will
> > > > > be dropped soon?
> > > > > Otherwise just adding the missing "o" in protocols i'm fine
> > > > with your
> > > > > proposal.
> > > > > 
> > > > > We need to refine if we do a javamail subsite or a generic
> spec
> > > > > subsite sill :s.
> > > > > 
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> > > > > 
> > > > > 
> > > > > Le mer. 2 déc. 2020 à 15:26, Zowalla, Richard <
> > > > > richard.zowa...@hs-heilbronn.de> a écrit :
> > > > > > I updated the diff (cf. v2) to (hopefully) address the
> > > > concerns
> > > > > > raised
> > > > > > (if I understood them correctly).
> > > > > > 
> > > > > > If you point me to a location where I can add a README /
> > > > > > documentation,
> > > > > > I would be happy to fill another JIRA with a related PR to
> > > > document
> > > > > > the
> > > > > > usage of the custom ssl socket factory.
> > > > > > 
> > > > > > Am Mittwoch, den 02.12.2020, 13:58 + schrieb Zowalla,
> > &g

Re: Re: Geronimo Java Mail 1.6 in TomEE 8.0.5 -> TLS 1.2 / 1.3 Support?

[Zowalla, Richard]

Should be fixed now.

Am Mittwoch, den 02.12.2020, 15:32 + schrieb Zowalla, Richard:
> It is indeed
> 
> mail..ssl.socketFactory.class
> 
> (see line 88, MailConnection#MAIL_SSL_FACTORY_CLASS -> uses
> reflection to create an instance of the specified factory.
> 
> or
> 
> mail..ssl.socketFactory
> 
> (which requires adding a pre-configured and instantiated factory
> instance into the properties of the mail session)
> 
> To be complete, I will add this way to the README as well.
> 
> Am Mittwoch, den 02.12.2020, 16:24 +0100 schrieb Romain Manni-Bucau:
> > Isnt the property mail..ssl.socketFactory ?
> > 
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> > 
> > 
> > Le mer. 2 déc. 2020 à 16:09, Zowalla, Richard <
> > richard.zowa...@hs-heilbronn.de> a écrit :
> > > Okay. Thanks for the feedback - today, I learned a lot about the
> > > insides of Javamail :)
> > > 
> > > I have updated my PR:
> > > 
> > > - Updated README.txt to contain some documentation about setting
> > > a
> > > custom ssl socket factory
> > > - Dropped TLSv1 in the fallback protocols (if no custom set
> > > properties
> > > are present)
> > > 
> > > Thanks,
> > > Richard
> > > 
> > > 
> > > Am Mittwoch, den 02.12.2020, 15:29 +0100 schrieb Romain Manni-
> > > Bucau:
> > > > Guess you can just create a readme in the geronimo-javamail
> > > root
> > > > project, will be sufficient as a first step.
> > > > Abou he default I wonder if dropping tlsv1 cant be good since
> > > it will
> > > > be dropped soon?
> > > > Otherwise just adding the missing "o" in protocols i'm fine
> > > with your
> > > > proposal.
> > > > 
> > > > We need to refine if we do a javamail subsite or a generic spec
> > > > subsite sill :s.
> > > > 
> > > > Romain Manni-Bucau
> > > > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> > > > 
> > > > 
> > > > Le mer. 2 déc. 2020 à 15:26, Zowalla, Richard <
> > > > richard.zowa...@hs-heilbronn.de> a écrit :
> > > > > I updated the diff (cf. v2) to (hopefully) address the
> > > concerns
> > > > > raised
> > > > > (if I understood them correctly).
> > > > > 
> > > > > If you point me to a location where I can add a README /
> > > > > documentation,
> > > > > I would be happy to fill another JIRA with a related PR to
> > > document
> > > > > the
> > > > > usage of the custom ssl socket factory.
> > > > > 
> > > > > Am Mittwoch, den 02.12.2020, 13:58 + schrieb Zowalla,
> > > Richard:
> > > > > > Thanks for your thoughs - I think, I get the idea.
> > > > > > 
> > > > > > Maybe:
> > > > > > 
> > > > > > - Using "mail.smtp.ssl.protocls" to allow easier
> > > configuration
> > > > > (as
> > > > > > proposed in the PR) for
> > > MailConnection#getConnectedTLSSocket() -
> > > > > > would
> > > > > > address 1.
> > > > > > 
> > > > > > - To address 3. and pre-claim: PR would enable all
> > > protocols;
> > > > > maybe
> > > > > > address this concern by adding a default fallback pointing
> > > to
> > > > > TLSv1,
> > > > > > TLSv1.1, TLSv1.2 and TLS v1.3 (if supported) if no custom
> > > > > > configuration
> > > > > > via "mail.smtp.ssl.protocls" is present?
> > > > > > 
> > > > > > - Documentation is always appreciated ;)
> > > > > > 
> > > > > > Wdyt?
> > > > > > 
> > > > > > Am Mittwoch, den 02.12.2020, 14:41 +0100 schrieb Romain
> > > Manni-
> > > > > Bucau:
> > > > > > > Yes but issue that we don't want to enable them all too.
> > > > > > > So to be concrete what about:
> > > > > > > 
> > > > > > > 1. Enable a smoother configuration (to avoid a custom
> > > class)
> > > > > > > 2. Document the custom class case better (at least in a
> > > readme)
> > > > > > > 3. Change 

Re: Re: Geronimo Java Mail 1.6 in TomEE 8.0.5 -> TLS 1.2 / 1.3 Support?

[Zowalla, Richard]

It is indeed
mail..ssl.socketFactory.class
(see line 88, MailConnection#MAIL_SSL_FACTORY_CLASS -> uses reflection
to create an instance of the specified factory.
or
mail..ssl.socketFactory
(which requires adding a pre-configured and instantiated factory
instance into the properties of the mail session)
To be complete, I will add this way to the README as well.
Am Mittwoch, den 02.12.2020, 16:24 +0100 schrieb Romain Manni-Bucau:
> Isnt the property mail..ssl.socketFactory ?
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> 
> 
> Le mer. 2 déc. 2020 à 16:09, Zowalla, Richard <
> richard.zowa...@hs-heilbronn.de> a écrit :
> > Okay. Thanks for the feedback - today, I learned a lot about the
> > 
> > insides of Javamail :)
> > 
> > 
> > 
> > I have updated my PR:
> > 
> > 
> > 
> > - Updated README.txt to contain some documentation about setting a
> > 
> > custom ssl socket factory
> > 
> > - Dropped TLSv1 in the fallback protocols (if no custom set
> > properties
> > 
> > are present)
> > 
> > 
> > 
> > Thanks,
> > 
> > Richard
> > 
> > 
> > 
> > 
> > 
> > Am Mittwoch, den 02.12.2020, 15:29 +0100 schrieb Romain Manni-
> > Bucau:
> > 
> > > Guess you can just create a readme in the geronimo-javamail root
> > 
> > > project, will be sufficient as a first step.
> > 
> > > Abou he default I wonder if dropping tlsv1 cant be good since it
> > will
> > 
> > > be dropped soon?
> > 
> > > Otherwise just adding the missing "o" in protocols i'm fine with
> > your
> > 
> > > proposal.
> > 
> > > 
> > 
> > > We need to refine if we do a javamail subsite or a generic spec
> > 
> > > subsite sill :s.
> > 
> > > 
> > 
> > > Romain Manni-Bucau
> > 
> > > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> > 
> > > 
> > 
> > > 
> > 
> > > Le mer. 2 déc. 2020 à 15:26, Zowalla, Richard <
> > 
> > > richard.zowa...@hs-heilbronn.de> a écrit :
> > 
> > > > I updated the diff (cf. v2) to (hopefully) address the concerns
> > 
> > > > raised
> > 
> > > > (if I understood them correctly).
> > 
> > > > 
> > 
> > > > If you point me to a location where I can add a README /
> > 
> > > > documentation,
> > 
> > > > I would be happy to fill another JIRA with a related PR to
> > document
> > 
> > > > the
> > 
> > > > usage of the custom ssl socket factory.
> > 
> > > > 
> > 
> > > > Am Mittwoch, den 02.12.2020, 13:58 + schrieb Zowalla,
> > Richard:
> > 
> > > > > Thanks for your thoughs - I think, I get the idea.
> > 
> > > > > 
> > 
> > > > > Maybe:
> > 
> > > > > 
> > 
> > > > > - Using "mail.smtp.ssl.protocls" to allow easier
> > configuration
> > 
> > > > (as
> > 
> > > > > proposed in the PR) for
> > MailConnection#getConnectedTLSSocket() -
> > 
> > > > > would
> > 
> > > > > address 1.
> > 
> > > > > 
> > 
> > > > > - To address 3. and pre-claim: PR would enable all protocols;
> > 
> > > > maybe
> > 
> > > > > address this concern by adding a default fallback pointing to
> > 
> > > > TLSv1,
> > 
> > > > > TLSv1.1, TLSv1.2 and TLS v1.3 (if supported) if no custom
> > 
> > > > > configuration
> > 
> > > > > via "mail.smtp.ssl.protocls" is present?
> > 
> > > > > 
> > 
> > > > > - Documentation is always appreciated ;)
> > 
> > > > > 
> > 
> > > > > Wdyt?
> > 
> > > > > 
> > 
> > > > > Am Mittwoch, den 02.12.2020, 14:41 +0100 schrieb Romain
> > Manni-
> > 
> > > > Bucau:
> > 
> > > > > > Yes but issue that we don't want to enable them all too.
> > 
> > > > > > So to be concrete what about:
> > 
> > > > > > 
> > 
> > > > > > 1. Enable a smoother configuration (to avoid a custom
> > class)
> > 
> > > > > > 2. Document the 

Re: Re: Geronimo Java Mail 1.6 in TomEE 8.0.5 -> TLS 1.2 / 1.3 Support?

[Zowalla, Richard]

Okay. Thanks for the feedback - today, I learned a lot about the
insides of Javamail :)

I have updated my PR:

- Updated README.txt to contain some documentation about setting a
custom ssl socket factory
- Dropped TLSv1 in the fallback protocols (if no custom set properties
are present)

Thanks,
Richard


Am Mittwoch, den 02.12.2020, 15:29 +0100 schrieb Romain Manni-Bucau:
> Guess you can just create a readme in the geronimo-javamail root
> project, will be sufficient as a first step.
> Abou he default I wonder if dropping tlsv1 cant be good since it will
> be dropped soon?
> Otherwise just adding the missing "o" in protocols i'm fine with your
> proposal.
> 
> We need to refine if we do a javamail subsite or a generic spec
> subsite sill :s.
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> 
> 
> Le mer. 2 déc. 2020 à 15:26, Zowalla, Richard <
> richard.zowa...@hs-heilbronn.de> a écrit :
> > I updated the diff (cf. v2) to (hopefully) address the concerns
> > raised
> > (if I understood them correctly).
> > 
> > If you point me to a location where I can add a README /
> > documentation,
> > I would be happy to fill another JIRA with a related PR to document
> > the
> > usage of the custom ssl socket factory.
> > 
> > Am Mittwoch, den 02.12.2020, 13:58 + schrieb Zowalla, Richard:
> > > Thanks for your thoughs - I think, I get the idea.
> > > 
> > > Maybe:
> > > 
> > > - Using "mail.smtp.ssl.protocls" to allow easier configuration
> > (as
> > > proposed in the PR) for MailConnection#getConnectedTLSSocket() -
> > > would
> > > address 1.
> > > 
> > > - To address 3. and pre-claim: PR would enable all protocols;
> > maybe
> > > address this concern by adding a default fallback pointing to
> > TLSv1,
> > > TLSv1.1, TLSv1.2 and TLS v1.3 (if supported) if no custom
> > > configuration
> > > via "mail.smtp.ssl.protocls" is present?
> > > 
> > > - Documentation is always appreciated ;)
> > > 
> > > Wdyt?
> > > 
> > > Am Mittwoch, den 02.12.2020, 14:41 +0100 schrieb Romain Manni-
> > Bucau:
> > > > Yes but issue that we don't want to enable them all too.
> > > > So to be concrete what about:
> > > > 
> > > > 1. Enable a smoother configuration (to avoid a custom class)
> > > > 2. Document the custom class case better (at least in a readme)
> > > > 3. Change a bit default to inherit JVM ones
> > > > 
> > > > Think we should make the 3 to consider this case treated (does
> > not
> > > > mean it must be in the same PR but more before next release).
> > > > Wdyt?
> > > > 
> > > > Romain Manni-Bucau
> > > > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> > > > 
> > > > 
> > > > Le mer. 2 déc. 2020 à 13:20, Zowalla, Richard <
> > > > richard.zowa...@hs-heilbronn.de> a écrit :
> > > > > Ah sorry - I misunderstood your comment.
> > > > > 
> > > > > A custom socket factory would indeed fix the problem, but it
> > is
> > > > > rather undocumented.
> > > > > 
> > > > > Nevertheless I think, that the default fallback shouldn't be
> > > > > hardcoded or at least support some more protocols...
> > > > > 
> > > > > Best and thanks for the idea,
> > > > > Richard
> > > > > 
> > > > > Am Mittwoch, den 02.12.2020, 12:16 + schrieb Zowalla,
> > > > > Richard:
> > > > > > Honestly I didn't. I discovered the hard-coded
> > > > > > String[]("TLSv1")
> > > > > > in
> > > > > > MailConnection#getConnectedTLSSocket(), which is (imho) a
> > bit
> > > > > > odd.
> > > > > > 
> > > > > > Imho, users should either be allowed to specify the enabled
> > > > > > (and
> > > > > > supported) protocols or to use the default ones provided by
> > the
> > > > > > jdk
> > > > > > classes :)
> > > > > > 
> > > > > > This is already done for
> > MailConnection#getConnectedSSLSocket
> > > > > > but
> > > > > > not
> > > > > > for the TLS handling.
> &g

Re: Re: Geronimo Java Mail 1.6 in TomEE 8.0.5 -> TLS 1.2 / 1.3 Support?

[Zowalla, Richard]

Ah ... typo was only in the mail ;)
Thx

Am Mittwoch, den 02.12.2020, 15:38 +0100 schrieb Romain Manni-Bucau:
>  "mail.smtp.ssl.protocls" <- I would have added a "o" between the
> last "c" and "l" ;)
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> 
> 
> Le mer. 2 déc. 2020 à 15:37, Zowalla, Richard <
> richard.zowa...@hs-heilbronn.de> a écrit :
> > Thanks. Removing TLSv1 in the fallback is fine for me.
> > Didn't find the missing "o", though :D
> > 
> > I will update the README and include it in my patch proposal (so no
> > need for another issue).
> > 
> > 
> > Am Mittwoch, den 02.12.2020, 15:29 +0100 schrieb Romain Manni-
> > Bucau:
> > > Guess you can just create a readme in the geronimo-javamail root
> > > project, will be sufficient as a first step.
> > > Abou he default I wonder if dropping tlsv1 cant be good since it
> > will
> > > be dropped soon?
> > > Otherwise just adding the missing "o" in protocols i'm fine with
> > your
> > > proposal.
> > > 
> > > We need to refine if we do a javamail subsite or a generic spec
> > > subsite sill :s.
> > > 
> > > Romain Manni-Bucau
> > > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> > > 
> > > 
> > > 
> > > Le mer. 2 déc. 2020 à 15:26, Zowalla, Richard <
> > > richard.zowa...@hs-heilbronn.de> a écrit :
> > > > I updated the diff (cf. v2) to (hopefully) address the concerns
> > > > raised
> > > > (if I understood them correctly).
> > > > 
> > > > If you point me to a location where I can add a README /
> > > > documentation,
> > > > I would be happy to fill another JIRA with a related PR to
> > document
> > > > the
> > > > usage of the custom ssl socket factory.
> > > > 
> > > > Am Mittwoch, den 02.12.2020, 13:58 + schrieb Zowalla,
> > Richard:
> > > > > Thanks for your thoughs - I think, I get the idea.
> > > > > 
> > > > > Maybe:
> > > > > 
> > > > > - Using "mail.smtp.ssl.protocls" to allow easier
> > configuration
> > > > (as
> > > > > proposed in the PR) for
> > MailConnection#getConnectedTLSSocket() -
> > > > > would
> > > > > address 1.
> > > > > 
> > > > > - To address 3. and pre-claim: PR would enable all protocols;
> > > > maybe
> > > > > address this concern by adding a default fallback pointing to
> > > > TLSv1,
> > > > > TLSv1.1, TLSv1.2 and TLS v1.3 (if supported) if no custom
> > > > > configuration
> > > > > via "mail.smtp.ssl.protocls" is present?
> > > > > 
> > > > > - Documentation is always appreciated ;)
> > > > > 
> > > > > Wdyt?
> > > > > 
> > > > > Am Mittwoch, den 02.12.2020, 14:41 +0100 schrieb Romain
> > Manni-
> > > > Bucau:
> > > > > > Yes but issue that we don't want to enable them all too.
> > > > > > So to be concrete what about:
> > > > > > 
> > > > > > 1. Enable a smoother configuration (to avoid a custom
> > class)
> > > > > > 2. Document the custom class case better (at least in a
> > readme)
> > > > > > 3. Change a bit default to inherit JVM ones
> > > > > > 
> > > > > > Think we should make the 3 to consider this case treated
> > (does
> > > > not
> > > > > > mean it must be in the same PR but more before next
> > release).
> > > > > > Wdyt?
> > > > > > 
> > > > > > Romain Manni-Bucau
> > > > > > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> > > > > > 
> > > > > > 
> > > > > > Le mer. 2 déc. 2020 à 13:20, Zowalla, Richard <
> > > > > > richard.zowa...@hs-heilbronn.de> a écrit :
> > > > > > > Ah sorry - I misunderstood your comment.
> > > > > > > 
> > > > > > > A custom socket factory would indeed fix the problem, but
> > it
> > > > is
> > > > > > > rather undocumented.
> > > > > > > 
> > > > > > > Nevertheless I think, that the de

Re: Re: Geronimo Java Mail 1.6 in TomEE 8.0.5 -> TLS 1.2 / 1.3 Support?

[Zowalla, Richard]

Thanks. Removing TLSv1 in the fallback is fine for me.
Didn't find the missing "o", though :D

I will update the README and include it in my patch proposal (so no
need for another issue).


Am Mittwoch, den 02.12.2020, 15:29 +0100 schrieb Romain Manni-Bucau:
> Guess you can just create a readme in the geronimo-javamail root
> project, will be sufficient as a first step.
> Abou he default I wonder if dropping tlsv1 cant be good since it will
> be dropped soon?
> Otherwise just adding the missing "o" in protocols i'm fine with your
> proposal.
> 
> We need to refine if we do a javamail subsite or a generic spec
> subsite sill :s.
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> 
> 
> 
> Le mer. 2 déc. 2020 à 15:26, Zowalla, Richard <
> richard.zowa...@hs-heilbronn.de> a écrit :
> > I updated the diff (cf. v2) to (hopefully) address the concerns
> > raised
> > (if I understood them correctly).
> > 
> > If you point me to a location where I can add a README /
> > documentation,
> > I would be happy to fill another JIRA with a related PR to document
> > the
> > usage of the custom ssl socket factory.
> > 
> > Am Mittwoch, den 02.12.2020, 13:58 + schrieb Zowalla, Richard:
> > > Thanks for your thoughs - I think, I get the idea.
> > > 
> > > Maybe:
> > > 
> > > - Using "mail.smtp.ssl.protocls" to allow easier configuration
> > (as
> > > proposed in the PR) for MailConnection#getConnectedTLSSocket() -
> > > would
> > > address 1.
> > > 
> > > - To address 3. and pre-claim: PR would enable all protocols;
> > maybe
> > > address this concern by adding a default fallback pointing to
> > TLSv1,
> > > TLSv1.1, TLSv1.2 and TLS v1.3 (if supported) if no custom
> > > configuration
> > > via "mail.smtp.ssl.protocls" is present?
> > > 
> > > - Documentation is always appreciated ;)
> > > 
> > > Wdyt?
> > > 
> > > Am Mittwoch, den 02.12.2020, 14:41 +0100 schrieb Romain Manni-
> > Bucau:
> > > > Yes but issue that we don't want to enable them all too.
> > > > So to be concrete what about:
> > > > 
> > > > 1. Enable a smoother configuration (to avoid a custom class)
> > > > 2. Document the custom class case better (at least in a readme)
> > > > 3. Change a bit default to inherit JVM ones
> > > > 
> > > > Think we should make the 3 to consider this case treated (does
> > not
> > > > mean it must be in the same PR but more before next release).
> > > > Wdyt?
> > > > 
> > > > Romain Manni-Bucau
> > > > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> > > > 
> > > > 
> > > > Le mer. 2 déc. 2020 à 13:20, Zowalla, Richard <
> > > > richard.zowa...@hs-heilbronn.de> a écrit :
> > > > > Ah sorry - I misunderstood your comment.
> > > > > 
> > > > > A custom socket factory would indeed fix the problem, but it
> > is
> > > > > rather undocumented.
> > > > > 
> > > > > Nevertheless I think, that the default fallback shouldn't be
> > > > > hardcoded or at least support some more protocols...
> > > > > 
> > > > > Best and thanks for the idea,
> > > > > Richard
> > > > > 
> > > > > Am Mittwoch, den 02.12.2020, 12:16 + schrieb Zowalla,
> > > > > Richard:
> > > > > > Honestly I didn't. I discovered the hard-coded
> > > > > > String[]("TLSv1")
> > > > > > in
> > > > > > MailConnection#getConnectedTLSSocket(), which is (imho) a
> > bit
> > > > > > odd.
> > > > > > 
> > > > > > Imho, users should either be allowed to specify the enabled
> > > > > > (and
> > > > > > supported) protocols or to use the default ones provided by
> > the
> > > > > > jdk
> > > > > > classes :)
> > > > > > 
> > > > > > This is already done for
> > MailConnection#getConnectedSSLSocket
> > > > > > but
> > > > > > not
> > > > > > for the TLS handling.
> > > > > > 
> > > > > > 
> > > > > > Am Mittwoch, den 02.12.2020, 13:09 +0100 schrieb Romain
> > Man

Re: Re: Geronimo Java Mail 1.6 in TomEE 8.0.5 -> TLS 1.2 / 1.3 Support?

[Zowalla, Richard]

I updated the diff (cf. v2) to (hopefully) address the concerns raised
(if I understood them correctly).

If you point me to a location where I can add a README / documentation,
I would be happy to fill another JIRA with a related PR to document the
usage of the custom ssl socket factory.

Am Mittwoch, den 02.12.2020, 13:58 + schrieb Zowalla, Richard:
> Thanks for your thoughs - I think, I get the idea.
> 
> Maybe:
> 
> - Using "mail.smtp.ssl.protocls" to allow easier configuration (as
> proposed in the PR) for MailConnection#getConnectedTLSSocket() -
> would
> address 1.
> 
> - To address 3. and pre-claim: PR would enable all protocols; maybe
> address this concern by adding a default fallback pointing to TLSv1,
> TLSv1.1, TLSv1.2 and TLS v1.3 (if supported) if no custom
> configuration
> via "mail.smtp.ssl.protocls" is present?
> 
> - Documentation is always appreciated ;)
> 
> Wdyt?
> 
> Am Mittwoch, den 02.12.2020, 14:41 +0100 schrieb Romain Manni-Bucau:
> > Yes but issue that we don't want to enable them all too.
> > So to be concrete what about:
> > 
> > 1. Enable a smoother configuration (to avoid a custom class)
> > 2. Document the custom class case better (at least in a readme)
> > 3. Change a bit default to inherit JVM ones
> > 
> > Think we should make the 3 to consider this case treated (does not
> > mean it must be in the same PR but more before next release).
> > Wdyt?
> > 
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> > 
> > 
> > Le mer. 2 déc. 2020 à 13:20, Zowalla, Richard <
> > richard.zowa...@hs-heilbronn.de> a écrit :
> > > Ah sorry - I misunderstood your comment.
> > > 
> > > A custom socket factory would indeed fix the problem, but it is
> > > rather undocumented.
> > > 
> > > Nevertheless I think, that the default fallback shouldn't be
> > > hardcoded or at least support some more protocols...
> > > 
> > > Best and thanks for the idea,
> > > Richard
> > > 
> > > Am Mittwoch, den 02.12.2020, 12:16 + schrieb Zowalla,
> > > Richard:
> > > > Honestly I didn't. I discovered the hard-coded
> > > > String[]("TLSv1")
> > > > in
> > > > MailConnection#getConnectedTLSSocket(), which is (imho) a bit
> > > > odd.
> > > > 
> > > > Imho, users should either be allowed to specify the enabled
> > > > (and
> > > > supported) protocols or to use the default ones provided by the
> > > > jdk
> > > > classes :)
> > > > 
> > > > This is already done for MailConnection#getConnectedSSLSocket
> > > > but
> > > > not
> > > > for the TLS handling.
> > > > 
> > > > 
> > > > Am Mittwoch, den 02.12.2020, 13:09 +0100 schrieb Romain Manni-
> > > > Bucau:
> > > > > Hi Richard,
> > > > > 
> > > > > Did you try a custom socket factory? In such a case you fully
> > > > > control
> > > > > it.
> > > > > 
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> > > > > 
> > > > > 
> > > > > Le mer. 2 déc. 2020 à 13:01, Zowalla, Richard <
> > > > > richard.zowa...@hs-heilbronn.de
> > > > > > a écrit :
> > > > > > Hi,
> > > > > > 
> > > > > > I did some debugging and found, that TLSv1 is hard-coded in
> > > > > > MailConnection.java in v1.0.0 of Geronimo Java Mail.
> > > > > > 
> > > > > > I filled a JIRA [1], which contains a patch proposal.
> > > > > > 
> > > > > > Happy to receive some feedback.
> > > > > > 
> > > > > > Thanks in advance,
> > > > > > Richard
> > > > > > 
> > > > > > [1] 
> > > > > > https://issues.apache.org/jira/browse/GERONIMO-6792
> > > > > > 
> > > > > > 
> > > 
> > > -- 
> > > 
> > > Richard Zowalla, M.Sc.
> > > Research Associate, PhD Student | Medical Informatics
> > > 
> > > Hochschule Heilbronn – University of Applied Sciences
> > > Max-Planck-Str. 39 
> > > D-74081 Heilbronn 
> > > phone: +49 7131 504 6791
> > > mail: richard.zowa...@hs-heilbronn.de
> > > web: https://www.mi.hs-heilbronn.de/ 
-- 
Richard Zowalla, M.Sc.Research Associate, PhD Student | Medical
Informatics
Hochschule Heilbronn – University of Applied SciencesMax-Planck-Str.
39 D-74081 Heilbronn phone: +49 7131 504 6791mail: richard.zowalla@hs-
heilbronn.deweb: https://www.mi.hs-heilbronn.de/ 


smime.p7s
Description: S/MIME cryptographic signature

Re: Re: Geronimo Java Mail 1.6 in TomEE 8.0.5 -> TLS 1.2 / 1.3 Support?

[Zowalla, Richard]

Thanks for your thoughs - I think, I get the idea.

Maybe:

- Using "mail.smtp.ssl.protocls" to allow easier configuration (as
proposed in the PR) for MailConnection#getConnectedTLSSocket() - would
address 1.

- To address 3. and pre-claim: PR would enable all protocols; maybe
address this concern by adding a default fallback pointing to TLSv1,
TLSv1.1, TLSv1.2 and TLS v1.3 (if supported) if no custom configuration
via "mail.smtp.ssl.protocls" is present?

- Documentation is always appreciated ;)

Wdyt?

Am Mittwoch, den 02.12.2020, 14:41 +0100 schrieb Romain Manni-Bucau:
> Yes but issue that we don't want to enable them all too.
> So to be concrete what about:
> 
> 1. Enable a smoother configuration (to avoid a custom class)
> 2. Document the custom class case better (at least in a readme)
> 3. Change a bit default to inherit JVM ones
> 
> Think we should make the 3 to consider this case treated (does not
> mean it must be in the same PR but more before next release).
> Wdyt?
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> 
> 
> Le mer. 2 déc. 2020 à 13:20, Zowalla, Richard <
> richard.zowa...@hs-heilbronn.de> a écrit :
> > Ah sorry - I misunderstood your comment.
> > 
> > A custom socket factory would indeed fix the problem, but it is
> > rather undocumented.
> > 
> > Nevertheless I think, that the default fallback shouldn't be
> > hardcoded or at least support some more protocols...
> > 
> > Best and thanks for the idea,
> > Richard
> > 
> > Am Mittwoch, den 02.12.2020, 12:16 + schrieb Zowalla, Richard:
> > > Honestly I didn't. I discovered the hard-coded String[]("TLSv1")
> > > in
> > > MailConnection#getConnectedTLSSocket(), which is (imho) a bit
> > > odd.
> > > 
> > > Imho, users should either be allowed to specify the enabled (and
> > > supported) protocols or to use the default ones provided by the
> > > jdk
> > > classes :)
> > > 
> > > This is already done for MailConnection#getConnectedSSLSocket but
> > > not
> > > for the TLS handling.
> > > 
> > > 
> > > Am Mittwoch, den 02.12.2020, 13:09 +0100 schrieb Romain Manni-
> > > Bucau:
> > > > Hi Richard,
> > > > 
> > > > Did you try a custom socket factory? In such a case you fully
> > > > control
> > > > it.
> > > > 
> > > > Romain Manni-Bucau
> > > > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> > > > 
> > > > 
> > > > Le mer. 2 déc. 2020 à 13:01, Zowalla, Richard <
> > > > richard.zowa...@hs-heilbronn.de
> > > > > a écrit :
> > > > > Hi,
> > > > > 
> > > > > I did some debugging and found, that TLSv1 is hard-coded in
> > > > > MailConnection.java in v1.0.0 of Geronimo Java Mail.
> > > > > 
> > > > > I filled a JIRA [1], which contains a patch proposal.
> > > > > 
> > > > > Happy to receive some feedback.
> > > > > 
> > > > > Thanks in advance,
> > > > > Richard
> > > > > 
> > > > > [1] 
> > > > > https://issues.apache.org/jira/browse/GERONIMO-6792
> > > > > 
> > > > > 
> > 
> > -- 
> > 
> > Richard Zowalla, M.Sc.
> > Research Associate, PhD Student | Medical Informatics
> > 
> > Hochschule Heilbronn – University of Applied Sciences
> > Max-Planck-Str. 39 
> > D-74081 Heilbronn 
> > phone: +49 7131 504 6791
> > mail: richard.zowa...@hs-heilbronn.de
> > web: https://www.mi.hs-heilbronn.de/ 
-- 
Richard Zowalla, M.Sc.
Research Associate, PhD Student | Medical Informatics

Hochschule Heilbronn – University of Applied Sciences
Max-Planck-Str. 39 
D-74081 Heilbronn 
phone: +49 7131 504 6791
mail: richard.zowa...@hs-heilbronn.de
web: https://www.mi.hs-heilbronn.de/ 


smime.p7s
Description: S/MIME cryptographic signature

Re: Re: Geronimo Java Mail 1.6 in TomEE 8.0.5 -> TLS 1.2 / 1.3 Support?

[Zowalla, Richard]

Ah sorry - I misunderstood your comment.
A custom socket factory would indeed fix the problem, but it is rather
undocumented.
Nevertheless I think, that the default fallback shouldn't be hardcoded
or at least support some more protocols...
Best and thanks for the idea,Richard
Am Mittwoch, den 02.12.2020, 12:16 + schrieb Zowalla, Richard:
> Honestly I didn't. I discovered the hard-coded String[]("TLSv1")
> inMailConnection#getConnectedTLSSocket(), which is (imho) a bit odd.
> Imho, users should either be allowed to specify the enabled
> (andsupported) protocols or to use the default ones provided by the
> jdkclasses :)
> This is already done for MailConnection#getConnectedSSLSocket but
> notfor the TLS handling.
> 
> Am Mittwoch, den 02.12.2020, 13:09 +0100 schrieb Romain Manni-Bucau:
> > Hi Richard,
> > Did you try a custom socket factory? In such a case you fully
> > controlit.
> > Romain Manni-Bucau@rmannibucau |  Blog | Old Blog | Github |
> > LinkedIn | Book
> > 
> > Le mer. 2 déc. 2020 à 13:01, Zowalla, Richard <
> > richard.zowa...@hs-heilbronn.de> a écrit :
> > > Hi,
> > > I did some debugging and found, that TLSv1 is hard-coded
> > > inMailConnection.java in v1.0.0 of Geronimo Java Mail.
> > > I filled a JIRA [1], which contains a patch proposal.
> > > Happy to receive some feedback.
> > > Thanks in advance,Richard
> > > [1] https://issues.apache.org/jira/browse/GERONIMO-6792
> > > 
-- 
Richard Zowalla, M.Sc.Research Associate, PhD Student | Medical Informatics
Hochschule Heilbronn – University of Applied SciencesMax-Planck-Str. 39 D-74081 
Heilbronn phone: +49 7131 504 6791mail: richard.zowalla@hs-heilbronn.deweb: 
https://www.mi.hs-heilbronn.de/ 


smime.p7s
Description: S/MIME cryptographic signature

Re: Re: Geronimo Java Mail 1.6 in TomEE 8.0.5 -> TLS 1.2 / 1.3 Support?

[Zowalla, Richard]

Honestly I didn't. I discovered the hard-coded String[]("TLSv1") in
MailConnection#getConnectedTLSSocket(), which is (imho) a bit odd.

Imho, users should either be allowed to specify the enabled (and
supported) protocols or to use the default ones provided by the jdk
classes :)

This is already done for MailConnection#getConnectedSSLSocket but not
for the TLS handling.


Am Mittwoch, den 02.12.2020, 13:09 +0100 schrieb Romain Manni-Bucau:
> Hi Richard,
> 
> Did you try a custom socket factory? In such a case you fully control
> it.
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> 
> 
> Le mer. 2 déc. 2020 à 13:01, Zowalla, Richard <
> richard.zowa...@hs-heilbronn.de> a écrit :
> > Hi,
> > 
> > I did some debugging and found, that TLSv1 is hard-coded in
> > MailConnection.java in v1.0.0 of Geronimo Java Mail.
> > 
> > I filled a JIRA [1], which contains a patch proposal.
> > 
> > Happy to receive some feedback.
> > 
> > Thanks in advance,
> > Richard
> > 
> > [1] https://issues.apache.org/jira/browse/GERONIMO-6792
> > 


smime.p7s
Description: S/MIME cryptographic signature

Re: Re: Geronimo Java Mail 1.6 in TomEE 8.0.5 -> TLS 1.2 / 1.3 Support?

[Zowalla, Richard]

Hi,

I did some debugging and found, that TLSv1 is hard-coded in
MailConnection.java in v1.0.0 of Geronimo Java Mail.

I filled a JIRA [1], which contains a patch proposal.

Happy to receive some feedback.

Thanks in advance,
Richard

[1] https://issues.apache.org/jira/browse/GERONIMO-6792



smime.p7s
Description: S/MIME cryptographic signature