Rob Spoor

serviceUnavailable is a mock, and its class therefore is not ServiceUnAvailable.class. You either need to provide an instance of serviceUnavailable itself, or change the predicate to also accept subtypes:
private static final Predicate<? super Throwable> ClassToControl = throwable -> Exceptions.stream().anyMatch(c -> c.isInstance(throwable));

Tim Holloway wrote:I don't think that there are any org.baeldung artefacts in the world-wide Maven Repository.

https://mvnrepository.com/artifact/org.baeldung.pmd/custom-pmd

I noticed an "ICM" above the single version. If I click on the version I see this:

Note: this artifact is located at ICM repository (http://maven.icm.edu.pl/artifactory/repo/)

So to access it, you need to add a <repositories> section, see https://maven.apache.org/guides/mini/guide-multiple-repositories.html for a bit more information.
(I currently get a 400 in the browser, so I don't know for sure if it actually works.)

Update: I tried a bit with mvn dependency:get, but after using Maven 3.6.3 (because 3.8.x blocks the http URL, and the site doesn't work properly with https) I get a 400 again. I guess that the Maven repository is broken.

My guess is that they've used the JDK's extension mechanism to load BouncyCastle. You can verify by checking the ext folder of the previous Java installation.

Instead of installing BC this way again, add it to your class path instead. That's more portable.

Jiri Nejedly wrote:

com.sun.xml.ws.client.ClientTransportException: HTTP transport error: javax.net.ssl.SSLHandshakeException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

I my experience, that always means that one piece of Java code is trying to communicate with another server through HTTPS, and the certificate isn't considered to be valid. Java does not use the OS' certificate storage, but instead uses its own. If your company uses its own root certificate for internal servers (which is often the case), that's probably integrated into your OS certificate storage. For Java you need to explicitly import it:
keytool -cacerts -import -alias <fill-this-in> -file <fill-this-in>The default password is "changeme".

Thanks for sharing your solution, and welcome to the Ranch!

I already replied to this on Stack Overflow.
Next time, please Be Forthright When Cross Posting To Other Sites.

I was referring to this:

obaid abbassi wrote:Now I want to get dId in patient table and pId in Doctor table vice versa

Because yes, you are absolutely right. I'd do it the way you described it.

I think you misread me. I didn't say you shouldn't have a bidirectional relationship in JPA (it's indeed very common to have one), just that you shouldn't have one in the database.

Tim Holloway wrote:It is possible to add 2 related records at the same time in the same transaction, although if you're using auto-generated keys, that means that you have to first get the doctor record saved and populated with its primary key. The patient Entity does not have the doctor ID in it, because this is an ORM and it references a Doctor object which, again, we just generated an ID for, so at that point, the patient record can be saved. The doctor Entity contains a Patient Collection property managing the reverse relationship, so you also have to add the Patient there and re-save the updated Doctor.

I am aware of that, but it requires one of the ID columns to be nullable, and it needs to be set afterwards like you said. If that updating isn't done (for instance if someone updates the database manually), the doctor will miss its relation to the patient in the database.
If you don't use auto-generated keys, you either need to have the nullable column, or don't use referential integrity constraints on the foreign key. Otherwise you still won't be able to set the column with the value, because at the time of insert the record still doesn't exist.

A one-to-one between patient and doctor means that every patient has his/her own dedicated doctor that does not have any other patients. I doubt that's correct. I therefore agree with Himai that a many-to-one would be better.

That said, if you ever have a one-to-one, it's very uncommon to have the bidirectional relationship at a database level too. The logical one-to-one is mostly actually a many-to-one in the database, with a unique constraint that the many side is limited to just one. Otherwise the two records get really tightly coupled, which has several complications. For instance, on at least one side the foreign key cannot be NULL, because a record has to be created first before its primary key can be used for a foreign key - and you simply cannot create two records at the same time.

Piet Souris wrote:Your code runs fine on java 17.

That's because effectively final, as already usable for lambdas, is now also enough for anonymous inner classes.

stefan nesic wrote:while (number > 12) ;///this is what i was trying now, does freeze the program up, doesn't work.

That while isn't part of the do-while above it - it's a separate while with an empty body. It's equivalent to this:
while (number > 12) {    // do nothing }So either this loop ends directly if number <= 12, or it loops forever because number > 12 will always be true.

You need to split your problem in two:
1) Take a template and JSON, and turn it into HTML.

2) Send an email with the HTML as body.


For the first you can check out template frameworks like Velocity, FreeMarker or Thymeleaf. They don't work with JSON, but they do work with a context or data-model. You can relatively easily turn the JSON into a Map, which can be turned into a context / data-model (for FreeMarker, the Map is the data-model).

For the second I can recommend Apache Commons Email. It makes it easier to work with JavaMail (and is safer - it can prevent CRLF injection in subjects).

Can you verify that you're using https to access your server? Because that <secure>true</secure> part means that the cookie doesn't work for http.

If your server is behind a proxy (apache, nginx, whatever) and that proxy communicates to your server over http (not https), you'll never get the cookie to work. Either use https between the proxy and the server, or something like AJP that keeps the https flag intact.

Any version other than 2.7.6 and 3.0.0 (or higher) should be ignored. Everything before version 2.7 is already end-of-life unless you have paid support.

You can upgrade to Spring Boot 3.0.0, but that's going to be a pretty big step from 2.3.x. The two biggest changes:

It requires Java 17 or higher (yes, really!)

It switches from Jakarta EE 8 (javax package prefixes) to Jakarta EE 9 (jakarta package prefixes)

If I were you, I'd upgrade to Spring Boot 2.7.6 now (and then keep updating to latest patch versions). A lot will still work; I have created a Spring Boot starter that I haven't had to change since Spring Boot 2.2.x. There may be some issues though, but these can mostly be solved by reading the release nodes:

2.4

2.5

2.6

2.7

Once you're using Spring Boot 2.7, you can start migrating to migrate to Spring Boot 3.x; version 2.7 isn't going to be end-of-life until next year November. Fortunately, there's a migration guide: https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Migration-Guide.

A famous quote:

Edsger W. Dijkstra wrote:Program testing can be used to show the presence of bugs, but never to show their absence!

The only way to handle this issue is to keep your tests, and every time a bug is found:

Write a new test first, that should test the desired behaviour with the actual input. This test should fail, because the code failed.

Fix your code to make this test succeed. Don't change anything else, especially not tests.

Verify that your existing and new tests all succeed.

This is a procedure followed by several large projects, including OpenJDK. I've also had to write such tests for some pull requests for Apache Commons IO; without them, pull requests are rejected.

Changing existing tests should only be done if you're 100% sure that the test is indeed incorrect.