Discussions

News: SpringFramework.com: Spring goes professional

  1. SpringFramework.com: Spring goes professional (114 messages)

    The Spring Framework is a very popular open source, pragmatic Java framework. Now there is a company behind the technology, as springframework.com has been announced.

    The founding members include Rod Johnson, Juergen Hoeller, and Bruce Tate. The group will be offering a variety of services around the technology.

    Press Release
    Interface21, a privately held company based in London, UK, and Austin, TX, announced its formation and availability as a source of expert-level professional services including consulting, training, and support focusing on the popular open-source Spring Framework and J2EE technologies.
    The company also announced the launch of www.springframework.com, which hosts information and resources on its commercial offerings.

    The founding partners are prominent and respected consultants recognized as pioneers in the "Lightweight J2EE" movement. They include Rod Johnson, founder and lead of the Spring Framework project, and author of the best-selling books "Expert One-on-One J2EE Design and Development" and "J2EE without EJB"; Juergen Hoeller, co-founder and co-lead of the Spring Framework project, and co-author of "J2EE without EJB"; core Spring developers and consultants Colin Sampaleanu and Keith Donald; and well known consultant, speaker, and best-selling author Bruce Tate.

    Interface21 aims to help clients achieve quality, cost-effective results by applying and sharing its expertise in leading edge J2EE architecture and agile methods. The company is the definitive source for Spring experience, and the principals and partners pool their expertise with a wide range of enabling technologies in the J2EE space. As a team they strive to deliver measurable value to clients by helping them implement end-to-end solutions that make sense for their business.

    The formation of Interface21 will further accelerate the already extensive enterprise adoption of Spring. Many companies will appreciate knowing that the Spring Framework is now backed by a business demonstrating its value in projects for large clients across a diverse set of industries.
     
    Revenues from commercial activities will fund ongoing enhancements to the Spring Framework, including development, documentation, support, and testing. A substantial portion will directly fund the time of Interface21's Director of Spring Development, Juergen Hoeller, to continue his level of commitment to the code base and user community.

    Spring is and will continue to remain fully open-source, free software, published under the Apache 2.0 license. Interface21 is committed to a partnership with the wider Spring community.
    Read the announcement: Interface21 To Provide Expert Spring Framework Consulting, Training, and Support

    Visit www.springframework.com

    Threaded Messages (114)

  2. All the best[ Go to top ]

    Best of luck to you guys! You deserve it. :) Keep up the good work.

    Yann
  3. All the best[ Go to top ]

    Best of luck to you guys! You deserve it. :) Keep up the good work.Yann
    Just wondering why JBoss gets harsh comments, and Spring gets congratulatory notes for following JBoss model?
  4. All the best[ Go to top ]

    Best of luck to you guys! You deserve it. :) Keep up the good work.Yann
    Just wondering why JBoss gets harsh comments, and Spring gets congratulatory notes for following JBoss model?
    'cos JBoss did it first.


    Anyway, congratulations to the Spring guys - IMO, this is the only model that can really support a popular open source framework in the long term, so it's a natural progression (I've just been through that progression myself).
  5. All the best[ Go to top ]

    Thanks Gavin--much appreciated. Yes, there's no question that a framework of the sophistication of Hibernate or Spring needs a viable economic model behind it. That also benefits all the users who continue to use the framework without purchasing any services...
  6. ...Yes, there's no question that a framework of the sophistication of Hibernate or Spring needs a viable economic model behind it....
    And again Rod gives no credit to JBoss…
    Probably because JBoss is a direct competitor and from technical perspective there are no reasons (almost) to use Spring with JBoss because Spring is a just wrapper for real frameworks with questionable practice of non-checked exceptions and JBoss does all the heavy lifting itself: JMS, EJB, dependencies, etc.

    PS: No, I am not affiliated with JBoss. Just trying to separate technical issues from personal and business ones :)
  7. Konstantin

    I'm quite happy to credit JBoss for pioneering a commercially supported model in the Java/J2EE space. I've never been one of the critics of their basic business model. But to be fair, I think that the credits should also be spread wider to companies like Red Hat, who have demonstrated that such a model can work.

    I didn't mean to exclude JBoss in my post above: as I was replying to Gavin and this thread is about Interface21 and Spring I named only Hibernate and Spring.

    As for checked exceptions, I think you and I we're going to continue to disagree on that one :-)

    Rgds
    Rod
  8. RH[ Go to top ]

    Rod, I don't think Red Hat's "take other people's software, stick it on a CD, and sell it for money" is really quite the same thing as what jboss.com or spring.com is doing - OK, I'm regurgitating company line now, but I think there is a *real* difference there.

    Oh, by the way, you are now a target for all the irrational hataz, keep your head up, it's just noise. :-)
  9. RH[ Go to top ]

    Rod, I don't think Red Hat's "take other people's software, stick it on a CD, and sell it for money" is really quite the same thing as what jboss.com or spring.com is doing - OK, I'm regurgitating company line now, but I think there is a *real* difference there.Oh, by the way, you are now a target for all the irrational hataz, keep your head up, it's just noise. :-)
    To be fair to RedHat, they actually spend _a lot_ of money and resources on directly and indirectly funding development of Linux, both the core kernel and higher level APIs and tools.

    Regards,
    Colin
  10. RH[ Go to top ]

    Rod, I don't think Red Hat's "take other people's software, stick it on a CD, and sell it for money"
    Irrational hataz indeed, Gavin. You should really, and I really ashamed. And remember, when you're making harsh bullshit affirmations you don't get to smile oh-so-allknowingly in the next paragraph.

    As some else pointed out, Redhat does work on Linux and on a lot of the stuff that's on that CD.
    From where I stand Redhat's contributions to Linux are a lot larger in terms of code size, quality and relevancy than JBoss + Hibernate to the Java community.
    Things that Redhat put into the kernel and glibc alone is used by most if not all the Linux servers out there, and not all of those run Java and not all of those who do run JBoss or Hibernate.

    Now how's that for twisted logic ?

    You know you'd best do what you do and not make an ass of yourself like this. I personally loathe hibernate and what it stands for, but that doesn't mean I can just rant mindlessly on TSS about it.
    Check your facts before opening your mouth in public, especially since the remarks about redhat were uncalled for.
  11. IDEA IDE?[ Go to top ]

    Rod, what about Spring support in IntelliJ IDEA? I would say, community would appreciate this ;)
  12. Great![ Go to top ]

    Getting Hibernate (and now Spring) into the organization is getting easier and easier every week... thanks, and good luck! I'm already signed up for the Central Ohio Software Symposium and am looking forward to Bruce's sessions this weekend on Spring, Hibernate, EJB, etc.
  13. Konstantin:
    And again Rod gives no credit to JBossÂ…
    Probably because JBoss is a direct competitor and from technical perspective there are no reasons (almost) to use Spring with JBoss because Spring is a just wrapper for real frameworks with questionable practice of non-checked exceptions and JBoss does all the heavy lifting itself: JMS, EJB, dependencies, etc.
    JBoss was definitely not the first open source project to "go commercial" yet stay open source. They just happen to be a very well known (and seemingly successful) example of it in the Java/J2EE space. (FWIW I don't remember ever hearing the phase "professional open source" before JBoss.)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  14. JBoss was definitely not the first open source project to "go commercial" yet stay open source. They just happen to be a very well known (and seemingly successful)
    Of course.

    I just think that Rod should be more grateful to J2EE stack and vendors, and JBoss in particular for pioneering/promoting “Professional Open Source” in Java field.

    From www.springframework.com:
    #"Orthodox" approaches to J2EE development are slow, unproductive and lead to excessive unmaintainable code, and poor performance. We can change that, and save you money.#

    That smells like FUD because bad design and unskilled developers are not particular to J2EE and the same causes will compromise Spring and other useful frameworks.

    For now Spring enjoys success largely because most capable developers have adopted it as a collection of certain design practices, we are yet to see what will happen when crowd of code monkeys will be forced to use Spring :).

    I am not trying to say that Spring does make sense, it probably does, as well as numerous alternatives: JBoss on its own, Pico, Pico + AOP, good old code generation (XDoclet etc.), bare AOP, etc.

    C’mmon: Spring is not a silver bullet and lets not positioning Spring as such.
  15. Please give credits where due[ Go to top ]

    Spring is not a silver bullet and lets not positioning Spring as such.
    True....Spring is the golden bullet!
  16. Please give credits where due[ Go to top ]

    Spring is the golden bullet!
    Rather a “golden hammer” and everything else is a nail :)
  17. Please give credits where due[ Go to top ]

    Spring is the golden bullet!
    Rather a “golden hammer” and everything else is a nail :)
    U dont seem too pleased with Spring being around. I am curious as to why?
    do u know of anything better than spring.
  18. Please give credits where due[ Go to top ]

    Spring is the golden bullet!
    Rather a “golden hammer” and everything else is a nail :)
    U dont seem too pleased with Spring being around. I am curious as to why?do u know of anything better than spring.
    I have nothing against Spring being around. I am not happy with hype around Spring, and Spring positioning as “magic” J2EE solution…
    IMO, Spring is just too ambitious for no apparent (technical) reasons…
  19. Stop Flame ![ Go to top ]

    Konstantin, looks like you have some kind of personal problems.

    1. Nobody positions Spring as a universal cure. Stop blaming people for what they did not do.
    2. That excerpt from Spring web site is not about bad design and unskilled developers who are using EJBs. It is about bad design and unskilled developers who are IMPLEMENTING EJB Servers and specifications.
    we are yet to see what will happen when crowd of code monkeys will be forced to use Spring :).
    You are right. We are yet to see. So stop winning until we see it happens.

    2 Rod Johnson
    Congratulations! and good luck with your new company.

    BTW, I checked recently online documentation and was impressed by new additions, especially Remoting and AOP sections. Great job! Thank you!
  20. Why Spring rather than JBoss?[ Go to top ]

    I can give you at least one reason why there is so much hype: as someone who has developed projects in JBoss and Spring / Hibernate, the projects developed in Spring / Hibernate are quicker to develop and easier to test, modify and maintain, by a significant margin. Sure, it's no silver bullet, but I'd say it's definitely the best solution out there for medium-sized projects.
  21. Only medium-sized?[ Go to top ]

    Sure, it's no silver bullet, but I'd say it's definitely the best solution out there for medium-sized projects.
    Only medium-sized? Is there anecdotal evidence that it can't support larger-sized projects? Just curious.....
  22. duh[ Go to top ]

    er... I think he said 'middle-sized' because that is what HE experienced, isn't it?
  23. Only medium-sized?[ Go to top ]

    Only medium-sized? Is there anecdotal evidence that it can't support larger-sized projects? Just curious.....
    Large in what dimension? LOC? Load? Complexity? We are using Spring in production on a website with >10M page hits/month. We also have a 3 man year Spring-based project that is about to go live. We have seen no indication of any ceiling in what Spring can handle.

    Neither of these two is particularly huge in the absolute sense, but if there were some fundamental problems with Spring scaling to larger projects we would have found them. There are none.

     - Peter
  24. JBoss vs Spring

    JBoss, Old Legacy Elephant EJB server.
    Spring, revolutionary new design, minimalistisk - fast

    JBoss, Managenment Hi-Jack the project like Animal Farm
    Spring, The original inventors reap the rewards and has control of the company.

    JBoss, Ugly LGPL license. contains non-redistributable, non-free code.
    Spring, Apache licensed, free without any restrictions

    JBoss, management tones down contributions from "Star" team members
    Spring, "All star" team around the product from the beginning.

    JBoss, Java only
    Spring, both Java and C#!

    JBoss, poor documentation that cost money too
    Spring, excellent free documentation and "Get started" tutorial.

    JBoss, "One size fit all"
    Spring, every project is customized

    In short,
    JBoss, example of the greediness of man
    Spring, a fairy tale.

    Regards
    Rolf Tollerud
  25. IMO, Spring is just too ambitious for no apparent (technical) reasons…
    Again. I've it when people who don't like/don't understand/don't use always manage to attack a solution they are not fond of and by inference *everyone* else using it is stupid, gullible, or just foolish.

    You don't find a technical reason to use Spring. Don't use it and go away. The rest of us seem to find value and *don't* care about your opinion.
  26. I've it when people who don't like/don't understand/don't use always manage to attack a solution they are not fond of and by inference *everyone* else using it is stupid, gullible, or just foolish.You don't find a technical reason to use Spring. Don't use it and go away. The rest of us seem to find value and *don't* care about your opinion.
    LOL. This is honest expression of ignorance which I read as: Everybody who does not like my favorite toy is stupid, gullible, or just foolish.
    I offer to appoint Mr. McCoy to the “Grand Censor of TSS” with unlimited rights to decide which posts should not appear and who should be banned from posting :)
    On the serious note: similar to Mr. McCoy's attitude and hostility towards different opinions are things, which needs to be avoided for the success of an enterprise. Congratulations are pleasant but useless as a source of ideas...
  27. If you don't want to use it, don't. But so far, the only one he seem to understand the point it you. At least others see the point, but don't want to use it for whatever reason.

    You appear to be the only person who both doesn't seem to get the software and is uninterested in understanding it. If that is the case, why not spend your time in a more productive pursuit? Or take some time to understand the software and critique based on something a bit thicker than "I don't see the point."?
  28. no apparent "technical" reasons? how much have you used it?
    do you really like extra complexity when you really don't need it?

    Spring is not trying to be the "magic" solution... just a logical one for people fed up with the hype that is all around commercial J2ee. All the commercial vendors are actually still trying to sell complex solutions and convincing people that they really need things to be complex.

    RE: Red Hat did go public + have given a lot back to the linux community. sure you can knock any company, but may all the good "Professional Open Source" help each other along (in some way or another)... Red Hat, JBoss + now Spring...

    each of these success stories helps bring better overall solutions and keeps the big companies (a little more) honest.


    -jp

    good luck to the spring team, and you've done a great job so far!!!
  29. Please give credits where due[ Go to top ]

    Spring is the golden bullet!
    Rather a “golden hammer” and everything else is a nail :)
    U dont seem too pleased with Spring being around. I am curious as to why?do u know of anything better than spring.
    I have nothing against Spring being around. I am not happy with hype around Spring, and Spring positioning as “magic” J2EE solution…IMO, Spring is just too ambitious for no apparent (technical) reasons…
    Please give me a list of technical reasons why u feel that Spring is not a great framework. Where does it fall short? What do u feel is missing from spring that it cannot be called ambitious. And if not Spring, what is ur alternative to doing a J2EE project in a manner as efficient as Spring. Lets hear some technical talk from you.
  30. Technical reasons not to use swing[ Go to top ]

    Please give me a list of technical reasons why u feel that Spring is not a great framework. Where does it fall short? What do u feel is missing from spring that it cannot be called ambitious. And if not Spring, what is ur alternative to doing a J2EE project in a manner as efficient as Spring. Lets hear some technical talk from you.
    I would normally mark the whole thread as noisy anyway, but I am happy to give you a "technical reason" - not why not to use is, but why I think there is far too much hype surrounding it. Where it is good it is trivial - sorry Rod, Colin etc. you did not reinvent the wheel, nor derive a new abstraction :-). It is a centralised, instance and interface based configuration framework. I think it is interesting that they managed to market it as some sort of cure for all ills but I think it is about as much so as, say, log4j.

    Now, the Spring guys are quite clever, they understood that someone would sooner or later point out that the emperor is quite naked - or they felt uneasy in the first place. So they added stuff, like the web framework (sigh, again a dispatcher servlet!), they wired an AOP framework around it, because they noted that, well, people might want transaction, advanced, declarative security etc. Soon they will realize that they want to ship a library of "Aspects" so that the individual developer need not bother with it any more (to some extent this is done with metadata and autoproxying already). They added there own DAO support. They added stuff to wrap JDBC. They added a timer. They added support for "traditional" J2EE components like EJBs and JMS.

    So in the end we are looking at a complex framework in its own right, getting more complex all the time. Dependencies will sooner or later spring(!) up all over the place, with regard to your cross application libraries. Consider that spring is dependent on 20 or so libraries in its own right as will be your EJB container (if you still have one) as is your actual ORM tools ....

    Now, the main driver that I can see to use spring is that it is fun to use and that you might be faster in building certain things (and thus enjoy it more) - oh and by the way you will always be faster to build things with something you understand thoroughly and that at the same time gives you powerful tools - friends of mine are incredibly fast building things with CLISP.

    I don't buy the stuff about "increased code quality" because, frankly I think there are no usable metrics available for a combination of sourcecode and configuration, let alone for implicit dependencies introduced by AOP and "IoC" in the first place. One of the real fun things is that when people use it they are fairly unaware that they are subscribing to a highly proprietary framework. To me this is the ultimate proof that the original developer acceptance of J2EE was not because of "standards" as a lot of people claim but rather because of "cool stuff".
  31. Technical reasons not to use swing[ Go to top ]

    Karl

    I'm flattered that you find us "quite clever" . However, it's important to correct some factual errors: "So they added stuff, like the web framework [and data access etc]": in fact that was part of Spring from the beginning (indeed, the Interface21 framework that preceded Spring), as was the DAO abstraction and JDBC support. In fact, nearly everything that you assert we added to "hide the emperor's new clothes" was there from day one, so your attempt to characterize Spring's evolution is completely wrong.

    Furthemore, it's simply not true that I/we promote Spring as the "cure for all ills". In J2EE without EJB for example, we do not claim that Spring is the solution to all problems. Nor do I/we claim so on this site or elsewhere. I have always made claims based on actual experience.
    So in the end we are looking at a complex framework in its own right, getting more complex all the time. Dependencies will sooner or later spring(!) up all over the place
    I guess I don't have your crystal ball, but the modular nature of Spring means that dependencies won't spring up "all over the place". E.g. the core IoC container doesn't depend on the web framework, AOP or transaction capability etc. It didn't with 1.0, it won't with 1.1, it won't with 1.2 etc.

    Yes, Spring integrates with lots of third party software. That's good, because it gives Spring users choice. E.g. do they want to use ORM like Hibernate, a JDO implementation or (hopefully soon) TopLINK, or do they want a more relational solution with JDBC or iBATIS? The core framework provides a consistent abstraction that works with all those technologies, but is independent of them. Only the specific packages depend on the third party library.

    The core of Spring is dependent on precisely one JAR: commons-logging.jar. You only need the 20 odd to build it, not to use it. For example, if you use Spring + Hibernate in a typical Spring/Hibernate app, you don't need a single JAR besides spring.jar to support Spring: Hibernate's dependencies are all (and more than) Spring needs.
    One of the real fun things is that when people use it they are fairly unaware that they are subscribing to a highly proprietary framework
    As has often been pointed out, Spring aims to keep the framework out of your code. Thus it's possible to reuse the majority of code in Spring applications in another environment if users wish--at least with configuration is concerned. There's more of a dependency where the class library elements of Spring are involved, such as the DAO abstraction, but then there's no convincing alternative to Spring in that area either, so the alternative is to use the persistence API directly, which is a more constraining dependency. (It also typically results in more code, as Spring nicely abstracts things like ThreadLocal sessions that you'd otherwise probably need to do in-house.)

    As for a "combination of sourcecode and configuration": isn't that what J2EE itself has always had? ejb-jar.xml + [vendor]-ejb-jar.xml is typically far more complex than a Spring configuration, for example.

    Rgds
    Rod
  32. Technical reasons not to use swing[ Go to top ]

    Rod,

    I didn't mean to accuse you of marketing the cure for all ills. However I've met a couple of people who believe that Spring is just that. (and I've met others that think the same about AspectJ, JBoss etc. ) And I generally find that a dangerous attitude that gets me sort of wound up. Thanks for setting my misconception about the spring history right.
    As has often been pointed out, Spring aims to keep the framework out of your code. Thus it's possible to reuse the majority of code in Spring applications in another environment if users wish--at least with configuration is concerned. There's more of a dependency where the class library elements of Spring are involved, such as the DAO abstraction, but then there's no convincing alternative to Spring in that area either, so the alternative is to use the persistence API directly, which is a more constraining dependency. (It also typically results in more code, as Spring nicely abstracts things like ThreadLocal sessions that you'd otherwise probably need to do in-house.)
    Well as soon as you get into using AOP framework or indeed your API you are dependent and it will not be easy to untangle the application and reassemble it using something else.

    I do not see this as much of problem, as long as people are aware this is the case. Or to put it differently: I am convinced that maintainability and features come at a price and one should get round to acknoledge it. Probably has something to do with thermodynamics...
    As for a "combination of sourcecode and configuration": isn't that what J2EE itself has always had? ejb-jar.xml + [vendor]-ejb-jar.xml is typically far more complex than a Spring configuration, for example.RgdsRod
    Oh absolutely. But what happens as you start doing more fancy things in spring.
  33. Aopalliance[ Go to top ]

    Well as soon as you get into using AOP framework or indeed your API you are dependent and it will not be easy to untangle the application and reassemble it using something else.
    http://aopalliance.sourceforge.net/
  34. So in the end we are looking at a complex framework in its own right, getting more complex all the time. Dependencies will sooner or later spring(!) up all over the place

    I guess I don't have your crystal ball..
    Couldn't sum it up better than that :)
  35. <comment>So in the end we are looking at a complex framework in its own right, getting more complex all the time. Dependencies will sooner or later spring(!) up all over the place, with regard to your cross application libraries. Consider that spring is dependent on 20 or so libraries in its own right as will be your EJB container (if you still have one) as is your actual ORM tools .... </comment>

    Here is how I see it. Complexity create works and provide bases for technology infrastructure that is hard to test and maintain. Now proponents of complexity whose business is based on misdirected efforts , they find them self in uneasy spot when they see real efforts by team of people who are trying to create transparent and simple infrastructure which is easy to test and maintain in long term. Ejb is another attempt to increase this complexity by creating another layer of vendor specific architecture. Spring does provide alternate to this by following OO principal and design. It is a least dependent and intrusive framework for creating loosely coupled and transparent design which is mainly depend upon one jar file commons-logging.jar as mentioned earlier in this thread. Where EJB provide totally container based vendor specific complex solution.

    Rod and his team has done a great job by providing suitable infrastructure plate form and marketing for framework like spring to bring it to masses and Rod deserves a lot of credit for that. Thanks Rod for your efforts.
  36. I spent the last night reading through the Spring source and docs yet again to find out what the "hype" is about. And spent the rest of the night playing with it (yet again) and I am still lost - for example I am struggling to understand why using Spring's web framework gives me better turnaround than any of the other stuff I used (I like the URL mapping though :-)). I do acknoledge it gives superior out of container testing though.
    Here is how I see it. Complexity create works and provide bases for technology infrastructure that is hard to test and maintain. Now proponents of complexity whose business is based on misdirected efforts , they find them self in uneasy spot when they see real efforts by team of people who are trying to create transparent and simple infrastructure which is easy to test and maintain in long term.


    Oh no I am all for easiness. On top of that I am all for simplicity. But using Spring I am lost where it stems from. Because you have a single configuration tool? Hmm, you do have that with JNDI as well. Because you have a nice and easy testing? Granted it gives you that. Because of the goodies that come outside of the core and context packages? They are nice but they push you in a certain direction (velocity, hibernate, for example), which is not necessarily bad at all but combining spring with hibernate with velocity and we approaching square one of high complexity again.
    Ejb is another attempt to increase this complexity by creating another layer of vendor specific architecture.
    Is it? I think EJB, JNDI, JMS is pretty Vendor agnostic if you want it to. And it does things that a lightweight framework does not yet do for you. The underlying implementation is vendor specific of course and will feature things that you may or may not use.

    Anyway, in the end a lot of applications will need reliable messaging (JMS), some will need remote distributed transactions on business objects (Stateless Session Beans) or they may need to access web services and on it goes. The "providers" of these services will likely be "vendor specific" or in case of open source "provider specific" in its own right. So you'll end up with a zoo of tools and providers where you are the one who needs to manage how these things work together and how to introduce new releases, instead of one big bloated product. I don't really know what is better. I do however know that it is still a major challenge of integrating certain database drivers with certain JMS providers. And you know what: This is only fun the first time you do it!
    Oh and maintaining such fine grained dependencies in production environments is even more of a challenge.
    Spring does provide alternate to this by following OO principal and design.
    Now when all of my classes must be "open" (no apparent encapsulation) to allow "push configuration" and in fact must "advertise" what they use for reaching a particular goal (like advertising setConnectionPool or something the like) I would argue this is not really object oriented design (at least not along the usual Java/C++/Smalltalk lines). On the other hand there is surely no silver bullet, since the alternative would be to reach the same effect using Constructors (major drawbacks in its own right) or use AOP and annotation where the complexity easily sneaks in because noone of the vanilla programmers understands what is going on any more :-).
    It is a least dependent and intrusive framework for creating loosely coupled and transparent design which is mainly depend upon one jar file commons-logging.jar as mentioned earlier in this thread. Where EJB provide totally container based vendor specific complex solution.
    As far as core spring is concerned, there is in fact very little dependency. There is more in the "support" packages and in the end I would assume this is what people will call "the spring framework". I do not see why EJB provide totally vendor specific solutions. They do if you use it in a vendor specific way, but you don't need to. What gets vendor specific is more along the lines of "eBusiness" or "integration" frameworks that run on top of it.
    Rod and his team has done a great job by providing suitable infrastructure plate form and marketing for framework like spring to bring it to masses and Rod deserves a lot of credit for that. Thanks Rod for your efforts.
    Absolutely, I do think it is a nice and clever effort.
  37. Technical reasons not to use swing[ Go to top ]

    Now when all of my classes must be "open" (no apparent encapsulation) to allow "push configuration" and in fact must "advertise" what they use for reaching a particular goal (like advertising setConnectionPool or something the like) I would argue this is not really object oriented design (at least not along the usual Java/C++/Smalltalk lines).
    You can preserve encapsulation easily by not having the setter methods on the interface callers code against. Only the implementation classes are "open", and the implementing classes are hidden from the caller's view. That represents greater encapsulation than with "pull" configuration, where the dependencies are typically harder to supply and not equally self-documenting.

    Of course Spring also provides sophisticated support for Constructor Injection, for users who prefer that approach.
  38. Technical reasons not to use swing[ Go to top ]

    You can preserve encapsulation easily by not having the setter methods on the interface callers code against. Only the implementation classes are "open", and the implementing classes are hidden from the caller's view. That represents greater encapsulation than with "pull" configuration, where the dependencies are typically harder to supply and not equally self-documenting.
    Fair enough, one might argue that the implementation class has the dependency internally (in the source code) anyway, so it may as well expose it - not sure if that is the purest of OO thinking though :-).

    I am not sure that the encapsulation is any greater or lower than with pulling all configuration from, say JNDI. I'd argue it is pretty much the same, since there is no way of knowing which of the setters/getters/attributes on the implementation class are actually required by the implementation runtime and in what combination, other than documentation or annotation which in turn is pretty much the same as with announcing the required JNDI names. The advantage may be that completeness of configuration and correct typing can be checked on initialization rather on usage....
  39. Technical reasons not to use swing[ Go to top ]

    Karl
    Fair enough, one might argue that the implementation class has the dependency internally (in the source code) anyway, so it may as well expose it - not sure if that is the purest of OO thinking though :-).
    Not exposing it is far preferable, IMO.
    I am not sure that the encapsulation is any greater or lower than with pulling all configuration from, say JNDI.
    One important difference is that with JNDI you're dependent not only on what objects/config you need (which is unavoidable), but also where they're obtained from. I guess this is not a pure issue of encapsulation, but with JNDI the object is placing more demands on its environment.

    Also, JNDI is particularly messy for getting simple properties from: with Dependency Injection the container can hide type casting, lookups etc.

    Rgds
    Rod
  40. Technical reasons not to use swing[ Go to top ]

    Not exposing it is far preferable, IMO.
    Now what? Just two posts above you argued to expose them in the implementation to be set by spring :-).
    I am not sure that the encapsulation is any greater or lower than with pulling all configuration from, say JNDI.
    One important difference is that with JNDI you're dependent not only on what objects/config you need (which is unavoidable), but also where they're obtained from.I don't really think there is a difference. Anything must be bootstrapped somehow, so the constrain would be that they would be obtained from any JNDI provider while with the spring approach the implicit assumption is that the configuration will be supplied by any push configurator/IoC framework. You might argue that you put constrains on the JNDI of course, for example to avoid naming conflicts.
     I guess this is not a pure issue of encapsulation, but with JNDI the object is placing more demands on its environment. Also, JNDI is particularly messy for getting simple properties from: with Dependency Injection the container can hide type casting, lookups etc.RgdsRod
    Ah well, but that is the container framework. I would assume writing a JNDI framework that does the same for you is easy, even though you probably would not get away with casting, along the lines of

    JDBCPool pool = (JDBCPool)JNDIHelper.getHelper().typeSafeLookup("mypool",JDBCPool.class);
  41. Technical reasons not to use swing[ Go to top ]

    Now what? Just two posts above you argued to expose them in the implementation to be set by spring :-).
    I was talking about the caller's view, not the object itself. The object's dependencies are concealed from the caller by the use of an interface.
    JDBCPool pool = (JDBCPool)JNDIHelper.getHelper().typeSafeLookup("mypool",JDBCPool.class);
    That's better than a setter or constructor arg?

    With a DI approach you can still easily source the config from JNDI if you want to (using a lookup with your factory or the Spring JndiObjectFactory or the like). How do you test your JNDI implementation from a JNDI test without fairly complex config? What if you want to add additional behaviour around your pool--with Spring you can do that easily through adding an interceptor?

    I used to use a similar helper approach to what you suggest--of course it's far better than hardcoding JNDI lookups everywhere. But since I moved to a DI approach back in 2000, I would never want to go back.
  42. Technical reasons not to use swing[ Go to top ]

    I was talking about the caller's view, not the object itself. The object's dependencies are concealed from the caller by the use of an interface.
    Yup, that's what I understood. So the actual implementation does not really follow object oriented principles like encapsulation etc :-). Which, as I stated is not much of a problem, as long as you are aware that the objects are written to be used in a certain scenario....ah, now that makes my head spin since the original advocacy was that spring will allow you to write objects that are agnostic in how they are used while we now arrive at objects that are - well - sort of expecting that some push configurator/IoC framework is supplying them with what they need. Interesting twist.
    JDBCPool pool = (JDBCPool)JNDIHelper.getHelper().typeSafeLookup("mypool",JDBCPool.class);
    That's better than a setter or constructor arg?Ah, but no, I would argue it is about as simple. Apart from the easy testing - you do have a point there, even though one could argue (I am not) that setting up the bean factory for tests is pretty much similar than setting up any JNDI environment with test instances...

    Anyway, I really enjoyed the discussion, gave me some motivation of digging into Spring again :-). And if I get to do a project outside the usual corporate constraints that I face more often than not, I might actually use it.

    Cheers, Karl
  43. Technical reasons not to use swing[ Go to top ]

    Yup, that's what I understood. So the actual implementation does not really follow object oriented principles like encapsulation etc :-).
    All implementation strategies are going to be dependent on collaborators/config parameters unless they're trivial. So there is no loss of encapsulation vs any realistic alternative.
    Apart from the easy testing - you do have a point there, even though one could argue (I am not) that setting up the bean factory for tests is pretty much similar than setting up any JNDI environment with test instances...
    Setting up the factory is typically a lot simpler, in my experience. However, I only use a factory for integration testing. In true unit testing I populate the dependencies through constructor arguments or setting bean properties in plain JUnit tests that don't require the Spring container. E.g. I can easily use mock objects.

    Good discussion...

    R
  44. I think you miss an important point:
    What Spring provides you is the liberty to make choices among different
    implementation choices.
    Can you claim that it is possible with using plain EJB, JMS, etc.,
  45. I spent the last night reading through the Spring source and docs yet again to find out what the "hype" is about. And spent the rest of the night playing with it (yet again) and I am still lost - for example I am struggling to understand why using Spring's web framework gives me better turnaround than any of the other stuff I used (I like the URL mapping though :-)).
    One small fact, that I just found out yesterday, playing with PetClinic app. There is an HTML FORM, you submit it, it is processed on the server, then server renders the result. It does this using RedirectView class and a Model object (essentially just a HashMap), which does boring stuff for you:
    * creates redirection request
    * pulls Model properties and stuffs them into the request query parameters
    * after redirection completed, pulls current data from the persistent storage so it can be shown
    * if you click Back button in the browser, it shows HTML FORM again, but now it contains data which was just entered and stored, not the stale data. Exactly what I wanted!
    I did the same kind of things with Struts and it took some programming and I had to handle data in the session in between of requests. In Spring it is done so effortlessly, that they do not even advertize RedirectView class as a solution for after-POST response handling. Which they should do, by the way, I think this is one of the strong selling points. It is just one area which was particularly interesting for me, but I am sure there are others.
  46. Technical reasons to use spring[ Go to top ]

    I spent the last night reading through the Spring source and docs yet again to find out what the "hype" is about. And spent the rest of the night playing with it (yet again)
    Get a life and spend your time and energy in some other productive pursuit.
    Oh no I am all for easiness. On top of that I am all for simplicity
    I know but I just don't see your point when you try to promote EJB use in same context.
    Ejb is another attempt to increase this complexity by
    creating another layer of vendor specific architecture.

    Is it? I think EJB, JNDI, JMS is pretty Vendor agnostic if you want
    it to. And it does things that a lightweight framework does not yet
    do for you. The underlying implementation is vendor specific of course
     and will feature things that you may or may not use.
    Is that so ? EJB specs make EJB to heavily dependent on vendor specefic containers and this makes EJB based architecture hard to test and maintain. EJB comes with all string attached in terms of vendor specific solution.. This makes ejb code hard to test , re-engineer, reuse in different context and refactor.

    The need of spring like framework arise from failed orthodox j2ee complex architectural approaches. Spring framework clearly aims to apply best practices like programming to interface rather than classes to create loosely coupled and transparent infrastructure which make testing quite easier. Since it is designed around interfaces using proper abstraction, it is also quite easy to extend and customize. Overall Spring framework address areas not well served by any other framework exist in any shape or form as far as I know based on my experience. It does provide much liberal, better, transparent and maintainable infrastructure mean to succeed in long term. How often anyone come across a framework and say that this is what I have been looking all along and that’s how things should be done. Spring framework gives me that exact feeling. It’s about really believing in something and apply it to it’s full potential to experience the difference yourself.
  47. Technical reasons not to use swing
    Are you sure you're in the right thread ? ;-))))
  48. Karl,

    I couldn't agree more. Although I am using spring (the core and cool BeanFactory), i must admit, that it is mostly hype without cause. As far as i can see, there is one concept, namely IoC, which buys you mainly one thing, namely better and easier testing, that's all, folks. The rest is proprietary and debatable, or at best old concepts and frameworks in new clothes.
    Apart from that, it is an enrichment in the OpenSource landscape, so I am glad to see it.

    Just my 2 cents
  49. I've never really used Spring but am really considering it. To me EJBs have two main advantages : caching and clustering (with support for load balancing and fail-over as consequences of this). My main concern about Spring is, if you use it with Hibernate as an EJB replacement, will it work in a clustered environment ? Caching would be provided by Hibernate, but what about clustering ?
  50. Spring and clustering[ Go to top ]

    AFAIK, you have to rely on your web / app server to provide clustering, or use something like Tangosol Coherence.

    Spring is not supposed to replace your app server, it's supposed to let you write dependency-free pure object oriented code which can then be plugged in to any app server.
  51. Spring in a cluster[ Go to top ]

    What are the features provided by EJB that make you say it's "cluster ready" ? Saying that EJB is cluster ready might be true, but without specific needs it's just marketing talk.

    Imho if you have clustered data cache and if needed state replication (may it be sfsb or http sessions) than your architecture is cluster ready, unless you have specific needs.

    If you use spring without ejb you do not cluster spearately on servlet and ejb container, you cluster colocated architectures (the whole layer stack gets deployed on single server). It can be used like that without any problem.

    Plus you should not forget that you can use spring + ejb if you need to use some ejb specific features (apart from mdb, distributed identity propagation, and easy distribution / distributed transaction, I don't see which feature needs impose the use of EJB)
  52. Spring in a cluster[ Go to top ]

    You're right. I was misstaken about the fact EJBs are clustered. Let me be clear then : they can be clustered if the server supports it and they're called through their remote interface. So my question should habe been better formulated : will Spring applications be transparently clustered if run in a cluster of servers that support it (and not using EJBs in the Spring layers) ? Meaning that, if I deploy a Spring application on two computers in a cluster and one of them crash, my users will be automatically redirected to the other. I thought it was ok, but I just wanted to be sure there is nothing in the framework that could prevent clustering to work (things like singletons that would have to be trully unique within the application). Thanks for your reply.
  53. < My main concern about Spring is, if you use it with Hibernate as an EJB replacement, will it work in a clustered environment ? Caching would be provided by Hibernate, but what about clustering ? >

    You would use Hibernate and OSCache(or other cluster supported caching pacakages) , for clustering with hibernate. OSCache will broadcast via JMS
  54. [Spring] is mostly hype without cause. As far as i can see, there is one concept, namely IoC, which buys you mainly one thing, namely better and easier testing, that's all, folks.
    I find this type of statement bemusing. Have you really used the Spring bean factory (or perhaps Pico)? In earnest? On a real project? With a team who are not necessarily all guru-level developers? Because I have, and I am seeing significantly better code quality, with less hardcoded behaviour, more coherent classes which are loosely coupled and have well-defined responsibilities, more reuse, and improved consistency (and not just in configuration although that alone is a godsend).

    You are not alone in pointing out that IoC/DI is a simple and almost trivial idea; Gavin King recently said the same in another TSS thread. You are right. But stating that its effects are simple and trivial, that it "buys you mainly one thing", is a complete non sequitur. My own experience is that in the real world, with real teams, its impact goes far beyond what you would naively expect.

    There's of course much more to Spring, such as declarative transactions, pooling, JNDI support, Quartz integration etc. And that is before you start introducing proprietary code: if you're happy for your code to depend on Spring then there is also JDBC and DAO support, custom AOP aspects, the excellent MVC framework and so on. My team has used all of these in anger, on real projects. They bring real benefit. And do not let the sheer size of Spring put you off using it any more than the number of books in the library puts you off reading: Spring's component parts are quite independent and support an "a la carte" approach to using the framework.

     - Peter
  55. Sorry, I missed the technical bit[ Go to top ]

    I think the only technical comment you make is that Spring has loads of dependencies, which is incorrect - it has maybe one or two (of course it's a pretty fat jar in its own right, but that's fine by me, so long as it's just the one).

    On the non-technical front, you say it isn't any faster over the project cycle using Spring than any other framework you understand - but that's just not true, and having developed in a bunch of different technologies, I can tell you that for a whole range of applications (although of course not all) it definitely is. Remember it's not just developing apps that's important here (because let's face it you can easily knock up spaghetti PHP code much quicker than an app that uses Spring, and sometimes that's appropriate); it's maintaing, testing, debugging, adding features. When you consider all this stuff, Spring has a bunch of advantages over competing technologies.

    As for metrics for increased code quality, try "number of classes" for EJB, or "number of includes". More qualitatively, you can easily get a feel for how often you have to compromise on object-orientation.

    And no, name-dropping CLISP doesn't make you look cool.
  56. Jars[ Go to top ]

    Spring also ships a number of more fine-grained JARS as well as spring.jar, which obviously includes more features than you'll use in any one app. However, it's usually simpler to just put one JAR into your app, so there's little reason to exclude what you don't need, although you can if you want--for example, if you want to write an applet, as some users do, that uses only the IoC container.
  57. Sorry, I missed the technical bit[ Go to top ]

    I think the only technical comment you make is that Spring has loads of dependencies, which is incorrect - it has maybe one or two (of course it's a pretty fat jar in its own right, but that's fine by me, so long as it's just the one).
    Well, opening what they ship there is a lot of stuff in there from - for example - apache commons, velocity, altogether about 20 libraries. That introduces a major dependency on a particular version of these libraries or does it? Or they are not dependencies at all but are shipped to support examples, which would be fine but should be clearly visible.
    .As for metrics for increased code quality, try "number of classes" for EJB, or "number of includes".
    Now really, given stuff like ejbgen, middlegen, annotation etc. this should not be an issue any more. Also, what is lost on me is that somehow noone acknoledges that configuration files add to complexity in their own right. Simplicity and maintainability maybe quite different things, after all!
    More qualitatively, you can easily get a feel for how often you have to compromise on object-orientation.
    And no, name-dropping CLISP doesn't make you look cool.
    Apart from the name dropping, a lot of the AOPish, white box re-use that seems to get popular again for - to me - no apparent or urgen reason was available in CLISP.
  58. Dependencies[ Go to top ]

    Well, opening what they ship there is a lot of stuff in there from - for example - apache commons, velocity, altogether about 20 libraries. That introduces a major dependency on a particular version of these libraries or does it? Or they are not dependencies at all but are shipped to support examples, which would be fine but should be clearly visible.
    Have a look at the readme.txt files in the lib directory and the root of the distribution. They clearly state the dependencies, i.e. what each jar file is there for. Almost all of them are just necessary for certain support packages: Velocity just for using the Velocity support, Hibernate just for using the Hibernate support etc. The only core dependency is Commons Logging: a 30 KB jar file. (The other Commons libraries are mainly there for the Struts support.)

    If you choose to use Velocity in your app, you'll need the Velocity jar files in any case - no matter whether you're using Spring's Velocity support. Same for Hibernate, etc. So Spring does not introduce new dependencies to your application in that respect: It just integrates with the technologies that you've already chosen. Of course, each concrete application will just use a specific choice of those supported third-party libraries.

    We simply provide prebuilt integration classes as service for your users, to avoid the need for everyone to download and combine all sorts of integration libraries (each potentially in unclear state). With each release, you get a single distribution where the included integration classes are guaranteed to work with that specific version of the Spring core and the stated version of the respective third-party library.

    Juergen
  59. Karl,
    Bravo! Wery well said.
  60. Sorry, I missed the technical bit[ Go to top ]

    Well, opening what they ship there is a lot of stuff in there from - for example - apache commons, velocity, altogether about 20 libraries. That introduces a major dependency on a particular version of these libraries or does it?
    As has been pointed out elsewhere, you only need these if you're using particular features - personally I find that once I've got Hibernate and its dependencies in my lib dir I don't need any extra dependencies for Spring. It certainly beats a dependency on WebSphere or JBoss.
    Now really, given stuff like ejbgen, middlegen, annotation etc. this should not be an issue any more.
    What are these if not dependencies?
    Also, what is lost on me is that somehow noone acknoledges that configuration files add to complexity in their own right.
    Well, of course there's no silver bullet. But Spring, PicoContainer and their ilk also add value in terms of ease of testing and maintainability as well.
    Apart from the name dropping, a lot of the AOPish, white box re-use that seems to get popular again for - to me - no apparent or urgen reason was available in CLISP.
    Of course there's nothing massively revolutionary about Spring / AOP etc. in terms of computer science - but in the field of n-tier Java applications I think it hits a sweet spot and it's certainly made my life easier.
  61. Sorry, I missed the technical bit[ Go to top ]

    Now really, given stuff like ejbgen, middlegen, annotation etc. this should not be an issue any more.
    having a tonne of code generation tools just indicates the complexity of the techonology. all the more reason to have something like spring.

    And BTW, what u guys call hype is really praise from people who have actually started using spring and reaping its benefits.
  62. Technical reasons not to use swing[ Go to top ]

    One of the real fun things is that when people use it they are fairly unaware that they are subscribing to a highly proprietary framework. To me this is the ultimate proof that the original developer acceptance of J2EE was not because of "standards" as a lot of people claim but rather because of "cool stuff".
    My point is proven. "when people use it, they are fairly unaware that they are subscribing to a highly proprietary framework." Everyone else is ignorant, except these two beacons.

    I have two dependencies in my code on Spring and both are hidden inside my dependencies on Struts. 1) a settinga(and using) of an application context in an action and 2)a bean creation in a form base classe used because Struts forces you to extend ActionForm.

    I think I'll be alright. :-)
  63. One of the real fun things is that when people use it they are fairly unaware that they are subscribing to a highly proprietary framework. To me this is the ultimate proof that the original developer acceptance of J2EE was not because of "standards" as a lot of people claim but rather because of "cool stuff".
    So what ? You have the source code, this is not Microsoft ! Do you really think you could built a better application foundation inhouse in a reasonable amount of time ?

    This framework is built, supported and maintained by some of the finest developers in the J2EE space (btw this is something that differentiates Spring from JBoss). Do you think you can compete with them ?

    My best wishes to all the people of interface21 and thanks for your excellent work !

    Regards,
    Lars
  64. All the best[ Go to top ]

    Just wondering why JBoss gets harsh comments, and Spring gets congratulatory notes for following JBoss model?
    Most of the criticism of JBoss I've read seems to revolve around "Fleuryisms" and some of the online behaviour (the recent TSS astroturfing scandal) of JBoss developers/employees.

    I haven't really seen as much criticism/debate regarding the validity of the "professional" open source business model.
  65. All the best[ Go to top ]

    Best of luck to you guys! You deserve it. :) Keep up the good work.Yann
    Just wondering why JBoss gets harsh comments, and Spring gets congratulatory notes for following JBoss model?
    Please let's not get into an Interface21/Spring model vs. JBoss model debate here. I think both are quite viable. For the record, I think the fundamental differences come down to:

    - license: Spring is Apache 2.0 licensed. Anybody can do pretty well anything they want with the source and docs, subject to the attribution portion of the license which just says you have to give some credit to the original source. JBoss's LGPL license is quite a bit more restrictive, to the extent that any modifications to JBoss (by anybody) have to be made available when you distribute such a modified JBoss. That is a reasonable license for JBoss, which is a standalone app server and can be expected to be installed by customers separate from any code which will run in it. For Spring, which is effectively embedded in all sorts of applications, whether in modified or unmodified form, we simply feel that the Apache 2.0 license is the best choice in terms of its effect on Spring uptake and growth.

    - documentation: Spring has had and will continue to have decent quality, free, documentation. JBoss previoulsy forced you to pay (a reasonable amount) for quality documentation. I believe, although I am not 100% sure, that you can now get access to these docs just by registering somewhere.

    Best regards,
    Colin
  66. Colin,

    You are too modest. The Spring Framework does not have "decent quality" documentation. It is superb! The reference guide is very complete, and the Javadocs are about the best I've seen. Overall, the documentation is very precise and deliberate, and the writers obviously choose the words carefully. Keep up the great work!!
  67. All the best[ Go to top ]

    Best of luck to you guys! You deserve it. :) Keep up the good work.Yann
    Just wondering why JBoss gets harsh comments, and Spring gets congratulatory notes for following JBoss model?
    Marc Fleury
  68. Congratulations guys! This is great news for the Spring community.

    James
    Protique
    Open Source Middleware
  69. Good luck Guys !![ Go to top ]

    Very nice folks, good luck and keep it moving ....

    -Shashi
  70. can anyone comment on the market/mind share of Spring vs Struts?
  71. Mindshare[ Go to top ]

    can anyone comment on the market/mind share of Spring vs Struts?
    I can only give you an anecdote. It would be silly to pretend that Spring developers are as plentiful as Struts developers, but mindshare seems to be growing fast. When three months ago we needed a contractor with serious commercial Spring experience (plus a raft of other skills) we had no problem finding a number of strong candidates. This was in the UK Midlands, not always thought of as a high tech hotspot.

     - Peter
  72. Documentation[ Go to top ]

    Let's hope the documentation will remain in the open source community, as I see that as a accelerator to the acceptance of the technology.
    By the way, does anybody know if a good book about Spring will be on our shelves in a near future ?
  73. Re: Documentation[ Go to top ]

    does anybody know if a good book about Spring will be
    > on our shelves in a near future

    I know about this one:

    Professional Java Development with the Spring Framework
    http://www.javashelf.com/servlet/books/0764574833
  74. Documentation[ Go to top ]

    Let's hope the documentation will remain in the open source community, as I see that as a accelerator to the acceptance of the technology.
    The documentation, like the framework itself, will always remain free. In fact, since joining Interface21, Colin has put a lot of time into improving the (free) documentation.
  75. Documentation[ Go to top ]

    The documentation, like the framework itself, will always remain free. In fact, since joining Interface21, Colin has put a lot of time into improving the (free) documentation.
    Many thanks. And good luck with your new company.
  76. Documentation[ Go to top ]

    Good job on spring documentaion , Colin
    It really helps thanks
  77. Documentation[ Go to top ]

    Good job on spring documentaion , Colin It really helps thanks
    Thanks, but while I've been able to focus a bit more on them lately, the docs were actually produced very much as group effort, with a number of the other developers putting in quite serious time...
      http://www.springframework.org/docs/reference/index.html

    Regards,
    Colin
  78. I think this is great news. Got to admire people who push the boundaries.

    In terms of proffesional open source people tend to forget a lot of companies won't let technologies through the front door unless the managers can purchase support. The old "who do we blame when something doesn't work" mentality is still very strong.
  79. What is wrong with this mentality?[ Go to top ]

    Any manager with limited resources will be
    stupid taking responsibility for rolling
    complex framework into his project without
    support.
  80. What is wrong with this mentality?[ Go to top ]

    I agree as a manager you would be stupid not to pay the $$. Remember the first rule of management is at all cost make sure you can blame someone else when things do not work out. :-)

    Seriously though in terms of value I have found most commercial support organizations to be lacking. Real support comes from a good developer community, good documentation, good examples and the ability to look at the code that you are having issues with.
  81. What is wrong with this mentality?[ Go to top ]

    There's certainly a trend here, with enterprising getting leaner (typified by "J2EE w/o EJB" attitudes) while open offerings (SpringFramework, Hibernate et. al.) beefing up a bit with public offerings of support.

    After years of avoiding heavy enterprise architectures (both in the C++ world and now Java), I find myself part of a big-ol' corporation and what do I find? They are in the process of slimming down process and favoring agile cycles, open components/tools/frameworks, etc. Modest, clear support (a consulting site that quotes rates! Yipee!) for focused, modestly scoped products. Satisfying both managers and developers. What a concept!

    So, is a happy medium emerging? I fear that things fall apart; the center cannot hold.

    [apologies to Yeats and l'Engle, but mostly congrats to the Spring crew!]
  82. Best wishes to you guys in this new venture!

    It is not only that you deserve it (which you undoubtely do :), but also that your success will revert into the framework itself. And that is good news for the whole Spring community.

    Regards,
    Fernando Olcoz
  83. Heary Congratulations to Rod & Team!
  84. <offtopic>What is about "small/normal/large" selector on the right top of the page? My browser has font size menu item and I am grateful to springframework.com, that it works (some webmasters think that the small font is so cool, that they make it hardcoded at 7pt size, which cannot be changed using "Font Size" browser menu).</offtopic>
  85. good luck on this new project![ Go to top ]

    Now i have a new goal. To become the new Interface21 consultant :)

    Congratulations to you all, Rod, Juerguen, Bruce, Keith, Colin and Alef.

    The whole community will benefit from having a company backing up the framework.

    Fernando Racca
  86. Congratulations, too.

    Interface21 could also help developers who want (actually, need) to push Spring based solutions to bloated, over engineering projects around the world.

    I mean, certification programs, despite questionable, seens to be a good marketing tool to help us to push Spring over J2EE to non technical managers who just understand marketing, anyway...

    JBoss team has one certification program (but is much expensive, IMO), Red Hat and MySQL too, so please consider this in a short future. I have been tracking Spring for many time, but I never could use it in a professional project because usually managers think it is "too risky", etc.

    I hope Spring being more "enterprise" accepted (you know, marketing), Extremme Programing, Test Driven Development, Domain Driven Development and all these agile practiques could be also introduced in more "orthodox" driven projects.

    BTW: Rod, do you remember this ?
    http://www.theserverside.com/news/thread.tss?thread_id=21239#94692

    Regards
  87. Certification[ Go to top ]

    Rodolfo

    We are considering a certification program, although it's not part of our initial offering. It's essentially a question of demand and value. As you say, there can be a real value in certification processes to managers. We wouldn't want to create a certification program that was merely a money spinner, but it could be helpful to provide quality assurance for companies using Spring.

    Rgds
    Rod
  88. From the website: "Rod's best-selling Expert One-on-One J2EE Design and Development (2002) was one of the most influential books ever published on J2EE."

    The quoted phrase is apparently true, so I guess there is nothing bad in praising yourself. Mein kampf will follow.

    By the way, the strange stylesheet does not allow to select text from the website easily, it can be selected only in whole paragraphs.
  89. By the way, the strange stylesheet does not allow to select text from the website easily, it can be selected only in whole paragraphs.
    Weird stuff; this was not intentional. It works fine in Mozilla, which is what I use 99% of the time, except when some web site forces me to use IE. I did check the site with IE, but did not pick up on this. I'll try to get it resolved some time when things get quieter again.

    Regards,
    Colin
  90. Portlet integration[ Go to top ]

    Congratulations. I'm eager awaiting the portlet integration.
  91. I think it's an important step for Spring in getting recognition among large organizations. They are very conservative when it comes to adopting innovations and leading edge technologies.

    All the best to Spring team. I hope, I soon will be able to persuade my managers in Spring's numerous advantages over Struts.
  92. I think it's an important step for Spring in getting recognition among large organizations. They are very conservative when it comes to adopting innovations and leading edge technologies.
    In fact, most of them are just conservative about the way to spend money. When you speak to a financial manager, don't tell him it's open-source or, even worst, free. Companies spend money in IT to balance their accountancy. When they need expenses (all companies need a certain level of expenses to reduce their taxes), IT is a great place to spend a lot in a short time. If everything gets free, IT becomes useless. So, when you want to use open-source on your projects, counterbalance it by telling the financial manager that, for example, money can be used in better server hardware. I know this can sound crazy to the logical minded IT people, but that's the way it goes in the finance. The consequence of this is that, when markets slow down, IT is the first department impacted : the accountancy have to spend less money because the company earns less (the taxes are based on the earnings).
  93. I think it's an important step for Spring in getting recognition among large organizations. They are very conservative when it comes to adopting innovations and leading edge technologies.
    In fact, most of them are just conservative about the way to spend money. When you speak to a financial manager, don't tell him it's open-source or, even worst, free. Companies spend money in IT to balance their accountancy. When they need expenses (all companies need a certain level of expenses to reduce their taxes), IT is a great place to spend a lot in a short time. If everything gets free, IT becomes useless. So, when you want to use open-source on your projects, counterbalance it by telling the financial manager that, for example, money can be used in better server hardware. I know this can sound crazy to the logical minded IT people, but that's the way it goes in the finance. The consequence of this is that, when markets slow down, IT is the first department impacted : the accountancy have to spend less money because the company earns less (the taxes are based on the earnings).
    Okay, this is the most ridiculous thing I've ever heard on TSS, and that is saying a lot. Do you seriously believe that businesses spend money because they have to in order to decrease their taxes? Tax rates (at least in the overtaxed corporate USA environment) top off well short of the 40% mark. Let's suppose that you work for a company with sufficient income to pay a 36% marginal tax rate. So if you expense a $10,000 license you "save" $3,600, meaning that you spent $6,400. That's still a lot more money than $0.00. If value is truly equal between the two solutions, the $0 one will ALWAY be cheaper, unless tax rates somehow exceed 100%.

    Perhaps in a government or not-for-profit someone would turn down open source because they have budget that they "have to spend", but no profit-optimizing corporation would last long if they were run that way. I think the real reason that many corporate managers shy away from open source is that they manage with the CYA style. There's a saying that nobody gets fired for buying IBM. My guess is that many managers don't feel the same level of protection when they leave the beaten path and choose open source.
  94. Perhaps in a government or not-for-profit someone would turn down open source because they have budget that they "have to spend", but no profit-optimizing corporation would last long if they were run that way. I think the real reason that many corporate managers shy away from open source is that they manage with the CYA style. There's a saying that nobody gets fired for buying IBM. My guess is that many managers don't feel the same level of protection when they leave the beaten path and choose open source.
    That's not so unusual. A small example: Your department gets a yearly budget of say $1,000,000. If you manage this year to spend only $500,000, do you think the next year you will get the $1,000,000 again? I doubt that. So in order to have enough money to spend the next year it would be better if you spend your whole budget. Sounds wierd but quite common in business. Stakeholders don't want to optimize profit. Only the owner of a company wants to optimize profit. Ever heard someone say "The program I am working on could be replaced by the opensource program x. If my company fires me, they could greatly improve their profit by using opensource program x instead of my work."? No. Wheels are constantly reinvented... The list goes on and on. Companies are mostly the people that work for them. And because of that they are much more human or sociological than logical and businessoriented. And this applies even more the bigger the company is.
  95. Companies are mostly the people that work for them. And because of that they are much more human or sociological than logical and business oriented. And this applies even more the bigger the company is.
    I think it helps when management can balance between business objectives and technical excellence in a given project.
  96. Okay, this is the most ridiculous thing I've ever heard on TSS, and that is saying a lot. Do you seriously believe that businesses spend money because they have to in order to decrease their taxes?
    Perhaps it's not related, but try this : instead of telling your manager you want to use that new technology on your project because it's cool and free, tell him you want to use it because money will be better spent in another part of your project. I've tried it more than once, and sometimes after having tried the first approach, in different companies and it always worked for me. Is it just because it sounds more clever ? Maybe.
    Tax rates (at least in the overtaxed corporate USA environment) top off well short of the 40% mark. Let's suppose that you work for a company with sufficient income to pay a 36% marginal tax rate. So if you expense a $10,000 license you "save" $3,600, meaning that you spent $6,400.
    I don't know for USA, but in Europe the $6,400 will also be deducted the next years. At the end, the company will have paid something like 10% (depending on the type of equipment, for the company cars it's more like 25%. IT is around 10%) and, in the meantime, the company will probably have made money with the equipment (by increasing its performances or producing new goods/services around it).
    Perhaps in a government or not-for-profit someone would turn down open source because they have budget that they "have to spend",
    Though, from my point of view, I've the feeling open source is more popular in those government and not-for-profit organisations.
    There's a saying that nobody gets fired for buying IBM
    Everybody in IT has heard that urban legend. Do you really believe it ? (and you blame me for writing ridiculous things?) If it's not the right solution for the company, being IBM or open source, the manager is fired exactly the same. In these times of tight budgets, it's probably safer for a manager to work with free technologies.
    But, ok, you can think about it the way you want. That's my way of thinking, based on my personal experience, and everybody can have a different one. I'm not sure this is the best place to discuss such things.
  97. By the way, do you know that some companies from the United States are leasing public infrastructures (like bridges and other things that they cannot use for their business) in Europe just to increase their expenses ? It's been a subject of discussion in Belgium a few months ago because it allowed some towns in the country to balance their budgets.
  98. By the way, do you know that some companies from the United States are leasing public infrastructures (like bridges and other things that they cannot use for their business) in Europe just to increase their expenses ? It's been a subject of discussion in Belgium a few months ago because it allowed some towns in the country to balance their budgets.
    Really? What companies? I would be interested in finding out the true motivations of increasing expenses for no value in return. I shouldn't claim that *no* company would ever do business this way, but I do truly believe that increasing expenses for the sake of increasing expenses is a very lame tactic that is not being taught at the premier business programs.

    As far as the earlier IBM comment, *I* don't believe the saying myself. But I think you're kidding yourself if you don't think that uninformed IT managers have a tendency to "play it safe" when making buying decisions. Someone who knows the tradeoffs between different solutions will make a judgment for the right reasons and will hopefully choose the better product. But my personal experience has been that not all IT managers are qualified to make informed decisions. And when given a choice that they do not truly understand, they'll count the number of Gartner, Forrestor, and CIO references between the two products and choose the one with the most.
  99. The taxation myth...[ Go to top ]

    By the way, do you know that some companies from the United States are leasing public infrastructures (like bridges and other things that they cannot use for their business) in Europe just to increase their expenses ? It's been a subject of discussion in Belgium a few months ago because it allowed some towns in the country to balance their budgets.
    You are ill informed. What they do is they buy or lease the infrastructure and <em>lease it back</em> to the Europe town or company. It has been highly controversial in Germany, because it means long term costs for short term benefit. The deal is essentially financed by the U.S. taxpayer - and because of that thankfully certain flavours of it have been ruled illegal in the U.S. Also the owner or leaser will need to sign contracts that require him to maintain / extent the road/metro/bridge that he just acquired and that is deemed to be a problem as well. Thinking of it, it is a bit like selling your IT department to IBM or EDS and renting it back :-))
  100. OT: tax loophole[ Go to top ]

    Really? What companies? I would be interested in finding out the true motivations of increasing expenses for no value in return. I shouldn't claim that *no* company would ever do business this way, but I do truly believe that increasing expenses for the sake of increasing expenses is a very lame tactic that is not being taught at the premier business programs.
    A lot of big companies were doing this. One of the big accounting firms here was making many millions of dollars (for some reason I remember reading the number was close to $1 billion) a year just on consulting related to this loophole, so you can imagine that it is (was?) a _big_ loophole. (In Germany, they tried to lease a sewer from one city, for example. Totally bogus.)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  101. OT: tax loophole[ Go to top ]

    Sorry, this is getting incredibly off topic.....
    Was this a case like that mentioned in this post: http://www.theserverside.com/news/thread.tss?thread_id=28241#135412

    This doesn't seem like the kind of tactic that initially sparked the discussion, where a company takes on expenses to increase a tax break.
  102. OT: tax loophole[ Go to top ]

    And don't forget govt.(US) and budgeting. I've worked on projects where that was a mass hiring to increase the burn rate because if you were given $10 million, but only used $8 million, you next years budget could get slashed.

    Therefore, you had to burn the remaining funds before the end of the fiscal year.
  103. My heartiest congratulation to Springframework.com, I know many have said this in previous posts but I just can't help to say it again. Spring framework is really a brilliant piece of art. Once again congratulations.

    regards
    tmjee
  104. SpringFramework support[ Go to top ]

    I am really impressed by all the books written by Rod Johnson I have read so far in "expert One On One series". It clearly shows his upfront approach about -- technology infrastructure and how it works. I am really looking forward to apply his framework for creating appropriate transparent infrastructure for all my future j2ee projects.

    Regards,
    Yogesh shekhawat
  105. Seems like a success[ Go to top ]

    From what I read so far, seems like Spring has managed to become a real star. I must say that it does make for a very good/simple framework for a wide variety of applications (web, standalone). Ironically, this has all come about from a book (well its source as the story goes) that was originally written to show people how to make the best use of "Orthodox" J2EE ;). This is an evolutionary step for those in need of a simple framework to help them get their job done (including myself when it comes to a majority of the applications we write). Thanks to the Spring team for their great work and good luck with Interface21.
  106. Congrats! spring is one of the best framework I have ever used.
  107. Best of luck to Spring community, Rod and the rest. I did fine supporting Struts. Open source ends up giving us better quality in many areas.

    .V
  108. I think that technical toos and throes on the use of Spring/JBoss/EJB etc are a little by-the-by in the larger picture. Most of the time the reasons for these decisions in companies come down to the problem being solved and mostly just personal preference and the skills available.

    At least interface21 are putting Spring into a position where skills and support will be more readily available and open up choice in the larger development landscape.

    So on this im interested in the business model approach they are taking.

    Its good to see should a small "boutique" consultancy of talented and experienced professionals. I often find, especially in London, there are a lot of very talented Java professionals but they are either well-paid in the financial sector or independent contractors while the consultancies lack serious skills.

    But its interesting to see how much revenue stream you could achieve off only six people considering the additional overhead in marketing, speaking, writing and business maintenance/continuity.

    Some pertinent questions would be.

    * how far is interface21 going to extend beyond Spring? is there more framework/consulting products on the horizon?
    * what input will there be in a "free" community sense? will a revenue model based on support reduce the amount of input given on mail lists/forums etc to induce more companies to pay for dedicated support time?
    * what kind of vendor/ISV relationship structures are likely to come about?

    Anyway best of luck to you guys. I expect to see more and more small businesses spring up to support the great ideas coming out of the development community

    Stuart Eccles
  109. Stuart,

    Quick reply to some of your (good) questions:
    how far is interface21 going to extend beyond Spring? is there more framework/consulting products on the horizon?
    We do not plan other products in the foreseeable future, but I would never say never. Spring represents a huge ongoing commitment. One area in which we differ from, say, JBoss, is that we do more consulting, rather than purely Spring support. E.g. we are currently helping a large UK client build an application. We're using Spring in that engagement, but they're hiring us because we've proven we can achieve good results quickly. They're satisfied with the quality of Spring that it's not a risk, but they're not hiring us because they want Spring per se.
    will a revenue model based on support reduce the amount of input given on mail lists/forums etc to induce more companies to pay for dedicated support time?
    No. Look at the amount of time Colin has been putting into the forums since joining Interface21. I've also been pretty active. We will continue to publically support Spring.
    But its interesting to see how much revenue stream you could achieve off only six people considering the additional overhead in marketing, speaking, writing and business maintenance/continuity.
    Good question. We already have one additional consultant working for us full-time for a client in the UK, and expect to have more in the near future. We will also be announcing some partnerships.

    I'd be happy to discuss our business model further offline.

    Rgds
    Rod
  110. As Rod mentioned, not all of our engagements come to fruition simply because clients are bent on using Spring. More often than not clients are interested in the cumulative experience the team has building applications and leading successful projects, and particularly solving problems relavent in some way to their own business needs.

    With that said, Spring usually does play a major role, as it serves as a solid architectural foundation to build on consistently in a variety of environments: from web applications, to standalone apps, to rich clients. It helps us deliver more with less faster, and helps us better show our clients how to do the same.

    I think you'll see Spring continue to evolve and improve, particularly as we take it further into more environments, and particularly more demanding environments. To be an effective consultant you've got to have good tools to do the job, you can't go around reinventing the wheel on every project. Spring is that central tool in our workbench, glueing everything else together, and built and improving based on the experience gained from our (and the larger user community's!) continual applications of the technology.

    Keith
  111. Keith, Rod

    Thanks for your replies.

    In my previous experience i've tried to improve methods in consulting organisations to deliver better service and ideas by re-introduction of common ideas and solutions to clients and having some "rabbits in hats" to deliver solutions where the client money is more clearly focused on the business problems while having the technical challenges and plumbing already sorted with proven solutions.

    Unfortunately i found this contrasted with the traditional consulting model of 'charge em for everything' to up the revenue and found strong resistance/lack of effort to making it work.

    Glad people are breaking the mould, and applying a little common sense.

    Stuart
  112. With that said, Spring usually does play a major role, as it serves as a solid architectural foundation to build on consistently in a variety of environments: from web applications, to standalone apps, to rich clients. It helps us deliver more with less faster, and helps us better show our clients how to do the same.I think you'll see Spring continue to evolve and improve, particularly as we take it further into more environments, and particularly more demanding environments. To be an effective consultant you've got to have good tools to do the job, you can't go around reinventing the wheel on every project. Spring is that central tool in our workbench, glueing everything else together, and built and improving based on the experience gained from our (and the larger user community's!) continual applications of the technology.
    Hi Keith,

    It really sounds pretty good and it will definitely provide spring a infrastructure support to perform and evolve upto the spring community expectations. I am really looking forward for my spring break where I could apply spring framework to all my j2ee projects for providing loosely coupled, transparent and maintainable architecture
    with improved testability support.

    Also If you could give some idea when TOPLink access will be availaible officially to spring for integration. Any time estimates for official release for TOPlink integration will be helpful.

    Regards,
    Yogesh Shekhawat
  113. Also If you could give some idea when TOPLink access will be availaible officially to spring for integration. Any time estimates for official release for TOPlink integration will be helpful.
    It's likely that much of the integration will be done by a member of the TopLink team. Hence I can't commit to a date, as it's not entirely up to the Spring team. But I'm hoping it will be within a couple of months.

    Rgds
    Rod
  114. Spring Framework[ Go to top ]

    In my opinion , choice of using right framework and technology infrastructure is more based on people practical experience and their comfort level in terms of what they see work for them in long term rather than based on any marketing hype.

    Traditional approaches to j2ee architect has clearly produce disappointing results by creating more complex business environment which is hard to test and maintain in long term.
    Ejb is another attempt to increase this complexity by creating another layer of vendor specific architecture. Spring does provide alternate to this by following OO design and principal. Applied effectively spring framework could deliver high code reuse , loosely coupled and transparent design which is easy to test and maintain in long term across all j2ee projects.
  115. Springs Gone Professional[ Go to top ]

    That is a good effort of interface21 to live the springs framework as a professional framework for software development.
    Hope it will come up with light weight and better solutions.