tag:blogger.com,1999:blog-7836204352369514180.post3147883968063312088..comments2022-03-25T05:11:20.110+01:00Comments on Around the World in Java: Deconstructing Spring mythsHarald Wellmannhttp://www.blogger.com/profile/08039976160321882828noreply@blogger.comBlogger12125tag:blogger.com,1999:blog-7836204352369514180.post-39247164945511453082014-08-21T11:46:09.008+02:002014-08-21T11:46:09.008+02:00About the 'Singleton Antipattern' and hug...About the <b>'Singleton Antipattern' </b> and huge list of parameters: please <b>use a parameter object</b> instead of wild parameters. Then you have a 'context' that you pass around all stateless methods.Bloblohttps://www.blogger.com/profile/15101491360817930185noreply@blogger.comtag:blogger.com,1999:blog-7836204352369514180.post-47227122635206057562014-07-11T17:30:26.299+02:002014-07-11T17:30:26.299+02:00"Most people who drive a car don't want t..."Most people who drive a car don't want to get their hands dirty on the mechanics..." - yeah right, but as programmers we <i>are supposed to be</i> the mechanics. And of course I don't want to use something where I can't do my mechanic's work.<br /><br />You remind me of ancient VB6 programmers. They also didn't want to get their hands dirty, and were extremely happy with a platform that just worked. For whatever reason, they are mostly extinct nowadays ...<br />A_flj_https://www.blogger.com/profile/13123052099912825525noreply@blogger.comtag:blogger.com,1999:blog-7836204352369514180.post-46959191698518756982014-07-11T17:27:37.136+02:002014-07-11T17:27:37.136+02:00You seemingly don't get it at all what Spring ...You seemingly don't get it at all what Spring is about. You miss the fact that while there are tons of modules for Spring, these are all <i>optional</i> and you don't have to carry them around if you don't need them.<br /><br />In fact, given Spring's open source nature, it's easy to create your own spring module on top of whatever component you produce, and publish it via a public maven repo.<br /><br />In contrast, any JEE app server carries tons of JEE APIs around, with intricate under-the-hood dependencies between their implementations, making JEE servers huge, heavy beasts, in no way fit for deployment of modern services-based apps into lightweight docker containers or similar environments. Such services most often <i>do not</i> require the huge overhead imposed by JEE app servers, but can benefit greatly from the core IoC engine and the many available Spring modules.<br /><br />It may be true that by using Spring you buy into a single implementation - but just that of the core IoC container, not more. You have several alternatives available for various services, and you can easily wrap in your own implementation of anything, if none of the pre-existing solutions makes you happy. <br /><br />In contrast, if you build your app on JEE, you buy into one particular JEE implementation, just slightly incompatible with any other, so that moving from one app server to another is too painful to ever be done. There's no longer a mix and match of different API implementations from different vendors possible, at least not without huge headaches.<br /><br />(I've seen a documented example where somebody needed to disable all of JEE on JBoss and pull in alternative implementations - luckily his app was Spring-based, so this wasn't an issue - just because management decided to move to JBoss.)<br /><br />Finally, good luck porting your JEE apps to a newer, more modern, better scalable platform, such as vert.x ... - it has been at least attempted, I'm not aware of the outcome, but the process wasn't nice.<br />A_flj_https://www.blogger.com/profile/13123052099912825525noreply@blogger.comtag:blogger.com,1999:blog-7836204352369514180.post-81601420967631937942013-05-03T06:09:46.426+02:002013-05-03T06:09:46.426+02:00"The JAR HELL -- Once you get used to maven t..."The JAR HELL -- Once you get used to maven that solves this issue" - at best, this makes the redundant dependency management issue a little easier than it otherwise would be but it certainly does not eliminate the issue.<br /><br />"You should have turned Load Time Weaving off or told it not to scan your Domain Objects. And ran OpenJPA byte enhancer." - the point is that all that is extra work that doesn't need to be done in the first place.Reza Rahmanhttps://www.blogger.com/profile/15223266103098677143noreply@blogger.comtag:blogger.com,1999:blog-7836204352369514180.post-42853779883264362012013-05-03T06:02:59.225+02:002013-05-03T06:02:59.225+02:00"In my opinion CDI has one big flaw it does n..."In my opinion CDI has one big flaw it does not support Configuration" - assuming you are talking about something like Spring Config, multiple options already exists. For most cases, you may use CDI @Produces and/or CDI @Alternative. For more extensive cases, you can use CDI plugins like Seam 3 Config, Solder or DeltaSpike Core. Finally, you can have ultimate control by using the CDI portable extension SPI.Reza Rahmanhttps://www.blogger.com/profile/15223266103098677143noreply@blogger.comtag:blogger.com,1999:blog-7836204352369514180.post-68683145949391315072013-04-03T13:01:57.454+02:002013-04-03T13:01:57.454+02:00The JAR HELL -- Once you get used to maven that so...The JAR HELL -- Once you get used to maven that solves this issue<br /><br />Open JPA and Spring on Tomcat -- You should have turned Load Time Weaving off or told it not to scan your Domain Objects. And ran OpenJPA byte enhancer.featherweighthttps://www.blogger.com/profile/00984262329084618765noreply@blogger.comtag:blogger.com,1999:blog-7836204352369514180.post-52481641811782666232013-04-03T12:57:15.198+02:002013-04-03T12:57:15.198+02:00"And finally, CDI is much more powerful that ..."And finally, CDI is much more powerful that Spring Dependency Injection, due to its seamless scope handling, its event model and its portable extension mechanism."-- In my opinion CDI has one big flaw id does not support Configuration and makes apps tightly coupled. They may be simplier to develop to start. But if CDI had configuraton support that would be a plus. <br /><br />featherweighthttps://www.blogger.com/profile/00984262329084618765noreply@blogger.comtag:blogger.com,1999:blog-7836204352369514180.post-12962440756453124662012-08-10T05:21:22.875+02:002012-08-10T05:21:22.875+02:00Very interesting and well written.Very interesting and well written.Rahulhttps://www.blogger.com/profile/01970515790674651790noreply@blogger.comtag:blogger.com,1999:blog-7836204352369514180.post-60558236816348826512012-06-05T02:13:46.211+02:002012-06-05T02:13:46.211+02:00I agree with the premise of this article. The valu...I agree with the premise of this article. The value in Spring now lies in specific Spring projects like Spring Data and Spring Integration. But unfortunately these require core Spring and pretty much require YOU to use core Spring. That's not really a benefit anymore.Fashoomhttps://www.blogger.com/profile/02524721108737157998noreply@blogger.comtag:blogger.com,1999:blog-7836204352369514180.post-8599046642264054922012-05-03T19:11:15.163+02:002012-05-03T19:11:15.163+02:00@Luciano: You need to set an EntityManagerFactory ...@Luciano: You need to set an EntityManagerFactory on a <a href="http://static.springsource.org/spring/docs/3.1.x/javadoc-api/org/springframework/orm/jpa/JpaTransactionManager.html" rel="nofollow">JpaTransactionManager</a> - one and only one. <br /><br />For two or more persistence units or entity manager factories, you need a JtaTransactionManager and thus JTA - another Java EE component.<br /><br />Most people who drive a car don't want to get their hands dirty on the mechanics...Harald Wellmannhttps://www.blogger.com/profile/08039976160321882828noreply@blogger.comtag:blogger.com,1999:blog-7836204352369514180.post-12235714716834506792012-05-03T18:33:21.324+02:002012-05-03T18:33:21.324+02:00I'm not trying to defend Spring, but... There ...I'm not trying to defend Spring, but... <b>There is no Spring without Java EE:</b> Spring wants to be compatible to JavaEE on purpose. It even encourages you to use JEE standard annotations, like @Inject and @PersistenceContext. I see this as a good thing. Spring MVC may feel old.. that's really up to the project. Not all of them need an interface that is component oriented. <b>API vs. Implementation:</b> Yes, if you have a complex web application Spring will be there. It provides a lot of configuration and flexibility, but you know exactly what components your project use. <b>Vendor Lock-In:</b> You have this too in JEE world. WebLogic is different than jboss. You need to configure them differently. Even Jboss 7 is different that Jboss 6, which is also different that Jboss 5.1 <b>JAR & Configuration Hell:</b> Is it a hell? WIth more power comes more responsibility (and again, more flexibility). <b>Thread safety & Singleton Antipattern:</b> What you are writing is the difference between stateful and stateless. Also, the singleton bean in Spring is not the same as the Singleton pattern in Java, although they share the same name. Lookup the wikipedia definition for the singleton pattern.<b>Mixing scopes:</b> Since I never use the request scope or the prototype scope I cannot comment about this.<b>Transactions:</b> Spring does not implement JTA, but there are many existing implementations. " you need to configure a transaction manager per persistence unit". This is false, you use the same JTA transaction manager, unless you want your persistence units to use different transactions, which is a no-no. <b>LoadTime Weaving:</b> I never had problems with it, although I've never have used OpenJPA.<b>Summary:</b>I'm sure JEE 6 is excellent, but Spring is alive and awesome as always. They are both far from perfect as you say, but what is perfect? Play Framework?Lucianohttps://www.blogger.com/profile/13975148222856926741noreply@blogger.comtag:blogger.com,1999:blog-7836204352369514180.post-41034842675832327482012-05-02T13:29:10.262+02:002012-05-02T13:29:10.262+02:00Very eloquent and compelling post. Couldn't a...Very eloquent and compelling post. Couldn't agree more =)earcamhttps://www.blogger.com/profile/00745957800443401442noreply@blogger.com