Thanks Jason. There isn't much information on @BypassInterceptors in the docs.

a) When should this annotation be used?

b) When shouldn't it be used?

I assume that any sort of Helper class should get this annotation - especially where it is pretty much self-contained. Whereas any class that acts as a controller should not have it especially if it needs to inject/outject more than a few components from/to the context.

Can Norman/Pete/etc provide some guidance around this as the performance increase is too tempting to ignore.

Thanks,

Damian.

I am sure the upcoming performance review that has been mentioned will also result in better docs on that part.

I haven't followed the performance threads that closely but I got the impression that the injection happens on every call; does that also mean that if you have a FooBean with n injections and FooBean has a FooEntity and you have a page with m references to the entity, every fooBean.fooEntity.fooField getter call also results in the n fooBean injections?

Some sort of @In(lazy=true) would be cool but I guess it's not possible since it hasn't been done.

Am I way off in expecting this would normally be solved in the presentation layer (eg. the xhtml file) by exposing the necessary variables in the row variable?

Hi Folks,

I just came across a blog entry on Seam Performance and its interesting.

Here's the link:
http://svetzal.wordpress.com/2008/03/02/performance-profiling-with-jboss-seam-part-1/

Hi Jason,

I think the increment of performance is due to the change you did from @Stateful to simple POJO component, more than removing @BypassInterceptors.

After reading your post I was wondering what would be the impact of my code, which is very similar to yours:

@Name("cipherUtil")
@BypassInterceptors
@Scope(ScopeType.EVENT)
public class CipherUtil {
     public encrypt(String text) {
          return ((Cipher) Component.getInstance("cipher")).encrypt(String.valueOf(value));
    }
     ...
     
}

To the following:

@Name("cipherUtil")
@Scope(ScopeType.EVENT)
public class CipherUtil {

    @In
    private Cipher cipher;

     public encrypt(String text) {
          return cipher.encrypt(String.valueOf(value));
    }
     ....
}

I tested it several times, and I get the similar response time (78ms) for 10 items.

The xhtml is:

 <rich:dataTable value="#{categoryList.resultList}" var="categoryItem" id="categoryListId"
                        rows="10"
                        width="100%">
            <rich:column>
                <f:facet name="header">
               Code     
                </f:facet>
                <h:outputText value="#{cipherUtil.encrypt(categoryItem.code)}"/>
            </rich:column>
 </rich:dataTable>
 

I didn't try to test changing it to an @Stateful, but I guess that could be the reason.

I think it would be a pain to get rid of @In or @Out to increase performance and to have to use Component.getInstance() otherwise.

Anyway, I'm looking forward to the Seam performance recommendations.

Jason Long wrote on Mar 03, 2008 06:41 PM:


For this simple usage, I have no problem using

Component.getInstance

instead of

@In

While this might be the case. It is still a workaround rather than a solution, don't you agree?

Do you know by chance whether there is a JIRA issue for this (I couldn't find one)?

This is on our radar already, see .

Hi,

and instead of

@Out
private MyTest test;

I should use:

Contexts.getConversationContext().set("test", test);

?

Hi,

while

@In
EntityManager entityManager

works for me, unfortunately the following returns null in my case...

EntityManager em = (EntityManager) Component.getInstance("entityManager")

the same with the Seam log-component.
Why is null returned?

Alexander

Christian Bauer wrote on Mar 03, 2008 08:04 PM:


This is on our radar already, see .

This is excellent! But I actually meant something more traceable (JBSEAM-2704) :)

Here is a related thread: http://www.seamframework.org/Community/SeamPerformanceProblemRewardingWorkaround.

That discussion lands in a DTO-pattern for avoiding the repeated injection-overheads. It also provides some tools for finding similar problems over the set of beans (pojos or SxSB) you have in your application.