Re: [jakartaee-platform-dev] lassNotFoundException: com.sun.mail.util.Pr

["Kevin Sutter" <sutter@xxxxxxxxxx>]

Patrick,
>  Wintin
the tested Logic the method 
javax.mail.internet.InternetAddresses.create(String) is being called, 
wich leads to an error with the JakarataEE API and DOES work with the 
JavaEE API artifact.

Going back to
my note...

Are you saying
that you replaced
https://search.maven.org/artifact/javax.mail/javax.mail-api/1.6.2/jar
with
https://search.maven.org/artifact/jakarta.mail/jakarta.mail-api/1.6.4/jar
and that changed
caused the failure?  (Of course, using the maven coordinates instead
of the actual jar files...)

Looking at these
two jars, the missing PropUtil class doesn't exist in the 1.6.2 java ee
api jar file either.  Or, do you mean that the javaee version throws
the "not implemented" exception?  Or, something else?  Just
trying to clarify whether we have an issue still to clean up or not.  Thanks!

---------------------------------------------------
Kevin Sutter 
STSM, MicroProfile and Jakarta EE architect
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn: https://www.linkedin.com/in/kevinwsutter



From:
       Patrick
Reinhart <patrick@xxxxxxxxx>
To:
       Bill
Shannon <bill.shannon@xxxxxxxxxx>
Cc:
       Kevin
Sutter <sutter@xxxxxxxxxx>, jakartaee-platform developer discussions
<jakartaee-platform-dev@xxxxxxxxxxx>
Date:
       10/19/2019
08:56 AM
Subject:
       [EXTERNAL]
Re: [jakartaee-platform-dev] lassNotFoundException: com.sun.mail.util.PropUtil
when using javax.mail.internet.InternetAddress

---

Hi Bill,

In that specific failing test the goal ist to check if our logic is 
returning the correct InternetAddress oobjects based on entries within
a 
database by using a public static API method of InternetAddress. Also I
would then implement those parts of the implementation within the test
project though.

I would expect of a API to not throw any ClassNotFound exception when 
creating any of the provided classes. I accept to get any exceptions of
type "no implementation found" of course...


In my case the test szenario we pass an String containing multiple Email
addresses delemited by a custom delemitor. And we want to test if those
addresses have been correctly parsed....

Wintin the tested Logic the method 
javax.mail.internet.InternetAddresses.create(String) is being called, 
wich leads to an error with the JakarataEE API and DOES work with the 
JavaEE API artifact.

Anyway, My pont is the I not expect that API does refer classes of the
API implementer.


-Patrick






On 2019-10-18 08:54, Bill Shannon wrote:
> If your unit test depends on all of Jakarta EE being available for
> testing,
> then you're going to need to find a way to do the unit testing by
> running
> a complete app server as a separate program; no set of jar files is
> likely
> to do that for you.
> 
> If your unit test depends on only some of the APIs from Jakarta EE,
> then
> depending on which APIs you might be able to find a standalone 
> implementation
> of those APIs that you can run inside the unit testing framework.
> 
> In particular, if you are trying to do unit testing that depends on
> Jakarta
> Mail, you can use the com.sun.mail:jakarta.mail jar file for testing,
> which
> contains a complete implementation of Jakarta Mail.
> 
> 
> Patrick Reinhart wrote on 10/17/19 11:37 PM:
>> The problem happens in test phase of our build after the compilation.
>> But comparing the both libraries (old and new one) those where
>> different content wise. It is just that the current behavior has
>> changed now...
>> 
>> What would be the correct unit test dependency in that case?
>> 
>> Best regards Patrick
>> 
>>> Am 18.10.2019 um 05:03 schrieb Bill Shannon 
>>> <bill.shannon@xxxxxxxxxx>:
>>> 
>>