-
Notifications
You must be signed in to change notification settings - Fork 100
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding setters for system properties #515
Conversation
6342a0a
to
f197255
Compare
Looks like a reasonable fix for #513 👍 |
0938c78
to
06b7e50
Compare
@chrisrueger I read it and I will need to try it. I am busy with other tasks right now but I will come back to this. I am converting this PR to draft for the time being. |
I have added changes related to session properties. There are no setters but properties are protected, so it can be modified in other ways (not only via session properties). |
There are 2 tests failing:
|
In the mail-tck repo |
There is a signature test failing. It complains with the added fields and the constructor. Do we modify that test to not fail?. There is other test failing that I need to investigate: api/javasoft/sqe/tests/jakarta/mail/Message/testlist.html#setFileNameTest_encodeFalse_decodeTrue: setFileName() API(s) with mail.mime.encodefilename=false and mail.mime.decodefilename=true
|
I investigated this test: The issue is that the system properties are set after MimeMessage is instanced, so that properties are ignored because MimeMessage makes use of them before. |
Signed-off-by: Jorge Bescos Gascon <jorge.bescos.gascon@oracle.com> Move methods from jakarta to com.sun.mail Signed-off-by: Jorge Bescos Gascon <jorge.bescos.gascon@oracle.com> Use session properties instead of setters Signed-off-by: Jorge Bescos Gascon <jorge.bescos.gascon@oracle.com>
I have created a jakartaee/mail-tck#24 for the issue of: api/javasoft/sqe/tests/jakarta/mail/Message/testlist.html#setFileNameTest_encodeFalse_decodeTrue Now it is failing only the SignatureTest, but I need advise about how to proceed. |
I'm closing this PR and opening a new one: #578 |
Relates to #513
Adding those parameters in constructor bring some problems:
So I thought about keeping constructors and creating a builder. Then setting parameters is easy, but it has the disadvantage that scales badly with heritage. These classes are somehow thought to be extended.
And finally, the thing that fits better in this scenario is adding some setters. It has the disadvantage that it is not thread safe, but anyway there are other fields that are not thread safe already. The user must know that same instances of this class are not thought to be modified by different threads.