...snip > Two things that would be nice to clean up with the existing WS binding > structure are: > > - change the wsdlgen module to be more of a standalone utility with no > or minimum dependencies on the WS binding. There's already been some > work on that and IIRC it doesn't now drag in the entire Axis2 runtime > but it could be cleaned up more so that you can gen a wsdl port type > without needing any WS binding.
+1 to cleaning up etc. I have to educate myself more about its innards. > > - separate the scdl xml/model from the Axis2 runtime modules so you > can use scdl including WS (and policy) without dragging in all the > Axis2 runtime (does anyone really care about this? we try to keep all > the model modules separate from the runtime ones but its not done > properly yet and after 4 years _no one_ has ever asked or complained > about it so maybe we shouldn't bother trying) It's the right idea. It's interesting to node that the version of axis we use does have an influence elsewhere. For example, it implies a version of axiom which is then used by other modules. Maybe in the OSGi world we can get away with multiple version of things but I thing we want to avoid if we can. > A lot of those modifications were to do with getting Axis2 to support > the SCA service names which can include slashes which didn't used to > be supported in Axis2 but i think might be now. The main things to > check are the service name we want can be registered and the correct > endpoint is made available and the wsdl gets the correct endpoint. > Useful to know, thanks. >> B/ There are several questions in code comments about sharing >> configuration context. I'm not sure whether this was ever resolved > > I don't think it was. Axis2 has a ConfigurationContext that configures > the Axis2 runtime including all the configuration for each service > endpoint. Right now we create a new ConfigurationContext for every WS > service. That sounds inefficient though i've no idea how much overhead > it really is. Nor me. I'll experiment. Simon
