-
1. Re: SwitchYard runtime config
tfennelly Mar 23, 2011 1:09 PM (in response to kcbabo)So are we talking about a process whereby these runtime configs are loaded based on a classpath scan for one or more runtime config files? For example, out-of-the-box transformers are placed in META-INF/switchyard/transforms.xml and would only contain TransformsModel data?
-
2. SwitchYard runtime config
kcbabo Mar 25, 2011 7:10 AM (in response to tfennelly)That's a good point about META-INF/transforms.xml. For the benefit of folks that did not see our #switchyard IRC conversation yesterday, here are the use cases we talked about for transformer configuration:
1) we have a stock set of transformers that we define and these are wrapped up in a definition file inside a jar
2) the user might want to supply instance/domain-wide transforms and those can be put in the runtime config
3) lastly, there may be application-specific transforms and those go in switchyard.xml
The runtime configuration I was referring to when I originally created this thread was #2 above. It's a configuration that controls the configuration of a service domain and anything it creates (registry, bus, activators, etc.). Looks like we will need to add config support for #1 as well.
This brings up another question w/r/t schema modularity. We need to decide whether all of these configs go inside one big switchyard schema or if they are stuck in independent schemas. The latter approach would likely lead to n + 1 schemas, since you would want a base schema which holds common types. Personally, I'm leaning toward one switchyard schema, but I can certainly be convinced otherwise.
-
3. Re: SwitchYard runtime config
tfennelly Mar 30, 2011 8:15 AM (in response to kcbabo)Keith Babo wrote:
This brings up another question w/r/t schema modularity. We need to decide whether all of these configs go inside one big switchyard schema or if they are stuck in independent schemas. The latter approach would likely lead to n + 1 schemas, since you would want a base schema which holds common types. Personally, I'm leaning toward one switchyard schema, but I can certainly be convinced otherwise.
One uber config namespace for everything? Not sure how nicely that would play with the configuration code, since it relies on the namespacing to split out the configs. One uber config namespace would mean all the config stuff we currently have split out for core, transform, soap, bean etc would all be piled in together. In time, I'd say that could become a big blob. It would work... just saying that I wouldn't really like it... I think having the separate concerns split out cleanly into their own namespaces is nice.
-
4. SwitchYard runtime config
kcbabo Mar 30, 2011 8:34 AM (in response to tfennelly)We definitely can't have one uber namepsace for everything, because it destroys our modularity and extensibility support. To be perfectly honest, I can't remember what point I was trying to make with the single schema thing. ;-) I think I might have meant that the runtime configuration that I referred to in the first post can all go in the same schema. One risk with the modular configuration is that you end up with a schema for each element in the name of modularity. Certainly there are cases where this is appropriate (e.g. component schemas), but we should try to group schema definitions when they are related (e.g. runtime configuration).