Discussions

News: Rod Johnson interview by Dion Almaer

  1. Rod Johnson interview by Dion Almaer (24 messages)

    Javapolis has published an interview of Rod Johnson conducted by Dion Almaer. In this interview Rod talks about the many new features found in Spring 2.0 as well as how their in addition of the impact that Adrian Colyer has had on the evolution of the framework.

    In the interview, Rod stresses the efforts they have made to ensure that Spring 2.0 is fully backwards compatible. As Spring 2.0 is a non-invasive framework, the decoupling means it can be improved without breaking your application code. However there will be many new features that Rod expects that people will take advantage of.
    if you're defining are defining arbitrary objects we think that people will continue to use the bean mechanism and you know that it is a basic mechanism for Spring and you know that it is obviously always going to be supported. But the differences will be that we expect people to be define AOP using the new XML simplification. We expect to see people using that to make objects transaction rather then for example directly using ProxyFactoryBean or one of the older proxy creators that we see at present.


    The biggest changes will be in how Spring 2.0 works with respect to AOP. The XML extension mechanism should simplify common tasks and provide a simplified means to extend Spring. These changes include a dedicated tag to support JNDI lookups. Rod talks about how these types of changes will make it easier to do repeated tasks as well as make Spring more amenable for tooling.

    In addition, Rod has been working very closely with Adrian on integrating AspectJ. He was happy with the point cut Java API but felt that the point cut expression language support in Spring has been weak. Spring 2.0 addresses this weakness. Also the cumbersome nature of the XML configuration of aspects has been tackled. The integration is such that Spring will auto-detect AspectJ annotations and weave them in. But that same code and be compiled and run with AspectJ. This should bring additional advantages to the AspectJ community as well.

    Two new aspects will be included in Spring 2.0, dependency injection ofr objects not created by Spring and a transaction aspect which apparently can be used without the Spring container. In addition there will be new scoping methods to include new life cycles, singleton and prototype. Singleton will tie and object to the lifetime of the container where as prototype will create a new instance for every new reference.


    You can view the interview (Login required) or download the podcast @ http://www.javapolis.com.

    Threaded Messages (24)

  2. Congratulations. I love spring, I like it, I use it, but... isn't any idea for non-XML configuration?

    I'm developing a website with Wicket 1.2rc3, Hibernate 3.1.3 and Spring 1.2.8. And there's only two XMLs in my source tree:

    - applicationContext.xml
    - web.xml

    Here are some details:
    - hbm.xml? Nope! Hibernate EJB 3.0 Annotation support!
    - Dependency injection of beans into Wicket's webpages with @SpringBean from wicket-spring project.
    - Transactional declaration into beans with @Transaction annotation from Spring.
    - Schema Export auto-updates database.

    Is it so difficult to understand that there's somethings that can be done without XML? Maybe Spring Framework could steal (with owners concern, of course) some of the ideas Pico Container has.
  3. Congratulations. I love spring, I like it, I use it, but... isn't any idea for non-XML configuration?I'm developing a website with Wicket 1.2rc3, Hibernate 3.1.3 and Spring 1.2.8. And there's only two XMLs in my source tree:- applicationContext.xml- web.xmlHere are some details:- hbm.xml? Nope! Hibernate EJB 3.0 Annotation support!- Dependency injection of beans into Wicket's webpages with @SpringBean from wicket-spring project.- Transactional declaration into beans with @Transaction annotation from Spring.- Schema Export auto-updates database.Is it so difficult to understand that there's somethings that can be done without XML? Maybe Spring Framework could steal (with owners concern, of course) some of the ideas Pico Container has.

    Here is the problem. What if you don't want to markup all the code with annotations, especially annotations that belong to a particular product, like Wicket-spring.

    I personally feel that the XML complaints in Spring in particular and frameworks in general are overblown.

    We had a minor problem with a transaction declaration that was set to read-only using Spring There was a block of code that an 'if' condition that was doing an insert and that if condition was missed in testing. During training, it was encountered. The fix was an easy XML change and bounce of the app, not a full recompile to pick up the annotation.

    We use annotations for things like Hibernate to markup domain objects with OR mapping information, but I prefer the XML for tranactions and other AOP markup.
  4. Let me just complete my post:

    I don't want to see a future Spring version without XML configuration.

    For real, I would like to see a new feature that could give me the option to not use the XML. :)

    And as I am a person who doesn't make changes to a project and publish it to production without doing a full build (compiling again; and testing again; and tagging a new version in CVS; and etc...), I'm not worry about losing the possibility of just opening an xml in VI and doing the properly changes.
  5. Let me just complete my post:I don't want to see a future Spring version without XML configuration.For real, I would like to see a new feature that could give me the option to not use the XML. :)And as I am a person who doesn't make changes to a project and publish it to production without doing a full build (compiling again; and testing again; and tagging a new version in CVS; and etc...), I'm not worry about losing the possibility of just opening an xml in VI and doing the properly changes.

    Well, we have imperfect humans testing imperfect code,and needed the ability to fix a file in an emergency situation as opposed to having dozens of people sit idlely by while the full deployment process unwinds itself.

    Regardless, the XML options in Spring, I feel, are fine. Besides, you already can forego the XML configuration in Spring.
  6. Yes, that's right, I prefer XML over annotations for Spring and Hibernate configurations. I find that it separates concerns better, is more logical to maintain and eliminates the dependancy upon deployment scripts during development. I sure hope neither Spring nor Hibernate ever *require* the use of annotations...
  7. Yes, that's right, I prefer XML over annotations for Spring and Hibernate configurations. I find that it separates concerns better, is more logical to maintain and eliminates the dependancy upon deployment scripts during development. I sure hope neither Spring nor Hibernate ever *require* the use of annotations...

    Agree with you, annotations should be mostly used for declarative programming and not for configuration.

    To me, configuration is when you can change freely some values without having to change anything in the source code (for example Spring dependency injection). Hence the change doesn't have any impact on the code. Declarative programming is different because changing a value means you also have to change some code (for instance declaring an EJB stateless or statefull or declaring a method is a WebService). In this case it doesn't make any sense to separate the meta data from the code since the two are closely linked. But Spring xml files are truly configuration files.
  8. +1

    Please... Spring, Hibernate team... Do not go this way. It clear that having XML file separated from Source Code is a "Good Thing"(tm).

    Having Source code anotated with @things, get really messy. Loosely Coupling anyone???... do you remember!!!! dahhh!!.

    Regards,
       -Rory.
  9. Well, we have imperfect humans testing imperfect code,and needed the ability to fix a file in an emergency situation as opposed to having dozens of people sit idlely by while the full deployment process unwinds itself.

    Really? If you can't do a build and deploy in a very short time in a controlled manner, you should seriously consider fixing your build process.
  10. Give him a break: the guy's an architect. He knows better then me what style I prefer (or *should* prefer) and what makes me productive. He's a better programmer--than anyne around. He's a design God who doesn't even have to understand my problem in order to offer the universal solutions. He just likes technology X and that's it; how dare you argue, and what's that you don't you understand? He doesn't even have to know technical stuff, really: that's not required in order to be able to pontificate.

    Arguments are pointless: the guy's an architect--much like Art Vandelay (cf., the Seinfeld series)
  11. Well, we have imperfect humans testing imperfect code,and needed the ability to fix a file in an emergency situation as opposed to having dozens of people sit idlely by while the full deployment process unwinds itself.
    Really? If you can't do a build and deploy in a very short time in a controlled manner, you should seriously consider fixing your build process.

    Our build process is fine, but thanks for the unsolicited advice. The facts are that
    1) having to recompile and rebuild code for configuration is foolish. You're welcome to all the foolishness you can endure.

    2)It was not possible to put a build up and no matter how fast the process was, it was too slow for the situation.

    3) Springs configuration files allowed us to successfully salvage the situation and please our customers.
  12. Our build process is fine, but thanks for the unsolicited advice.

    Heh. Isn't posting on dicussion forums great?
    The facts are that 1) having to recompile and rebuild code for configuration is foolish.

    No, it's not. It's very simple really. Even the tiniest project should have an automated build process, whether using ant, maven, or whatever batch file to do the job. Any project of any importance should have a seperate deployment environment which you shouldn't touch directly. These principles are almost as old as software engineering itself.
    2)It was not possible to put a build up and no matter how fast the process was, it was too slow for the situation.3) Springs configuration files allowed us to successfully salvage the situation and please our customers.

    I'm sure you had a good reason, and rules are there to be broken, but saying that XML configuration is great because you can tweak runtime environents is just bs. If you need to tweak at runtime, expose something purposefully, like throught a couple of JMX beans.
  13. +1

    Having a clean Java bean API exposed gives you options. While XML configuration is obviously the most popular solution, embedded scripting languages provide a powerful alternative. A configuration script can be very expressive, too. Some good examples are WLST from BEA (uses Jython), DynaOp (BeanShell), and to some extent JINI config.
  14. No, it's not. It's very simple really. Even the tiniest project should have an automated build process, whether using ant, maven, or whatever batch file to do the job. Any project of any importance should have a seperate deployment environment which you shouldn't touch directly. These principles are almost as old as software engineering itself.
    Again, thinks for the unsolicited less, but we have an automated process. I've never heard of any software principle, old or otherwise, that states that setting things like "temp" upload directory paths or perhaps cache settings should be tied to a build process.

    To me, that is a configuration options. Perhaps ou should ask the people who wrote whatever software you are using to force you to endure an automated build process whenever you want to change, say the install directory.
    I'm sure you had a good reason, and rules are there to be broken, but saying that XML configuration is great because you can tweak runtime environents is just bs. If you need to tweak at runtime, expose something purposefully, like throught a couple of JMX beans.

    No, that was one reason. Also, what I said was that I think the problems of attributed to Spring's XML are overstated. I don't think you are exposing anything, I simply feel that having to rebuild that app for configuaration is annoying at best.

    I think that the configurations, if done correctly and especially with that even the first generation tool support available, makes it, in fact, very easy to understand the application.

    You don't agree? Hey, knock yourself out. I don't have to maintain your stuff! :)
  15. I never said that _all_ of the configuration should be written outside XML (or better saying: inside the Java program). I just said that would be nice to have another way to do some simple things like DI sessionFactory with DAOs for example (remember Pico?).

    And I'm using @Transactional because I don't have nested Services persisting things dependently... So I don't have to fill the annotation with lots of parameters. It keeps the class code simple and clean and I don't have to configure transactional beans/methods in the XML.

    Repeating: it would be nice to have some options be "codeable" or _configurable_ by Java API and keep the XML very small, with things that are more generic and associated with options like Cache, stuffs that Beans doesn't have to care about.
  16. No, that was one reason. Also, what I said was that I think the problems of attributed to Spring's XML are overstated. I don't think you are exposing anything, I simply feel that having to rebuild that app for configuaration is annoying at best.

    No, you are totally missing my point. I was not ranting against XML configuration at all. I wasn't even suggesting that your build process has to re-compile your code every time you deploy. What I was sugesting is that you should have a clear distinction between your development and production environment, meaning that any change you're gonna make to it is either meant to be available for changing in that environment (like expose it through JMX, or use JNI or whatever), or you should just do it by at least repackaging and putting it through whatever minimal process you have in mind to throw it from a development (to test) to production environment. Anything like e.g. tweaking JSP files, Spring xml configuration files and whatever (I suppose you don't deploy you web apps as war files as that prevents you from directly editing it?) is just plain amateurism to me. I'm not saying you should burn in hell because you did that - probably most of us have done that at some point of our carreers, but I am saying that you are selling crap if you are defending having XML configuration as that will enable you to make changes in your production environment.
  17. A couple of points I find real confusing:

    1. What is the difference between "static configuration" and normal code? I remember C programs that had a big "initialise" procedure that configured everything. Wasn't that configuration?

    2. Many people that will argue passionately against dynamic languages are more than happy to use XML because of it's "runtime" advantages despite no dynamic checking at all.

    It seems to me that people tend to have a narrow view of what is possible based on what they currently do/know.

    It reminds me of the saying "if the only tool you have is a hammer, then every problem will look like a nail". I think that this is true for static languages and XML.

    IMO XML (and now annotations) are often used to deal with deficiences in the base language rather then addressing the language limitations head on(runtime binding, meta model etc), or even just using a different language.

    IoC Containers have been experimenting with so called scripting languages for "configuration" for a while, this seems a much more promising approach IMO. Then again you could choose to go all the way and use a base language like Ruby instead.

    Paul.
  18. Java configuration[ Go to top ]

    IMO externalizing configuration often makes most sense; as other posters have pointed out, it's not feasible to abandon that in complex apps. However, there are different types of configuration, and Java is appropriate to expressing some of them.

    I have a working prototype of a Java configuration option for Spring. This is not designed to replace XML configuration, but to complement it. It produces the same metadata, so it's possible to mix and match Java and XML configuration. (And potentially other types, such as database configuration.) There is no need to change Spring internals. Java configuration will enable beans to be configured in Java configuration files, with annotations in Java configuration files rather than mainline code. The core Spring team think this is very promising; as soon as the big push to get Spring 2.0 out the door is over we will try to get it ready for prime time and some user feedback.

    Note that Spring's internal metadata and all the ApplicationContext and BeanFactory implementations are independent of XML.

    With the Spring 2.0 feature set, I would expect typical XML configuration files to be significantly smaller. Note also that the elegant @AspectJ annotation-style syntax enables AOP constructs to be put in Java, as well as XML.

    Btw Spring 2.0 will be released shortly after Java One. The current 2.0 M4 is quite useable in development.

    Rgds
    Rod
  19. Java configuration[ Go to top ]

    IMO externalizing configuration often makes most sense; as other posters have pointed out, it's not feasible to abandon that in complex apps. However, there are different types of configuration, and Java is appropriate to expressing some of them.I have a working prototype of a Java configuration option for Spring.

    I like the idea of "configuration" being in the native programming language. In a sense much of this configuration can be considered a DSL. Dynamic languages like Ruby seem to better support the idea of DSLs, but it is feasible to a lesser degree in Java too.

    PicoContainer supports Java configuration and for a lot of things I find it preferrable to angle brackets (XML). My preference would be for better support for meta-programing within the Java language itself (I don't like annotations), that way I'm sure there would be less need for XML.

    Paul.
  20. Java configuration[ Go to top ]

    IMO externalizing configuration often makes most sense; as other posters have pointed out, it's not feasible to abandon that in complex apps. However, there are different types of configuration, and Java is appropriate to expressing some of them.I have a working prototype of a Java configuration option for Spring.
    I like the idea of "configuration" being in the native programming language. In a sense much of this configuration can be considered a DSL. Dynamic languages like Ruby seem to better support the idea of DSLs, but it is feasible to a lesser degree in Java too.PicoContainer supports Java configuration and for a lot of things I find it preferrable to angle brackets (XML). My preference would be for better support for meta-programing within the Java language itself (I don't like annotations), that way I'm sure there would be less need for XML.Paul.

    I think java is better when your configuration is based upon a lot of processing and conditional logic. But if your configuration is totally static, XML is more concise then Java. So I am quite happy, we are going to be able to mix them together in the version 2.0. Just my two cent but I am eager to see what the Spring team has to offer. They know better then me :)
  21. Java configuration[ Go to top ]

    IMO externalizing configuration often makes most sense; as other posters have pointed out, it's not feasible to abandon that in complex apps. However, there are different types of configuration, and Java is appropriate to expressing some of them.I have a working prototype of a Java configuration option for Spring. This is not designed to replace XML configuration, but to complement it. It produces the same metadata, so it's possible to mix and match Java and XML configuration. (And potentially other types, such as database configuration.) There is no need to change Spring internals. Java configuration will enable beans to be configured in Java configuration files, with annotations in Java configuration files rather than mainline code. The core Spring team think this is very promising; as soon as the big push to get Spring 2.0 out the door is over we will try to get it ready for prime time and some user feedback.Note that Spring's internal metadata and all the ApplicationContext and BeanFactory implementations are independent of XML. With the Spring 2.0 feature set, I would expect typical XML configuration files to be significantly smaller. Note also that the elegant @AspectJ annotation-style syntax enables AOP constructs to be put in Java, as well as XML.Btw Spring 2.0 will be released shortly after Java One. The current 2.0 M4 is quite useable in development.RgdsRod

    How would this look? Is there a example, that is small so as not to inconvenience, that you can put up?
  22. Java Configuration[ Go to top ]

    I'm new to Spring (just started looking at it) which is why I am asking this, but is the configuration not an interface that can be implemented in various ways eg. on top of xml, a scripting language or just plain Java configuration?

    Some of the above answers seem to hint that it is.
  23. Java Configuration[ Go to top ]

    is the configuration not an interface that can be implemented in various ways eg. on top of xml, a scripting language or just plain Java configuration?Some of the above answers seem to hint that it is.

    You can write your own implementation of the 'configuration' interface, which is called BeanFactory. I'm assuming that the Spring team is doing just that for the Java configuration support in 2.0.

    From the Javadoc:

    Normally a BeanFactory will load bean definitions stored in a configuration source (such as an XML document), and use the org.springframework.beans package to configure the beans. However, an implementation could simply return Java objects it creates as necessary directly in Java code. There are no constraints on how the definitions could be stored: LDAP, RDBMS, XML, properties file etc. Implementations are encouraged to support references amongst beans, to either Singletons or Prototypes.
  24. Java Configuration[ Go to top ]

    You can write your own implementation of the 'configuration' interface, which is called BeanFactory. I'm assuming that the Spring team is doing just that for the Java configuration support in 2.0.

    It's actually even more fine-grained: We reuse the entire DefaultListableBeanFactory as-is and just implement a bean definition reader that populates that BeanFactory in a different fashion. The management of runtime bean definitions and bean instances is completely separated from the reading of bean definitions from source files.

    You can already see this in Spring 1.2, where the XML parsing logic resides in an XmlBeanDefinitionReader that gets applied to a DefaultListableBeanFactory. We already ship a PropertiesBeanDefinitionReader as alternative, for example. The BeanFactory implementation itself operates purely on BeanDefinition Java objects, not being tied to any particular definition source format (such as XML).

    Juergen
  25. Dev Diff Doc == null[ Go to top ]

    Apologies for the disrespectful title, Spring's great (awesome! ) and I know very well writing good Doc is a pain, if only for the time it consumes (also knowing what the extra code equivalent might have been)

    Yet... has Interface 21 any plans for writing a kindof "Developer's Difference Documentation" ?
    Very brief, to the point, let's say max 30 pages, focussing specifically on the differences between Spring version 1 & version2.
    Newcomers will have to read the entire doc anyway, but...
    To get all of us devs already using v1, up-to-speed & start using v2 in efficient fashion, I think this would be a fine idea.
    Thx,
    Phil
    (ps know I'm asking a lot, but this would even ideally come out before the GM comes out --> this way we can prepare ourselves & start using it the day it is released)