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
