Article:		POJO Application Frameworks: Spring Vs. EJB 3.0
Subject:		opinion piece veiled as objective article
Date:		2006-02-22 07:28:10
From:		steve--o
Response to: opinion piece veiled as objective article
i found the article to be excellent and unbiased.. the spring XML files are verbose crap.. i don't like xml as you've probably guessed.. in fact the article was so informative that i will now use jboss and EJB for the first time.. i have always found it to be a pack of complex bother and spring did not get me to jump in.. thank you michael.. incidently, i have a phd from USC and a MS from MIT and 25 years programming experience so don't make the mistake of thinking i'm a lightweight.. i'm hoping that design by committe has for once cleaned up the pathetic mess that is EJB and a lot of J2EE..

Showing messages 1 through 2 of 2.

• opinion piece veiled as objective article
  2008-01-10 11:53:22  Rick010 [View]
  
  
  Thank you for your incredible credentials. I would side with you on EJB 3 being good, but this side of the street believes that you should address this concern of mine ( especially about xml "crap" you mentioned, keep your mind unbiased and objective ) :
  I have gotta situation.
  I am going for release of my app tomorrow, i followed everything to the toe and then suddenly i've gotta do some changes in code ... for this i have to do a build ( build and then deploy the EAR / WAR or whatever ). Now suppose that i am writing configurations for all POJOs to-be-persisted in xml, all i have to do is change xml file configurations. On the other hand if i am doing annotations i have to go in code and do something ( blah blah ). My code was "frozen" state until now. Technically making jsp, HTML or xml changes do not come in code changes ( as per my company policy at least ) so yea i am safe when i working with xml. we do a build and all is solved ... But what would happen if i am using annotations ...
  
  Regards
  Vyas, Anirudh
• opinion piece veiled as objective article
  2008-05-06 22:50:02  HumbleMan [View]
  
  
  "I am going for release of my app tomorrow, i followed everything to the toe and then suddenly i've gotta do some changes in code ... "
  
  Possible Solution:
  If the change is absolutely necessary, extend the release date and after the product is released, fire the project manager.
  
  If the change is not absoultly necessary to get into this release, deliver it as a service pack.
  
  Never rush to change anything before delivery. It's dangerous.