Yes, this is a serious bug, that I reported last week.

Could you give precisions on how the ordering of interceptors is done when many extensions define their own interceptors in beans.xml.

I guess it is undefined except if the application redefines all interceptors in its own beans.xml.

I think they are just listed in the order they happen to appear in the list of URLs to beans.xml files in the bean deployment archive and according to the tree of reachable bean managers(?)

Thanks for the update, Gavin -- is there a ballpark release date for the 1.0.1 release?

William Draï wrote on Dec 02, 2009 11:52:
Could you give precisions on how the ordering of interceptors is done when many extensions define their own interceptors in beans.xml. I guess it is undefined except if the application redefines all interceptors in its own beans.xml.

Nono, interceptor ordering is per-module. So each module has its own list of interceptors, with its own well-defined ordering. There is no application-global interceptor ordering, since there are no application-gobal interceptors.

Does that make sense?

Nicklas Karlsson wrote on Dec 02, 2009 12:25:
I think they are just listed in the order they happen to appear in the list of URLs to beans.xml files in the bean deployment archive and according to the tree of reachable bean managers(?)

No, definitely not.

I understand that the interceptor chain is per module.

But what happens if I have 3 jars with an extension that defines SomeUsefulInterceptor in beans.xml of its own jar, a second extension that defines EvenMoreUsefulInterceptor, and the application module itself that has only TotallyUselessInterceptor in beans.xml.

Do you mean that only TotallyUselessInterceptor will be enabled for the app module ?

Exactly. The module would need to declare all three interceptors explicitly in its own beans.xml. I really think this is the Right Thing :-)

If I understand correctly, that means that what Matt tries to do wouln't work (defining an interceptor in a library jar beans.xml) even without the bug you indicate.

And that's not what I've observed in the current version of Weld/JBoss 6. My interceptor defined in the beans.xml of an extension jar is happily applied to all beans of all my other ejb jar modules (and that perfectly fits my need). I've no idea what would be the order of interceptors for now as I've only one :-)

As for the Right Thing to do, I think what Matt (and I) want to do is correct, and it would be strange to force users of extensions to define all the extension interceptors manually in their beans.xml.

At least, there should be a way to do something like this :

<interceptors>
   <class>...</class>
   <extension>...</extension>  => All interceptors of the extension applied here
   <class>...</class>
</interceptors>

If I understand correctly, that means that what Matt tries to do wouln't work (defining an interceptor in a library jar beans.xml) even without the bug you indicate.

Right. You must declare interceptors in the module in which they are to be used, not in the module in which they are packaged. :-)

And that's not what I've observed in the current version of Weld/JBoss 6. My interceptor defined in the beans.xml of an extension jar is happily applied to all beans of all my other ejb jar modules

OK, then that is a bug. Please report it in JIRA.

(and that perfectly fits my need). I've no idea what would be the order of interceptors for now as I've only one :-)

Right, so it's perfectly fine when you've got just one interceptor. Once you have lots of modules in your application, along with several portable extensions, each defining their own interceptors, it's going to be a total clusterfuck :-)

So, like I said, what the spec says is the Right Thing :-)

At least, there should be a way to do something like this :

<interceptors>
   <class>...</class>
   <extension>...</extension>  => All interceptors of the extension applied here
   <class>...</class>
</interceptors>

Hrm, that's not a bad idea, however I don't expect that many extensions are going to define multiple interceptors.

By the way, I'm planning the next release of CDI to include a programmatic way to register interceptors/decorators/alternatives. Namely, a Module object, and a ProcessModule event in the portable extension SPI.

So you would be able to magically register interceptors with that. Whether it would be a Good Idea, I doubt :-)

Having many interceptors for an extension is not necessarily the problem. But exposing the internal implementation (i.e. the interceptor class) of the extension to the user does not look as a Good Idea :-) I would like to be able to change the class names of my interceptors without breaking all applications using my extensions.

I agree that automatic registration of interceptors can lead to a total clusterfuck (never seen this word before, I like it so much that I felt an absolute necessity to reuse it somewhere immediately), but on the other hand non-automatic registration complicates the installation of extensions that in most cases could be as simple as putting a jar in WEB-INF/lib (or adding a dependency to pom.xml for maven lovers). This problem of ordering resembles to what happens with the new web-fragment feature of servlet 3, I don't know how it's handled there.

Gavin King wrote on Dec 02, 2009 16:34:
No, definitely not.

Yes, if you interpret me correctly ;-)

What I was saying that a BeanDeploymentArchive can have multiple beans.xml (although there is usually only one for a file-based one). And if each beans.xml enables some interceptors, the order of them will be the order of the files (keeping the order within each single file). Well, URL, not always file.

The reachable managers-stuff was of course a brain fart...

But exposing the internal implementation (i.e. the interceptor class) of the extension to the user does not look as a Good Idea :-)

Yes, I also don't love this, but I don't see any better solution to the problem of ordering interceptors defined in different portable extensions, We have to guarantee deterministic behavior here, we can't have the container just set them up in a random order at runtime.

Now, I guess what you're suggesting is to introduce some additional indirection - a string based name or annotation - instead of using the bare class name, but I don't really see that very much is to be gained by that.

This problem of ordering resembles to what happens with the new web-fragment feature of servlet 3, I don't know how it's handled there.

Yes, it's a very similar problem. I'm not a big fan of their solution, frankly. Go take a look at the new servlet spec. I think what they have is probably OK for the problems they're working with, but it wouldn't be OK, IMO, for what we're doing.

What I was saying that a BeanDeploymentArchive can have multiple beans.xml (although there is usually only one for a file-based one). And if each beans.xml enables some interceptors, the order of them will be the order of the files (keeping the order within each single file). Well, URL, not always file.

A single bean archive can have multiple beans.xml files? Really? What for?

Dunno. Pete wrote it ;-)

A while back I had a theory in another thread for autoconfiguring applications that could enable an alternative stereotype from a know JNDI key by adding another beans.xml to the deployment archive...

I did some refactoring that might have touched this area, do you still have your deployment archive and do you think you could attach it to https://jira.jboss.org/jira/browse/WELD-319 ?

Yes, I also don't love this, but I don't see any better solution to the problem of ordering interceptors defined in different portable extensions, We have to guarantee deterministic behavior here, we can't have the container just set them up in a random order at runtime.

I can think of lots of ways to do it -- the details don't really matter, as long as it is explicitly defined (something Java EE specs have been bad at historically, but which the CDI spec does a good job of)...

For the record, I can live with the current solution, but would prefer a standard ordering mechanism, with some way to override it in a given module... having to expose the interceptor class name is a bit smelly -- even using the InterceptorBinding would be more palatable, but I recognize this is really a different thing...

I don't expect that many extensions are going to define multiple interceptors.

An extension that defines a Transactional interceptor to handle the various EJB TransactionTypeAttributes could have six, if they're implemented separately, so I think it's quite feasible... Any shop who adopts CDI as an internal framework platform could have several interceptors over time to handle transactions, logging, security, etc -- I think it's quite likely that this will be more common than you think, especially if CDI gets the traction that I think it will :)

Again, though, I think the current solution is workable, and is far better than simply leaving it up to the implementation...

M

Gavin King wrote on Dec 02, 2009 17:47:
Right, so it's perfectly fine when you've got just one interceptor. Once you have lots of modules in your application, along with several portable extensions, each defining their own interceptors, it's going to be a total clusterfuck :-) So, like I said, what the spec says is the Right Thing :-)

But try to think what would be the situation in JSF if it requires every component (view handler, navigation handler, phase-listener) to be configured in WEB-INF/faces-config.xml. This configuration file should expose a lot of implementation details.

In JSF the ordering is not well defined, but at 95% it's ok. Usually extensions work on different aspects so also if the order is not deterministic this doesn't cause issues.

Hrm, that's not a bad idea, however I don't expect that many extensions are going to define multiple interceptors.

Because of success of CDI and CDI extensions, I think you said the last famous words ;)

But try to think what would be the situation in JSF if it requires every component (view handler, navigation handler, phase-listener) to be configured in WEB-INF/faces-config.xml.

Funny, it was actually my (bad) experience with JSF extensions that convinced me that we really needed to have a well-defined, deterministic ordering here :-)

In JSF the ordering is not well defined, but at 95% it's ok.

I don't think you realize the pain and suffering that framework developers go through to ensure that you guys get a 95% ok user experience :-)

Usually extensions work on different aspects so also if the order is not deterministic this doesn't cause issues.

Trust me - it does.

Because of success of CDI and CDI extensions, I think you said the "last famous words" ;)

Hehe, you could be right. But I'm not worried, it's going to be easy for us to add something additional here, if and when the need arises.

Gavin King wrote on Dec 08, 2009 20:56:
Funny, it was actually my (bad) experience with JSF extensions that convinced me that we really needed to have a well-defined, deterministic ordering here :-)

Ok you are right, but I realized today that JSF 2.0 tried to solve the faces-config.xml ordering.

http://snipurl.com/tmbz5

If I read well they let specify a name for every faces-config.xml so that the main configuration file can define an order using this names.

Nicklas Karlsson wrote on Dec 02, 2009 21:54:
Dunno. Pete wrote it ;-) A while back I had a theory in another thread for autoconfiguring applications that could enable an alternative stereotype from a know JNDI key by adding another beans.xml to the deployment archive...

I guess left over from old version of SPI, for 1.1 we can probably remove it.

BTW JBoss AS also has another bug in this area - it doesn't describe the module structure well enough.

https://jira.jboss.org/jira/browse/WELDINT-1