Thats fine with me - do you mind applying the change?
No problem. Will do.
Did you try that? I wonder the current org.switchyard.config.model.Descriptor may only support just one marshaller for each one namespace, so in order to use other Schemas in SCA namespace, we may need to add marshaller logic into V1CompositeMarshaller in the core repo, or change the namespace and isolate from SCA default.
Good point. I haven't looked into it in that much detail. I think you are correct, which makes me wonder about the best way to deal with this, if at all.
Thanks for highlighting the issue.
Assuming I understand the problem correctly, the quickest and cleanest way to solve this might be to simply acknowledge that multiple marshallers can be registered for a given namespace. Not sure how nicely fits with the current config API though.
David and I were actually chatting about the config API the other day. He put a lot of work into it back in the day and it's pretty much just plugged along without major mods for the better part of a year. In that year, we developed a better understanding of what our runtime and components would need from a config standpoint. In fact, I think we are still learning on that front. I sense that there will be one large (and final) refactoring there, and I don't believe we are ready for that yet. My preference would be to sit down with David and others and discuss all the changes at once instead of just updating as we go. So my feeling here would be to go with the least complex solution possible. If that's keeping a distinct namespace for now, let's just do that. If it's trivial to allow multiple handlers per namespace, then we can do that instead and use the standard SCA namespace. IMHO, what we should *not* do is drop 2-3 weeks on this right now when there are so many other important things to get done for 0.5.
The simplest is to do nothing now and address it as part of the future refactoring effort.
That gets my vote.
This just occurred to me, but yet another option is that all of the standard SCA config support is added inside the config project. Or maybe we split all the SCA config into a distinct module. In any case, the standard SCA stuff would all go there, including things like BPEL. This is all standard stuff and not tied up with component code at all. Now, if a component has an extension to the SCA types that it wants to register, then that goes in the component project module with a distinct namespace.
Now that I think about it, I think this is better than the other two ideas I discussed above.
@Rob : right, none of this has to happen immediately.
- I like the idea of getting the SCA stuff out of config.
- I agree that it would be best for us to get all our config requests/requirements put together instead of messing around as we go.
- I would need to go back and research the possibilities/impact/estimate on the multiple namespaces front. It indeed has been plugging right along on it's own now for quite some time, so I'm a bit dusty on what I wrote - LOL. And as Keith said, we already have enough to do for 0.5.
I am not sure what David means but getting the SCA stuff out of the config. Do you mean out of switchyard.xml. Or is this purely an internal discussion?
Purely a Maven and modularity thing. At present, the core config has model classes for SCA elements (composite, component, etc.). We're talking about moving that to a distinct SCA config module in the project structure.