SEAM: Effective use of @BypassInterceptors?

Question

I was wondering what advice the community could give me on the use of the @BypassInterceptors annotation when programming with Seam? I've been reading up on increasing Seam application performance, and without fail every article mentions that adding this annotation can increase performance. My question is, where should it be applied? Are there general rules that say "when writing a component that does XXX you can safely apply @BypassInterceptors"? For example, should I apply it to my entity classes? What about a DAO? I'd be very curious to know what everyone else out there is doing, as well as what sort of performance increases you saw when applying it correctly.

Answer 1

If you are sure you do not need interceptor functionality, you can rely on @BypassInterceptor annotation to disable interceptors. Functionality includes

• Bi-jection (@In - @Out)
• Transaction management
• Event handling

And so on...

Because bi-jection functionality is achieved by using reflection (runtime) - See, for instance, this question where you can have an idea how much performance overhead reflection can add -, it can be avoided (besides @BypassInterceptor) by using

• Component.getInstance(<COMPONENT_NAME_GOES_HERE>)

• getter's and setter's

If you have

@Name("personManager")
public class PersonManager {

    private @In Person person;

}

<h:inputText value="#{person.name}"/>

You can instead of @In annotation

@Name("personManager")
public class PersonManager {

    private Person person;

    public Person getPerson() {return this.person;}
    public void setPerson(Person person) {this.person = person;}

}

But do not forget (Notice its newest value attribute)

<h:inputText value="#{personManager.person.name}"/>

Answer 2

Just a follow up to Arthur's post.

As a rule of thumb, if for instance, you are doing some calculation on a method that does not use any of the interceptors in Seam, ie: calculating some values, then it is a good thing to mark that method with @BypassInterceptors.

But always test thoroughly after adding this annotation. I have experienced strange bugs because I had this annotation on methods and classes that didn't come up on the initial testing.

It is wiser to let it be if you don't know exactly what you are doing or what the annotation is doing.