Jeremy Boynes wrote:
Jean-Sebastien Delfino wrote:
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.
I would be concerned here about putting all the implementation details
for all the extensions in a single file. The existing implementations
already use multiple components and as they get more sophisticated
they are only going to use more.
I do like the idea though of having one file where the administrator
can tweak the system configuration.
I'd suggest therefore that we have one file in the tomcat conf tree
(perhaps conf/tuscany/system.conf) which uses the proposed recursive
model to declare each of the extensions as a sub-component. Something
like:
<composite name="tuscany.system">
<component name="axis2 extension">
<implementation name="axis2.module"/>
</component>
<!--
<component name="celtix extension">
<implementation name="celtix.module"/>
</component>
-->
</composite>
where "axis2.module" and "celtix.module" are the names of composites
that are defined by each extension.
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.
I agree we should move away from merging together system.fragment
files. I think the proposal above moves in the direction you proposed
but hides the internals of the extensions from the administrator.
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.
Agreed.
--
Jeremy
+1 from me, I like that. Shifting the configuration of the composite
level is a (better) extension of what I was proposing, although it
requires us to get support for composites in place, but it's a good move
as well :) so if other people agree then I'd like to see this
implemented for our May release.
--
Jean-Sebastien
