The Observer Pattern is also known as a publisher and subscriber design pattern. The pattern is useful when you have one publisher and many subscribers (one-to-many) that are interested in the publisher's state or messages. This article by Scott Priolo describes an easy process of implementing the observer pattern within the Spring framework, as well as an easy way to start the Spring Framework in any project.

Read Spring Loaded Observer Pattern

Dear God, No!

MethodInvokingFactoryBean was intended to be used to procure Spring-managed beans from legacy factory methods, not as a substitute for general-purpose computing.

The TownCrier should have been injected into the TownResident concrete class, and registration could have occurred in the constructor, like so:

private Subject _townCrier;

public initialize()
{
  _townCrier.addListener( this );
}

Instead, we are given this nightmare of XML-as-programming-language where we clumsily attempt to execute this operation in the Spring configuration file:

<bean id="registerTownResident1" class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
  <property name="targetObject"><ref local="townCrier"/></property>
  <property name="targetMethod"><value>addListener</value></property>
  <property name="arguments">
    <list>
      <ref bean="townResident1"/>
    </list>
  </property>
</bean>

If you weren't struggling with the size of your Spring configuration file before, you sure are now!

http://dynaop.dev.java.net/nonav/release/1.0-beta/manual/ch02.html

http://dynaop.dev.java.net/nonav/release/1.0-beta/manual/ch02.html

I think I like this approach better. Having the implementation of a Subject "mixin" to the target of interest. Cool way and Spring could do "mixin" as well.

regards

http://dynaop.dev.java.net/nonav/release/1.0-beta/manual/ch02.html

I think I like this approach better. Having the implementation of a Subject "mixin" to the target of interest. Cool way and Spring could do "mixin" as well.regards

I think you are right when we discuss the Observer design pattern itself. In this article, Scott would like to refer to Spring strength in the aspect of applying well-known design patterns to the framework. We all see that we are freed from wiring all the objects together to form an Observer context.

http://dynaop.dev.java.net/nonav/release/1.0-beta/manual/ch02.html

I think I like this approach better. Having the implementation of a Subject "mixin" to the target of interest. Cool way and Spring could do "mixin" as well.regards

Yes it could, it is much less intrustive and reusable:

http://wiki.jboss.org/wiki/Wiki.jsp?page=GOFObservable
or
http://www.damnhandy.com/?page_id=17

I have to agree with Corby there: this article scares me.

While I see value in specifying information in XML to do some decoupling, this line concerns me:

 <property name="targetMethod"><value>addListener</value></property>

To me, a method name in an XML file is a sign of "XML gone wild". This is going too far and we have learned this lesson the hard way with EJB's assembly descriptor.

Corby provided a valid workaround to accomplish the same goal without this hack, and I would probably suggest looking at specifying this with an annotation instead (haven't really thought that one through).

--
Cedric

I have to agree that I wouldn't do this this way, and don't regard this as an example of Spring best practice. Spring is not intended to foster programming in XML. As a previous poster pointed out, we refer to XML bean "definition" files, not XML scripts.

Rod Johnson
Interface21 - Spring from the Source Training, Consulting, Support

this line concerns me:&nbsp;<property name="targetMethod"><value>addListener</value></property>
To me, a method name in an XML file is a sign of "XML gone wild". -- Cedric

Funny, I just spotted this on Keith's blog regarding SWF:

<action-state id="executeSearch">
  <action bean="phonebook" method="search(searchCriteria)"/>
  <transition on="success" to="displayResults"/>
</action-state>

Looks quite similar .. and scary!

blockquote>private Subject _townCrier;public initialize(){&nbsp;&nbsp;_townCrier.addListener( this );}
This can be done however if there is another towncrier2 and the townresident1 wants to subsribe to towncrier2 then we would have to recompile code, isn't it?

With putting the details in the xml file at least we can do away with the above issue and just change the xml setting as

<!-- this is a method invoking bean that registers the first town resident with
          with the town crier -->
    <bean id="registerTownResident1"
      class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
      <property name="targetObject"><ref local="townCrier2"/></property>
      <property name="targetMethod"><value>addListener</value></property>
      <property name="arguments">
      <list>
        <ref bean="townResident1"/>
      </list>
      </property>
    </bean>

Further the TownResident class does not know about the TownCarrier, it is only through the app context xml/

This can be done however if there is another towncrier2 and the townresident1 wants to subsribe to towncrier2 then we would have to recompile code, isn't it? With putting the details in the xml file at least we can do away with the above issue and just change the xml setting

You can easily support multiple subjects by making the dependency a list of subjects rather than a single subject. Then you can declare any number of subjects in the xml file without recompiling.

You certainly do not need to misuse MethodInvokingFactoryBean as a generic programming language construct to accomplish this.

Good Lord, TSS posting is messed up. Joe, please post an update when you've fixed this, I'm not going to keep going through this much effort just to get a message up.

This is in fact the essence of a trend in Java programming I am watching with some suspect since several years. It's nice to bann out unwanted dependencies on, say vendor specific data sources and the like, from your java source and inject others, even mocks, at will. But beware of outsourcing your business and domain logic into an XML configuration hell! This might work on a small level; but I'm sure you will loose yourself and your co-programmers in a system, that has it's glues not in Java, but in external XML files and depends on code only available at runtime through Java reflection mechanisms.
I think sometimes it's good to remember that reflection is a nice tricky tool, but it is in fact the quite opposite of object oriented programming styles. So in fact I'm doubting whether trendsetters like Spring really are making programmers live and work easier...

This looks similar to the picocontainer sample at http://www.picocontainer.org/Two+minute+tutorial which will prevent the use of XML.

Actually, I think Spring supports something similar, though its not as well publicized as their XML bean definition file.

FD: I use PicoContainer extensively on my test framework http://twiff.sf.net/

So in fact I'm doubting whether trendsetters like Spring really are making programmers live and work easier...

Let me attempt to answer that: They're not.

Spring has become an application container in exactly the same way as J2EE.

Let me attempt to answer that: They're not.

Thanks for volunteering to answer, but the many happy Spring users would disagree with you.

Spring has become an application container in exactly the same way as J2EE.

Would you care to elaborate?

Good one. Gets you started with spring and explains a key BeanFactory and how to use it. Live code examples are a plus.

Keep going Scott, expecting more on Spring.

Muthu Ramadoss
http://groups.google.com/group/EtoE

Another way to do this is using a BeanPostprocessor. Whenever a class that implements the Observer interface is found the bean BeanPostprocessor can automatically add it as a listener to the Subject.

This has the advantage that it is completely transparent to the writer of the observer and observable and that it totally avoids having to write any wierd wiring instructions on a per class basis.

It has the disadvantage that there is only one Subject per Observer.

I have not tested this specific instance, but I have previously used this pattern to register objects that implement an MBean interface with JMX.

Surely setting the list of observers would be a better solution:

[code]
  <bean id="thePublisher" class="...">
    <property name="observers">
      <list>
        <ref bean="observer1"/>
        <ref bean="observer2"/>
      </list>
    </property>
  </bean>
[/code]

????

Colin, I agree... That is how I have done it.

You might want to take a look at the discussion of Java training on Javalobby: http://javalobby.com/java/forums/t44476.html

Although I have my personal opinions on the matter (as you will read), I think you need to decide if you really need training in-person from someone or can get it doing your own learning and saving money.

Sorry all, wrong thread...could moderator please remove.

There is some reason they're called "bean definitions" instead of "bean scripts", you know.

I'm relatively new to all this and I keep trying to find out what is the point of Spring or Tapestry or similar. This article just moves this points further away. I just don't get it - where would I use this complex (as it seems to me now) and hard to use code? I can't be the only one to think this... really...

I would have liked to see this implemented using Spring's native event propagation support e.g. the publishEvent() method from the ApplicationContext. (See chapter 3 of Spring Reference) The ACEGI Security framework relies Spring event propagation and it works great.

ApplicationContext context = new ClassPathXmlContext("appContext.xml");
context.publishEvent(new SillyEvent("Hello"));