Ryan has posted 17 posts at DZone. You can read more from them at their website. View Full User Profile

The Cost of SpringSource Enterprise Support

09.26.2008
| 16203 views |
  • submit to reddit

I'm in the early stages of combining several Java EE 5 projects into a single project (WAR, EJB, EAR, JARs, etc). To do that I needed to swap out EJB 3.0 for Spring 2.5. I'm trying really hard not to replace anything else by keeping the JNDI DataSources, JTA and JPA implementations provided by GlassFish V2. I'm using annotations such as @PersistenceContext and @Transactional to keep the code clean and lean like it was in EJB 3.0. I've encountered several challenges and found the Spring Forums helpful. There seems to be paid SpringSource staff on the forums helping people. From what I can tell, my most recent issue appears to be deficiencies in the design of Spring. Nobody has replied in a few days so I thought about purchasing per-incident support from SpringSource. I've done this with other products before and was hoping that they would offer the same.

I went to SpringSource's website and looked up the pricing. I had to fill out information about my company so that a sales rep could phone me back. A while later they phoned to ask a few more questions. My answers were:

  • We're using Spring DI + transactions + JPA + unit testing features. Nothing else.
  • Deploying to a single GlassFish V2 server with two CPUs
  • The application that uses the Spring Framework is a custom application for a single customer
  • The customer owns and maintains the server. We only install our application onto it and do upgrades.
  • Our company has around 12 employees

He plugged all of this information into his computer and came up with a total: $22,500 per year. I must have sounded like an idiot because I had to ask him the same question three or four times: "You said twenty two thousand dollars, not two thousand five hundred, right?" Many things were going through my mind so his responses didn't register the first few times. I told him that we don't use the whole Spring Portfolio, and do not deploy on their application server. I'm only using a few jar files that probably add up to less than 1 MB and only want one support incident. The best he could offer is the Spring Forums which he said is staffed by the developers who maintain the actual source code. He also said that the level of support they will offer in the forums will deminish because of the new commercial support offering.

At first I wondered how they could come up with such a price. Then I realized they are positioning themselves up there with IBM WebSphere, BEA WebLogic, and Oracle Fusion. Those products cost around $20,000 - $30,000 per year as well, or more. SpringSource's support is for the entire portfolio, just like support for a Java EE application server covers all of the Java EE APIs. We purchased a GlassFish V2 support contract for $4,500 per year, and we get unlimited incidents for everything in Java EE 5. We've already had to use it once and they were helpful to find the solution.

When I think back to the original allure of Spring [to me], it was to have EJB like container managed transactions and dependency injection but in the .war file and in unit tests. When EJB 3.1 and WebBeans 1.0 come out I will be able to swap out Spring and can get the support I need from Sun since we're already paying for it.

From http://www.ryandelaplante.com/

Published at DZone with permission of its author, Ryan Developer.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Ryan Developer replied on Wed, 2008/10/01 - 12:52am

[quote]

I really cant see how you see Spring is complex,

[/quote]

That's because you've never used Java EE 5 & EJB 3.0 to see how everything works out of the box.  I've wasted weeks with Spring class loader, load time weaver, and JPA problems.  I can't say that I've ever wasted so much time trying to do something in EJB 3.0.  Yes I have read two books on Spring cover-to-cover, have used the Spring reference manual, Spring forums and google.  My issues are legitimate ones, some of which are flaws in Spring that EJB doesn't have.  I'm not the only person who thinks Spring is more complex than it needs to be. I've read many comments from Spring users in recent threads saying the same thing.  For now I've found workarounds for most things and have moved forward.

[quote]

By the way you write, you seem to be someone who buys into every technology going before really anaylsing what you are trying to solve or what the technology does

[/quote]

Actually I'm just the opposite.  Rod said in "Secrets of the Rockstar Programmers", when everyone else was accepting the status quo, he was questioning it. I too question the status quo. I fully read up on every technology I'm considering before using it.  That means I read a lot of books, spend a lot of time doing research online, and try the stuff out first.  I just haven't come to the same conclusions as you  because I'm able to put J2EE behind me and evaluate Java EE 5 without bias.  I value the benefits of JCP standards and know from first hand experience how much they have learned from their mistakes and corrected them.  I'm not the only one.  Why do so many developers choose JPA standard APIs over using direct Hibernate? Why do so many developers choose JAX-WS standard APIs over using direct Axis2, XFire or CXF? Why did you choose to use Java EE 5's JAX-WS APIs?

I recommend you read up on EJB 3.1 (full and lite), WebBeans (based on Seam, which I have also read a book on), and JSF 2.0.  I'm sure you will find that all of these technologies have come leaps and bounds from where they were in Java EE 5, which was alread very usable.   Once Java EE 6 comes out with a fully integrated stack that does everything I need without having to wire and configure it, I will no longer be able to justify the extra work and dependencies to use non-standards.  I think we're going to see Spring used the same way Hibernate is used today: behind the JCP standard APIs of EJB 3.1 and WebBeans 1.0.

 [quote]

It seems the developer here range from either the long term 'J2EE' is the only way to work brainwashed to the guys who have worked on a few small scale applications with license to go technology crazy without proper oversight, perhaps you need to spend a few more years working to understand you are trying to solve problems and not just play with the newest toy on the block. 

[/quote]

Last Friday I celebrated my 10th anniversary working professionally as a software developer. A couple years ago my software had a full page ad in the Wall Street Journal.  I think I have the experience to make informed decisions and to not just play with the newest toy on the block.

It seems like every single Spring fan I've talked to has the notion that anyone who likes EJB 3.0 or JSF must obviously be too close minded to look at anything outside of Java EE and hasn't looked at the alternatives.   The tables have turned.  Many Java EE developers like myself have used Spring, Hibernate, etc. and choose to use Java EE standards as much as possible where they work (ex: drop only EJB container for Spring to use it in .war file until EJB 3.1 comes out, or preferring JPA APIs except when needing features not yet in the spec)  Spring fans can't say the same about evaluating Java EE 5. Often they are the brainwashed ones who don't like or can't accept change. You, Rod, and the rest of the Spring community should stop comparing Spring to J2EE. J2EE implies version 1.4 from 2003.  Instead, compare Spring to Java EE 5/6, or EJB 3.0/3.1. 

Thank you for the interesting conversation. I have enjoyed it. 

Rick Reumann replied on Wed, 2008/10/01 - 2:22am in response to: Liam Knox

[quote=knoxl]

Can you explain what Spring does not give you easier that what J2EE after N years of development does now?  I really cant see how you see Spring is complex, you have an applicationContext with a completely standard bean definition syntax and integrations with practically any technology you require and in a standard and concise way.  I think some of you guys must be very punch drunk in having got to use and deploy these clunky applications to app servers you don't really see the wood from the trees anymore.[/quote]

 I guess maybe I am drunk, but I was just trying to get JPA stuff working on Tomcat6 and running into load time weaving errors. So I started looking over the docs http://static.springframework.org/spring/docs/2.5.x/reference/orm.html#orm-jpa-setup-lcemfb-tomcat  Gee that's a lot of fun. Then things still aren't working so I start googling.. and things get worse. Some say I need to add the tomcat-weaver jar.. some say you don't. Some say you need the load-time-weaver definition in your context.xml.. others say you don't. Some say you need to include the property definition for the load-time-weaver in your entityMangerFactory, other say you don't. Next I have to figure out what aspectj jars I have to move over into my app's lib. Do I need to include aspectjr.jar and aspectjweaver.jar? Sure I'll eventually figure it out, but I started wondering "How is this making my job any easier?" 

 Now lets take dependency injection in general. Ok it's great for testing. I give Spring the plus on that. 100% very nice there. But ok what else? Ok DI is nice for injecting things like entitymanagers, etc, so that you don't need a service locator, I get the same thing out of the box using a jee container. Next Spring is nice for transaction demarcation.. ok that's wash as well. You have that out of the box as well in the JEE world. AOP stuff.. I thought I'd be into it, but I just wasn't. Ok maybe for some logging it's nice and/or for security lock downs on method invocations (granular security you get with JEE as well.)  Truthfully, though, other than DI for swapping out test implemenations, injection of resource type objects, and transaction demarcation, what other aspects of Spring is "that" incredibly helpful? I have the Spring in Action book, and please don't get my wrong- I'm not really "anti" spring.. I just think it's overrated when things just work with LESS configuration deploying to a jEE server. (granted this certainly wasn't always the case.)

 

[quote] That there is actual arguments about support costs for a free framework that is so mature and stable tha Blue chip companys are using it across 1000s of developer without even signing up to these is a bit strange.  Do you not have the expertise to read their concise documentation?[/quote]

I'm not saying the documentation is bad or that i can't read it. I'm just stating that I have to read less of it to be up and running in a JEE world.

[quote]It seems the developer here range from either the long term 'J2EE' is the only way to work brainwashed to the guys who have worked on a few small scale applications with license to go technology crazy without proper oversight, perhaps you need to spend a few more years working to understand you are trying to solve problems and not just play with the newest toy on the block.[/quote]

I'm also not "whoopie JEE5 is awesome" either. I come from a simple Tomcat/iBATIS background where I've used Spring for the DAO support and to help in testing. Truthfully Spring didn't give me that much even there. The DAO was nice, but not like I wasn't working with my own version did the job before I went to the more 'standard' Spring support. I think a lof this discussion comes to 'what do you plan to code?" if it's going to be your standard self-contained CRUD app, use whatever is simple and gets the job done (truthfully I think Java is now overkill for this kind of app - yet I still use it because I'm more familiar with it - simple Stripes webapp with ibatis or even hibernate is fine for me there, but I'm liking Rails a lot for these kinds of apps now.) But now take larger apps that also needs JMS support, webservices thrown in, possibly JTA with multiple databases, security. Sure I know Spring has support for all of these, and yea I can read the docs on how to get Spring to do what I need, but I'd say the onus is on you, not me, to show me how using Spring makes these other enterprise aspects "more simple' ?  Spring would be most helpful for me in those cases where I had my 'simple app' already built and deployed to Tomcat as a simple war and now later realized "Hmmm I really need support  for X now." But just starting out on a brand new application where I knew up front I was gong to be using JPA, JMS, Webservices, what advantage to have I using Spring? (and don't see portability since I've totally given up thinking that's even important any more. Regardless the standard implementations are quite portable now. Sure you might have a few custom things to tweak that are server specific.. possibly pool/queue sizes etc., but that's not a big deal.)

A couple years ago, without question, Spring 100% all the way. I was just surprised once I took a new look at JEE, how easy it has gotten (relatively speaking of course to the ugly beast it once was.)  Yes, I understand Spring had a lot to do with being the impetus for those changes (just like C# had a lot to do with pushing Java forward with needed changes to the language.)

 

Mark Unknown replied on Wed, 2008/10/01 - 8:09am in response to: Rick Reumann

Some of us do more than just Web Apps (ie Eclipse RCP), so we need a little more than what Java EE gives us.  Does it provide the ability to easily remote a service or run outside the Java EE container?

Rick Reumann replied on Wed, 2008/10/01 - 9:36am in response to: Mark Unknown

[quote=mknutty]Some of us do more than just Web Apps (ie Eclipse RCP), so we need a little more than what Java EE gives us.  Does it provide the ability to easily remote a service or run outside the Java EE container?[/quote]

The thread was in the context of Java web applications. Pick the best tool for the job. For example JPA/Hibrernate is great for some things, but other times iBATIS could be an easier/better approach. 

My overall point is that I don't feel Spring makes things easier any more when it comes to a comparison to using that latest JEE spec implementations (other than, like I mentioned, testing is easier with Spring.) 

I'm not saying Spring is crappy or doesn't have its uses (quite the contrary, look at how frameworks like Grails leverages it behind the scenes.) 

Mark Unknown replied on Wed, 2008/10/01 - 10:04am in response to: Rick Reumann

[quote=rickcr]

The thread was in the context of Java web applications.

[/quote] What thread? The main topic was about Java EE 5.  Other than that thread I can't see another (at least not the view I am using).

[quote=rickcr]

Pick the best tool for the job

[/quote] Correct. But not sure what that has to do with what I said.

 [quote=rickcr]

My overall point is that I don't feel Spring makes things easier any more when it comes to a comparison to using that latest JEE spec implementations (other than, like I mentioned, testing is easier with Spring.) 

 [/quote] And my point is that not everyone lives in a Java EE container.  You asked "But ok what else?"

Ryan Developer replied on Wed, 2008/10/01 - 11:59am in response to: Mark Unknown

I would not argue for the use of EJB 3.0 over Spring outside of a Java EE application server.  When running inside a Java EE application server the value is having a full featured and pre-integrated stack that can be used by your applications without having to add them and their dependencies into your .war,  without having to  configure their integrations, and without having to have different settings when deploying onto a different vendor's Java EE application server. This kind of out of the box experience sounds a lot like the direction Spring is going with the Spring Application Platform. 

As for unit testing EJBs, it is possible today using OpenEJB. EJB 3.1 spec is directly addressing unit testing issues as well. 

EJB has always supported remoting, and can also be exposed as a JAX-WS web service.

Otengi Miloskov replied on Wed, 2008/10/01 - 12:10pm in response to: Mark Unknown

Mark I see your point but you could use Guice or OpenEJB with EclipseRCP and gives you the same as with Spring if you just want to decouple your logic and other features, but for other things yes go with a JEE solution or Spring portfolio.

Take a look at OpenEJB http://openejb.apache.org/ or Guice http://code.google.com/p/google-guice/

Liam Knox replied on Wed, 2008/10/01 - 5:54pm in response to: Otengi Miloskov

You clearly cant see the wood from the trees.  You were no doubt stating the same things about EJB 2.0, 3.0. and 3.1.  J2EE in Sun's manifestation does not know what it is and is now just pigey backing on the most complete enterprise frameworks ideas.  Yes there are options out there, but if you look at Guice and the other IoC containers they are less mature and make massive assumptions, such as I can do everything via annotations, which is simply not the case especially as soon as you have 3rd party libraries.

The J2EE 'expert' group maybe working hard, but given the track record of the most rigid remoting, infected design to now the lets just take Hibernate and Spring and call it EJB 3.1, I really do not trust their expertise.  You sound like many others on this blog that anything given a JSR must of been written by God and therefore can be assumed correct, which is simply not the case.  I reiterate that you chose a tool based on its ability to solve a problem, i.e. you hit a nail with a hammer , not a Sledge Hammer ( EJB ) or a Mallet ( Guice ) or a match stick ( Rails ).  Personally I am not advertising Spring as any panacea yet it brings to the table to best yet solution.  The competition in the market is good, Guice influenced the adoption of annotation drive IoC which has its place and is usefull.

I am also not blinded by Spring, several of the choices, for example JMX annotation choices, JDBC support limitations and other annotation based ideas I find questionable.  But still you do and should do this to any technology.  Also given certain J2EE containes are written using Spring you comments about running away from Spring may leave you with no Toys left in your toy box to play with ;-).

I also dont undesrstand your one vendor point,  can you give me an historical example of when taking a larger market share technology was a bad idea interms in continuality.  I would be more scared investing in something like F# just because the vendor was Microsoft and there turn of 2 pence behaviour. Also in the EJB world the multi vendor has just led to different deployment descriptors, runtime behaviour etc etc, J2EE is not that portable.   At the end of the J2EE was kept going by Sun for one reason , money, that you ever needed App servers of containers to build Enterprise applications is one of the biggest Lies to the computing world, and purely addressed the application server providers profit margin and no inherent problems in Enterprise development

   

 

Ryan Developer replied on Wed, 2008/10/01 - 9:42pm in response to: Liam Knox

[quote=knoxl]

I reiterate that you chose a tool based on its ability to solve a problem, i.e. you hit a nail with a hammer , not a Sledge Hammer ( EJB )

[/quote]

They've already tackled the sledge hammer problem in EJB 3.0.  I don't think your heavyweight point holds up anymore.

http://www.adam-bien.com/roller/abien/entry/heavyweight_ejbs_lightweight_pojos_or

http://www.adam-bien.com/roller/abien/entry/is_it_worth_using_pojos

 [quote=knoxl]

Also in the EJB world the multi vendor has just led to different deployment descriptors, runtime behaviour etc etc, J2EE is not that portable. 

[/quote]

True. The Java EE 5 expert groups realized this was a problem and tightened up both the specifications and the TCKs years ago.  Java EE 6 continues this by standardizing global JNDI naming conventions, by standardizing more JPA hints (such as for cache), and by adding much needed features into EJB 3.1 that you could only get using proprietary deployment descriptors in the past.

 

Alex(JAlexoid) ... replied on Thu, 2008/10/02 - 10:00am in response to: Liam Knox

[quote=Liam Knox]Also given certain J2EE containes are written using Spring you comments about running away from Spring may leave you with no Toys left in your toy box to play with ;-).[/quote]

Given that any J2EE container must adhere to the specificatio, the container may be written in C# or Assembler.

 And I thought we all know now that j2ee means J2EE 1.4 and lower. So you are trying to reason on basis of J2EE 1.4, while the people you oppose talk about Java EE 5.
Therefore I have to assume that you really have not looked at Java EE 5, and just have you nose deep in Spring not really caring about what's out there.

Ryan Developer replied on Thu, 2008/10/02 - 11:34am

The Spring community should be proud to have a silver tongued ambassador like Liam.

Liam Knox replied on Fri, 2008/10/03 - 8:24am in response to:

It is nice to see this site has atleast, more recent, 2 Spring articles, one an interview with Rod Johson ;-)

 

Liam Knox replied on Fri, 2008/10/03 - 8:36am in response to: Alex(JAlexoid) Panzin

I will put this very straight forward. Are you working ?

At work you try to solve problems in ordered to get paid. Sure there are laws like Governmental, or from the FSA , but  J2EE is not one of them.  Who make laws about J2EE ? Spring ( and not only ) said one main, thing You can writte an application using a JDK easier and better than using a J2EE, EJB and a container

I really like your use of the word 'must' , and also based on you eclectic talk Mono will bet running on one of those Mars rovers next week ?? ta ta

;-)

Rick Reumann replied on Fri, 2008/10/03 - 8:56am in response to: Liam Knox

[quote=knoxl]Spring ( and not only ) said one main, thing You can writte an application using a JDK easier and better than using a J2EE, EJB and a container [/quote]

 

The part I don't see answered by most of the Spring propopents here is:

"Assuming you are building an enterprise applicaiton with an ORM persistence layer (Hibernate, Toplink, etc), how does Spring make this easier TODAY than using JEE5 EJB3?" 

I don't want comparisons to EJB2 and I want some answers from those who have coded at least one production EJB3 application. It seems people just assume the baggage that once existed is still there.

Your next part about it being "Better" with Spring could potentially hold some more weight, but I'd like this "easier" question answered. I'm not claiming Spring is necessarily a lot more difficult (alhtough I personally happened to have similar frustrations the op had in relation to JPA and Spring), but I'm curious how Spring makes things easier, since thats the claim I often hear.

Alex(JAlexoid) ... replied on Fri, 2008/10/03 - 2:33pm in response to: Liam Knox

Yes I am working. And since as part of my work I have to evaluate different technologies, I have time to look at Java EE, though I have not gone for Spring (since as stated in my previous post, the docs are horrible for a newcomer to learn the framework and even with tutorials it's already very complex*).
As part of my work I am charged with remembering the staffing possibilities and training costs. Guess what? Java EE 5 has a faster startup time then spring.

So yes, I think of how to get things done and I also have to think how to protect my clients' investments in their application stacks(be that standards or workforce availability**).

* - Let us not forget the "XML hell" scenario.

** - there are a LOT of people lately that have Spring on their CV,  while having the same amount of experience with it like me - having the general DI container expereince.

And the part that you misread or chose to ignore is the part that J2EE ir NOT Java EE 5.

I am pretty much sure that you also don't care in what language Spring is written in.

James Law replied on Fri, 2008/10/03 - 4:40pm

Alex,

Couple of points .

The spring docs are amazing, especially considering it is OSS, and not developed by IBM. The source codes' javadoc is top notch (compared to almost every other source code i've looked at). So I can't agree its horrible for a newcomer. Armed with Spring in Action, the reference docs, and some sample apps I'm not sure what else one would need. While I agree there's a lot of information, that's because spring has a large API surface area, as they solve nearly every enterprise problem I throw at it. Need messaging? Jms? Email? Webservices,batch? Spring will help you out, and J2EE still has missing pieces. Want to run your stack standalone in batch? Run integration tests without a container? Yes each piece will have some learning involved, but I've always felt in the end the business got their time back in my increased productivity.

Re: XML hell. Had you designed an IOC container back in 2002 before annotations existed in Java 5, I think you also would have done it in xml. Of course spring requires almost zero xml now. Cool thing about spring is they always have supported multiple config options.

I consider myself open to J2ee, and happy to see it evolving, but if you want one stop shopping for a lot of java functionality SS is the still the best place in java. Given suns waning influence , at this point I'm not sure the entire JSR process is going to matter for much longer. 

 

Alex(JAlexoid) ... replied on Fri, 2008/10/03 - 5:52pm in response to: James Law

[quote=James Law]The spring docs are amazing, especially considering it is OSS, and not developed by IBM. The source codes' javadoc is top notch (compared to almost every other source code i've looked at). So I can't agree its horrible for a newcomer. Armed with Spring in Action, the reference docs, and some sample apps I'm not sure what else one would need.[/quote]

I do like Spring docs, those are complete, easy to find what you are searchin for. Those look very much like Hibernate's and are of equal or better quality. But that documentation is optimal for a person that knows what he's looking for, a newcomer will not know. And if you want to learn Spring, you need to buy a book(or get training). And since Spring came out of a book, that is not very surprising...

SpringSource is the main/best training company for SpringFramework, so not surprising that good newcomer docs are hard to come by, without paying.
Don't get me wrong, I think it's a sound and good business model, but when you need to commit before you learn what you're commiting to, that is not my way*. (Compare to Compiere ERP - their suite is GPL licensed, but hey sell consulting/training and documentation)

[quote=James Law] always have supported multiple config options[/quote]

Didn't they have the annotations since 2.5? So not always. And Java 1.5 is around since 2004.

* - Just to remind you, I have never used Spring. Tried to, but found that there is no easy(fast startup) tutorial for a rescent Spring version.(Checked May 2008)

And all of the above is IMHO.

Liam Knox replied on Sat, 2008/10/04 - 7:15pm in response to: Alex(JAlexoid) Panzin

If you think

 ApplicationContext ctx = new ClasspathApplicationContext(resource);

 Is complex then I am not really sure how I cant help? 

I also believe that any good developer worth his weight would be able to glean enough from the excellent documentation provided on their web site to get up and running.  For one thing the JavaDoc drives this as this specifies how you can configure any Java Bean.  The xml configuration is very logical and consistent.

If you dont like XML then you also have the annotation model, and also even classpath scanning if you really hate it.  The mention of the xml hell scenario is a massively overblown excuse here.  Code can equally become monolithic and verbose if not structured.  In Spring you can import resources and use AbstractBean definitions to minimize this and as mentioned you always have annotations, Spring support for this is a superset of what EJB 3.0 provides ( and 3.1 will ) .  What people also fail to mention that in many applications you cannot just get away with annotations, if you want to maintain and proper consistent IoC model.  Guice has king of skipped this issue and in doing so has basically put its hands up that it will never compete directly agaist Spring and will be a weaker model. 

As you mention you have never used Spring so I would encourage you to take a better look.  On the CV point the real issue if not that there are alot of Spring skills , it is this is an increasing number per anum.  Equally you see the job skill required for Spring increasing agaist EJB which is no flat or even reducing in  number. 

 

 

Liam Knox replied on Sat, 2008/10/04 - 8:34pm in response to:

Perhaps the Rod's comment that EJB 3.0 is basically a cheap hack of Spring really does some this up.  In that respect Spring has really won on the ideas front and I believe will continue todo so based on one fundamental point.  Spring is based on a very simple premise that you need only POJO's and a JVM to write an enterprise (or any) application.  IoC breaks the horrors of configuration when your application requires this. Add in another simple paridgm such as AOP, then you have all the power you need. I think this answers someone elses question of why it is easier.  There is not alot to it, but theres a hell of alot of what you can make from it. 

EJB, J2EE whatever the new dress today is, will always have the disadvantage of coming from a complex non pure POJO model.  With JNDI look ups, bean specialization, intrinsic container behaviour, you still have a bucket of behavioural technologies and strings that hold you with respect to what you can do, how you can test etc etc. This compromises development , testing and archictecture.  Its kind of akin to building an house out of certain sized components, you are restricted in how you can manipulate it, what shapes can be achieved.   I am sure EJB 3.1 will move even more towards Spring, but will always lag behind interms of innovation. There is just to much baggage.  I also feel very sorry for J2EE developers because each year you just get something completly different based on the downsides of the previous mutant release.  Blue prints, casing point in how to highlight how bad a design is dressed up a usefull patterns. Presumably backward compatability , expoential support and complexity doesnt really come into Sun's view of the world also ?

In these unsure Job times I am certainly glad of my skill set now.  I am also glad I can continue to develop easily, with no strings attached and concience clear ;-)

I really hope your wall street advertisement payed off and cost less than whatever application servers contracts you have invested in to date

regards 

lk

Alex(JAlexoid) ... replied on Sun, 2008/10/05 - 4:57am in response to: Liam Knox

[quote]I would encourage you to take a better look[/quote]

I did try. That is where I got the result that Java EE 5 is has a faster startup time. Based on short and concise tutorials, witch Spring lacks. (or maybe lacked at the time, there is still no official fast startup tutorial on their site)

Ryan Developer replied on Sun, 2008/10/05 - 7:53pm

[quote=Liam Knox]

Spring is based on a very simple premise that you need only POJO's and a JVM to write an enterprise (or any) application.  IoC breaks the horrors of configuration when your application requires this. Add in another simple paridgm such as AOP, then you have all the power you need. I think this answers someone elses question of why it is easier.  There is not alot to it, but theres a hell of alot of what you can make from it.

[/quote]

I think you are over simplying and missing the points we have been making. I use container managed transactions to keep my JPA code clean and simple.  I choose to use the transaction manager (via AOP), JPA provider, and DataSources built into the application server instead of using 3rd party ones which many Spring examples seem to assume I want.  That was a painful decision to make because there are no complete examples anywhere on the Internet on how to do this with GlassFish V2.  The only help I could get on the Spring forums were people telling me that I have classloader problems.  I had to battle Spring myself for a couple of weeks until I got it all working and could begin my actual programming.  Have I ever had to configure various pieces of middleware to work together before using them in Java EE 5? No.  Java EE 5 application servers come fully integrated out of the box. That is one of several points I have been repeating.

Once I got past that issue it was smoothe sailing with Spring and I was feeling good about it until I added a second database.  I ran into all kinds of problems with Springs JPA support and even read things like @PersistenceContext and @PersistenceUnit don't work when multiple entity managers are configured in the applicationContext.xml. It also doesn't let you have multiple persistence units in the same persistence.xml.  I had a few other problems that other people confirmed in other threads which lead me to the conclusion that EJB 3.0's **JPA support** is superior to Spring's. Liam, you are not qualified to argue with me about Spring JPA support because you said that you don't use it, and I'm sure you haven't tried it in EJB 3.0.  You are wrong about Spring being easier to use and better than EJB 3.0 **when using JPA**.  This is a second point I have been repeating. 

I will agree that Spring was necessary for many years, and was the driving force (along with Hibernate and Seam) behind changes in EJB 3.0, 3.1, and WebBeans.  I also agree that EJB 3.0 is lacking important features, and that the packaging requirements are rediculous.  That is exactly why I chose Spring on my current project. It's the right tool for the job, but severely decreased my productivity getting ramped up with it, even after reading a Spring book.  I'm not talking about Spring basics, I'm talking about making Spring have the equivalent feature set that I've enjoyed in EJB 3.0 by integrating it with the existing infrastructure in GlassFish V2.

The EJB expert group said that the focus of EJB 3.0 was to make it easier to use, and to replace the old CMP with JPA.  JPA took most of their time, so they didn't add any new features in EJB 3.0.  JPA is now completely separate from EJB, which enables the EJB 3.1 expert group to focus their time entirely on new features and packaging issues.  Developers will find that EJB 3.1 and WebBeans' simple POJO based development, IoC, AOP, unit testability, and other features meet all of their requirements for most applications and encourages the same architectural designs as Spring. Both new and experienced EJB 3.1 developers will find it quicker and easier to begin making progress in projects than Spring because they don't have to configure enterprise services to play nicely together. 

[quote]

EJB, J2EE whatever the new dress today is, will always have the disadvantage of coming from a complex non pure POJO model.  With JNDI look ups, bean specialization, intrinsic container behaviour, you still have a bucket of behavioural technologies and strings that hold you with respect to what you can do, how you can test etc etc. This compromises development , testing and archictecture.

[/quote]

You can potty mouth EJB 3.1 all you want, but don't expect those who've read the specs to take your uninformed flame bait seriously.

[quote]

There is just to much baggage.

[/quote]

Like Spring's legacy baggage, EJB keeps old features around for backwards compatability.  Nobody is forced to use the "baggage".  If you read articles on EJB 3.1, you would know that EJB 3.1 Lite "cuts the baggage" so new vendors like Spring Source can get certified without having to implement "baggage", and that Java EE 6 introduced profiles (like in Java SE). One of the features of profiles is to make official recommendations on permanently removing "baggage" in the next spec version.  That gives people time to migrate to the newer features.  Your idol blogged about how Java EE 6 gets it right. I'm surprised you haven't read it:  blog.springsource.com/2007/07/03/java-ee-6-gets-it-right/

If you had paid attention to other people's comments you would also know that Spring IoC + AOP is not competing with J2EE or Java EE 5.  Specifically it competes with EJB (and soon WebBeans), which is only one of twenty two standards under the Java EE 5 umbrella:  java.sun.com/javaee/technologies/  ...hence the book title "J2EE development without EJB". If you wanted to look smart you would stop typing J2EE and would type EJB 3.0, EJB 3.1, and/or WebBeans instead. 

I still think in 2-3 years time Spring will be commonly used behind EJB 3.1 and WebBeans APIs, like Hibernate is commonly used behind JPA APIs today, and Axis2/XFire/CXF are commonly used behind JAX-WS APIs.   Even though JPA 1.0 APIs are missing features, people still use them and add vendor specific APIs when necessary.  JPA 2.0 will standardize the rest of most commonly needed functionality and make many developers happy.

Even though Spring has more features, most developers will find that EJB 3.1 and WebBeans APIs will have everything they need for most systems.  If they need a feature not in the APIs, then they use vendor specific APIs until the next spec standardizes them. 

You don't have to tell me that you completely disagree, followed by further insults to my intelligence.  It doesn't matter how much you look down your nose from your high horse at me, or how sorry you feel for me, you won't change my views on EJB 3.1 and WebBeans 1.0.  I don't matter to you anyway, so give it up.

This is the last of my long replies because we're never going to fully agree.  Thanks for the interesting conversation, and no hard feelings.

Alex(JAlexoid) ... replied on Sun, 2008/10/05 - 4:54am in response to: Liam Knox

[quote]always lag behind interms of innovation[/quote]

Most of us here are techies and the word innovation is and empty one for the management, care to point where to find examples of innovation or list them in this thread?(Beyond just plain AOP and DI) Maybe there is even a comparison of Spring 2.5 with Java EE 5? Since I am not part of Spring community, I don't know who is auhtoritative enough to make those comparisons.

hookfi john replied on Sun, 2009/05/31 - 7:53am

dfdf dfd replied on Wed, 2009/06/24 - 9:29pm

I like the ed hardy clothing. ed hardy is one of the most popular brands. ed hardy clothes displays the brilliant work of Don ed hardy uk. He is a gifted painter, printmaker and tattoo artist. cheap ed hardy offerings include ed hardy tank, cheap ed hardy clothing, ed hardy on sale, ed hardy handbags, ed hardy discount etc. ed hardy swimwear is just 4 years old and was launched by Audigier in 2004. There were many Hollywood stars who wear his ed hardy swimwear. Some of the famous celebrities include Ed Hardy Belts, Jessica Alba, Mariah Carey, Paris Hilton etc.

Carla Brian replied on Sun, 2012/04/22 - 8:42am

SpringSource offers enterprise support packages that help you get the most out of enterprise products from SpringSource, th and Apache technologies from the actual people who conceived the Spring Portfolio. - Tire Works

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.