Article: Dynamic Routing Using Spring and AOP

Hi,

the XML sample code is not showing correctly.

Hi Alef,
We fixed the XML sample code as far as I could see. You know how things get messier when it gets to convert XML tags into HTML. Thanks Alef for posting the article in your blog about using Hibernate Session API directly in the data access code.
Regards
Vigil

Hi William,

You could also apply the classic decorator pattern implementation to add custom behavior before and after the actual business service method invocation without using AOP in the examples shown in the article. AOP is more powerful and has got a variety of advices you can choose from, depending upon the need. The framework offers the choice and you have the freedom to make an informed decision as to which option best suits your particular use case or scenario.

Regards,
Vigil

William, a business logic concern should be coded as an advice when it is or becomes a cross-cutting concern. The example showed the notification module being used only in one instance (when the doRegister method gets called). If the notification module would have been used in a lot more places then you would have had a cross-cutting concern, of a business logic nature, which should have been implemented using AOP.
I agree with you saying that the component doing the work of the advice should actually reside outside of the advice, this way this component can be used outside AOP. I think AOP should be used mostly for binding a component to another component transparently.

Yeah, it sounds familiar. I just revamped my personal blog a little bit and have plenty of XML fragments there as well. Sometimes I think we should never have invented the pointy brackets--would have saved us a lot of trouble ;-).

I'have read with interesting this article, and also the post comment. So a question is come into my brain, relatively AOP.

So, during my studies I had always read that AOP is usefull when is necessary to model a cross-concern, to alleviate (as say William Louth), and evitate to write some boilerplate code in all the class that we intended to proxy. Example of this concept is the logging problem or the exception managing problem. But really I had read wath sustain Vigil Bose: the potential of AOP is significant, and it potential is not be relegate only to managing of logging, exception, etc..but it must be used also in al the situation to improve the quality of the software, regarding the readability, elegance, and obviously to separate the concerns.

William say also that is important first to write the code without the AOP advice action in field, and than apply this action of the code already working, to apply other functionality.

So in conclusion, is better for you, write (or thinking) the code from start with or without the help of AOP concept?

Thank at all.

Samuele Pretini

I think in cases where you've had previous experience to guide you, it's fine to design and build with AOP in mind from the beginning. I wouldn't put all of the transaction handling code in every service method just to then refactor it and use the @Transactional annotation with an AOP interceptor to manage transactions. I know I'm going to need those across my app, and I use them from the beginning. I agree that pre-mature refactoring is problematic, but if you've built these systems before and seen these needs, you know some of the common things you're going to end up with, so just skip the intermediate steps.

Instead of trying to write all of the Event infrastructure and AOP stuff, use Spring's ApplicationEvents... (extend ApplicationEvent) then just wire up the Router/Dispatcher as an "extend ApplicationListener" to dispatch the events to one or more subsystems. You'll have a lot less infrastructure code, and also get rid of the AOP configuration mess.

Spring's ApplicationEvent infrastructure is woefully inefficient, last I looked. Basically every event is passed to every listener to decide if it should handle it, and there's no good way to filter them down, register for only certain types, or make event listeners run asynchronously. I rewrote the event system for an app at my last job (where I was unfortunately unable to convince them to open source the code) to allow for registering for particular sub-classes of events and run event handlers asynchronously up to and including transaction synchronization so that event listeners would only be queued up to process if the transaction committed. I may re-write that stuff, because a central event system is an important thing, and Spring's was just not good enough for real use.

Of course, maybe they've fixed all of this stuff?

Jason...

to your comments:

• Basically every event is passed to every listener to decide if it should handle it

  
  True, I'd suggest having a single "EventDispatcher" bean as an app listener that can filter/dispatch events to the appropriate places...
  
  

• make event listeners run asynchronously...

  
  Spring 2.0 allows the SimpleApplicationEventMulticaster to pass in a TaskExecutor (i.e. AsynchTaskExecutor to run things asynchronously... then you wont be blocking on each execution)
  
  ...I agree that a centralized event system is a big value add in an app(Especially for trying to hook things up to support "operations"). Currently we are using the existing Spring Event infrastructure for cache refreshing, additional exception support (providing discrete "files" for critical app exceptions) and some other tooling, I've been impressed and it's worked exceptionally thus far.
  
  It'd be cool if we had a good, standard way of doing this...
  
  

Hi can u please send me the code of only how the jtaTransaction work in Spring2.0.
i have two databases one is remote and another one is local.i want complete applicationContext.xml file