Comments on: Creating a Spring 2.0 namespace? Use Spring's AbstractBeanDefintionParser hierarchy. http://blog.springsource.com/2006/08/28/creating-a-spring-20-namespace-use-springs-abstractbeandefintionparser-hierarchy/ The voice of SpringSource Tue, 06 Jan 2009 23:33:57 +0000 http://wordpress.org/?v=2.6.2 By: Adding Support for Custom Namespaces at Spring IDE Blog http://blog.springsource.com/2006/08/28/creating-a-spring-20-namespace-use-springs-abstractbeandefintionparser-hierarchy/#comment-17523 Adding Support for Custom Namespaces at Spring IDE Blog Thu, 05 Apr 2007 14:01:39 +0000 http://blog.interface21.com/main/2006/08/28/creating-a-spring-20-namespace-use-springs-abstractbeandefintionparser-hierarchy/#comment-17523 [...] Since version 2.0 Spring supports an XSD-based configuration approach that allows integrating your own DSL for configuration into Spring. How to implement such namespace extension has been documented and the approach has been adopted by several Spring sub-projects and others, e.g. Spring Web Flow and DWR. [...] [...] Since version 2.0 Spring supports an XSD-based configuration approach that allows integrating your own DSL for configuration into Spring. How to implement such namespace extension has been documented and the approach has been adopted by several Spring sub-projects and others, e.g. Spring Web Flow and DWR. [...]

]]> By: Interface21 Team Blog » Why the name Acegi? http://blog.springsource.com/2006/08/28/creating-a-spring-20-namespace-use-springs-abstractbeandefintionparser-hierarchy/#comment-9456 Interface21 Team Blog » Why the name Acegi? Sat, 27 Jan 2007 05:54:15 +0000 http://blog.interface21.com/main/2006/08/28/creating-a-spring-20-namespace-use-springs-abstractbeandefintionparser-hierarchy/#comment-9456 [...] These changes will be noticeable with release 1.1.0, which will offer namespace support and require Spring 2. At that point the product will be renamed, and package names will also change. We don't anticipate the package renaming will cause any difficulties, as the move to namespaces also means a move to the new simplified configuration format that so many people have asked for. As such, people would likely be changing their configurations anyway. For those wishing to preserve the old configuration format, simply use find and replace. We won't be changing the acegisecurity-developer mailing list or Subversion repository any time soon. [...] [...] These changes will be noticeable with release 1.1.0, which will offer namespace support and require Spring 2. At that point the product will be renamed, and package names will also change. We don't anticipate the package renaming will cause any difficulties, as the move to namespaces also means a move to the new simplified configuration format that so many people have asked for. As such, people would likely be changing their configurations anyway. For those wishing to preserve the old configuration format, simply use find and replace. We won't be changing the acegisecurity-developer mailing list or Subversion repository any time soon. [...]

]]> By: Interface21 Team Blog » Last chance to join 500+ others in Australia http://blog.springsource.com/2006/08/28/creating-a-spring-20-namespace-use-springs-abstractbeandefintionparser-hierarchy/#comment-1100 Interface21 Team Blog » Last chance to join 500+ others in Australia Wed, 01 Nov 2006 08:31:37 +0000 http://blog.interface21.com/main/2006/08/28/creating-a-spring-20-namespace-use-springs-abstractbeandefintionparser-hierarchy/#comment-1100 [...] Whilst on the topic of user group meetings, at the last Sydney meeting I presented a session on using Spring 2.0 Namespaces. These are a fantastic new feature in Spring 2.0 that can be used to simplify your existing configuration - or even build your own problem domain-specific configuration schema. If you'd like to know more about this, here are the slides. You might also want to check out blog entries by Ben Hale and Erik Wiersma on the same topic.   [...] [...] Whilst on the topic of user group meetings, at the last Sydney meeting I presented a session on using Spring 2.0 Namespaces. These are a fantastic new feature in Spring 2.0 that can be used to simplify your existing configuration - or even build your own problem domain-specific configuration schema. If you'd like to know more about this, here are the slides. You might also want to check out blog entries by Ben Hale and Erik Wiersma on the same topic.   [...]

]]> By: The thoughts of an IT professional : Spring config as code http://blog.springsource.com/2006/08/28/creating-a-spring-20-namespace-use-springs-abstractbeandefintionparser-hierarchy/#comment-468 The thoughts of an IT professional : Spring config as code Sun, 08 Oct 2006 16:31:31 +0000 http://blog.interface21.com/main/2006/08/28/creating-a-spring-20-namespace-use-springs-abstractbeandefintionparser-hierarchy/#comment-468 [...] I was reading (belatedly) Crazy Bob’s rant about Spring. It is an interesting point, the fact that your configuration settings become code because they do what code is meant to do, that is, they implement a desired behavior. Yes, the lines between configuration and code blur, just look at the number and size of various XML descriptors which are popping up everywhere. So, I would say the Bob was right about the fact that your Spring XML descriptor is code. However, he was definitively wrong about Spring configuration file being intrusive. Yes, you need such a file for your application to be bootstrapped correctly, but you do not need to abide by Spring’s XML descriptor. The Spring XML descriptor is a window onto a particular binding mechanism, there is nothing that requires you to use this particular file. You can set-up your configuration syntax, write a parser around it, plug this parser into the IoC for application bootstrap and have Spring use your own bootstrapper with your own semantics. It is not going to happen over-night, you will probably need an in-depth knowledge of Spring, but if you are concerned about developing in an intrusive environment you may want to look at it. (One danger of going this route is that your syntax will diverge from Spring’s syntax and new additions to the framework’s syntax (such as AOP) will have to be re-developed according to your environment. In the case of an IoC container using a different syntax is very similar to forking a project and has pretty much the same synchronisation problems.) Another option would be to create your syntax, have a translator which converts your XML descriptor into an Spring XML descriptor and have your application run on the Spring descriptor your translator would produce. You are running the same dangers as before since you are basically forking a language. Or you could take a look at the XML namespaces that have been added to Spring 2.0 which include extended XML authoring and have all your problems resolved (you can find a small tutorial here). I really like the fact that the Spring community decided to do away with the only thing in the framework which cold have been regarded as intrusive and to do it in style . Again, the Spring XML descriptor was just a window onto a binding mechanism which could have been replaced/enhanced with another window at various costs. It was not intrusive, it just carried a lot of weight. Well, this weight disappeared. Nice move. [...] [...] I was reading (belatedly) Crazy Bob's rant about Spring. It is an interesting point, the fact that your configuration settings become code because they do what code is meant to do, that is, they implement a desired behavior. Yes, the lines between configuration and code blur, just look at the number and size of various XML descriptors which are popping up everywhere. So, I would say the Bob was right about the fact that your Spring XML descriptor is code. However, he was definitively wrong about Spring configuration file being intrusive. Yes, you need such a file for your application to be bootstrapped correctly, but you do not need to abide by Spring's XML descriptor. The Spring XML descriptor is a window onto a particular binding mechanism, there is nothing that requires you to use this particular file. You can set-up your configuration syntax, write a parser around it, plug this parser into the IoC for application bootstrap and have Spring use your own bootstrapper with your own semantics. It is not going to happen over-night, you will probably need an in-depth knowledge of Spring, but if you are concerned about developing in an intrusive environment you may want to look at it. (One danger of going this route is that your syntax will diverge from Spring's syntax and new additions to the framework's syntax (such as AOP) will have to be re-developed according to your environment. In the case of an IoC container using a different syntax is very similar to forking a project and has pretty much the same synchronisation problems.) Another option would be to create your syntax, have a translator which converts your XML descriptor into an Spring XML descriptor and have your application run on the Spring descriptor your translator would produce. You are running the same dangers as before since you are basically forking a language. Or you could take a look at the XML namespaces that have been added to Spring 2.0 which include extended XML authoring and have all your problems resolved (you can find a small tutorial here). I really like the fact that the Spring community decided to do away with the only thing in the framework which cold have been regarded as intrusive and to do it in style . Again, the Spring XML descriptor was just a window onto a binding mechanism which could have been replaced/enhanced with another window at various costs. It was not intrusive, it just carried a lot of weight. Well, this weight disappeared. Nice move. [...]

]]> By: Ben Hale http://blog.springsource.com/2006/08/28/creating-a-spring-20-namespace-use-springs-abstractbeandefintionparser-hierarchy/#comment-154 Ben Hale Tue, 05 Sep 2006 13:29:43 +0000 http://blog.interface21.com/main/2006/08/28/creating-a-spring-20-namespace-use-springs-abstractbeandefintionparser-hierarchy/#comment-154 I probably should have mentioned the existing namespaces in the body of the post, but for sure they're great resources. If you ever have questions about how to design and implement a namespace, the existing Spring namespaces are a good place to start. I'll also be doing a presentation at a couple of NFJSs and TSE this year with a more in depth treatment of this subject. I probably should have mentioned the existing namespaces in the body of the post, but for sure they're great resources. If you ever have questions about how to design and implement a namespace, the existing Spring namespaces are a good place to start. I'll also be doing a presentation at a couple of NFJSs and TSE this year with a more in depth treatment of this subject.

]]> By: Mike Bosch http://blog.springsource.com/2006/08/28/creating-a-spring-20-namespace-use-springs-abstractbeandefintionparser-hierarchy/#comment-152 Mike Bosch Tue, 05 Sep 2006 07:00:51 +0000 http://blog.interface21.com/main/2006/08/28/creating-a-spring-20-namespace-use-springs-abstractbeandefintionparser-hierarchy/#comment-152 I'm building out a namespace at work for making service and bean management more standardized within the development group. This also tends to make things simpler and not have them worry if I change the standard for a bean definition or maybe use different factories for different types of services in the future. I'm still figuring out how to best utilize this new mechanism, though. You pretty much nailed it when you said that the biggest headache was just how to decide which abstract parser to use or just implement the interface bare. I initially started to do just that but then went and looked at existing implementations for the util and tx namespaces and when I realized what they were doing it started to get a little easier but I'm still far from done with this exercise. I'm building out a namespace at work for making service and bean management more standardized within the development group. This also tends to make things simpler and not have them worry if I change the standard for a bean definition or maybe use different factories for different types of services in the future. I'm still figuring out how to best utilize this new mechanism, though.

You pretty much nailed it when you said that the biggest headache was just how to decide which abstract parser to use or just implement the interface bare. I initially started to do just that but then went and looked at existing implementations for the util and tx namespaces and when I realized what they were doing it started to get a little easier but I'm still far from done with this exercise.

]]>