On 11-09-21 11:41 PM, EricF wrote:
In article<4e7a8166$0$281$14726298@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?=<arne@vajhoej.dk> wrote:
On 9/21/2011 12:38 AM, EricF wrote:
In article<4e77f29e$0$311$14726298@news.sunsite.dk>,
[ SNIP ]
I do think Spring is nice but it doesn't try to provide the standards (JEE).
When it first came out, it was a lot easier to use than much of the JEE
stack.
These days JEE has been simplified.
But to me it is difficult to see why go with a non-standard
solution exists when a standard solution exists that does the
same.
Arne, I certainly agree with your comment in general. Personally I like Java
and many parts of JEE, but I'm not sure how "standard" Oracle solutions are.
Pretty standard now. :-) They own Glassfish, for example.
Seriously, Oracle's been as standard as anyone else in the J2EE/Java EE
world, in my experience, for quite some time.
There are several JEE servers so there are a few options - Websphere,
Weblogic, JBoss, Glassfish, ... I must be missing 1 or 2. But have you ever
ported an EJB from 1 to the other? I have. Standard solutions just aren't that
standard anymore.
But with Java EE the progression has absolutely been from less
standardization to more standardization. This has gone hand in hand with
the rationalization/simplification of specifications.
It's not been that long since EJBs meant ejb-jar.xml, and the server's
own ejb-jar.xml companion configuration file, and doing explicit JNDI
lookup. All of that - especially the JNDI - is what was exposing
non-standardization. Not only are less things non-standard now, but the
beauty of API specifications movement in the Java EE space has been that
a lot of the non-standard bits have been hidden. Dependency injection
has a lot to do with that.
The LAMP stack, JEE, Spring are all different ways to do similar things.
Options are nice.
LAMP absolutely. Or write an HTTP server using node.js. Or operate in
the ASP.NET MVC ecosystem. Options are essential.
But Spring was only an option - a credible, useful option - for a brief
window back when, during some period of J2EE 1.2-1.4. Recall that Spring
emerged during J2EE 1.3, and really only matured during J2EE 1.4. *All*
Spring 2.x releases happened after Java EE 5 was released. Basically
Java EE 5 closed the lid on Spring, and Java EE 6 has hammered in the nails.
My argument now is, if you're using Spring, most of the time there is a
standard non-Spring way to do the same thing.
is used moderatly then it is not so bad.
turns pretty ugly.