Container Interceptors in JBoss 7.2Alpha1

[fernando.rubbo]

Hi,

Suppose we have two CONTAINER interceptors. Each one perfoming a diferent task but with a dependent order. According to https://docs.jboss.org/author/display/AS72/Container+interceptors the below configuration seems to be correct?

          <ci:container-interceptors>

            <jee:interceptor-binding>

                        <ejb-name>*</ejb-name>

                        <interceptor-order>

                                      <interceptor-class>..Log4JContainerInterceptor</interceptor-class>

                                      <interceptor-class>..MonitoringContainerInterceptor</interceptor-class>

                        </interceptor-order>

            </jee:interceptor-binding>

          </ci:container-interceptors>

However, whenever I've tryed to use the above configuration, I got the follwing error:

          Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS014552: Default interceptors cannot specify an <interceptor-order> element in ejb-jar.xml

                    at org.jboss.as.ejb3.deployment.processors.dd.ContainerInterceptorBindingsDDProcessor.deploy(ContainerInterceptorBindingsDDProcessor.java:103)

                    at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:120) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]

                    ... 5 more

What I would like to undertand is: what is the reasoning for this error whenever you use * in <ejb-name>. Moreover, how can we ensure this interceptor order?

Thanks

Fernando Rubbo

[jaikiran]

Just remove the interceptor-order for ejb-name = * and have it as follows:

<jee:interceptor-binding>
                        <ejb-name>*</ejb-name>
                                      <interceptor-class>..Log4JContainerInterceptor</interceptor-class>
                                      <interceptor-class>..MonitoringContainerInterceptor</interceptor-class>
            </jee:interceptor-binding>

It will run in the order those interceptors are listed.

As for the interceptor-order element, the EE spec says that first the default interceptors (i.e. those applicable to all beans), then the class level interceptors (i.e. those marked specifically for a EJB) and then the method level interceptors are run in that order. So if you want to change that order, you are expected to use the interceptor-order element.

[fernando.rubbo]

Jaikiran,

Two things:

1. Thank you very much for you fast response and for your explanation. It worked just fine.
2. Actually I have another item to discuss with you. It is about the interceptor order you have planned. As I could notice the order is something like this:

	TCCLInterceptor
	AditionalSetupInterceptor
	NamespaceContextInterceptor
	*LoggingInteceptor
	ShutdownInterceptor
	<MY CONTAINER INTERCEPTOR>
	*SecurityContextInterceptor
	CuncurrentInvocationInterceptor
	*CMTTxInterceptor
	PooledInstanceInterceptor
	ComponentDispatcherInterceptor
	SBInvocationInterceptor
	*ExecutionTimeInterceptor
	UserInterceptorFactory
	ManagedReferneceMethodInterceptor
	<MY EJB Interceptor>
	<MY EJB>

The problem I'm facing it that some interceptors (monitoring and logging) I have nowadays depends on the user being in the context. For example, in jboss 7.2Alpha1 container interceptor whenever I've tried to get the principal using SecurityContextAssociation.getPrincipal(), I've got a SimplePrincipal. And not The Principal Object we have defined in our logging module. When this method call reaches the EJB I got our app specific Principal.

So, the point is: could you guys change the interceptor location for one step further? After SecurityContextInterceptor?

Thanks a lot for you help

[jaikiran]

The whole point of introducing these container interceptors was to allow user application's to plugin the interceptors before the security/tx management interceptors come into picture so that the user application interceptor can play a role in passing along any additional data required by the later interceptors.

If you want certain interceptors to be run after the security context and other container managed resources have been setup then all you need is Java EE spec specified user interceptors.

[fernando.rubbo]

Not actually,

What I need is after Security and before transaction.

...

Security

<MyContainerInterceptor>

CMT

...

<MyEJB>

This way It is garanteed that the transaction will be commited and the user will be logged on with all its information. Including impersonating information (when be the case), roles, and others

Default EJB spec is after security and after transaction.

...

Security

CMT

...

<MyEJBInterceptor>

<MyEJB>

So we have no ide if the transaction was commited or not.

[fernando.rubbo]

I know I've asked in this forum https://community.jboss.org/thread/213749 to put the container interceptors in the place of LoggingInteceptor, but I haven't realize I would not have the security context done at that point.

Actually, I think that both possibilities would be interesting (before and after security). What do you think to put some configuration in jboss-ejb3.xml for that?

Thanks

[jaikiran]

Fernando Rubbo wrote:

Not actually,

What I need is after Security and before transaction.

We don't have any plans to add such support where the application can plugin in system interceptors at arbritary locations. At least not that I'm aware of.

Fernando Rubbo wrote:

So we have no ide if the transaction was commited or not.

Why do you need an interceptors for that because the transaction commit/rollback is something that's supposed to be handled by the transaction manager and the container. If that's not working then you'll see a lot other issues. I don't see a reason why one would need a interceptor to verify that. If you still want to check the transaction activity, all you need to do is switch the relevant logging from the transaction logging packages.

[fernando.rubbo]

We don't have any plans to add such support where the application can plugin in system interceptors at arbritary locations. At least not that I'm aware of.

I understand your point and in some parts I agree with you. Doing this you are adding complexity. But we had that in older version of jboss and actually I liked it as it was because of the flexibility we had.

Why do you need an interceptors for that because the transaction commit/rollback is something that's supposed to be handled by the transaction manager and the container. If that's not working then you'll see a lot other issues. I don't see a reason why one would need a interceptor to verify that. If you still want to check the transaction activity, all you need to do is switch the relevant logging from the transaction logging packages.

We do not need to handle anything about the transaction. We just ned to be sure it have been commited or have been rollbacked. Let me give you an exemple: supose you have executed an EntityManage.persist(..) or update(..) but the flush to the database have not being performed yet. Then your EJB method finished. Then your Spec EJB Interceptor finished (it has the same lifecicle of the EJB). Then it reaches CMTTxInterceptor and the interceptor actually execute the SQL into the database. At this point an error ocurrs.

So if you have used an Spec EJB Interceptor to log or monitor our services. This intercetor would say: "there was no problem executing this service" . However the problem was shown only at CMTTxInterceptor when comminting the transaciton.

In other words. To not get incorrect information about the services we need to intercept as earlier as possible in the stack (or, at lease in this case, earlier than CMTTxInterceptor). In our especific case, these interceptor use User context information. That is why the best place for our container interceptor would be between SecurityContextInterceptor and CMTTxInterceptor.

Of course, we can make it work as you have designed container interceptors nowadays retriving required information (which will be acessible in an interceptor further). May be it impact in performance once we need to go to the database. May be we can use a shared cache. I don't know. Need to think better.

Actually I'm glad you have added container interceptor in jboss 7. But I still think it would be interesting to have the flexibility we had in the past. Actually, I can not understand why this kind of container interceptor is not in the spec. Lots of people in enterprise use it for this kind logging and monitoring.