The following info may be somewhat related to this discussion....
For the recursive proposal under consideration in the spec, there is
a way to specify a composite property which can be a complex type.
Child components may have properties configured using an XPath
expression that point to a property on their parent. If we support
some form of inclusion for properties, the composite property can
actually be another xml file. This would allow us to define a
"complex configuration" type that is edited by administrators in
another xml file and then have runtime system services configured
using xpath expressions pointing to parts of that complex type. This
will allow us to avoid having admins mess when SCDL of system
composites.
Thoughts?
Jim
On Apr 13, 2006, at 10:54 AM, Jean-Sebastien Delfino wrote:
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
