All 7 entries tagged Spring

View all 45 entries tagged Spring on Warwick Blogs | View entries tagged Spring at Technorati | There are no images tagged Spring on this blog

June 15, 2006

Session3: AOP and Domain Driven Design

Contention: You can't do full DDD without AOP

DDD is about moving away from database–driven design and towards an object model with is a meta–language for the problem domain

Itegration services (email facade, report generator) == good ; technical services (AccountingService – providing TX + Audit to Accounts) == bad
AJ gives us a (nother) way of injecting services onto POJOs when they come out of persistent storage; has the advantage that it can also DI on construction and/or deserialization

neat semantic trick; given Order and OrderLine classes, have a method Order.with(product, quantity) to

add a new OrderLine and return a reference to self, so you can say

customer.addOrder.with("widget",2).with("gadget",6),with("sprocket",7)

Example of Domain AOP: associating failure behaviour (retry or check credit history) with domain objects – have a set of aspects which encapsulate the behaviour, applied to the order object (which need not contain this logic). I guess this would be OK if your whole team and your development process was AOP–friendly.

refactoring towards DDD: move logic from service layers into domain objects; move crosscutting concerns into aspects. Finally remove the service layer itself. If there's still logic in the service layer, look for missing domain objects


session 2: spring AOP

[Adrian Colyer]

– spring AOP can be applied either using xml config (optionally with the [aop:] namespace) or using @AspectJ apsects
– spring and AJ are still separate projects, but spring now uses the AJ pointcut paser/matching API not using the weaving engine / compiler
really simple to advise beans being instantiated via the container.
– Lots of really good examples. I hope we get access sample code
– AJ can do pretty smart code inspection to generate warnings and errors about code usage.
– jMon profiling library – easy to integrate with apsects around methods to be profiled.
– migration to AOP: start with spring OOTB AOP (e.g. transactions), then add custom spring AOP, then use AJ for enforcement/inspection, then intfrastructure with AJ, finally domain aspects with AJ


springone keynote

It's the conference season again. I'm in Antwerp for SpringOne, a developer get–together for users of the spring framework. I'll be blogging key points from all of the sessions I attend, battery permitting. So to begin; Rod Johnson's keynote.

– Rod's intro section is largely bog–standard 'rah rah rah for spring'. However, he then bought on the IT director of VOCA (BACS as was) talking about their experience of using Spring for totally mission–critical software (i.e. the UK banks clearing house). Writing code for handling 100,000,000 complex transactions in a 4 hour window with no failures. It's impressive to hear about how the technology's being adopted in such a conservative and risk–averse environment.

Rod then goes on to talk about how BEA are building on spring 2 to provide their JEE5 implementation. (pitchfork), then the 'what's new in spring 2.0' highlights – simplified config, AOP, web flow, simplified transactions, IL8N, and JPA.

Support for dynamic JVM languages (groovy, jruby, etc) looks pretty cool – define a bean in jRuby, and spring will let you use it just like a regular java class, except that it will also allow you to periodically poll the script for changes and bring them in at runtime – auto–redeploys ahoy :–)

Then onto Adrian Colyer, who talked a little bit about AspectJ AOP (good) vs JEE5 AOP (bad), then goes onto spring post–2.0. Spring 2.0 is the launchpad; the set of foundation abstractions, but there's a lot more to do. Moving towards a more rails–ish environment with an emphasis on convention over configuration, rolling out support for profiling and instrumentation and looking at reducing time–to–refresh in development. Also operational enhancements to make it easier and more productive at runtime – including OSGi support for module replacement, and SCA support.

On a side note, the keynote is held in a cinema, with comfy seats and THX sound, which would be totally cool were it not for the fact that the aircon is shot and the temperature is about 70 degrees C.


August 23, 2005

EJB 3.0: What's in it for me?

Writing about web page http://houseofhaug.net/blog/archives/2005/08/12/hibernate-hates-spring/trackback/

There's an interesting discussion here about the relationship between Spring, Hibernate, and the forthcoming EJB 3.0 spec. In summary (AIUI):

  • Hibernate removed the references to Spring from their wiki
  • Scott blogged about this, with the rather provocative title 'Hibernate Hates Spring'
  • Gavin King commented, asserting that Spring's hibernate support doesn't add any value to a hibernate 3 application, and that moreover there are personal differences between the two teams. He goes on to claim that using an EJB3 container (such as JBoss's embeddable one) provides a better solution to transaction demarcation, exception handling, and session provisioning than the Spring offering.
  • Jurgen Hoeller observed that Spring already supports hibernate's native session provisioning as an alternative to the old-style HibernateTemplate, and allows it to work outside of an EJB environment
  • Bill Burke (in a much more reasonned and mellow style than in days of old!) weighs in to note that JBoss doesn't consider itself as a competitor to Spring, though he does think that some of spring's integration code isn't really adding value.

It's an interesting read. But what it made me think about is: What is EJB 3 going to offer me, that Spring currently doesn't ?

Firstly, there's the persistence standardisation (JSR220) which might be nice. Actually I'm pretty content with Hibernate right now, but it looks like a short jump to make to go with the standard. But what about the other stuff? I'll admit right now I haven't read the spec, but my understanding is that it'll provide basically all the same stuff as EJB2, but without the cruft

  • declarative transaction demarcation
  • some IOC / object provisioning
  • a bunch of distributed stuff that I don't care about :-)

Now, the burning question is, why would I want to pick up a new technology for that? Clearly it's not going to replace all of the functionality I currently get from Spring, so my options are {Spring}, or {EJB3+Spring}, or {EJB3 + some other MVC + some other collection of utility libraries + more hand-written stuff}.

What will EJB3 give me that Spring won't? Right now, the only answer I'm seeing is 'standards-compliance'. Which seems like a relatively small benefit for picking up a shedload of new technology.

I think I need to go and find out what else it might be offering, just in case there's something I've missed.


August 19, 2005

Spring JMX integration

Oh, this is just too easy. Take any spring-managed bean and export it to a JMX server, without needing to write any code or reference any of the JMX interfaces


<bean id="jmxExporter"
        class="org.springframework.jmx.export.MBeanExporter">
        <property name="beans">
            <map>
               <entry key="Hibernate:name=statistics"> <ref bean="statisticsBean" /></entry> 
               <entry key="Lucene:name=luceneTemplate"><ref bean="luceneTemplate"/></entry> 
            </map>
        </property>
    </bean>


August 17, 2005

Binding things othe than HTTP request parameters in Spring

Spring's support for binding HTTP request parameters to command objects is superb. You can do pretty much any mapping from parameters to domain objects that you want, in a totally non-intrusive way, using PropertyEditor classes to manage the translation.

However, woe betide you if you ever want to bind something other than request parameters. A request attribute, say. Because within AbtractCommandController, ServletRequestDataBinder is new()ed up inside a heap of other code inside createBinder() – so it's not easy to inject an alternate binder. And ServletRequestDataBinder itself new()s RequestParameterPropertyValues inside another heap of hard-to-override code. So trying to mess with the binding phase itself is not worth the pain.

All is not lost, however. Conveniently, there's an onBind() lifecycle method in AbstractCommandController that you can intercept to do your own custom binding. And because you can create DataBinders yourself, it's easy to bind stuff in a way that's not at all coupled to your domain. Time for an example:

public class SearchQueryHandler extends AbstractCommandController{

    protected void onBind(HttpServletRequest request, Object command) throws Exception {
        new UserBinder(request).bindUser(command);
    }

    protected ModelAndView handle(HttpServletRequest req, HttpServletResponse resp, Object obj , BindException arg3) throws Exception {

        QuerySource query = (QuerySource) obj; // with request params and user already bound
        SearchResults results = new SearchResults(query.getSearchResultsDecorator(decoratorConfig), query);
        search.execute(query, results);
...

UserBinder's bindUser() method looks like this: Note how it doesn't care at all about what class it's binding to
...
    public void bindUser(Object o ) {

        String propName = (propertyName == null)?DEFAULT_PROPERTY_NAME:propertyName; 
        PropertyValues pv = new MutablePropertyValues(Collections.singletonMap(propName, user));
        DataBinder binder = new DataBinder(o,DUMMY_COMMAND_NAME);
        binder.bind(pv);
    }

Nicely separated. To take it one step further, it would be cool to invoke UserBinder.bindUser from an AOP advice around the onBind() method, rather than in the class itself. That way, controllers could be configured to bind or not bind users as appropriate, rather than explicitly calling the binder in code. I think that's a good thing, though I'm not quite sure why.
update Of course, it's a good thing, because it means that the same controller class can be configured to execute different commands without needing to know whether or not they need users (or whatever) binding to them.


August 16, 2005

I wish I'd known

Writing about web page http://www.springframework.org/dtd/spring-beans.dtd

I wish I'd known before I started writing the spring config files for search that you can now do


   <property name="foo" value="bar"/>

instead of


<property name="foo"><value>bar</value></property>

– and the same for ref= . Oh well, cutting and pasting is good for the soul.


Most recent entries

Loading…

Search this blog

on twitter...


    Tags

    RSS2.0 Atom
    Not signed in
    Sign in

    Powered by BlogBuilder
    © MMXXI