how is the interceptor instance map to ejb bean instance ?

[bondchan921]

Dear All,

We need modify audit trail in an extended interceptor, but have no ideal about how interceptor instance service bean instance,

from my test seems, 1 interceptor instance service 1 bean instance, can anyone give a confirmation? and explain how interceptor instance map to different type of bean instance ?

Bond

[wdfink]

I can not exactly understand what you mean, could you explain a bit more?

If you mean how an interceptor is related to a bean instance, from specification the Interceptor lifecycle is the same as the bean lc. If the bean is created the interceptor is created and associated to the bean instance.

[bondchan921]

Thanks Wolf-Dieter Fink,

my questions is

1 interceptor instance associated to 1 instance of one bean ?  or 1 interceptor instance associated to all instances of one bean ?

[wdfink]

From the EJB spec, chapter 12.2 Interceptor lifecycle

The lifecycle of an interceptor instance is the same as that of the bean instance with which it is associ-

ated. When the bean instance is created, interceptor instances are created for each interceptor class

defined for the bean. These interceptor instances are destroyed when the bean instance is removed. In

the case of interceptors associated with stateful session beans, the interceptor instances are passivated

upon bean instance passivation, and activated when the bean instance is activated. See sections 4.4,

4.5.1, and 5.5.

That mean the Interceptor class is instanciated and destroyed together with the bean instance. So each interceptor instance is related to one bean instance.

[bondchan921]

Thanks Wolf-Dieter Fink,

Found this on "JSR 220: Enterprise JavaBeansTM,Version 3.0 EJB Core Contracts and Requirements"

[bondchan921]

Hi Wolf-Dieter Fink,

Why can't found interceptor section on the "Enterprise JavaBeansTM Specification, Version 2.1" ?  We have configured interceptors in the ${profile}/conf/standardjboss.xml  for our EJB2.1.

[wdfink]

EJB2.1 is different, and interceptors configured in standardjboss.xml are JBoss specific. AFAIR the interceptor is also has the same lifecycle as the bean.

[bondchan921]

Thanks Wolf-Dieter Fink, you always show light for me

1)Can I take further to take the interceptors configured in ${profile}/deploy/ejb3-interceptors-aop.xml as JBoss specific as well?

2)Do we have any doc describing the interceptor liftcycles configured in standardjboss.xml ?

[wdfink]

I don't understand exact what you want to achieve.

For 2) unfortunately I do not know a doc, if I remember correct there are only small snippets in docs, wikis and threads.

[bondchan921]

I have a customized Intertorceptor, used to do audit setters with the value before and after,

my concern is if one AuditTrailInterceptor instance service one EJB instance, for several interceptor instances of the same bean, the 'private Set auditedMethods' would be inconsistence.

================================================================

public class AuditTrailInterceptor extends FirmamentInterceptor implements NotificationListener {

   ...

   private String appName = null;

   private String beanName = null;

   private Set auditedMethods = new HashSet();    //this method need to audit.

   ...

  //handle the GUI changes audit seting for the bean

  public void handleNotification(Notification nf, Object handback) {

           if(nf instanceof MethodAuditChangeNotification) {

                    try {

     if(!gotAuditConfig) getAuditConfig();

            } catch (Exception e) {

     log.error("Error handling audit notification change for bean " + beanName,e);

            }

            MethodAuditChangeNotification macn = (MethodAuditChangeNotification) nf;

            String methodname = macn.getMethodName();

            boolean on = macn.isEnabled();

             log.info(this + " Notification received! " + (on?"Adding":"Removing") + " method " + methodname + " for bean " + beanName);

            synchronized(auditedMethods) {

    if(on) {

              auditedMethods.add(methodname);

    } else {

              auditedMethods.remove(methodname);

    }

            }

  }

}

.....

public Object invoke (Invocation mi) throws java.lang.Exception{

   //

   if(auditedMethods.contains(mi.getMethod().getName())){

        //log the changes before and after to database.

    }

}

}

[wdfink]

I'm not 100% sure, but I suppose that the HashSet() is not shared in that case between all Interceptors and you have to add it as a static Set

But if you only need the information during the invocation (before and after) the same Interceptor instance is used and you don't have a problem (but in this case I wonder whether you need the auditedMethods)

[bondchan921]

Thanks Wolf-Dieter Fink,

I have analyze the heap dump.

In my case, one instance of this interceptor maps to one EJBBean, not one EJBBean instance. and my auditedMethods is bean level, so it's ok to keep it private.

Thanks again...