Discussions

News: iSeeSpring - NetBeans plugin to visualize Spring DI

  1. iSeeSpring - NetBeans plugin to visualize Spring DI (12 messages)

    I started a Spring IDE module for NetBeans, inspired by a number of other recent projects. Spring is great, but applications with more than 1000 beans are awful to read, especially if the project is configured by more than one Application Context, as seems common. Even a small project with about 50 beans to configure needs a visualization of the configured dependencies. The NetBeans Spring Ide supports readability and documentation of Spring based applications. The main interest of my activities are visual tools to improve customization, configuration and readability and last but not least documentation of a Spring based solution. The current version is a pre-alpha, but it is on its way. It's based on the NB VisualLibrary 2.0 and supports XML Context Navigation and Visualization of the DI web with some palette functions. If you would like to contribute to this project, contact me at Dirk dot Rost at appshare dot net. Message was edited by: joeo@enigmastation.com
  2. Spring is great, but applications with more than 1000 beans are awful to read, especially if the project is configured by more than one Application Context, as seems common.
    I have an experience with XML-based Spring configurations and after 100 beans it becomes simply unmanageable. It is very hard to understand dependencies; you lose the ability to 'find references', 'refactor' and other features of Java language. You ask yourself all the time: 'How will Spring act if I do it like that?' A configuration with 1000 beans is just a disaster. I really don't understand why would you prefer XML-style coding to Java coding. The bottom line is that Spring becomes a headache in a big project and is completely unscalable. Want to kill a project - use Spring. In most cases it is enough to specify a factory class (which is analogous to Spring context). In this class you can initialize all required properties in Java language, which will detect most of your problems at compile time, will be refactorable and will have the full support of a Java IDE. Also, all Spring-based files are completely unreadable and are not at all type safe: 10.12.11.254 5001 Looking at this I'm thinking: what the hell these consructor-args are about? Are they type-safe? This is enough for me to say that Spring should be avoided. It 'looks' good but in real life it isn't.
  3. you lose the ability to 'find references', 'refactor' and other features of Java language.
    No you don't. There are tools to do this, such as the Spring IDE for Eclipse.
    I really don't understand why would you prefer XML-style coding to Java coding.
    Because configuration should be more dynamic than compiled code.
  4. you lose the ability to 'find references', 'refactor' and other features of Java language.


    No you don't. There are tools to do this, such as the Spring IDE for Eclipse.
    Are you using Spring XML configuration files as an end user configuration? Is user happy about creating Spring files? My personal opinion that end user's configuration should be as simple as: server.mode=production server.host=10.20.30.40 server.port=100 instead of 10.20.30.40 100


    I really don't understand why would you prefer XML-style coding to Java coding.


    Because configuration should be more dynamic than compiled code.
    If we speak about a configuration on the developer's side, than you need to recompile and redeploy your application anyway to make these changes effective. XML does not have any advantages here because it is redeployed just like Java classes.
  5. I dont see your issue Sergei. Use PlaceHolderConfig for this kind of configuration. And YES, Spring will convert automatically the data Type to the java type. No big deal here. And I dont see how you can have 500-1000 spring beans inter-connected, must be a big and messy project. Neither EJB, Simple Java, etc, would have help you. It is a design issue. Usually, you should define some layers of interaction, 500 beans should not communicate together on the same level. If you dont like XML, instead of using XML, use annotation? Dont use the arg-constructor, for simple usage, I hate that, use parameter injection instead. It is simpler. Your bean are more POJO like. And if you plan to create a Factory, this is exacly what is doing Spring, but in better. Use Spring as a simple Object Factory. Anyway, I look forward to see the new Spring IDE. Regards, Etienne Laverdiere Paris
  6. Replace 500 beans by 100 beans = same issue.
  7. you lose the ability to 'find references', 'refactor' and other features of Java language.


    No you don't. There are tools to do this, such as the Spring IDE for Eclipse.


    Are you using Spring XML configuration files as an end user configuration? Is user happy about creating Spring files? My personal opinion that end user's configuration should be as simple as..[..] If we speak about a configuration on the developer's side, than you need to recompile and redeploy your application anyway to make these changes effective. XML does not have any advantages here because it is redeployed just like Java classes.
    The kind of configuration Spring allows can't easily be reduced to properties files; it is problematic to represent large lists and maps that way, for example. XML has advantages over Java for configuration by developers because it is designed for the markup of data. Also, avoiding the use of Java in this situation means that you often don't have to recompile and redeploy to make changes effective, any more than is required with properties files.
  8. My personal opinion that end user's configuration should be as simple as:

    server.mode=production
    server.host=10.20.30.40
    server.port=100
    As already mentioned, it's trivial to do this using Spring. A common practice is to pull out such deployment-related properties into a single properties file that can be easily edited. And of course, you can always use Java to configure Spring. It's very easy to do, and I know the Spring folks are creating an annotation-based way to make it even easier to do in Java. Of course, you lose the ability to reconfigure without recompiling, but at least you won't have to hyperventilate about how awful the XML is. Spring configuration - or any configuration, for that matter - will get difficult to manage as it grows. That's true of just about anything - the more you have of it, the more difficult it is to manage - like money, or clothes, or kids. People make tools to help deal with these difficulties (except for kids), such as the tool mentioned in this post. I'd also wager that no one would be writing tools for Spring if it didn't work in "real life" (which was a very amusing comment).
  9. And of course, you can always use Java to configure Spring. It's very easy to do, and I know the Spring folks are creating an annotation-based way to make it even easier to do in Java. Of course, you lose the ability to reconfigure without recompiling, but at least you won't have to hyperventilate about how awful the XML is.
    Or use Groovy. No XML, but still no re-compiling: http://grails.org/Spring+Bean+Builder
  10. It 'looks' good but in real life it isn't.
    Oh and you are the authority on 'real life'.... Not every object in a application that uses Spring needs to be a spring bean(!). If you have to many configured beans and you are finding it confusing then you have messed up your design. As with any framework Spring should only be used to the extent that its make your app more managable/flexible/understandable. If it doesn't you are not using it correctly.
  11. Would i be able to use this tool to handle DAO,Remoting and other components of Spring? Specifically JavaSpaces spring modules – JavaSpaces Spring modules It could be a nice add-on to our users who are already using our GigaSpaces sprig integration for scaling out their statefull applications. Nati S. GigaSpaces
  12. I think it's quite obvious but somehow it was confused: you don't have recompile your app if you change XML configuration (Spring or something else). In some cases you would need to re-start the app and in some cases you just need to instruct it to reload the configuration. If you embed configuration in Java code – you will HAVE TO recompile in all cases. In my opinion, Spring Configuration probably accounts for 90% of all usage of Spring and it's well done configuration framework that has a good type checking (although at runtime). Good Junits will spot most of the type-related errors almost as good as a compiler. Regards, Nikita.
  13. What is the diffrence between the project spring-netbeans.sf.net and this?