Discussions

News: Spring Framework 1.2 Final

  1. Spring Framework 1.2 Final (26 messages)

    Spring Framework 1.2 has been released for download. Spring is a popular application framework, leveraging inversion of control to provide many application services.

    Major changes for 1.2 from 1.1 are:

    • TopLink support
    • JDO 2.0 support
    • finer-grained distribution jar files, alongside the full spring.jar
    • AOP Alliance interfaces are now contained in spring-aop.jar and spring.jar
    • XML bean definition improvements ("ref" and "value" shortcut attributes etc)
    • improved AOP TargetSourceCreator mechanism (supporting
      LazyInitTargetSource too)
    • transaction annotation support for JDK 1.5+ (annotation called "Transactional")
    • improved WebLogicJtaTransactionManager (transaction names, isolation levels)
    • SqlRowSet support for JDBC (in conjunction with JdbcTemplate's "queryForRowSet")
    • Hibernate3 support (in orm.hibernate3; Hibernate 2.1 support is still available)
    • JMX support for export of Spring beans as managed resources and for MBean access
    • Commons Attributes and JDK 1.5+ annotations for JMX MBean export
    This release also includes Spring Web Flow as part of the build. Reflecting Spring's visibility in the J2EE space, Oracle contributed the original TopLink support prototype, and Jim Clark from Oracle is credited with getting TopLink support into its final shape.

    Threaded Messages (26)

  2. Congratulations..spring rocks[ Go to top ]

    If the outstanding consistency remains then this will be awesome release...spring rocks...
  3. Congratulations[ Go to top ]

    In my last project I took the decision and integrated spring, in the beginning only small parts, now at the end of the project spring is interwoven left and right, a sign of the quality of this framework.
    It literally has save me weeks-months of development time.
  4. Building systems (mostly websites) these days for me is a matter of pulling lots of small (as in do one thing do it well) excellent open source components together (eg hibernate, hessian,axis,apache-commons,tapestry etc)

    However BSF (Before Spring Framework) i was always writing the glue layer to pull together my business layer and the components above... Eg this mean adhoc config files, adhoc singletons, adhoc factorys etc...

    All in all quite a bit of heavy lifting...

    However spring does this HEAVY lifting for you in possibly the most eloquent way i could think of...

    It provides a consistent repeatable configuration process (dependency injection, in-direction) that allows me to do this SO easily...

    Whats more which is probably one of best things... is !!!

    It does this in such a consistent way... Eg once you understand the concept of configuration by dependency injection... you can plugin in the components you need in the same way...via the main config file...every thing is a BEAN (without it know it is a bean)

    eg: add JMS, ORM, Remoting, web framework etc all in a consistant manner...

    I am so impressed that they kept the consistantcy across the framework...it is like everyone in the project thinks with the same mind... like the borg :)

    The framework is revolutionary...
  5. an example if you please[ Go to top ]

    However spring does this HEAVY lifting for you in possibly the most eloquent way i could think of...

    Could you give an example of what kind of lifting it does for you? That would be helpful to me in figuring out why to use it.
  6. an example if you please[ Go to top ]

    > However spring does this HEAVY lifting for you in possibly the most eloquent way i could think of...Could you give an example of what kind of lifting it does for you? That would be helpful to me in figuring out why to use it.

    As it happens, here's one I prepared earlier :-)
    <p />
    Say you have a POJO containing some JDBC code & it's deployed within a J2EE app. Let's say this
    needs a DataSource. This might look something like:



      public class MyDAOImpl implements MyDAO {
        private static final Logger LOG = Logger.getLogger(MyDAOImpl.class);
        private DataSource _myDataSource;

        public MyDAOImpl() {

          InitialContext ctx = null;
          try {
            ctx = new InitialContext();
            _myDataSource = (DataSource)ctx.lookup("MyDataSource");
          }
          catch (NamingException e) {
            throw new SystemException("Error looking up datasource from JNDI", e);
          }
          finally {
            if (ctx != null) {
              try {
                ctx.close();
              }
              catch (NamingException e) {
                LOG.warn("Error closing JNDI naming context", e);
              }
            }
          }
        }

        ...data access methods...
      }


    With Spring, you can get rid of all the lookup stuff with the following bean configuration XML fragment:


      <!-- JNDI connection template.
        Configures a JndiTemplate object (part of the Spring Framework) which provides JNDI
        lookup capabilities against a particular JNDI server.
      -->
      <bean id="myJNDITemplate" class="org.springframework.jndi.JndiTemplate"/>

      <!-- Datasource.
        Uses an object from the Spring framework to lookup a DataSource from a JNDI server.
        The datasource is then available as a Spring bean with the specified id.
      -->
      <bean id="myDataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
        <property name="jndiTemplate">
          <ref bean="myJNDITemplate"/>
        </property>
        <property name="jndiName">
          <value>MyDataSource</value>
        </property>
      </bean>

      <!--
        Creates a DAO bean which uses the datasource configured above.
      -->
      <bean id="myDAO" class="uk.co.myorg.myapp.dao.jdbc.MyDAOImpl">
        <property name="dataSource">
          <ref bean="myDataSource"/>
        </property>
      </bean>



    You would remove the lookup code from the constructor of MyDAOImpl and add a setter method:


      public void setDataSource(DataSource dataSource) {
        _myDataSource = dataSource;
      }


    At runtime, the configuration XML is used to configure a Spring bean factory. This creates the
    POJOs which back the above bean definitions and wires them together according to the bean references.
    Your application code can then get the DAO object by just doing:


      BeanFactory beanFactory = ...Load the bean factory - there are various ways to do this - see Spring docs...
      MyDAO dao = (MyDAO)beanFactory.getBean("myDAO");


    Note that the final Java code just looks up a single object from Spring. It doesn't need to obtain
    a JNDI context or look up the DataSource. So your code becomes much cleaner. Also, we have
    externalised the details of the look up process - we could change the JNDI name of the DataSource,
    JNDI connection settings or even the mechanism used to obtain the DataSource just by changing the
    config file.

    In practice, there's no need to stop with the DAOs. You might define a layer of POJO service objects
    which receive DAO references through dependency injection, all configured in the XML file. This allows you to pass in mock DAO
    implementations when you unit test your service layer. It gets better too - you can use Spring bean
    definitions in the XML to transparently declare transaction demarcation on your service object methods (similar
    to CMT with EJB, but with less config and no tie-in to a specific API.) There's loads of other good stuff too,
    such as the ORM implementations.


    I've been using Spring for a couple of years now. I always try to use it on all except the simplest of apps.
    The benefits of Spring grow as your app increases in complexity.


    Hope this helps, <br/>
    Regards,<br/>
    Alastair.
  7. Spring Framework 1.2 Final[ Go to top ]

    Congrats to all of the Spring team.

    Having been around the 'Java block' a few times I have tried many different Java tools and libraries. If somebody were to ask me which have made the biggest difference to my productivity then Spring would definatly top my list (IntelliJ idea would be the only other serious contender).

    Please dont get me wrong, there are many tools that provide a very real advantage over the plain alternatives (tapestry vs JSP/servlets or Hibernate vs pure JDBC for example), but there always seems to be a slight grey area where the only solution I can find feels very much like an anti-pattern. I have never had this with Spring.

    Perhaps this sounds like sucking up but I believe in credit where credit is due and the Spring development team have made my life much much easier. Thanks guys!

    One small point though. Portlet support? Last I checked that was on the roadmap for 1.2. Has this been delayed?
  8. Spring and JSF[ Go to top ]

    First of all, i totally agree with Wesley.
    But i would be happy about a more complex built-in JSF integration like JSF-Spring.
  9. Spring Framework 1.2 Final[ Go to top ]

    One small point though. Portlet support? Last I checked that was on the roadmap for 1.2. Has this been delayed?

    This has been moved to the Spring 1.3 timeframe a while ago. Spring 1.3 will include both Portlet support and Spring Web Flow. Both of those already reside in the sandbox and will continually be developed alongside the 1.2.x releases. We expect Spring 1.3 RC1 to be released in late July now.

    Juergen
  10. Spring Framework 1.2 Final[ Go to top ]

    Congrats !!

    I was hoping (guess I have to read the roadmap more often :) ) that Cayenne support would be out with this release...

    Pedro Costa
  11. Toplink Support?[ Go to top ]

    Wow..

    Is the Toplink as well integrated into spring as Hibernate is?
  12. Yes![ Go to top ]

    Spring is becoming more and more complex
  13. Yes![ Go to top ]

    Spring is becoming more and more complex

    More features != more complex. Do you really mean it is more complex? If so, can you elaborate?
  14. Complexity[ Go to top ]

    Complexity usually comes with size, but Spring seems to me to be getting simpler. As Spring adds more glue code that I need, I don't have to implement it. JDO 2 will make my life much easier, as will the context short cuts.

    Spring contains a lightweight container, and glue code that makes a whole lot of things easy to integrate. If you don't need the glue code in question, you don't have to pay the penalty. Interface21 has done an excellent job with keeping the dependencies between modules to a bare minimum.

    Congrats, once again, to an outstanding release.
  15. Toplink Support?[ Go to top ]

    Wow..Is the Toplink as well integrated into spring as Hibernate is?

    This is the first release of TopLink integration in Spring so I'm sure we'll find things we can improve upon but TopLink is as integrated as any other persistence framework and ready to use. Check out the Pet Clinic sample app configured to use TopLink.

    - Shaun
  16. Toplink Support?[ Go to top ]

    Wow..Is the Toplink as well integrated into spring as Hibernate is?

    The TopLink support is essentially as sophisticated as the Hibernate support, both in terms of data access convenience and in terms of transaction management. The differences in support only account for the differences between the underlying tools themselves.

    In particular, TopLinkTemplate exposes operations with TopLink semantics, just as HibernateTemplate exposes operations with Hibernate semantics. So be aware of the differences between TopLink and Hibernate there, for example regarding shared read-only objects etc.

    Of course, Spring's TopLink support is as consistent as possible with Spring's overall data access and transaction management style. Consequently, you will feel quite familiar with it if you already know Spring's Hibernate and/or JDO support.

    As Shaun says, we do expect refinements and further conveniences to be added in forthcoming Spring releases: for example, support for new features of TopLink 10.1.3 (which currently is in developer preview). Thanks to the close collaboration with Jim Clark from the Oracle TopLink team, we will stay at the leading edge there!

    Juergen
  17. Thanks for making the hibernate support fairly painless. All I needed was a few string replaces and I was set to go.
  18. Thanks for making the conversion between hibernate2.1 to hibernate3 fairly painless. All I needed was a few string replaces and I was set to go.
  19. Modularity[ Go to top ]

    For me, the problem with Spring is that it should be more modular. I shouldn't have to install 10+ jars just to use dependency injection.
  20. Modularity[ Go to top ]

    I shouldn't have to install 10+ jars just to use dependency injection.

    And guess what: you don't have to. spring-core has a single(!) dependency (commons logging). You could have found this information in Springs's readme.txt.
  21. Modularity[ Go to top ]

    For me, the problem with Spring is that it should be more modular. I shouldn't have to install 10+ jars just to use dependency injection.

    YOU DON'T! Sheesh! Don't use it if you don't want to read the docs!
  22. Modularity[ Go to top ]

    For me, the problem with Spring is that it should be more modular. I shouldn't have to install 10+ jars just to use dependency injection.

    Daniel,

    While Spring ships as a single, comprehensive download, it is as modular as possible. Please check the "DISTRIBUTION JAR FILES" section in readme.txt: You can find details on the individual jar files and their dependencies.

    For example: To run the core DI container, all you need as of Spring 1.2 is spring-core.jar (~75 KB) and spring-beans.jar (~215 KB). For using the AOP framework standalone, take spring-core.jar and spring-aop.jar (~150 KB). The only third-party dependency of those is commons-logging.

    As a convenience, Spring also ships a full spring.jar (~1720 KB) that includes the entire framework, covering all areas. This is an alternative to combining multiple individual jar files, mainly for environments where jar file size does not matter.

    In general, third-party dependencies only arise when you're actually using corresponding functionality: for example, CGLIB is not needed unless you're proxying full target classes with Spring's AOP framework. Hibernate is not needed unless you're actually using Spring's Hibernate support.

    Finally, for a size comparison: The full spring.jar is roughly as large as hibernate3.jar or axis.jar; a bit larger than jpox.jar and significantly smaller than toplink.jar. Note that Hibernate and Axis require multiple third-party jars even for core functionality, in contrast to Spring.

    Juergen
  23. Security and Persistence[ Go to top ]

    Does anyone know if this framework is able prevent you from submitting or viewing pages that do not belong to the current state?

    And, is the flow execution id secure, since the article says that it is tracked as a hidden field by the client?

    Also can the state of the state machines be persisted and restored to support pausing and resuming?
  24. Missing the flow[ Go to top ]

    Maybe I'm just blind but I didn't find any Spring Web Flow (SWF) related stuff in the release?! In addition, SWF home site advises to download the SWF preview releases that will *run* on spring 1.2, but is not saying that SWF is actually included in the release.
  25. Missing the flow[ Go to top ]

    Spring Web Flow goes final with Spring 1.3. Between now and then, you can expect at least 2 more preview releases stable for development use. We're working on PR3 now.

    Regards,
    Keith
  26. Missing the flow[ Go to top ]

    From what I've read, SWF will be integrated in Spring 1.3. Until then, you need the 2 SWF jars (spring-webflow.jar, spring-webflow-support.jar) in addition to Spring 1.2 (spring.jar).
  27. Missing the flow[ Go to top ]

    So it is how I thought is was. I was just wondering if this had changed since this news stated the following:
    This release also includes Spring Web Flow as part of the build