Gordon Brown

Hi there,

Have you added some debugging statements to see if your controller method is being called?

My guess is that it's a problem with the view name you're supplying. I believe the default ViewResolver is a InternalResourceViewResolver. I think you therefore want to be returning a view name of "hello", rather than "hello.jsp".

Let's say we have a couple of classes; Brand and Supplier, where Supplier is a property of Brand.

We have the following interfaces à la the Controller-Service-Repository pattern: BrandService, BrandRepository, SupplierService, SupplierRepository.

Within an a JDBC implementation of BrandRepository, we implement this method: public Brand find(int brandId). Within this method we retrieve brand.supplier_id within the SQL query, and we wish- somehow- to use it to set the Supplier property on the Brand object. The most obvious way to do this is to inject a SupplierRepository into the BrandRepository implementation, and just call public Supplier find(int supplierId) on that.

Do you have strong objections to this? If so, could you outline a preferable alternative?

I'm less interested in the specifics of this example than I am the general principle of whether it's ever okay for a Repository to depend on another.

Many thanks.

Just in case anyone comes across this issue in future: I needed to add @WebAppConfiguration...and the name of the class to be passed to the @SpringApplicationConfiguration was that of the Spring Boot Application e.g.
@SpringApplicationConfiguration(classes = AcumenApplication.class)

Hi,

This is a pretty basic issue, but after Googling and trying various things I have had no success.

I suppose this is an integration test given that it'll also be testing my tiles configuration, though my initial intent was to find the simplest way to unit test the controller. I have actually written the simple controller I'm trying to test, and my tiles configuration works fine.

I have a Spring Boot app with three Java configuration classes (listed in the code below).As you can see from my failed attempt, I'm simply trying to test that a specific view name is returned, at this stage. What I haven't been able to do is configure the test so that it uses my existing ViewResolver. I've seen examples that create a new ViewResolver in the setup method, but... DRY.

@RunWith(SpringJUnit4ClassRunner.class) @SpringApplicationConfiguration(classes = {ViewsConfig.class, SecurityConfig.class, DatabaseConfig.class}) public class IndexControllerTest { private MockMvc mockMvc; @Before public void setUp() { mockMvc = standaloneSetup(new IndexController()).build(); } @Test public void defaultRequestReturnsIndex() throws Exception { mockMvc.perform(get("/")) .andExpect(status().is2xxSuccessful()) .andExpect(view().name("index")); } }

The above code results in the following Exception:
java.lang.NullPointerException at org.apache.tiles.request.ApplicationAccess.register(ApplicationAccess.java:50)

How should I be going about this?

Thanks.

I noticed that I listed the pre/post-conditions etc. for pop(), but suggested that they were those for push(E obj). Apologies for any confusion.

IStack? I've never been a fan of that sort of naming convention though.

Thanks! First cow

I have a few suggestions, but the most important point is the one Stephan has already made: you do not want to iterate the stack.

Firstly, unless you have been explicitly told to name it as such, "Program1" is a terrible name for a class. There's actually no need to have separate class just to kick off the program, in my opinion: Stick the main method in your ReversePolish class. (A better name might be RPNCalculator.)

How about defining an interface for a Stack, and having another class, LinkedStack, that implements that interface? That way you can code against an interface rather than an implementation. (As Campbell suggested, you should make these generic types: e.g. Stack<E>. If you haven't covered generics yet, though, don't worry about using type parameters.) For bonus points, list the pre- and post-conditions, return types (and, if you're comfortable with them, exceptions) for each of the interface methods. Doing this will help you better understand Stack's methods, and why they should have the return types they do. e.g. for push(E obj), you could have:

Preconditions:

stack is not empty

postconditions:

stack size is decreased by 1

top item of stack is returned

the rest of the stack is unchanged

returns the element on the top of the stack
throws StackException if stack is empty

LinkedStack then implements Stack (or, if using generics: LinkedStack<E> implements Stack<E>), and should have a private member variable of type Node (or Node<E>), representing the top of the stack (thus you could call it top). If you wanted to type-parameterise your Node class, instead of having
private String data;
You would have
private E data;
This generic version is far more reusable, as it is type-parameterised: it can objects of any type, not just Strings.

Rather than just using a String array of operators, why not use an enum? Here's a partial sample of what it might look like:
public enum Operator { EQUALS('=', 0) { int apply(int operand1, int operand2) { throw new NotImplementedException(); } }, PLUS('+', 1) { int apply(int operand1, int operand2) { return operand1 + operand2; } }, //... more code abstract int apply(int operand1, int operand2); public void handleString(String str) { //... more code handleOperator(op); //... more code } public void handleOperator(Operator op) { // ... more code } //... more code }
That way, in your RPNCalculator class, you can say:int result = op.apply(operand1, operand2);

Your ReversePolish class (which, again, I'd rename to RPNCalculator for better descriptiveness) is overly simple. Bear in mind that you want to handle ints and operators very differently: With ints you simply want to pop them on to the stack, with operators, you want to pop the next two items off the stack and apply the operator to them. So, how about a couple of methods: public void handleInt(int i) and public void handleOperator(Operator op)?

I don't want to give you too much help on this, but hopefully I've given you some ideas to move you forward. I think you're still a wee bit away from a decent solution, though, so feel free to ask further questions.

Puspender Tanwar wrote:
the reason for this could be that -> an effectively final variable couldn't be a compile time constant, as we can change that later in our code(unlike final variable), so compiler is not pretty much sure about the effectively final variable that whether it is constant or not and treats it like the normal variable

In order for a variable to be effectively final, the compiler needs to know that the variable is isn't reassigned a value after it's initialised.

I suspect that this is something that could be implemented (with respect to while loops) but has not yet been. If anyone knows for sure I'd be really interested to hear.

Indeed. Same issue in 8 though (have checked): it warns about unreachable code when the variable is final, but not when it's effectively final.

hi Vilda,

Good insights.

It's interesting that in your second example, variable is effectively final. In the case of closures, the compiler allows the use of effectively final variables. You'd think, therefore that it'd be able, by the same logic, to determine that line 3 is unreachable.

You're right... it operates like any reference variable. Not sure how I managed to confuse myself on that one. Long day.

Is it fair too see this as a language design flaw? Q: To what does m[1] refer, the container of the contents? A: Well, that depends on the context in which you use it. Ripe source of confusion I reckon.

A few issues straight off:

You've misspelled "scanner" in your import statement.
You're not using any of the variables you declare.
You're using a variable you don't declare (tall).
You're trying to break out of a loop using a label, but you haven't created the label. You're not actually in a loop, though, so there's no need to break here.

Agreed: NotePad++ is an excellent choice. It's free, you get syntax highlighting (for numerous languages), and you avoid the learning overheads of an IDE when you're just starting out.