Win a copy of Spring Boot in Practice this week in the Spring forum!

Tapio Niemela

Ranch Hand
+ Follow
since Jan 06, 2006
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
4
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Tapio Niemela

hello,

I've been struggling configuring spring security for too many hours. What I'm trying to accomplish is that authentication process could be toggled on/off at runtime. My idea was that I could extend FilterSecurityInterceptor and override it's doFilter-method to check whether authentication is "enabled"..(yes I know security shouldn't probably be toggled on/off at runtime..)

However, I'm in trouble figuring out how security namespace and "traditional" bean configurations mix..Or do they mix at all?

I've tried to provide bean with id 'filterSecurityInterceptor'. As far as I'm concerned this is the way it should be, right? I mean that those security namespace auto-created beans should/could be overriden in spring.xml with specific id, sort of callback...Or are I'm lost here? Anyhow if that's not the case, I can give custom-filter in position 'FilterSecurityInterceptor' to http-element. But that doesn't seem to work either...filterSecurityInterceptor requires something called 'securityMetadataSource' which in turns seems to be related to sec:http-element / intercept-url -mapping..However, If I don't use security namespace config, do I really need to make all bean definitions by hand? That doesn't sound right either..



big thanks in advance for all replies
9 years ago
Hi, I've recently been pondering about the YAGNI principle. Basically it warns about over-engineering and premature over-optimization. I agree somewhat to that principle, but at my current project I'm working with legacy code which could have benefited of *some premature* design. Now code-base is filled with classes with static methods. Methods which iterate through similar-like structures and apply some invocation (like calculate something) to applicable objects in the structure. Sounds bit like visitor or functional programming (or it's counterpart implemented in java), especially predicates, or what do you think?

The problem is that the code-base should have been implemented differently in the first place (maybe using visitor or FP). Now when I have to make changes I have two options:
- apply same methodology as used previously. E.g. everything is static something();. (Need I say more..)
- try to apply *some* design within the change. The problem is that it should have already been made; it's like post-over-engineering the implementation, also concern is it "necessary" or "(re)-usable". Code changes where I have taken this road have probably become more complicated.

Especially I think that acyclic visitor "hooks" could have been put into important classes. Some say it will complicate the code. Maybe, but then it would exist, thus enabling adding functionality afterwards

So, in my opinion, YAGNI doesn't always apply. Sometimes it might be better to design the code before jumping to the coding activity. But this should take place in the first phases of the project, not in late phases. Big question remains : WHEN are you actually gonna need it, or not?

Paul Clapham wrote:I think this is a well-known problem in the OO Design area, although I had a quick google and I couldn't find a writeup about it. I do remember reading about it some time ago, though.

Basically it's an insoluble problem. It requires objects of every subclass of MyUpper to be able to compare themselves to objects of any other subclass. It's easy to figure out how to compare an object of one subclass to another object of the same subclass, but not how to compare it to an object of some other (unknown) subclass.

And the solutions you come up with to do that generally fail to follow the rule that a.compareTo(b) and b.compareTo(a) must have opposite signs.

As I recall, the article that I read basically threw up its hands and said not to do this.



Thanks Paul and Matthew for clear answers. So the way to go is Comparator of course for Objects which can't be ordered "naturally". Also "It requires objects of every subclass of MyUpper to be able to compare themselves to objects of any other subclass" is a nice point of view I didn't figure out in the firstplace :)
9 years ago
Hello fellow ranchers, I've been puzzled how to implement Comparable regarding inheritance..

Lets say we have List defined as superclass and we wish to sort it using Collections.sort(List<T>), but meanwhile List contains both instances of superclasses and subclasses. Let's also assume that SubClass adds some field, which is relevant to the comparison process, but (of course) only when comparing subclasses. Therefore we need to make instanceof tests and cast objects to subclass when applicable..let's also say that Subclasses come "first"..example java code follows..



Now this *seems* to give correct results, but from my point of view it's ugly code. How comparing lists which may contain both subtypes and supertypes should be implemented? (Without Comparator). Surely my implementation can't be satisfactory? Or should we provide *some* hook / callback method which would then be called on compareTo-method? How should one solve this in a satisfactory way?
9 years ago
Hi, I was reading Java Generics and collections by Maurice Naftalin & Philip Wadler. I have been puzzled (and tried to search help, but couldn't any match) with this highlighted sentence on page 102 regarding reflection, arrays and generics..

Unchecked casts are required because the methods in the Java reflection library cannot return sufficiently accurate types, for various reasons. The method getComponentType is in the class Class<T>, and java provides no way to restrict the receiver type to be class<T[]> in the signature of the method (though the call raises an exception if the receiver is not a class token for an array type)

and here's relevant java code..



Probably something quite easy, but it's expressed quite tricky. Any help?
9 years ago

Mike Simmons wrote:True, when you write throws "Throwable" or "throws Exception", those are the two special cases where the exception may be checked or unchecked, and so the compiler does not complain if you don't have any code that overtly throws an exception. However for all other checked exceptions (such as, for example, IOException, the one that was relevant here) my statement above is correct. This problem is not about import statements.

You're welcome.



Sir, I still disagree. The question is all about wrong namespaces; either one should import java.io.IOException or declare the method to throw java.io.IOException

On my previous message by "Throwable" I was referring to Throwable or any it's subclass..

This is perfectly legal:


Code compiles fine, body in the test method never throws exception, still I can declare it to throw *any* Throwable (checked and unchecked) I wish. Note on the testTest that it must catch IOException possible thrown by test-method

Mike Simmons wrote:

Tapio Niemela wrote:
Correct answer is D, This is because IOException wasn't imported. So the given code wasn't complete.


No, that's not the reason. Even if we assume IOException was imported in code not shown (and that's what I would assume, but we can't tell in your example), the code with "throws IOException" will not compile. That's because (a) IOException is a checked exception, and (b) in the code shown, which is the complete class Frisbee including method main(), there is no code that could possibly throw an IOException. Even if it were imported. If you declare a method throws a checked exception, and the compiler can see that there's nothing that could throw that checked exception, that's a compile error.



Actually not. You can declare method to throw any Throwable if overrididing is not considered. What you can't do is try/catch checked exception which is not "never thrown" (some method in the try-block must be declared as "throws <thatException>")

Anyways, thanks Matthew and Bert. I didn't notice that line-number thingie, but now I know when code is considered complete and when not
I really hope that the format of questions in the real exam is better than in The book (SCJP 6 by Sierra and Bates).
Now it's not possible to answer correctly to all questions. Correct answers depens on whether given code was complete or whether *some* code had to precede the given one.

For example on page 409 question 15


Correct answer is D, This is because IOException wasn't imported. So the given code wasn't complete. (Also the line number isn't correct?) BUT simultaneously following question #9 exist on page 777


The "correct" answer HERE is G. (although I can't compile such code) So the code is not considered complete, opposite to previous question. How should one know when code is complete and when not? From my point of view there are two possible combinations of correct answers here:
- All code IS complete
----> #15 answer is correct
----> #9 answer is not correct (won't compile)
- All code IS NOT complete
----> #15 answer is not correct (B would be correct)
----> # Answer is correct

It's not possible to know when given code on question is considered complete, or then it should be explicitly mentioned, which is not the case here
I'm reading "Java generics and collections" by Maurice Naftalin & Philip Wadler. I'm having trouble understanding the following sentence on page 101. "The restrictions on class tokens lead to useful property. Wherever a type of the form Class<T> appears, the type T should be a reifiable type"

However I'm allowed to do following:

where <? extends String>isn't reifiable type (as parameterized types with bound are not reifiable) , so either the quoted sentence isn't true or I have misunderstood something

Also I'm not allowed to do following

where <String> actually is reifiable type. So, please help me to understand the sentence..

10 years ago

Paul Clapham wrote:It's not that complicated. Each time the user clicks on that "Submit" button the browser creates an HTTP request. That's all there is to it.



Thanks Paul, so I assume two threads are also created; one for each request
10 years ago
Hi,

after some googling I could not find satisfactory answer..

What happens when user double submits (double clicks "Submit" or similar) form to servlet? Will/could it create 2 httprequests and 2 threads? Or one httprequest and 2 threads? Or something else?

Please help
10 years ago
Hi Tommy and thanks for reply

Yes, I know about the lower bounds, but I was distracted by the different compile errors. Handling wildcards with java.util.List (like trying to add to wildcard-List) generates (at least on my 1.6.0 compiler) different compile error than with the Box-example. With List I get "cannot find symbol" and with "Box"-example I get "cannot be applied" to -error. This really puzzled me. The thing is that if I use Collection.add I get also "cannot be applied"-error, not "cannot find symbol", so I should get "Cannot find symbol" error with modified OtherBox as I do..



So the problem was the distraction from different compile error messages created by my compiler
Hello Jeff and thanks for the answer

Yes it seems which error is given is compiler-specific. I was once again studying generics and ran into this "issue"..What I also found was that on my compiler (1.6.0) I got "cannot find symbol, if SubClass has ALSO defined generics method", which is the case for List.add(E e) and Collection.add(E e)

This is what I found out (if anyone is interested with details )

10 years ago
Hello fellow javaranchers.

I'm puzzled what is the difference between "cannot be applied to" and "cannot find symbol" (method)

I understand simple case where "cannot find symbol" occurs due to misspelling of the method name or similar (like calling System.print instead of System.out.print), but http://www.javafixer.org/cannot-find-symbol.php suggests that following situations could lead to "cannot find symbol" compilation error:

-An extra parameter was added or was left out.
-The parameters are used in the wrong order.

However those situations will end in "cannot be applied to" -errors instead of "cannot find symbol", for example consider following code:



Also following situation is even stranger:


Any idea why adding object of wrong type to Collection gives different compile error vs. adding object of wrong type to Set (or List)? Are Set and List given *some* special care by the compiler?
10 years ago
Hello, I'm puzzled how the "adding" to wildcard java.util.Collection is blocked by the compiler; compiler even suggests that "add"-method doesn't exist. Also how is this different to "putting" element to custom wildcard object.

For example,
Following attempt will produce following compiler error "cannot find symbol / symbol : method add(java.lang.String) / location: interface java.util.List<capture#913 of ? extends java.lang.String>"


while following code (modified example from http://www.ibm.com/developerworks/java/library/j-jtp04298/)

produces compiling error that "put(capture#189 of ? extends T) in OtherBox<capture#189 of ? extends T> cannot be applied to (java.lang.String) box.put("blaa");"

It *seems* that compiler adds some check for Collection add and addAll methods, but surely that can't be true?