Daniel Kulp wrote:
Just a quick question: has any actions been taken on this issue yet?
Anymore thoughts or suggestions?
Thanks!
Dan
If we want to have a solution for this in our first release before
JavaOne, given the time we have left I think we need to take a very
simple approach. So here's what I'd like to suggest:
- We do not change the programming model, an application developer just
says <binding.ws> to declare a web service binding
- We probably don't have time to augment the programming model with
enough metadata and policies or profiles that will allow us to
dynamically pick a particular binding extension implementation
- We just allow multiple implementations of a particular binding
(<binding.ws> for example) to exist on the classpath of the server.
- We allow the system administrator to configure the binding extensions
that he wants active in a particular server
- We could invent a new configuration file listing the binding
extensions to activate, or we can just say that the system administrator
can configure the extensions in a system.fragment file under tomcat/conf.
In other words, instead of having fixed system.fragment files buried in
the binding extension jars, we have one system.fragment file under
tomcat/conf, where the system administrator can configure which binding
extension implementations he wants to activate. We could also use the
same approach to configure which component implementation / container
types to activate on a particular server.
We could also extend this to activate binding and container extensions
on an application basis, but I'm not even sure we need this right away.
I think we can live with a per server config for now, and revisit the
approach later in June.
Any opinions?
--
Jean-Sebastien
