Ole,
the interceptor layout is a mirage.
yes it calls "next().invoke()". But the given sequence of interceptors
MAKES THE EJB CONTAINER.
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).
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.
marc
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Ole Husgaard
|Sent: Monday, January 29, 2001 2:41 PM
|To: jBoss Developer
|Subject: Re: [jBoss-Dev] Externalized container interceptors
|patchreadyfor commit
|
|
|Hi,
|
|marc fleury wrote:
|> Also the main container "interceptors" should not be removed (i.e. if you
|> put the acquisition after the synchronization the whole thing bombs).
|>
|> We might have "typeless" interceptors but their ordering is quite set in
|> stone (CMT BMT etc etc). So the externalization is relevant to add
|> additional custom interceptors in between or before and after but not the
|> "basic EJB interceptors".
|
|I think that we should give people the freedom
|to configure the interceptor chain in whatever
|way they want. Except for the ContainerInterceptor
|who is always last and is not configured here.
|
|Of course, such freedom also means that people are
|free to shoot themselves in their feet :-(
|
|But this *is* advanced configuration, and I think
|that we should assume that people that are changing
|this must know what they are doing.
|
|In some cases it might make sense not to have all
|the "basic EJB interceptors" in the chain. This
|might be the case if a developer wrote a custom
|interceptor that did the job of one of the basic
|interceptors in some special way.
|
|
|Best Regards,
|
|Ole Husgaard.
|
