at com.demo.warehouse.controller.RetrievalController.searchRetrievals(RetrievalController.java:59) ~[classes/:na]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_251]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_251]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_251]
at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_251]
Actually, what Dave was asking for was a full stack trace, not the full application listing. Too much code is as bad as too little. Worse, really, because too little and we'll ask for more, but too much and it's better just to skip over it. Well, actually, a full stack trace is usually pretty long, but we're used to being able to skip quickly to the important parts.
However, your lastest exception is on line 77 of something that's posted with only about 40-something lines in it. If you could let us know which line in RetrievalController is supposed to be line 77, we can say more.
I'm going to be a "small government" candidate. I'll be the government. Just me. No one else.
In your Retrieval class, there is no attribute called productbarcode. Instead, there is an attribute called product.
So, if your repository, you may want to define a method called findByProductAndDate() instead of findByProductbarcodeAndDate.
So, your original problem was with the retrievalService, which was not autowired, and so was still null when you tried to use it. It looks like you're now having the same problem with retrievalRepository. Which probably has the same solution...