Hi,
marc fleury wrote:
> the interceptor layout is a mirage.
Well, it is also a way of seperating different
pieces of work into different interceptors.
> yes it calls "next().invoke()". But the given sequence of interceptors
> MAKES THE EJB CONTAINER.
Yes.
> So get me right, you will be able to change your "persistence" CMP engine to
> be file based (I know it is the class I gave a couple a days ago on JBoss to
> a corporate client). Yes you can even remove it if you don't want the
> persistence.
>
> However you don't put the persistence before the acquisition for example, it
> just makes no sense (logically speaking it's absurd).
This is one way of shooting yourself in the foot.
I don't think it has been explicitly stated
before, but we do have a protocol before and after
each interceptor in the chain. This protocol
includes restrictions on the state of the MI and
objects that can be reached from there.
If two adjacent interceptors do not have a
compatible protocol, things simply won't work.
An example:
The protocol before the BMT interceptor says that
the EnterpriseContext in the MI must be set.
The protocol after the InstanceInterceptor says
that the EnterpriseContext in the MI is set.
So, if BMTInterceptor comes after InstanceInterceptor
this is fine.
BMTInterceptor can only come before InstanceInterceptor
if some other previous interceptor did set the
EnterpriseContext, otherwise the protocol would be
violated. (Don't ask me what the II then is supposed
to do if some other interceptor does its job.)
Similar statements about protocol can be made to
show why the CMT interceptor has to come before
the InstanceInterceptor, or why acquisition must
come before persistence.
> YES you can write any interceptor and do a "container in a class" work like
> JBoss1.0 (which I am really proud of, proves it can be done light;-) but the
> fact remains that the EJB work that is to be done remains pretty static and
> set in stone. (I should know..)
>
> So don't get me wrong. Yes we are modular EVEN IN THE INTERCEPTORS, yes YOU
> HAVE A CHOICE *** of INTERCEPTORS *** (woohoo), YOU ARE IN CHARGE but behind
> the doors, you are in charge of jack when it comes to EJB calls, you just
> can't put one notification before the other because that "is how you want to
> shoot yourself in teh foot"... if not... this isn't a "J2EE" EJB container.
> It is a "freak" container. Period.
>
> Now, the power of J2EE is the "stack" based approach IN-VM. I was the first
> one to preach it. Since Servlet is already a "stack" based design (I forget
> the word they use) EJB is also taking this route for EJB3.0 and making it
> "modular" means we can ADD stuff and SUBSTRACT SOME STUFF. I also suspect
> that the "valid" configurations can be numbered and some are just "freaks"
> (like you are going to sync before you lookup in cache? huh???)
>
> Bottom line, there is a finite set of valid XML configurations.
>
> Which is the point about "relevance" of the interceptor layouts.
For complete EJB conformance (nothing less, nothing
more and nothing custom), we have one and only one
valid interceptor chain configuration for each kind
of container (when counting CMT/BMT as seperate kinds
of containers). In such a case, there is no need for
configuration, as the interceptor chain might just as
well be hardcoded. This is where we are today.
When interceptor chain configuration is possible, and
the configuration is changed from the default, we get
some kind of "freak" container. I think these can be
put into three categories:
A) Working EJB compliant containers. An example of
this could be a user adding a debugging interceptor
somewhere in the chain to tell what is going on
there. Another example could be replacing one of the
standard interceptors with another interceptor that
does the same job, but in a different way.
B) Working, but non-compliant containers. A (not very
good) example of this could be replacing the
TxInterceptorCMT with another interceptor that does
not lookup metadata, but just assumes all methods have
transaction attribute Required.
C) Nonworking containers. The "persistence before
acquisition" example you mentioned comes into this
category.
I think we can agree that category A is OK.
Category C is bad, but we can see such things whenever
someone tries to change something they do not
understand. We probably have dozens of other things
that can be configured to make JBoss nonworking, and
it is hard to do anything about it if we want to give
people the freedom to configure without restriction.
Category B is not good either, but how can we tell if
a given interceptor chain configuration belongs to
this category (or category C), if we do not even know
the internals of all the interceptors in the configured
chain? And do we really want to stop people that want
non-compliance in their own private configuration?
Of course, JBoss should only ship with interceptor
chain configurations in category A.
Also, it might be a good idea to warn people that
changing the interceptor chain configuration from
the default is advanced and may lead to non-compliance
or a non-working container.
But I do think that we should be liberal about what
interceptor chain configurations should be allowed
to leverage the full potential of interceptor chains.
Best Regards,
Ole Husgaard.
