New AspectJ integration

[turksheadsw]

I'm trying to read up on the Spring 2.0 M1 release and I'm a bit troubled by the deeper AspectJ integration.

On the one hand, I understand the need to wire domain objects that are constructed outside of Spring. For example, libraries like Hibernate that construct domain objects using default, parameter-less constructors prevent any further configuration of the object.

A way to integrate with such libraries is necessary.

However, from a best practices perspective, doesn't it make more sense for Hibernate (and libraries like it) to allow you to provide some other kind of factory for your classes than the constructor?? Wouldn't that be a more appropriate solution to this problem?

I realize that backward compatability is required and that, in general, this solution will be needed where you have to use a third-party library that doesn't allow you to provide a separate factory.

Perhaps what I am really asking is: am I off my rocker here or am I missing something? Is this not really a case of Spring solving "Hibernate's problem"??

Thanks..

Ps.. this isn't a complaint about the new features, it's more just that I'm really bothered that people are going to see this as the "right" solution rather than as a "bridge" solution.

[oliverhutchison]

The beauty of this new integration with AspectJ is that it provides a generic way to wire up objects regardless of where they are constructed. It's not about fixing a problem with Hibernate is about offering a wealth of new opportunities to use IoC.

Ollie

PS. Spring already has a solution to the specific "Hibernate Problem" see DependencyInjectionInterceptorFactoryBean in the sandbox.

[sethladd]

Another thing to consider is that Hibernate doesn't control 100% of the object lifespan. For instance, Hibernate doesn't act as a generic object factory. You don't ask Hibernate for 'new' objects, only those that have been persisted.

What's nice about the new AspectJ integration is that it works all the time, independent of the persistence lifecycle.

[Rod Johnson]

Ps.. this isn't a complaint about the new features, it's more just that I'm really bothered that people are going to see this as the "right" solution rather than as a "bridge" solution.

On the contrary, I see as very much the right solution, and a solution tied to a particular ORM tool such as Hibernate as a significantly "bridge" solution. AspectJ provides an elegant, general solution in this case, which is far less fragile than an API-dependent solution that adds an additional point to keep in synch between Spring and a variety of other frameworks.

As Seth pointed out, we have had such a solution for Hibernate for well over a year, with DependencyInjectionInterceptorFactoryBean. It has never been promoted to the core, rather than the sandbox, because it's not nearly as general a solution as the AspectJ solution. For example:

- As other posters have pointed out, the ORM tool doesn't always instantiate the object. E.g. imagine that the isUserNameUnique() method uses an injected service. I can write the following code and it will work:

User u = dao.findUserById(25);  // Retrieved by Hibernate
if (!u.isUserNameUnique()) { ...

But if I do the following it will not work, as Hibernate doesn't yet know about the object:

User u = new User(uname, pwd, ...);
if (!u.isUserNameUnique()) { ...

- The Hibernate-specific solution is tied not only to Hibernate, but to a particular Hibernate version. E.g. we needed a Hib 3 version, because the Hib 2 one was broken by that incompatible migration. The AspectJ solution works with any ORM tool--imagine for example, switching between JPA providers, which you well might want to do in an evaluation scenario. The AspectJ solution also works in many scenarios other than O/R mapping. This means not only that there is a working mechanism regardless of the other tool or tools, but that users only need to learn one technique, and can then use it anywhere.

Rgds
Rod

[turksheadsw]

Thanks for the feedback.

I guess I'm just uncomfortable with the fact that I now have to incorporate AspectJ in order to use Spring, which was something that was unnecessary in the past.

However, if it's possible to fall back to the "less general" solution provided by DependencyInjectionInterceptorFactoryBean in cases where integrating AspectJ poses problems (political or technical) then I guess this makes everyone happy.

You guys seem to be very good at that :o)

Alright... back to learning about all the new features in 2.0...

[Rod Johnson]

I guess I'm just uncomfortable with the fact that I now have to incorporate AspectJ in order to use Spring, which was something that was unnecessary in the past.

This is new functionality, which extends the reach of Spring IoC to new areas. So there's no need to use AspectJ tomorrow to do anything you could do without AspectJ yesterday.

However, if it's possible to fall back to the "less general" solution provided by DependencyInjectionInterceptorFactoryBean in cases where integrating AspectJ poses problems (political or technical) then I guess this makes everyone happy.

We'll keep it around in the sandbox, at least. However, I doubt it will be promoted to the main tree--for the same reasons it hasn't been in the last 15 months.

Rgds
Rod

[sethladd]

I guess I'm just uncomfortable with the fact that I now have to incorporate AspectJ in order to use Spring, which was something that was unnecessary in the past.

Well, if done right, you won't even know that AspectJ is involved. AspectJ can use load-time weaving, so no compile step is required. It'll be pretty much a case of just including the aspectj.jar in your project, and use the new annotation.

In other words, there should be a very minimal impact on your code. The upside is that it is much more robust than the Hibernate solution.

[nlif]

Hi,

We are now exactly at the point of deciding on a solution for domain object dependency injection.

We have three places in our architecture in which domain objects may be created: Hibernate, the Web-Tier (we use domain objects as command-objects for form controllers), and our remoting layer (during deserialization of XMLs into Domain Objects. On one hand, since we know it's just these three places - we can add a call to AutowireCapableBeanFactory.applyBeanPropertyValues () and inject the new instance with the needed dependencies. On the other hand, this is not a very elegant solution. Not to mention that one of these days there may be a new place in which domain objects are created, and then we'll have to take care of it there as well.

So we were initially very happy to replace our code with the AspectJ solution. But we are now having some second thoughts: first of all, if we want to use compile-time weaving, we will need to either add the aspcetJ compiler to our IDEs (we use eclipse), and also to the Ant build scripts.

On the other hand, when trying to use LTW, we are running into nasty OutOfMemory issues when launching the application (it's a web-app running on Tomcat), which is caused by the AspectJ LTW (even when the aop.xml includes just a single class!).

This was solved by increasing vm heapsize and MaxPermSize, but still, it is somewhat alarming.

Has anyone encountered such OutOfMemory problems with LTW? What is considered better - LTW or compile-time weaving? Has anyone actually used this solution in a large-scale production application?

Thanks,
Naaman