[nickarls]

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...

[nickarls]

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 ?

[matt.corey]

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

[agori]

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  ;)

[gavin.king]

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.

[agori]

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.

[pmuir]

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