This week's book giveaway is in the Spring forum.
We're giving away four copies of Spring in Action (5th edition) and have Craig Walls on-line!
See this thread for details.
Win a copy of Spring in Action (5th edition) this week in the Spring forum!

Dave Tolls

Rancher
+ Follow
since Sep 04, 2013
Cows and Likes
Cows
Total received
40
In last 30 days
0
Total given
0
Likes
Total received
625
Received in last 30 days
6
Total given
20
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Dave Tolls

But this method tests for nothing.
All it does is call the service method.
That's why I don't see the point of testing this at all.

But, if you want it to throw an exception then use thenThrow(some exception) rather than thenReturn.
11 hours ago
In your test cod you have this:


That says that you have mocked out the bookCrudOperationsService to return the newBook object on a createBook call.

Looking at the error you want to get back it looks like you get an error that is thrown by that service (that is, it is thrown when your service attempts to save the Book).

So, if you want this to test the service then either don't mock out the service (which implies this is an integration test), or simply have the service throw the exception rather than return the book.

Is this supposed to be a unit test (ie testing the controller and only the controller), or an integration test (testing hwo the parts talk to each other)?
13 hours ago
There's not (in my view) much point testing that conrtoller.
It just calls the service (which is correct).
Test the service.

As for your issue, your test mocks out the service and then has the service pas a valid book back from the create call.
If you want it to throw a validation exception then that call should throw the exception.
16 hours ago
Well, that's a long thread there that probably covers most things we could cover here.
Depends whether you've taken all the suggestions on-board (though, as one of the replies says, don't worry too much about performance or memory unless you're fairly sure you'll hit an issue).
19 hours ago
Set your @ManyToMany association as FetchType.LAZY.
That way the Funds will only be fetched when they are accessed.
Not off the top of my head, but there must be something on github or similar.
Do a search on Java ResultSet to JSON, or something like that.
1 day ago
I'd be surprised if there wasn't already some package that can do this for you.
1 day ago
Your class is marked to Inject the TaskManagerServiceBean, however that doesn't happen when you do new BackgroundTask.
That reference is null, so I would guess each thread is throwing a NullPointerException.

I'm not too sure on the setup you are using here, so there may be a way around this, but that is your current issue.
You have a single BackgroundTask object, which you change the TaskId several times on.
All these changes seem to be occurring before the first task executes, so all the "tasks" (actually the same task executed several times) run with the same (last) value of taskId.

If you have several tasks, then you need several task objects.
How are you compling this code?
Where are the source folders/classes in relation to each other?
2 days ago
It depends on your client.
My preference in a situation like this is that you have an app out there doing something they shouldn't be doing (changing this user_type for this user), so they should end up getting an error.

Using a trigger will hide this issue.
Using a constraint will highlight it to the app making the problematic UPDATE query.

Now, if the client is adamant that they cannot (or will not) make changes to their app, then your only option is a trigger to "fix" the issue.  But I would consider that a bit of sticky tape over the problem, rather than an actual fix.

Obviously, bear in mind I do not know your requirements, or service deals or anything like that.
I'm simply taking this from the position that something is setting user_id 1003's user_type to something other than 200, and it shouldn't be.  It's quite possible (even likely) that there are other things in play here that I do not know about.
Also, once you know which app (or apps) that are causing th eproblems, then hopefully they'll fix thngs, and then you can disable the CHECK.
No, you have to add the OR part as well, otherwise only the user_id 1003, with a type of 200, will ever be allowed to be added or updated.
Depending on the database, add a CHECK constraint to the table. Something like:


That way the problematic app is the one that gets the hit and can then be fixed.
You only need to flush the new line if you are dealing with input from the console that can have multiple tokens.
For example, asking for an age and then asking for a full name, using nextInt and then nextLine.

If (as in the example above) you use nextInt and then nextDouble then there is no need to use nextLine after successfully reading in a value.
This is because the new line character left in the buffer is thrown away by the nextDouble call before reading the value.
3 days ago