The Spring Framework is a very powerful library for J2EE development. It comes with an AOP implementation (based on proxies) that is in many cases sufficient in terms of what you need to do. However, there are many situations where you need a more full-blown AOP framework (such as AspectWerkz) to do the job.
This article discusses how you can work with an integrated Spring and AspectWerkz.
Read more: Spring and AspectWerkz - A Happy Marriage
Conratulations! AspectWerkz is the right choice!
Thanks Jonas. This is cool stuff! I look forward to having enough time to look at it and kick the tyres. Hope we find time to discuss it at JAOO in a couple of weeks.
Thanks a lot Rod.
I really like Spring and I think that there is a lot that we could do together.
Let's talk more at JAOO. See you.
Looking forward to it. I've posted
on the Spring Forums about this integration.
I was waiting for this. Thanks Jonas !
Does anybody knows Francis Fukuyama's End of History polical thesis.
He claims that the liberal capitalist system sets the final stage of human polical history and since there are no convincing alternatives, it is the end.
I percieve Spring in that manner. It has already set a very high standard of J2EE competency and quality that I think very few, if not any, competing frameworks could challenge. So it is the end.
Enjoy it and thanks to Rod and others for their excellent contributions
I am speechless. Are you Rod's alter ego? Or Jürgen's :-). They didn't come over like that yet. Did they found a church :-). No serious, I have had a good look at spring during the last three weeks or so of my playtime.
While it is nice and clever, I fail to see, why other's could not challenge it. Take the AOP layer that is very basic. Take the Web Layer, that is years away from what modern web based UI frameworks like JSF or WebLogics NetUI or the Oracle Stuff can do (let alone .NET).
It's core being a cleverly though out push configurator, but I don't think even that is without competition, looking at stuff like BeeHive... And of course, for a full blown framework it is still quite incomplete (for the fun of it, try receiving email with anything in the framework :-)).
Just for the record: Rod and me don't have alter egos - please don't confuse us with some other well-known open source group ;-)
A couple of clarifications, regarding your points:
The AOP layer aims to be as powerful as a proxy-based approach can be, and we certainly push the limits of what's possible there. This already gives a lot of power, with very fine-grained control over where you want to apply AOP, and with no hassle with application server integration.
For even more power (which is not necessary for typical application needs like declarative transactions), consider a classloader-based approach: We collaborate with AspectJ and AspectWerkz to provide proper integration - we do not aim to compete with them in the first place.
2. WEB SUPPORT
The web support actually consists of multiple parts:
* The WebApplicationContext constitutes an integration of Spring's ApplicationContext concept with a ServletContext environment, which can be combined with any web layer design. Such a root WebApplicationContext can be accessed from virtually any web resource, e.g. from a plain Servlet or even JSP.
* DispatcherServlet is a powerful dispatcher approach, for mapping a single servlet to multiple handlers, with support for a variety of mapping strategies, view resolvers, and view technologies. It can be used with plain Controllers - similar to the Servlet level, just more flexible and with a view abstraction.
* One usage for DispatcherServlet is remote service exposure. Our exporters for HTTP-based remoting (Hessian, Burlap, HTTP invoker) are all implemented as Controllers for DispatcherServlet. This is completely independent of a web UI framework within the same application: It can nicely run alongside any web UI.
* Spring includes a set of prebuilt Controllers that can be used for data binding and form handling in a request-driven web MVC layer. We also provide a JSP tag library and Velocity/FreeMarker macros here. This is essentially what competes with Struts and WebWork, which follow a similar approach.
My main point is that Spring's web support is not just about web UIs (competing with Struts and co): The UI framework is just a part of it. A root WebApplicationContext and remote service DispatcherServlet are useful with any web UI, be it based on Struts, WebWork, Tapestry, JSF, Echo...
We do believe that Spring's web UI support offers a lot of value, when choosing to follow a request-driven approach (Struts/WebWork-style). We do not aim to compete with component-based web UI frameworks like Tapestry, JSF or Echo, though - we rather collaborate with them for easy integration.
3. BEING INCOMPLETE
Of course Spring is incomplete - in the sense that it does not aim to provide everything itself! At its heart, Spring is a configuration and glue framework with strong middle tier capabilities. It does, however, not aim to provide its own logging abstraction, connection pool, O/R mapping framework, etc.
In the case of receiving mails: Feel free to implement this with the well-known JavaMail API, but manage your mail-receiving business objects as Spring beans :-) It's important to stretch that you're free to use whichever API you choose and still manage it as component in a Spring context.
Of course, Spring provides a variety of preintegrations and other helpers that make things easier, in particular for various data access strategies. You can still easily use any of those APIs directly, if you choose to - Spring's support classes for those just aim to remove the integration burden from you.
Neither I nor Juergen claim that Spring is the last word in frameworks--however, we're going to continue to work very hard to keep ahead of competition :-) Of course there will always continue to be innovation in the framework space, and that will continue to raise the bar and benefit everyone. Take Dependency Injection: PicoContainer came up with some good ideas, and took onboard some of ours, and now both products are more capable than they otherwise would have been.
It does, however, not aim to provide its own logging abstraction, connection pool, O/R mapping framework, etc.
I absolutely agree with this: one of the things that make Spring a great tool is the "common language" it establishes with regard to the integration of a number of different tools, allowing the developers to reduce the initial integration effort, and to use those tools in a "pattern-driven" way, automatically following implementation best practices. What is even more great, these days, is the fact that everyone seems interested in integrating his or her stuff with Spring (or at least assure the world that the integration is seamless), and this pushes the "common language" part of spring even further.
The "spring approach" has taken me so much that these days I really choke when I see stuff done "the old way": I just ended the refactoring of a huge MDB with a lot of messed jdbc code inside, and created a nice independent subsystem which can be run (and tested) in a standalone way and has email failure notifications and quartz scheduler integration. All of this is constantly made easier because every time I start a new development I know what the "basic" part of it will be: an application context, and a set of bean: and the fact I can count on the spring libraries in order to reduce code and simplify stuff with regards to jdbc, transactions, jms, configuration, email and so on is simply great: to me, Spring is the real J3EE: a layer above J2EE, making it simpler, more powerful and more clear.
your points are well taken. But if I see people praising frameworks like spring - which happens to be the one that gets a lot of "air time" at the moment, I see a lot of overemphasis on the "core framework", that is, well nice and clever, but neither unique or revolutionary. The very idea that a centralized singleton or factory factory can steer us back into cherished OO grounds is to me quite exaggerated anyway...
So a lot of people will take spring as "the whole spring framework with its dependencies" that again gives you a lot (hibernate, dao, ibatis, transaction handling, aop, web framework), is quite clever, but - as a full blown framework - is at the moment far away of being the end of all frameworks.
Also, I like the web framework, it is really nice, but it still is a request based approach (one of the best I've come across, because it is so seamless), but the web based approach in itself is only mildly object oriented in the first place, of course.
By the way, I think mail receiving is an interesting example, because almost everything that you would like to configure on a mail receiver is on a per user basis (mail server, address, protocol, certificate...), pretty much unlike what you'd like to configure using a singleton container.
[...] I see a lot of overemphasis on the "core framework", that is, well nice and clever, but neither unique or revolutionary. The very idea that a centralized singleton or factory factory can steer us back into cherished OO grounds is to me quite exaggerated anyway...
A comment that, on the face of it, looks quite reasonable. But have you used
any of these DI frameworks in anger? On real projects, with a real-world team that does not just have guru-level developers? Do. You might be surprised. I was.
[...] By the way, I think mail receiving is an interesting example, because almost everything that you would like to configure on a mail receiver is on a per user basis (mail server, address, protocol, certificate...), pretty much unlike what you'd like to configure using a singleton container.
All that means is adding a layer of indirection (eg factories), which you would, well, configure using your container. The usefulness of DI containers has limits, but this is not where they are.
A comment that, on the face of it, looks quite reasonable. But have you used any of these DI frameworks in anger? On real projects, with a real-world team that does not just have guru-level developers? Do. You might be surprised. I was.
I am in the process of doing it in a pilot project. I do see advantages, mainly that there is a clear "scheme" how to handle things, regardless of where they originate, which is very convenient, no doubt.
But even now I start seeing limits, for example pushing to much into the bean factory configuration which makes it rather easy to lose track of why things happen in what order and the like. On the other hand, one might argue, there is at least some amount of meta information available outside of the code - not to bad given the quality of documentation that often gets produced in projects with "aggressive" timelines.
I do acknoledge it is a nice and fresh approach but for me it is still far from a silver bullet.
A comment that, on the face of it, looks quite reasonable. But have you used any of these DI frameworks in anger? On real projects, with a real-world team that does not just have guru-level developers? Do. You might be surprised. I was.I am in the process of doing it in a pilot project. I do see advantages, mainly that there is a clear "scheme" how to handle things, regardless of where they originate, which is very convenient, no doubt. But even now I start seeing limits, for example pushing to much into the bean factory configuration which makes it rather easy to lose track of why things happen in what order and the like. On the other hand, one might argue, there is at least some amount of meta information available outside of the code - not to bad given the quality of documentation that often gets produced in projects with "aggressive" timelines. I do acknoledge it is a nice and fresh approach but for me it is still far from a silver bullet.
Actually, I think the opposite holds. It makes it easier to see how the order because you see exactly what lower dependencies are in place for higher level objects, for me anyway. In addition, since such dependencies have to work for the bean to be created, you find out very quickly of something is wrong or missing.
I set up a skeleton web-app, that is based on Struts, Spring, and Hibernate and handed it off to the a developer who had no experience with Spring and very little with Hibernate. He had never seen this setup and in on Day two, he was getting real work done. By the end of week 3, as per his assignment he'd gotten his task done.
The framework(Struts,Spring,Hibernate) did its job and stayed out of his way allowing him to rapidly crank out his application while retaining a well-designed(IMO) architecture. As opposeded to what would have come out if he had to "crank out" code.
To me, that is the essence of a good framework. It stays out of the way.
I `m J2ee Architect.I deploy sevral J2ee project with jsf and struts.
I want to give you new powerful j2ee framework toname shine.
when I searching for a powerful j2ee frame work fore use insted of struts and jsf, I see a document about a j2ee frame work with name shine framework.
when I see a simple helloword sample with it, I think I find apowerful framework for replace it insted of shine.
but I can not trust it in that time.because it`s new and I can not finde more document about it.but after 1 week when I searchin about shine I see sevral document about shine that writen with shine framework`s support team.
that is unblivable.
when I read shine `s learning samples, and deploy thats sample,I enjoy.
because when I work with it , I understand shine is very powerful (as a sample when I work with ajax in shine, I understand working with ajax in shine is very easy,create a connection and work with data bases with jdbc and hibernate is easy and strong in shine and ...)
my friend my discribtion is not show ,shine frame work`s power.
you must test shine frameworks yourself and work with it for understand shine `s power.
test it for one time and be shine framework`s user for always like me.
for finde documents about shine(shine`s learning document) visit this links:
www.j2sos.org in technical forum
and for download shine framework you must visit sourceforge.net in this link:
remembre you my friend.you are in my dept for this informathion.
you must if you find a new j2ee framework in future , send your informathion about that for me,for release you from my dept .
good luck and enjoy than shine framework.
I am speechless. Are you Rod's alter ego? Or Jürgen's :-). They didn't come over like that yet. Did they found a church :-).
We all know that u r not impressed with Spring. But cant u just keep that to urself. Is it necessary to give vent to ur feelings in any thread which praises Spring. 99% of the community believes that Spring is a wonderful framework and it solves most of the problems that many of the people face in their J2EE life. Its the community that is praising Spring. Its not Rod & Juergen that are boasting abt it. And whats with this ego thing. If u want to taste that, try messing arnd with the JBoss guys.
My comments do not intent to praise anybody's ego. If someone has already done a
great contribution to the community, you should at least give them a credit and
show your gratefulness : it is just a good social conduct.
I did not said that there is no room for innovation: What I said is that Spring is a state-of-the-art framework and it has set a high standards of quality "difficult" to be challenged. In fact, it can be argued that it is one of the its most important contributions, that is , it will a play a quality
enhancement catalyst accross the community.
As far as your comments regarding how basic Spring AOP is concerned,
it just shows that you did not understand what Spring is all about.
It is not my duty to lecture about enteprise computing and Spring's pragmatic solutions to the problems encountered in this area I feel obliged to make a point clear: Spring is not yet another AOP framework. It is a framework that removes the buzz around AOP and puts it in a pragramtic perspective so that you use it to solve your problems(like declarative middleware services) and add real value to your applications.
It is just irrelevant to say that Spring AOP is basic. It is in fact not.
It is true that it is not as complete as a language level
AOP implementation like AspectJ but who cares?