"Powerful", expensive application servers were bought a few years ago. The reasoning was: reliability + support / maintenance contracts from a single vendor is the only viable solution for mission critical projects. For some reasons the most inefficient servers (from the development perspective) were the most popular.
The "popular" J2EE servers were not frequently released and upgraded - so they are significantly lagging behind the "state of the art" technology. Furthermore the internal corporate policies don't allow to upgrade the platform too often - because of stability.
Developers just wanted to use the latest and greatest and begun to overshadow the existing infrastructure with additional frameworks like Spring
In these cases Spring took more and more responsibility - at the end only about 5% of the bought functionality was used. 95% came from Spring and alternatives (like e.g. Hibernate)
Spring is deployed with the application - upgrades are easy, because the server functionality is actually not used. Operations don't noticed that - so there was no problem so far :-)
Because the server license was expensive and also maintenance costs had to be paid - there is no more budget left for commercial support for Spring. So only 5 % of the overall functionality is supported. The whole application is actually unsupported - so money for nothing.
Because the mix of Spring + overloaded Servers works - sometimes it became strategic.
Running unsupported software on overloaded and slow application servers became a "best practice". 95% of the unused services consume productivity, CPU-cycles, memory and increase the complexity.
I'm sometimes asked how I was able to introduce something new into "enterprise" environments. Its simple. I made the craziness transparent and explained what it actually means :-).
Because Java EE 5/6 is very similar to Spring - the future of Enterprise Java is clear - either full-stack Java EE or full-stack Spring. The mix is not very efficient and also not reasonable - especially not in the economic downturn.
Comments:
In my comment to You last post I said it was desperate. Now it's sad :> Enough said.
Artur
Posted by
Artur Karazniewicz
on March 23, 2010 at 09:39 PM CET
#
You're right Adam. Some developers used to mix Java EE and Spring just for the fun. No need with Java EE 5/6.
Posted by
Arist
on March 23, 2010 at 11:34 PM CET
#
>Furthermore the internal corporate policies don't allow to upgrade the platform too often - because of stability.
[...]
>Spring is deployed with the application - upgrades are easy, because the server functionality is actually not used. Operations don't noticed that - so there was no problem so far :-)
This is the exact issue that I've been pointing out to people for years. Thanks for writing this down in such no nonsense and clear words :)
The very idea that your organization forbids something (upgrading, because of stability reasons) and that another company offers a product that it touts as having the advantage that it allows you to deceive the ones who pay you wages, is just morally wrong.
Unlike some of my post may seem to express, I do think Spring itself (especially full-stack Spring) is a good technology. I just *highly* dislike the fact that Springsource people says it offers you easier upgrades, which we all know has no technologic grounds but is solely based on sneaking upgrades past operations.
Increasingly I also dislike that people still hold on to the notion that Spring supposedly makes Java EE better. Once this was true, but it wasn't true anymore when Java EE 5 came out and it certainly isn't true anymore with Java EE 6. I also think that Spring is valuable on its own merits, but has little value sitting on top of Java EE.
Posted by
Robert Tuinman
on March 24, 2010 at 12:25 AM CET
#
Hi Adam,
I definitely agree with this post. In the J2EE 1.4 era, Spring may had been the most powerful J2EE technology. However, with the recent movement in the J2EE5 and J2EE6, I would think twice in using Spring in a new project. The case is different for projects that were designed and maintained over the years using the Spring stack.
Full J2EE stack offerings is the way to go I guess. So its either adopt the full J2EE stack in Spring or J2EE5/J2EE6.
-Jerwin
Posted by
Jerwin Louise Uy
on March 24, 2010 at 06:26 AM CET
#
Is it Spring a J2EE spec implementation ? I think not ... So why mixing Spring with J2EE ? I heard of Spring running on Tomcat, so no J2EE app server was involved. In fact, I think you can run Spring on a mere servlet container. If you are paying a lot for a commercial J2EE app server, at least you can do is USE it.
I think that the last version of Java Enterprise is so much better than the previous versions, so the main Spring argument against it - that it is too complex - starts to fade. If one likes Spring, let him use it, but let's not mix apples with oranges...
Posted by
Bogdan Marian
on March 24, 2010 at 09:30 AM CET
#
People seem to forget that Spring does not require a J2EE app server or even a servlet container. You can run Spring in a standalone app.
That is actually how we use it: we have standalone apps that use Spring and use a embedded Jetty server. It's used in mission critical environments, performs very well, it's cheap and we have no maintenance issues.
The problem with Java EE is not so much the current level of the specs (5 and 6 are good) but more the culture of having bloated products and architectures that dominated the java world in the last 10 years.
Posted by
Ruben Badaro
on March 24, 2010 at 04:13 PM CET
#
Regarding upgrades...upgrading the server is one thing, upgrading the server and insuring none of the applications hosted on the server break due to the upgrade is something else.
If you have good regression testing then this minimizes things but there is still the issue that changes may cause new previously unseen issues to surface with no test cases in place (i.e. maybe new upgrade feature causes more memory usage resulting in app memory issues, maybe a new security or persistence change results in having to change configurations to have access to relevant resources, etc).
All the needed regression testing is where the management frowns on frequent updates. Upgrade can cost time and money. Regression testing can cost time and money. Changes may result in updates of apps which cost time and money.
This does not take in to account interoperability compatibility with other external services that likewise may require similar concerns. It's all about dependencies...
Posted by
Eric B
on March 24, 2010 at 05:00 PM CET
#
This is off topic, but I have a question about the JEE5/6 spec. When using a remote ejb you have to be very specific to the server you are going to talk to:
Properties props = new Properties();
props.setProperty("java.naming.factory.initial", "com.sun.enterprise.naming.SerialInitContextFactory");
props.setProperty("java.naming.factory.url.pkgs", "com.sun.enterprise.naming");
props.setProperty("java.naming.factory.state", "com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl");
Why can't the spec abstract that stuff away and leave us to only be concerned with the address, the port, and the remote interface? Has this ever been considered?
See my url for a post about this.
Posted by
Bobby
on March 24, 2010 at 05:00 PM CET
#
Eric B, just run one application on one AS and you'll never have that problem you talk about.
Upgrading is always a risk, but to stay competitive a business needs to take risks now and then. This is unrelated of running on Spring, Java EE, Grails or whatever.
Posted by
arjan
on March 24, 2010 at 07:26 PM CET
#
I agree with that. I don't know who ever thought you should run different apps on 1 AS, but just don't do this.
Don't consider JBoss to be -the- server, but consider it an app that runs on the actual server (whether that is a physical or virtual one).
Posted by
Dexter Hughes
on March 24, 2010 at 09:16 PM CET
#
I was just thinking that having to upgrade the application server to get Java EE 6 APIs is kind of like having to upgrade Oracle DB in order to use the next version of Hibernate. I can agree with the people who think programmer APIs should be separate from app server infrastructure...
However, I think GlassFish V3's modular design will make it possible to upgrade individual APIs (such as JSF and JPA) without upgrading the entire application server. You still won't need to deploy all the .jar's and dependencies inside of your .war file. JBoss is probably the same.
Posted by
Ryan
on March 24, 2010 at 11:11 PM CET
#
@Bogdan
"the main Spring argument against it - that it is too complex" - I don't think that it is still the main argument. Spring vs. EJB 2.1 times are long over. My main argument is that Spring gives you much more practical solutions/classes/patterns than pure JavaEE (once again - Spring Security vs. "declarative JavaEE security" which is too much dependent on what app server offers).
"If you are paying a lot for a commercial J2EE app server, at least you can do is USE it". The point is that the people paying for commercial JEE server are usually not the same persons developing and maintaining the application!!! The former ones care about "business relations with vendor X" and the latter care about "runing the app in the context of changing requirements". This is really important distinction! If someone'll buy you a XIX century velocipede will you do anything to force yourself to do mountain rides? I don't think so...
@Robert
"Spring [...] is solely based on sneaking upgrades past operations". I agree in 100% (putting aside Spring's technological benefits)! That's technological person's only way to say "hey - I really don't need everything WebSphere offers, I know you had to sign this IBM/Oracle contract, but I know this application and I know it will run much better on Jetty - even embedded". I've worked in many projects, where before any technological provisions some non-technical persons chose WebSphere "just because".
"it certainly isn't true anymore with Java EE 6" - why? Now there is only Glassfish (without clustering option) and TMAX JEUS (which I haven't heard about until now). And once again - JavaEE's "declarative" security is app server dependent. It cannot allow for e.g. authentication using two LDAP servers.
on previous entry on this blog you wrote "We run 1 application on 1 AS instance. I'm not really sure whether it's a misconception or a failure on Java's part, but I don't really think either the JVM itself or the AS is a replacement for what is the task of an OS: separating and isolating applications.". I think this is the "magicall" aspect of JavaEE which let grew WebSphere/WebLogic/OAS servers. The vendors told us that the application will contain only business logic and app server "will do the rest".
I understand you're treating app server like a lower part of your multi-module application. I don't disagree! But the next step is to say - "in my application, I only need servlets+jsps - let's use embedded Jetty instead!". And that's what @Ruben says. I also have such application - it's full-blown JavaEE application with server-application put inside out - I chose that I'll control the "app server" and not vice versa. And that's not making me "spring fan boy" :)
regards
Grzegorz Grzybek
Posted by
Grzegorz Grzybek
on March 25, 2010 at 10:24 AM CET
#
@Ryan
>I think GlassFish V3's modular design will make it possible to upgrade individual APIs (such as JSF and JPA) without upgrading the entire application server
I does, but this is also possible with JBoss AS and probably others. Several of the Java EE APIs (but not all) are plugable. It's already perfectly possible to run JSF 2.0 and JPA 2.0 on JBoss AS 5.1.
That said, again, don't think of the AS as something inherently difficult or time consuming. I may counter your remark by saying that if you want to upgrade Spring, you have to redeploy your *entire* war. Taken out of context, this may sound terrible. The *entire* war??? Just for upgrading Spring??? Jeezzzz!
Of course we both know that redeploying a war is not problematic again, but dramatic language may make it sound like its dramatic. I think this is similar for installing a new version of JBoss AS. You make it sound like it's a terribly complicated thing, but it's not. It's just not...
JBoss AS is not the 'server infrastructure' that you think it is. Only developers run JBoss AS directly as a server. In production, this doesn't happen. The infrastructure is the battery of Apache front-end servers, the firewall rules, the switches, the Linux installation, etc. JBoss AS is just the end-point application in all of this, NOT the root server in any way!
I think this simple little observation is at the heart of tons of misunderstandings.
Posted by
Robert Tuinman
on March 25, 2010 at 01:10 PM CET
#
@Robert
"JBoss AS is just the end-point application in all of this, NOT the root server in any way!" - politically, in case if WebSphere or OAS it is totally untrue!! In such cases app server is the most expensive (for the client) and most lucrative (for software provider) part of the installation :) So at the heart of misunderstandings lies politics...
Posted by
Grzegorz Grzybek
on March 25, 2010 at 01:28 PM CET
#
@Grzegorz
>That's technological person's only way to say "hey - I really don't need everything WebSphere offers,
I'm not 100% sure, since you just painted a completely different scenario. To recap, we thus seem to have two scenarios:
1. Management forbids frequent updates to the app foundation, which Operations enforces.
2. Management has a political interest in technology A, but the developers want to develop for technology B.
I have already discussed scenario 1 to great lengths. It's a form of deception that I'm not really sure I want to be a part of.
Scenario 2 is basically you not liking the tools or platform. How is this different from a company that has chosen to develop in Spring, but you like to work in RoR? Or a company that works with Wicket, while you want to develop for .NET?
If you don't like the tools you have to work with, don't work at that place. I was repeatedly offered a job at one of this world's biggest webplatforms, but I kept turning it down since their product is build with PHP, which I absolutely don't like. There is no way I would have accepted the job, then 'secretly' installed quercus, let their existing product run on top of that and then step by step started to use Java code instead of PHP. That really would be a bit debatable, wouldn't it? Yet you're more or less proposing the same thing with Java and Spring.
If you don't like Websphere, don't work at a company that uses it. We're using JBoss AS, and I like it a lot. I really do need/want to use the majority of the functionality JBoss AS offers. A few bits and pieces I don't use, but it doesn't bother me at all that these are available.
It's just like the JDK. In some project I might not use the HashSet. But what does it matter that the HashSet is there anyway? The same is true for Spring too. Their API is also huge. I don't think there is any single app, apart from Spring's own unit tests, that use each and every class and method Spring offers.
>The vendors told us that the application will contain only business logic and app server "will do the rest".
I think your beef is more with IBM and not at all with Java EE. Incidentally, neither JBoss or Apache ever told me this. Better yet, JBoss advised me to run a single app on a single JBoss AS instance.
>I only need servlets+jsps - let's use embedded Jetty instead!"
By all means, I'm not holding you back ;)
But do you have any idea how tiny small the fraction of non-trivial Java apps is that *only* uses Servlets + JSPs and *nothing* really *nothing* else? In years of consulting I've never ever seen any shop doing that for an application of a non-trivial size. There is always some amount of additional libs added.
With Java EE 6, I can for instance opt to start with the web-profile, which is a lighter weight version of regular Java EE 6. Servlets + JSPs will be available there and what I don't need I simply don't use. I can however seamlessly migrate my code to start adopting additional functionality and when my app has really grown I can even switch relatively easily from the web-profile to the full profile.
Posted by
Robert Tuinman
on March 25, 2010 at 01:43 PM CET
#
@Robert
Thanks for this pleasant discussion :)
ad1) Generally I've had situations where some app server was bought before the contract - as part of some vendor cooperation. And then it was not upgraded to newer version because current version "just works". We've migrated from WAS 5 (J2EE 1.3!) to WAS 6 (J2EE 1.4!), but no one sees any reasons to upgrade further (even if that would happen, we'll be at JEE 5 :). So I don't discuss this case any futher
ad2) Sometimes client has this interest. And no one from my company forbids me to use Spring. So I use it in these circumstances (WAS6 = J2EE 1.4). Of course someone might ask if I'd use JavaEE 6 if I had the choice. I'm sure I'd be happy to use JPA2 or Servlets3. But the most controversial (only for me!) part is CDI (former WebBeans). It's great technology and most distinct equivalent of what SpringDI is. In it's current state it's well designed and sometimes better (newer) than SpringDI. But the choice:
1) CDI+rest of JavaEE
2) SpringDI + rest of Spring (Security, Integration) + (yes!) these part of JavaEE 6 I can use now on Tomcat or Jetty (e.g. JPA2, JSF2)
is clear - I chose option 2).
So I'm not against company's interest. I'm an "architect" and I choose technology for company's benefit. I really like JBoss, but sometimes I can choose Tomcat/Jetty without loosing JPA, JSF, JMS, JAXB, etc.
> I think your beef is more with IBM and not at all with Java EE. Incidentally, neither JBoss or Apache ever told me this. Better yet, JBoss advised me to run a single app on a single JBoss AS instance.
You're right. I really like to start with JBoss "minimal" config and add to it everything I need from "default" and "all" ones - it show the real power of JBoss.
> But do you have any idea how tiny small the fraction of non-trivial Java apps is that *only* uses Servlets + JSPs and *nothing* really *nothing* else?
by servlets+JSPs I mean "app server transforms HTTP requests to servlet-API objects and handles my RequestDispatcher.forward()s to JSPs, the rest (e.g. JPA) is under control of my application = placed in WEB-INF/lib.". This of course is similar to very confortable situation where you can customize JBoss' "minimal" configuration, select Hibernate version or replace Mojarra with newer version. And also if you have only one app per server you can really treat JBoss as part of your solution (it's very elegant and confortable!). But once again - it's not a case with WebSphere. I'm not sure, but I think when you replace e.g. XML parser in WebSphere you'll not only loose confidence in its operation, you'll probably won't receive any support from IBM when they'll discover what you did to their server :)
So I emulate customizing JBoss configuration with customizing my WAR/WEB-INF/lib folder's content.
And JavaEE profiles? It's only partial solution - probably helping in marketing "big" servers which will now have option of "buy web profile, save 10%!"
regards
Grzegorz Grzybek
Posted by
Grzegorz Grzybek
on March 25, 2010 at 02:22 PM CET
#
So true. I'm still hanging around with WebSphere 5.1 in some projects because of "stability" of the infrastructure...
Posted by
Johannes
on March 25, 2010 at 08:26 PM CET
#
Johannes, if you're still on Websphere 5.1, then I take it you're also still on Java 1.4?
Posted by
Dexter Hughes
on March 26, 2010 at 12:24 PM CET
#
Grzegorz, the Java EE profiles are for small open source parties. The idea is that the full profile is too big to implement. No small open source party will ever want to implement EJB2 or Corba.
Now such guys can still officially enter the Java EE market by only concentrating on a smaller profile.
Posted by
Dexter Hughes
on March 26, 2010 at 12:31 PM CET
#
Spring is too complcated, and is not Model drived(MDD), so not completely OO, we need a lightweight framework, include AOP + DI + DDD +NoSQL + Async.
Posted by
bqlr
on March 27, 2010 at 04:28 AM CET
#
I think the main problem here is if you control the web server or not.
Not that you want to do something "illegal" or "forbidden".
I work for an editor. We do make and deploy for client web applications.
Some have and want WebSphere with full support. Some want Tomcat with support. Other Tomcat without support.
Some have Websphere bundled with a 1.4 JVM, some a 1.5 JVM...
Maybe one day we will have a client requesting to have BEA Weblogic or JBoss.
If all dependencies are in the war then we are only dependant of the JVM version (we could justify 1.5 but not more...) and servlet version (like 2.4 or 2.5).
Then all become easy, we can deploy our app everywhere.
If we end up couple with a specific J2EE version, or even worse a specific curstomised AS, then we end up with much more more deployement problems.
It's like the open source PHP world. It higly depend of what is available on web hosting services. Application that do no work on the entended enviroment will not be used.
Posted by
Nicolas Bousquet
on March 27, 2010 at 03:21 PM CET
#
I think citing Spring security and integration as a reason not to use Java EE 6 is really very weak. I've used Spring security on multiple projects and it is significantly more complex to configure and use than application server security or the pluggable security that Seam has offered for quite a while now. If we think CDI is cleaner than Spring DI, certainly the same can be said of Spring Security and Seam Security. Furthermore, Seam security will now become a portable extension that can be used with any CDI runtime.
As to Spring integration, it is an edge case solution that is applicable maybe for 3-5% of projects. For such projects, it is just as easy to use more Java EE friendly ESB products (both commercial and open source).
Cheers,
Reza
Posted by
Reza Rahman
on March 27, 2010 at 06:40 PM CET
#
@Nicolas
That's the point! When all parts of JavaEE that I need are placed in my WEB-INF/lib, the "write once, deploy anywhere" works, otherwise - it usually doesn't. Now I can test on Tomcat (which is fast) and deploy on WebSphere (which is eternal part of client's environment). If I rely on JPA from WebSphere (which by the way I can't, because WebSphere 6 is only J2EE 1.4 compliant) I'd have problem migrating from Tomcat, through JBoss to WebSphere.
@Reza
> Spring Security [...] it is significantly more complex to configure and use than application server security or the pluggable security that Seam has offered for quite a while now
application server security: sorry, but I just can't configure Websphere to use two LDAPs - first for authenticating users by X.509 and it's serialNumber field, second - for auxilliary authentication and role provider (+ mapping to application roles). I don't know whether Resin can do it (Tomcat/JBoss, without writing custom Realm can't).
Seam: I've written few comments ago (http://www.adam-bien.com/roller/abien/entry/future_of_enterprise_java_is#comment-1269416519172) that I think Seam (portfolio) is in a sense comparable to Spring (portfolio). I just don't know Seam. Spring Security is not an easy library (just as whole application security), but it's very powerful and customizable. I've succesfully used it in many complex scenarios.
> If we think CDI is cleaner than Spring DI, certainly the same can be said of Spring Security and Seam Security. Furthermore, Seam security will now become a portable extension that can be used with any CDI runtime.
I would be careful with such extrapolation. The point is you have to use something which is not part of JSRs of JavaEE 6. And remember - I can't use CDI + extensions on WebSphere 6 (and by the way on WebSphere 7 also).
And about these CDI extensions. I think it's great concept. But after using them, your app has to be aware (which is not a bad thing!) of them. I might be wrong, but they're not like JavaEE specs - you can't replace one extension with other which "conforms to the same spec" - I mean when you use "Seam 3 Security CDI extension", you're tied to Seam 3 (again - which is not a bad thing) - but this is not different from using Spring Security. The difference is I can use Spring Security on embedded Jetty or on WebSphere 6.
> As to Spring integration, it is an edge case solution that is applicable maybe for 3-5% of projects. For such projects, it is just as easy to use more Java EE friendly ESB products (both commercial and open source).
With all the respect to you Reza - what "Java EE friendly ESB products" you're thinking of? JBI is not part of JavaEE and is more "WSDL or contract driven". Spring Integration can be "anything" driven and I can use it in both simple and very complex scenarios. And (what should be great advantage for JavaEE advocates) it is great implementation of "Enterprise Integration Patterns" book (the other is Apache Camel) and is based on perfect java.util.concurrent classes.
And what do you mean by "JavaEE friendly"? Spring Integration can have Servlet endpoints, has JMS, JDBC, JMX gateways. What could be more JavaEE friendly?
And I also know Mule - That's what I've used before I've decided to rewrite the entire application using Spring Integration - for the benefit of all developers.
regards
Grzegorz Grzybek
Posted by
Grzegorz Grzybek
on March 27, 2010 at 09:32 PM CET
#
Post a Comment:
Number of posts: 2419
Number of comments: 6163
Yesterday's hits: 18790
Today's hits: 11163
Post reads / hour: 773
Top posts:
In my comment to You last post I said it was desperate. Now it's sad :> Enough said.
Artur
Posted by Artur Karazniewicz on March 23, 2010 at 09:39 PM CET #
Spring is too complex for 90% of apps...
Posted by Dyego Souza do Carmo on March 23, 2010 at 11:22 PM CET #
You're right Adam. Some developers used to mix Java EE and Spring just for the fun. No need with Java EE 5/6.
Posted by Arist on March 23, 2010 at 11:34 PM CET #
>Furthermore the internal corporate policies don't allow to upgrade the platform too often - because of stability.
[...]
>Spring is deployed with the application - upgrades are easy, because the server functionality is actually not used. Operations don't noticed that - so there was no problem so far :-)
This is the exact issue that I've been pointing out to people for years. Thanks for writing this down in such no nonsense and clear words :)
The very idea that your organization forbids something (upgrading, because of stability reasons) and that another company offers a product that it touts as having the advantage that it allows you to deceive the ones who pay you wages, is just morally wrong.
Unlike some of my post may seem to express, I do think Spring itself (especially full-stack Spring) is a good technology. I just *highly* dislike the fact that Springsource people says it offers you easier upgrades, which we all know has no technologic grounds but is solely based on sneaking upgrades past operations.
Increasingly I also dislike that people still hold on to the notion that Spring supposedly makes Java EE better. Once this was true, but it wasn't true anymore when Java EE 5 came out and it certainly isn't true anymore with Java EE 6. I also think that Spring is valuable on its own merits, but has little value sitting on top of Java EE.
Posted by Robert Tuinman on March 24, 2010 at 12:25 AM CET #
Hi Adam,
I definitely agree with this post. In the J2EE 1.4 era, Spring may had been the most powerful J2EE technology. However, with the recent movement in the J2EE5 and J2EE6, I would think twice in using Spring in a new project. The case is different for projects that were designed and maintained over the years using the Spring stack.
Full J2EE stack offerings is the way to go I guess. So its either adopt the full J2EE stack in Spring or J2EE5/J2EE6.
-Jerwin
Posted by Jerwin Louise Uy on March 24, 2010 at 06:26 AM CET #
Is it Spring a J2EE spec implementation ? I think not ... So why mixing Spring with J2EE ? I heard of Spring running on Tomcat, so no J2EE app server was involved. In fact, I think you can run Spring on a mere servlet container. If you are paying a lot for a commercial J2EE app server, at least you can do is USE it.
I think that the last version of Java Enterprise is so much better than the previous versions, so the main Spring argument against it - that it is too complex - starts to fade. If one likes Spring, let him use it, but let's not mix apples with oranges...
Posted by Bogdan Marian on March 24, 2010 at 09:30 AM CET #
People seem to forget that Spring does not require a J2EE app server or even a servlet container. You can run Spring in a standalone app.
That is actually how we use it: we have standalone apps that use Spring and use a embedded Jetty server. It's used in mission critical environments, performs very well, it's cheap and we have no maintenance issues.
The problem with Java EE is not so much the current level of the specs (5 and 6 are good) but more the culture of having bloated products and architectures that dominated the java world in the last 10 years.
Posted by Ruben Badaro on March 24, 2010 at 04:13 PM CET #
Regarding upgrades...upgrading the server is one thing, upgrading the server and insuring none of the applications hosted on the server break due to the upgrade is something else.
If you have good regression testing then this minimizes things but there is still the issue that changes may cause new previously unseen issues to surface with no test cases in place (i.e. maybe new upgrade feature causes more memory usage resulting in app memory issues, maybe a new security or persistence change results in having to change configurations to have access to relevant resources, etc).
All the needed regression testing is where the management frowns on frequent updates. Upgrade can cost time and money. Regression testing can cost time and money. Changes may result in updates of apps which cost time and money.
This does not take in to account interoperability compatibility with other external services that likewise may require similar concerns. It's all about dependencies...
Posted by Eric B on March 24, 2010 at 05:00 PM CET #
This is off topic, but I have a question about the JEE5/6 spec. When using a remote ejb you have to be very specific to the server you are going to talk to:
Properties props = new Properties();
props.setProperty("java.naming.factory.initial", "com.sun.enterprise.naming.SerialInitContextFactory");
props.setProperty("java.naming.factory.url.pkgs", "com.sun.enterprise.naming");
props.setProperty("java.naming.factory.state", "com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl");
Why can't the spec abstract that stuff away and leave us to only be concerned with the address, the port, and the remote interface? Has this ever been considered?
See my url for a post about this.
Posted by Bobby on March 24, 2010 at 05:00 PM CET #
Eric B, just run one application on one AS and you'll never have that problem you talk about.
Upgrading is always a risk, but to stay competitive a business needs to take risks now and then. This is unrelated of running on Spring, Java EE, Grails or whatever.
Posted by arjan on March 24, 2010 at 07:26 PM CET #
I agree with that. I don't know who ever thought you should run different apps on 1 AS, but just don't do this.
Don't consider JBoss to be -the- server, but consider it an app that runs on the actual server (whether that is a physical or virtual one).
Posted by Dexter Hughes on March 24, 2010 at 09:16 PM CET #
I was just thinking that having to upgrade the application server to get Java EE 6 APIs is kind of like having to upgrade Oracle DB in order to use the next version of Hibernate. I can agree with the people who think programmer APIs should be separate from app server infrastructure...
However, I think GlassFish V3's modular design will make it possible to upgrade individual APIs (such as JSF and JPA) without upgrading the entire application server. You still won't need to deploy all the .jar's and dependencies inside of your .war file. JBoss is probably the same.
Posted by Ryan on March 24, 2010 at 11:11 PM CET #
@Bogdan
"the main Spring argument against it - that it is too complex" - I don't think that it is still the main argument. Spring vs. EJB 2.1 times are long over. My main argument is that Spring gives you much more practical solutions/classes/patterns than pure JavaEE (once again - Spring Security vs. "declarative JavaEE security" which is too much dependent on what app server offers).
"If you are paying a lot for a commercial J2EE app server, at least you can do is USE it". The point is that the people paying for commercial JEE server are usually not the same persons developing and maintaining the application!!! The former ones care about "business relations with vendor X" and the latter care about "runing the app in the context of changing requirements". This is really important distinction! If someone'll buy you a XIX century velocipede will you do anything to force yourself to do mountain rides? I don't think so...
@Robert
"Spring [...] is solely based on sneaking upgrades past operations". I agree in 100% (putting aside Spring's technological benefits)! That's technological person's only way to say "hey - I really don't need everything WebSphere offers, I know you had to sign this IBM/Oracle contract, but I know this application and I know it will run much better on Jetty - even embedded". I've worked in many projects, where before any technological provisions some non-technical persons chose WebSphere "just because".
"it certainly isn't true anymore with Java EE 6" - why? Now there is only Glassfish (without clustering option) and TMAX JEUS (which I haven't heard about until now). And once again - JavaEE's "declarative" security is app server dependent. It cannot allow for e.g. authentication using two LDAP servers.
on previous entry on this blog you wrote "We run 1 application on 1 AS instance. I'm not really sure whether it's a misconception or a failure on Java's part, but I don't really think either the JVM itself or the AS is a replacement for what is the task of an OS: separating and isolating applications.". I think this is the "magicall" aspect of JavaEE which let grew WebSphere/WebLogic/OAS servers. The vendors told us that the application will contain only business logic and app server "will do the rest".
I understand you're treating app server like a lower part of your multi-module application. I don't disagree! But the next step is to say - "in my application, I only need servlets+jsps - let's use embedded Jetty instead!". And that's what @Ruben says. I also have such application - it's full-blown JavaEE application with server-application put inside out - I chose that I'll control the "app server" and not vice versa. And that's not making me "spring fan boy" :)
regards
Grzegorz Grzybek
Posted by Grzegorz Grzybek on March 25, 2010 at 10:24 AM CET #
@Ryan
>I think GlassFish V3's modular design will make it possible to upgrade individual APIs (such as JSF and JPA) without upgrading the entire application server
I does, but this is also possible with JBoss AS and probably others. Several of the Java EE APIs (but not all) are plugable. It's already perfectly possible to run JSF 2.0 and JPA 2.0 on JBoss AS 5.1.
That said, again, don't think of the AS as something inherently difficult or time consuming. I may counter your remark by saying that if you want to upgrade Spring, you have to redeploy your *entire* war. Taken out of context, this may sound terrible. The *entire* war??? Just for upgrading Spring??? Jeezzzz!
Of course we both know that redeploying a war is not problematic again, but dramatic language may make it sound like its dramatic. I think this is similar for installing a new version of JBoss AS. You make it sound like it's a terribly complicated thing, but it's not. It's just not...
JBoss AS is not the 'server infrastructure' that you think it is. Only developers run JBoss AS directly as a server. In production, this doesn't happen. The infrastructure is the battery of Apache front-end servers, the firewall rules, the switches, the Linux installation, etc. JBoss AS is just the end-point application in all of this, NOT the root server in any way!
I think this simple little observation is at the heart of tons of misunderstandings.
Posted by Robert Tuinman on March 25, 2010 at 01:10 PM CET #
@Robert
"JBoss AS is just the end-point application in all of this, NOT the root server in any way!" - politically, in case if WebSphere or OAS it is totally untrue!! In such cases app server is the most expensive (for the client) and most lucrative (for software provider) part of the installation :) So at the heart of misunderstandings lies politics...
Posted by Grzegorz Grzybek on March 25, 2010 at 01:28 PM CET #
@Grzegorz
>That's technological person's only way to say "hey - I really don't need everything WebSphere offers,
I'm not 100% sure, since you just painted a completely different scenario. To recap, we thus seem to have two scenarios:
1. Management forbids frequent updates to the app foundation, which Operations enforces.
2. Management has a political interest in technology A, but the developers want to develop for technology B.
I have already discussed scenario 1 to great lengths. It's a form of deception that I'm not really sure I want to be a part of.
Scenario 2 is basically you not liking the tools or platform. How is this different from a company that has chosen to develop in Spring, but you like to work in RoR? Or a company that works with Wicket, while you want to develop for .NET?
If you don't like the tools you have to work with, don't work at that place. I was repeatedly offered a job at one of this world's biggest webplatforms, but I kept turning it down since their product is build with PHP, which I absolutely don't like. There is no way I would have accepted the job, then 'secretly' installed quercus, let their existing product run on top of that and then step by step started to use Java code instead of PHP. That really would be a bit debatable, wouldn't it? Yet you're more or less proposing the same thing with Java and Spring.
If you don't like Websphere, don't work at a company that uses it. We're using JBoss AS, and I like it a lot. I really do need/want to use the majority of the functionality JBoss AS offers. A few bits and pieces I don't use, but it doesn't bother me at all that these are available.
It's just like the JDK. In some project I might not use the HashSet. But what does it matter that the HashSet is there anyway? The same is true for Spring too. Their API is also huge. I don't think there is any single app, apart from Spring's own unit tests, that use each and every class and method Spring offers.
>The vendors told us that the application will contain only business logic and app server "will do the rest".
I think your beef is more with IBM and not at all with Java EE. Incidentally, neither JBoss or Apache ever told me this. Better yet, JBoss advised me to run a single app on a single JBoss AS instance.
>I only need servlets+jsps - let's use embedded Jetty instead!"
By all means, I'm not holding you back ;)
But do you have any idea how tiny small the fraction of non-trivial Java apps is that *only* uses Servlets + JSPs and *nothing* really *nothing* else? In years of consulting I've never ever seen any shop doing that for an application of a non-trivial size. There is always some amount of additional libs added.
With Java EE 6, I can for instance opt to start with the web-profile, which is a lighter weight version of regular Java EE 6. Servlets + JSPs will be available there and what I don't need I simply don't use. I can however seamlessly migrate my code to start adopting additional functionality and when my app has really grown I can even switch relatively easily from the web-profile to the full profile.
Posted by Robert Tuinman on March 25, 2010 at 01:43 PM CET #
@Robert
Thanks for this pleasant discussion :)
ad1) Generally I've had situations where some app server was bought before the contract - as part of some vendor cooperation. And then it was not upgraded to newer version because current version "just works". We've migrated from WAS 5 (J2EE 1.3!) to WAS 6 (J2EE 1.4!), but no one sees any reasons to upgrade further (even if that would happen, we'll be at JEE 5 :). So I don't discuss this case any futher
ad2) Sometimes client has this interest. And no one from my company forbids me to use Spring. So I use it in these circumstances (WAS6 = J2EE 1.4). Of course someone might ask if I'd use JavaEE 6 if I had the choice. I'm sure I'd be happy to use JPA2 or Servlets3. But the most controversial (only for me!) part is CDI (former WebBeans). It's great technology and most distinct equivalent of what SpringDI is. In it's current state it's well designed and sometimes better (newer) than SpringDI. But the choice:
1) CDI+rest of JavaEE
2) SpringDI + rest of Spring (Security, Integration) + (yes!) these part of JavaEE 6 I can use now on Tomcat or Jetty (e.g. JPA2, JSF2)
is clear - I chose option 2).
So I'm not against company's interest. I'm an "architect" and I choose technology for company's benefit. I really like JBoss, but sometimes I can choose Tomcat/Jetty without loosing JPA, JSF, JMS, JAXB, etc.
> I think your beef is more with IBM and not at all with Java EE. Incidentally, neither JBoss or Apache ever told me this. Better yet, JBoss advised me to run a single app on a single JBoss AS instance.
You're right. I really like to start with JBoss "minimal" config and add to it everything I need from "default" and "all" ones - it show the real power of JBoss.
> But do you have any idea how tiny small the fraction of non-trivial Java apps is that *only* uses Servlets + JSPs and *nothing* really *nothing* else?
by servlets+JSPs I mean "app server transforms HTTP requests to servlet-API objects and handles my RequestDispatcher.forward()s to JSPs, the rest (e.g. JPA) is under control of my application = placed in WEB-INF/lib.". This of course is similar to very confortable situation where you can customize JBoss' "minimal" configuration, select Hibernate version or replace Mojarra with newer version. And also if you have only one app per server you can really treat JBoss as part of your solution (it's very elegant and confortable!). But once again - it's not a case with WebSphere. I'm not sure, but I think when you replace e.g. XML parser in WebSphere you'll not only loose confidence in its operation, you'll probably won't receive any support from IBM when they'll discover what you did to their server :)
So I emulate customizing JBoss configuration with customizing my WAR/WEB-INF/lib folder's content.
And JavaEE profiles? It's only partial solution - probably helping in marketing "big" servers which will now have option of "buy web profile, save 10%!"
regards
Grzegorz Grzybek
Posted by Grzegorz Grzybek on March 25, 2010 at 02:22 PM CET #
So true. I'm still hanging around with WebSphere 5.1 in some projects because of "stability" of the infrastructure...
Posted by Johannes on March 25, 2010 at 08:26 PM CET #
Johannes, if you're still on Websphere 5.1, then I take it you're also still on Java 1.4?
Posted by Dexter Hughes on March 26, 2010 at 12:24 PM CET #
Grzegorz, the Java EE profiles are for small open source parties. The idea is that the full profile is too big to implement. No small open source party will ever want to implement EJB2 or Corba.
Now such guys can still officially enter the Java EE market by only concentrating on a smaller profile.
Posted by Dexter Hughes on March 26, 2010 at 12:31 PM CET #
Spring is too complcated, and is not Model drived(MDD), so not completely OO, we need a lightweight framework, include AOP + DI + DDD +NoSQL + Async.
Posted by bqlr on March 27, 2010 at 04:28 AM CET #
I think the main problem here is if you control the web server or not.
Not that you want to do something "illegal" or "forbidden".
I work for an editor. We do make and deploy for client web applications.
Some have and want WebSphere with full support. Some want Tomcat with support. Other Tomcat without support.
Some have Websphere bundled with a 1.4 JVM, some a 1.5 JVM...
Maybe one day we will have a client requesting to have BEA Weblogic or JBoss.
If all dependencies are in the war then we are only dependant of the JVM version (we could justify 1.5 but not more...) and servlet version (like 2.4 or 2.5).
Then all become easy, we can deploy our app everywhere.
If we end up couple with a specific J2EE version, or even worse a specific curstomised AS, then we end up with much more more deployement problems.
It's like the open source PHP world. It higly depend of what is available on web hosting services. Application that do no work on the entended enviroment will not be used.
Posted by Nicolas Bousquet on March 27, 2010 at 03:21 PM CET #
I think citing Spring security and integration as a reason not to use Java EE 6 is really very weak. I've used Spring security on multiple projects and it is significantly more complex to configure and use than application server security or the pluggable security that Seam has offered for quite a while now. If we think CDI is cleaner than Spring DI, certainly the same can be said of Spring Security and Seam Security. Furthermore, Seam security will now become a portable extension that can be used with any CDI runtime.
As to Spring integration, it is an edge case solution that is applicable maybe for 3-5% of projects. For such projects, it is just as easy to use more Java EE friendly ESB products (both commercial and open source).
Cheers,
Reza
Posted by Reza Rahman on March 27, 2010 at 06:40 PM CET #
@Nicolas
That's the point! When all parts of JavaEE that I need are placed in my WEB-INF/lib, the "write once, deploy anywhere" works, otherwise - it usually doesn't. Now I can test on Tomcat (which is fast) and deploy on WebSphere (which is eternal part of client's environment). If I rely on JPA from WebSphere (which by the way I can't, because WebSphere 6 is only J2EE 1.4 compliant) I'd have problem migrating from Tomcat, through JBoss to WebSphere.
@Reza
> Spring Security [...] it is significantly more complex to configure and use than application server security or the pluggable security that Seam has offered for quite a while now
application server security: sorry, but I just can't configure Websphere to use two LDAPs - first for authenticating users by X.509 and it's serialNumber field, second - for auxilliary authentication and role provider (+ mapping to application roles). I don't know whether Resin can do it (Tomcat/JBoss, without writing custom Realm can't).
Seam: I've written few comments ago (http://www.adam-bien.com/roller/abien/entry/future_of_enterprise_java_is#comment-1269416519172) that I think Seam (portfolio) is in a sense comparable to Spring (portfolio). I just don't know Seam. Spring Security is not an easy library (just as whole application security), but it's very powerful and customizable. I've succesfully used it in many complex scenarios.
> If we think CDI is cleaner than Spring DI, certainly the same can be said of Spring Security and Seam Security. Furthermore, Seam security will now become a portable extension that can be used with any CDI runtime.
I would be careful with such extrapolation. The point is you have to use something which is not part of JSRs of JavaEE 6. And remember - I can't use CDI + extensions on WebSphere 6 (and by the way on WebSphere 7 also).
And about these CDI extensions. I think it's great concept. But after using them, your app has to be aware (which is not a bad thing!) of them. I might be wrong, but they're not like JavaEE specs - you can't replace one extension with other which "conforms to the same spec" - I mean when you use "Seam 3 Security CDI extension", you're tied to Seam 3 (again - which is not a bad thing) - but this is not different from using Spring Security. The difference is I can use Spring Security on embedded Jetty or on WebSphere 6.
> As to Spring integration, it is an edge case solution that is applicable maybe for 3-5% of projects. For such projects, it is just as easy to use more Java EE friendly ESB products (both commercial and open source).
With all the respect to you Reza - what "Java EE friendly ESB products" you're thinking of? JBI is not part of JavaEE and is more "WSDL or contract driven". Spring Integration can be "anything" driven and I can use it in both simple and very complex scenarios. And (what should be great advantage for JavaEE advocates) it is great implementation of "Enterprise Integration Patterns" book (the other is Apache Camel) and is based on perfect java.util.concurrent classes.
And what do you mean by "JavaEE friendly"? Spring Integration can have Servlet endpoints, has JMS, JDBC, JMX gateways. What could be more JavaEE friendly?
And I also know Mule - That's what I've used before I've decided to rewrite the entire application using Spring Integration - for the benefit of all developers.
regards
Grzegorz Grzybek
Posted by Grzegorz Grzybek on March 27, 2010 at 09:32 PM CET #