Security with Spring
baeldung.com
baeldung.com
Java has an ecosystem of enterprise consultants that sell castles in the sky and need to invent complex concepts and technologies to sell themselves and their services. Gullible enterprise developers eat it up and mimmick them. Ignorant CTOs buy their stuff. I'm pissed off about it because Java is basically cool technology but the culture is infected with these bloodsuckers who give it a bad name and do nothing for advancing the state of the language and ecosystem.
Why do you compare Spring with J2EE when in fact JEE took a lot of the good stuff from Spring?
The main point of Spring is to help develop consistent applications with enterprise requirements (integration, security, batch jobs, mvc, ...) and it does that incredibly well. Especially integration in a nightmare of systems at a large corporation.
Yet, after using Spring for a while, i really wondered how come there couldn't be any simpler solutions to that problem: any compiled language with a good support for interfaces should be able to reach that objective.
I think the bloat came from wanting to decouple compilation time from component assembling time, using xml files. I never understood the reason for that choice (who in its right mind would change a component without recompiling for type checking and retesting the code anyway ?).
I suppose it probably was the easiest way to accomplish that in Java at some point, and i'm really happy to see that latest Spring versions enable you to use Java configuration classes instead. But as enterprise means long-time support and never ending backward compatibility, i really doubt the bloat culture will fade away any time soon.
I find that for many of the configuration use cases that Spring is supposed to solve I am better off doing things programmatically (heresy in the Java world). Yes, this can be done and still have testable, decoupled configuration. (As for changing configuration on the fly, nobody does that. It is a leftover from the "Deployer" role defined by Sun's J2EE specification.)
If they could have dumped that, the world would be a better place. Note: it's a good idea in theory, just not in practice.
"Spring; Making simple things trivial and complex things nil possible."
That's a big claim, but can you back it up? Let's see...
Its main selling point is that it is not J2EE (shallow praise)
No, no it's not. It's main claim to fame is that it was one of the first IoC containers and did a lot if things right that earlier versions of J2EE didn't (Container Managed Transactions, anyone?).
In fact, Spring has influenced quite a lot of the direction of J2EE. Just look at the @Inject annotation, etc.
yet it retains a lot of the awfulness of J2EE, such as XML just for the sake of it (so now you need heavy tool support just to make sure that classes, methods and fields are referred correctly in the XML files).
Except you don't. You can write all configuration as code if you wish. It makes extensive use of annotations. You have no idea what you are talking about.
Incidentally, what sort of "heavy tool support" are you referring to? The XML syntax isn't that heavy, and things like JetBrains or Eclipse handles it fine. And I've never had to directly manipulate the XML programmatically, nor have I ever had to extend or even read the XSD files that go along with it. Nor have I had to do anything insane like use XQuery or XSLT.
On top of that it introduces layers of craziness that J2EE could only begin to dream of, such as "aspect oriented" configuration and dynamic proxies that enrich and inject and mutate your objects at runtime such that debugging and tracing becomes completely impossible.
You're doing it wrong then. AOP is not only a perfectly reasonable and sensible way of doing things, but by default you don't need to rewrite bytecode with CGLIB as it uses a proxy mechanism. Should you wish to use CGLIB, the option is there though.
Even core Spring concepts like "Inversion of Control" are questionable value propositions that even Martin Fowler has distanced himself from.
Are you serious? Inversion of Control, when done properly, is extremely powerful. It's a fantastic way of decoupling components in a flexible and powerful way.
But please, do let us in on why it is a "questionable value proposition", I'm genuinely curious as to some actual technical reasons behind this claim.
Java has an ecosystem of enterprise consultants that sell castles in the sky and need to invent complex concepts and technologies to sell themselves and their services.
Any sufficiently advanced framework or technology has this issue. Why just pick on Spring? It's hardly the fault of the framework though.
Gullible enterprise developers eat it up and mimmick them. Ignorant CTOs buy their stuff.
OK...
I'm pissed off about it because Java is basically cool technology but the culture is infected with these bloodsuckers who give it a bad name and do nothing for advancing the state of the language and ecosystem.
I'm interested in what you like about Java, and how Spring has blocked it's advancement; that's one hell of a big claim, but you haven't done anything to support your assertions other than make some broad and sweeping statements that aren't backed by any real reasoning.
Whenever you call an aspected object in Spring it likely goes through an object of this type first. On line 177 we find this
// massage return value if necessary
if (retVal != null && retVal == target) {
// Special case: it returned "this".
// Note that we can't help if the target sets
// a reference to itself in another returned object.
retVal = proxy;
}
It is this kind of leakiness that contributes to a sense of horror when dealing with Spring. The abstractions provided by Spring are so pervasive and invisible that this makes me very anxious. I really feel that when dealing with the large enterprise class applications, that Spring is aiming for, something direct and _very_ explicit and _visible_ would be far far better.
In this case though, wouldn't a different style of AOP be more useful? Perhaps something that doesn't use a proxy but rewrites the bytecode, like CGLIB? Not sure, not experienced enough in this I'm afraid.
Is it hard to work around the corner case? Interested...
My opinion is that aspects are a mistake in general. I think that all of the situations that I have seen aspects used they have saved roughly 5 lines of boiler plate in exchange for creating an invisible layer of very fragile code which ties you hard to your Spring container.
But I really like explicit code, so you would expect me not to like aspects. I do strongly think that aspects are really solving a 'not very hard' problem while exacerbating the biggest problem I have, which is not understanding the codebase.
The thing I truly hate about Spring are the stacks. Good lord, I cannot find my code in that skyscraper of abstract proxied garbage. If you want a good technical reason to dislike Spring it's good to note that deep stacks place a larger burden on your garbage collector, in this instance Spring is truly a degenerate case.
W.r.t. gclib I don't want my code byte weaved. Ever. I want it to do what is says on the tin. Always. I am very willing to write and read more code to do this. If too much code is becoming a problem don't turn to Spring - try removing some of your AbstractFactoryFactories first :) (tongue sort of in cheek)
Since I work with Spring every day it brings up some strong emotions.
If you like DI but not AOP, then something like Guice or plain Java and some self-discipline would probably work better for you.
If you like DI and AOP, then you can let Spring get you as close to proper AOP as Java allows without weaving, or you can use the same syntax to do compile-time weaving to get a non-leaky abstraction
All these are just choices to make; it seems like you're more fighting against the fact that you don't like how the 'industry' is making these 'enterprise standard' choices for you.
On a technical level it's more like criticising Rails for using meta-programming everywhere, or C because it's so low-level (i.e. that's what they were designed for! If that's not what you need, don't use it!)
I haven't used it, but my impression is that I'd be much happier with something like Guice that is lighter weight and actually does compile-time typechecking.
If you are looking at "big" frameworks in other language eco-systems, I can't help but think Spring should be considered quality stuff.
You have to keep in mind Spring is a Java framework, and therefore should reflect the stable, conservative nature of the language itself.
Spring stack traces can get long'ish, but they are very easy to understand. Take a look at a Clojure stack trace and you'll realize how simple Spring's are.
This framework really redefined my notion of bloated, although to be fair, i really don't know if the runtime and API part of the framework gave me that feeling, or if it's not mainly due to the extremely painful development environment (aka spring sts : one JVM for the IDE, one JVM for the bean execution, and one virtualization layer on top of the web server thanks to VMWare vFabric...).
In the end, it took me more than 5 minutes to boot STS and get the server run my code, on my fairly recent 4G of RAM MBP.
Your bad experience was with a Spring-branded Eclipse; the open-source IDE that's so slow and bloated Google preferred switching to a proprietary competitor (IntelliJ) for their latest version of the Android IDE.
I would not judge Spring the Framework by Spring the IDE (which is a bunch of plugins on top of Eclipse). The Spring integration in IntelliJ is great.
Excellent resource for anyone using Spring.