Spring Framework 1.1 RC1 released

Discussions

News: Spring Framework 1.1 RC1 released

  1. Spring Framework 1.1 RC1 released (44 messages)

    The Spring team are happy to announce a release candidate of Spring 1.1.

    New features and enhancements in Spring 1.1 RC1 include:

    * IoC container supports Method Injection: the overriding of concrete or abstract methods, typically to look up a dependency managed by the container. This means even less need to implement Spring-specific interfaces such as BeanFactoryAware.
    * The IoC container can now obtain objects from static factory methods as well as constructors. This enhancement allows excellent AspectJ integration: it is now possible to configure AspectJ aspects using Spring Dependency Injection, like any object. We plan to provide examples of AspectJ integration before 1.1 final.
    * Support for sending and receiving JMS messages
    * Support for Apache OJB as an ORM alternative, within Spring's consistent data access abstraction
    * Significantly improved JDO support
    * Greater flexibility in translating SQLExceptions, and other JDBC enhancements
    * Support for nested transactions and savepoints when working with JDBC. Declarative transaction management can support nested transactions.
    * AOP proxies are now serializable if all Advisors and target are serializable
    * Improved Velocity and FreeMarker support
    * Reworked parent/child bean definition concept: a child can now override any inherited settings. This can be used to simplify configuration.

    Spring 1.1 final is scheduled for release in mid August, and will be 100% backward compatible with Spring 1.0.2. As Spring aims to minimize dependency of application code on the framework, and because changes are backward compatible, we do not expect that existing applications will require any code changes to migrate to Spring 1.1.

    The main focus between now and the 1.1 final release will be on documentation and examples.

    Visit Springframework.org for further information. Spring 1.1 RC1 can be downloaded here.

    Threaded Messages (44)

  2. Great Job![ Go to top ]

    Spring gives the tired J2EE industry a fresher noew look.

    Congratulations for your great job, i still haven't read your new book and you released a new build, thank you for your great effort. I'm doing a huge lobby within my fellow architects to implement Spring :)

    Fernando Racca
  3. when will these two modules be released?
  4. The Spring rich client project is progressing aggressively. We are in the process of developing a specific initial release plan now, as well as extending our sample application to demonstrate new features (such as security/remoting integration). We are currently targeting an initial release candidate by the mid/end September timeframe between Spring 1.1 and 1.2.

    spring-richclient offers the following capabilities TODAY:

    - A generic application shell with well-defined points for customization within the app's lifecycle. Out of the box support for managing multiple application windows, application views, and GUI command bars is provided, all configurable conveniently via a Spring application context.

    - A powerful GUI action/command framework that builds on Swing's base action infrastructure. Support for actionable commands, targetable commands, toggle commands, and command groups are provided. Command configuration is externalized (fit for internationalization) and extremely simple. Unique features include support for command interceptors, parameters, and automatic updating of attached controls in response to command property changes (for example, if you add new command to a command group, and that group is visually realized by a displaying menu, toolbar, and popup menu, all three GUI controls will be updated for you in a single call - dynamically.)

    - A powerful Swing data-binding, validation, and form framework. Various domain object strategies (javabean, hashmap, etc.) can be used to bind backing domain objects to form GUI controls. No more repetitive manual bindings (e.g manual copying data from the controls to the business objects); instead you get automatic data binding, type conversion, validation, and as-you-type validation results reporting, including auto-enablement of guarded controls such as a form "finish" button in response to validation of declarative rules associated with your domain objects. Additional capabilities include support for buffered form models (to defer commits to the backing business layer - for example, if the user "Cancels" a form edit), metadata-driven control selection (for example, controls bound to Enum properties are by default combo-boxes, Spinners are produced for Integer/Date properties with ranges), and support for compound forms that span multiple pages (supporting wizards).

    - Various convenient support classes for dialogs, wizards, tables (multi-column sorting provided out of the box), lists/filtered lists, and image/icon management.

    By the release candidate we plan to provide these additional capabilities:

    - Support for declarative application "page configurations", where a page configuration defines the layout of the main application window area. You'll be able to define which application views (panels) should be displayed on the page, and how those views should be positioned.

    - Support for dockable, stackable views; we're working to integrate with & help improve upon available docking solutions within the open source community.

    - Client/server remoting integration with Hessian, and security integration with Acegi (all new features illustrated by our sample app.)

    It should be an exciting next few months for spring-richclient, definitely!

    Just a few other notes on the spring-richclient subproject:

    In general, we look to apply familiar design patterns leveraged in core Spring, and we strive to follow Spring conventions as much as possible. The framework makes heavy use of programming to interfaces, template method, and the core IoC/dependency injection support. We're also leveraging the new method injection support within the framework, and keen on applying the new AspectJ integration. In general we're are always looking for innovative ways to leverage the container in standalone applications!

    I would also like to add the rcp framework is somewhat unique as it was designed first-and-foremost as a shell for a generic rich client application, with specific supplimental support packages addressing requirements typical of rich client apps. This makes it considerably lightweight. In typical Spring fashion, you pick and choose what you need based on your requirements, and we work to simplify the integration of the best of what's out there (and innovate where gaps exist.)

    Congrats to fellow developers Rod, Juergen, Thomas, Colin, Alef, Dmitriy, Darren, Mark (JMS!) on 1.1 RC1!!! And a thanks to the Spring user community for being so active and so positive.
  5. Spring.Net Status[ Go to top ]

    The Spring.NET project is pretty much still in its infancy... at the time of posting, only the Spring bean factory and AOP packages have been ported over and are sitting in the CVS head.

    Work with regard to the Spring context packages is scheduled to begin soon, but a release is still some time away.

    Feel free to join the dev team though and speed the process up ;D
  6. No release date has been set yet. Spring.NET has gotten a real boost lately with some new developers joinings. The base "beans" and AOP packages are the most complete and the context package is the only remaining big chunk of work. Tests have been ported as well. It still needs rounding out, docs, and kicking of the tires, but we are working on it!

    Cheers,
    Mark
  7. JMX Support[ Go to top ]

    Great job!

    I thought JMX support is going to be in Spring 1.1. What's the plan?
  8. JMX Support[ Go to top ]

    I read on springframework-dev (gmane) that this is scheduled after 1.1, initial JMX support is checked in into cvs though.

    Artur
  9. JMX Support[ Go to top ]

    As Jurgen said, JMX support is something we are working on for 1.2. We are already have a good base of code in the sandbox, allowing you expose your Spring beans as JMX beans automatically, with control over the exposed attributes and operations using source level metadata.

    My plan for the next week or two is to refactor the MBeanServer location logic to accomodate both server and non-server based environments, add support for attribute change notifications, increase the number of tests and add some basic support for Spring based adaptor configuration.

    This code is in the sandbox now, and I am working on it quite frequently so new changes should appear fairly regularly. Any feedback or suggestions are more than welcome.

    robh
  10. JMX Support[ Go to top ]

    As Jurgen said, JMX support is something we are working on for 1.2. We are already have a good base of code in the sandbox, allowing you expose your Spring beans as JMX beans automatically, with control over the exposed attributes and operations using source level metadata.
    This is by far the most exciting new feature for me. Spring makes wiring and configuring application components relatively easy. Being able to manage these components at run time via JMX is the logical step. This will be great.

    Good work guys.

    Ryan
  11. JMX support[ Go to top ]

    We are already have a good base of code in the sandbox, allowing you expose your Spring beans as JMX beans automatically, with control over the exposed attributes and operations using source level metadata.
    JMX nails it for me.

    Without wanting to jump the gun too much, can you expand on "source level metadata"? Is this in the application context file or the java source file? Annotations, perhaps?

    Regards
    Kit
  12. Metadata[ Go to top ]

    Source-level attributes (annotations). Spring provides the org.springframework.metadata.Attributes interface to provide a consistent source of attributes, however defined (J2SE 5.0, Commons Attributes etc.) This also allows for dynamic overriding of attribute values (discussed here recently in another thread), which remains necessary even with the advent of core Java annotations.

    Spring provides support for Commons Attributes out of the box, and can use them for attribute-driven declarative transaction management also (see the /attributes directory of the jPetStore sample app). Commons Attributes is a pretty capable solution, but of course does require some changes to application build script. Once they're in place, however, it does incremental attribute compilation and is fast. We have users using Commons Attributes for a variety of purposes, including validation as well as transaction management.

    We'll be adding support for J2SE 5.0 attributes shortly in a preview.

    Rgds
    Rod
  13. JXM and Metadata[ Go to top ]

    Can you explain a little more how this works regarding JMX. Will attibutes define how classes/properties can be manager through JMX. That is, will a developer define whether a property is R/RW through metadata? What is the vision here?

    Ryan
  14. My bad[ Go to top ]

    Can you explain a little more how this works regarding JMX. Will attibutes define how classes/properties can be manager through JMX. That is, will a developer define whether a property is R/RW through metadata? What is the vision here?Ryan
    managed, not manager.

    Ahh, the perils of trying to type to fast.
  15. My bad[ Go to top ]

    Ryan,

    The implementation that we have at the moment is extremely flexible. The basic class is JmxMBeanAdapter that allows you to expose any Spring bean to the JMX MBeanServer. Internally, the JmxMBeanAdapter uses three components to control how the beans are exposed to JMX.

    The naming strategy component controls what ObjectName is given to the bean, currently we have four implementations of this - one that allows you to specify the name in your Spring config file and one that allows you to specify the name as an annotation in your source code.

    The metadata assembler controls how the beans management interface is created an passed to the MBeanServer. The default implementation uses reflection and simply exposes all properties as JMX attributes and all methods as operations. The other implementation provided allows you to specify exactly which operations and attributes you want to expose to JMX using annotations. I will probably add another implementation to read the metadata from an XML file - this allows you to share the same management information across many different beans that implement the same interface with ease.

    The invoker component is responsible for handling invocations on behalf of the MBeanServer, and we have two implementations one using JDK proxy and the other using Cglib.

    On top of these features, JmxMBeanAdapter will (soon) support automatic handling of attribute change notifications an allow you auto register your own MBeans.

    In standalone environment, you can use the MBeanServerFactoryBean to create your MBeanServer for you, so you don't need to include any JMX code in your application at all. Soon you will see support for a variety of adaptors such as those supplied in the reference implementation and for JSR-160 as well.

    For accessing managed resources, you can use the JmxObjectProxyFactory implementations to allow you to work with a proxy. Currently I have committed just the Cglib implementation but JDK proxy will follow soon. Using a proxy for JMX is actually quite a good idea, becuase the extra overhead of the proxy is vert little compared to the invocation against the MBean server, and it makes your code much clearer.

    Currently the ModelMBean implementation in Spring is a little of spec, but I just need to run through the spec and ensure that I have everything covered.

    More features are planned but this is the framework for my next few weeks coding.

    Rob
  16. Congratulations![ Go to top ]

    Congratulations on a major new release! I'm especially excited about the new JDO enhancements. They made a huge difference to the development of the Spring/JDO Sample app and will make using JDO with Spring much easier. A lot of our clients are turning on to Spring, which is turning out to be good news for them AND us.

    For those of you interested in looking at how Spring and JDO can be used together, you can download a sample web application that uses both from www.solarmetric.com and also from the Spring web site. The sample uses a lot of the new Spring/JDO APIs.

    Thanks for all of your effort!

    Greg Campbell
  17. We have used Spring 1.0 on two of our projects now, and the improvements in the quality of the code have been incredible. Using Spring to tie the layers of application together, and using interfaces, and using the DAO Support classes has made the world of difference. The amount of code that needs to be written is much less, the application structure is much more well organised, and the loose coupling makes it easier to introduce third party tools such as Hibernate and iBatis.

    Spring is making it much easier for the every day programmer to get into technologies that would have previously been too time-consuming, and therefore difficult to sell to management.

    I just bought a book on JMS so I can't wait to have a look at what JMS support Spring will be offering.
  18. Here, here[ Go to top ]

    +1
  19. Rod is an Aussie?[ Go to top ]

    I just discovered Rod is a fellow Australian! Go Aussie!
  20. ROD?[ Go to top ]

    LOL - you said "rod"
  21. Rod is an Aussie?[ Go to top ]

    I just discovered Rod is a fellow Australian! Go Aussie!
    And Gavin King (Hibernate) is an Aussie!
    We may have lost the Rugby World Cup but hey....

    Congrats to the Spring Team, it is going from strength to strength
    and is putting the enjoyment back into programming for me.
  22. No matter where is he from, he is Java, J2EE guy... like we guys!!!
  23. Rod is an Aussie?[ Go to top ]

    I just discovered Rod is a fellow Australian! Go Aussie!
    Ah, that explains why "The Spring team ARE happy to announce..." rather than the "The Spring team IS happy to announce...".
  24. Rod is an Aussie?[ Go to top ]

    http://www.learnenglish.org.uk/grammar/archive/collective_nouns.html

    A bit off-topic, but thanks for pointing out another of the differences between British/Australian and US usage. I'll remember for my next book...

    R
  25. JMS![ Go to top ]

    I have not tried it out yet but if we can now send/receive JMS messages then the only reason I had for using EJB's is gone. Has anyone seen any reviews yet? I know that it may be a bit early...
  26. Spring Framework 1.1 RC1 released[ Go to top ]

    Congratulations to all involved.

    How is the portlet support progressing? Is this planned for inclusion in the 1.1 final?
  27. How is the portlet support progressing? Is this planned for inclusion in the 1.1 final?
    Portlet support is planned for Spring 1.2. There is a working version in our CVS sandbox, but it doesn't cover all targeted functionality yet. Furthermore, some API details are still subject to change.

    Note that 1.1 final is scheduled for as early as mid August, so do not expect major new features there. The final release will mainly be about completed documentation and samples, and of course fixes for reported issues.
    I thought JMX support is going to be in Spring 1.1. What's the plan?
    JMX support is scheduled for Spring 1.2 too; initial work is already in our sandbox. Essentially, Portlet and JMX support will be two of the cornerstones of Spring 1.2, scheduled for October.

    Juergen
  28. JMX support is scheduled for Spring 1.2 too; initial work is already in our sandbox. Essentially, Portlet and JMX support will be two of the cornerstones of Spring 1.2, scheduled for October.Juergen
    Looks like by version 1.2 Spring is going to be an J2EE container without Entity beans…Hmm
  29. Looks like by version 1.2 Spring is going to be an J2EE container without Entity beans
    If you care to advance any specific arguments here I'll be happy to reply to them.
  30. Looks like by version 1.2 Spring is going to be an J2EE container without Entity beans
    If you care to advance any specific arguments here I'll be happy to reply to them.
    Rod, I do not have specific arguments against Spring (except use of non-checked exceptions) I rather expressed my overall feelings about the project. Those feelings have roots in my observations of many projects which were extremely good initially, but become less usable and convenient and robust as they tried to scale (up or down) and gain more and more features they started encounter more and more problems associated with that new horizon.
    Examples:
    MS-Dos/Win – initially was positioned as easy to use alternative to other OSes, as MS started to scale it up, they have encountered set of “enterprise” grade problems and …
    XML-RPC - initially was positioned as easy to use alternative to CORBA, and at this moment stack of SOAP-related protocols is more complex than CORBA, less efficient and less feature rich. Now we hear talks about ‘binary’ SOAP :)
    I could continue, but I hope you see my point.
    I wish Spring be a lucky exception and know its niche, scope and scalability.
  31. MS-Dos/Win – initially was positioned as easy to use alternative to other OSes, as MS started to scale it up, they have encountered set of “enterprise” grade problems and …
    MS-DOS was originally called QD-DOS (Quick and Dirty), before Microsoft purchased it from a Seattle based company. At that time all the other alternatives to DOS systems cost >$500, Microsoft sold QD-DOS for $50.

    So, MS-DOS was intially postioned as a cheaper alternative to other OS on the market. As for the scale problems, who cares about that as long as you own the market?

    Tim
  32. Konstantin,
    Rod, I do not have specific arguments against Spring (except use of non-checked exceptions) I rather expressed my overall feelings about the project. Those feelings have roots in my observations of many projects which were extremely good initially, but become less usable and convenient and robust as they tried to scale (up or down) and gain more and more features they started encounter more and more problems associated with that new horizon.... I could continue, but I hope you see my point. I wish Spring be a lucky exception and know its niche, scope and scalability.
    There is always a danger of feature creep/bloat. We believe that Spring's modular architecture helps to guard against that, but of course we also need to be careful in maintaining our focus. For example, we maintain a clean separation of modules. E.g. the core IoC container does not depend on features such as AOP, data access functionality etc. JMS and JMX will similarly be modules that sit on top of the core without complicating the configuration model, adding dependencies to existing application etc. And the goal of a "non-invasive" framework means that we can evolve the framework substantially without impacting applications.

    Rgds
    Rod
  33. Spring Framework 1.1 RC1 released[ Go to top ]

    Konstantin,

    I believe that Rod is correct in his assertion that none of the new features will impact on Spring's modularity. It is interesting to see how easy it is to write new major additions to Spring, such as JMX, without having to make ANY changes to the Spring core whatsoever.

    If anything this is a testament to the quality and modularity of the existing framework - when you can make major additions with no modifications to the core then clearly something is being done right!

    Because of the way Spring is packaged you are free to choose just the components you require and the rest can be left out of your application.

    Rob
  34. Spring Framework 1.1 RC1 released[ Go to top ]

    We believe that Spring's modular architecture helps to guard against that, but of course we also need to be careful in maintaining our focus. For example, we maintain a clean separation of modules. E.g. the core IoC container does not depend on features such as AOP, data access functionality etc. JMS and JMX will similarly be modules that sit on top of the core without complicating the configuration model, adding dependencies to existing application etc. And the goal of a "non-invasive" framework means that we can evolve the framework substantially without impacting applications.RgdsRod
    This is the so often spoken about "good design" but so hard to achieve. I am astonished when I look at how Spring evolved and how well defined are it's component's responsibilities. There it is already almost a full stack of enterprise features built on Spring core. From what I read in the development lists Spring RCP will change the way most of us write enterprise desktop clients just as Spring changed the way we develop server side apps.

    You guys totally rock !
  35. Spring J2EE Container[ Go to top ]

    JMX support is scheduled for Spring 1.2 too; initial work is already in our sandbox. Essentially, Portlet and JMX support will be two of the cornerstones of Spring 1.2, scheduled for October.Juergen
    Looks like by version 1.2 Spring is going to be an J2EE container without Entity beans…Hmm
    Sounds like a good idea to me.

    Just shooting from the hip - Could AOP be applied to html/javascript/css:

    Form/Input tags - could the usage of <spring:bind> tags be replaced by using AOP against forms and input fields. Also anchors, css, etc...
  36. Looks like by version 1.2 Spring is going to be an J2EE container without Entity beans…Hmm
    What about web services support? That will do away with session beans too...
  37. Looks like by version 1.2 Spring is going to be an J2EE container without Entity beans…Hmm
    Spring is by definition not a J2EE container and will never become one - it is an application framework that may or may not run on top of a J2EE server (or a J2EE-compliant web container like Tomcat). It helps to decouple your applications from concrete J2EE dependencies, though.

    In particular, Spring does not provide low-level system services like:
    - an HTTP server
    - a servlet container
    - a JSP engine
    - a JTA distributed transaction coordinator
    - a connection pool
    - a JMS provider
    - a JMX server
    - application separation through classloaders
    - etc

    but rather relies on running on top of a J2EE server for these. Alternatively, you can plug in third-party standalone implementations of those services. When we talk about JMS support, JMX support, etc, we "just" refer to providing easy Spring-style access to those services.

    As an example, Spring will never ship an own JMS provider. It allows to leverage the JMS provider of your J2EE server, just like you would expect. Alternatively, it allows to plug in a standalone provider (e.g. OpenJMS) in a straightforward manner, when running in a non-J2EE environment.

    Furthermore, Spring does not ship an own O/R mapping solution, but rather allows for seamless plugging in of Hibernate, JDO, Apache OJB, iBATIS SQL Maps, or effectively any other data access tool. I see that you already noticed that because you said "J2EE container without entity beans" ;-)

    Juergen
  38. Spring Framework 1.1 RC1 released[ Go to top ]

    My heartiest congratulations to Spring's team (Rod, Juergen et al) for delivering such a magnificient framework. Kudos!!! IMHO, Spring is a framework bearing a Stamp of quality and professionalism, plus good documentations, and a vibrate user & developer community. But Beware, just like cafein, it is addictive, once one get the hang of it, one will never want to loose it. ;-)

    regards
    tmjee
  39. Spring Framework 1.1 RC1 released[ Go to top ]

    Support for sending and receiving JMS messages*
    Can you please detail a little bit. It'll pass some time until I'll have the time to download the 1.1 and it seems I can't find any quick docs on this on springframework.org.

    Is the JMS support tied to a particular implementation or you can plug in any JMS implementation ? Can you point out some docs/code samples on this ?

    Btw. Great job, congrats :-) It seems Spring has a lot of momentum and gains more and more acceptance...
  40. JMS support[ Go to top ]

    See the Spring Reference Manual for more details on JMS support. There are more features planned for 1.2.

    Rgds
    Rod
  41. Is the JMS support tied to a particular implementation or you can plug in any JMS implementation ?
    It uses pure JMS API: You pass a JMS ConnectionFactory - typically fetched from JNDI - to a JmsTemplate instance. Then you can invoke operations on the template, for example for sending a message. This will work nicely both within a J2EE environment and with a standalone JMS implementation.

    The destination parameter as expected by send methods will typically be a JMS Destination fetched from JNDI too. Alternatively, there also is a destination name resolution mechanism that can resolve symbolic names to actual JMS Destinations, either creating dynamic destinations or doing JNDI lookups.

    Juergen
  42. Juergen thanks. Rod thanks fpr the link, it seems the online reference is much more up to date than the one I downloaded with the previous version of Spring.
  43. How come Juergen did not get to have his picture on the cover? :-)
  44. good work![ Go to top ]

    Congrats, guys :-)
  45. Martin Fowler[ Go to top ]

    An interesting artice about IOC can be found here http://www.martinfowler.com/articles/injection.html

    Thanks

    Ian Purton
    Managing Director
    http://www.alertrobot.co.uk