Best practice to extend controller

[xbryan]

I was wondering what the best approach to extend a Roo-generated controller is. For example, after an entity is persisted, I would like to fire off an event to a service layer which will then process the new entity.

The only way I can think of doing it thus far is to copy the Roo-generated method from the .aj file and paste it into the .java file, so it becomes manually managed.

I was hoping I could keep the Roo-generated methods in the .aj file so Roo can manage them, and hook in my own post-processing step. Is such a thing possible?

[Andrew Swan]

Even if you could do that, it might not (depending on your application's business rules) be a good idea, because your post-processing step would run in a separate transaction to the one in which the controller called persist() or merge(). In other words, the persist/merge might commit, but your post-processing step might roll back, leaving your system in an inconsistent state.

There are two solutions:

• Old skool:
  
  • write a service layer "save" method that encapsulates both the JPA persist/merge call and the post-processing step,
  • push the create and update methods into the controller's Java class, and
  • modify those methods to call the new save method instead of calling persist/merge, OR
  
  
• New skool:
  
  • write an aspect that runs before/after/around your entity's persist and merge methods to perform the necessary additional processing (which I assume automatically takes part in the same transaction)
  
  

[xbryan]

Transactions are non-issue in my case, but thanks for pointing that out. I didn't entirely follow how your solutions can work in conjunction with Roo. I was hoping to keep the controller Roo-managed.

[IcedDante]

Maybe I'm not understanding this properly, but I am pretty sure that Controllers are not managed by Roo. That's to say: Roo creates the stubs and you take ownership after that point.

[Andrew Swan]

Maybe I'm not understanding this properly, but I am pretty sure that Controllers are not managed by Roo. That's to say: Roo creates the stubs and you take ownership after that point.

For each domain entity, Roo creates:

• an AspectJ ITD called FooController_Roo_Controller.aj
• FooController.java annotated with @RooWebScaffold
  

If and when you make changes to the latter, Roo will manage the contents of the former, thanks to the presence of the @RooWebScaffold annotation. So while it's true that the controller's Java source code is not directly managed (altered) by Roo, the resulting class file will in most cases contain methods that were introduced by the ITD. Sorry if you already knew this.

[delgad9]

You can enabled your "after an entity is persisted" method in the entity class and annotated it with @PostPersist.

I hope this helps you

jD

[melutovich]

Wouldn't this work to created a subclass that overrides that method of the parent and then call the parent method in the subclass's method and after the parent method is called to call your service method?

A better solution: ?
Normally a method existing in a java source file is not defined in the appropriate aj file, perhaps Roo could have an annotation defined such as @RooStillIncludeGeneratedMethod, however the generated method will be defined as private and have a suffix of "roo", you a create method would become rooCreate in the associated aj file, but still available for usage.