Basically, that commit removed the Sun Reference implementation of JAXWS. However, we still require the jaxws API jar (since that is our public API) and we still use the Sun JAXB 2.0 reference implementation (until someone creates an open source alternative) and the Sun SAAJ 1.3 reference implementation (until we find another implementation with less bugs or have time to fix the bugsin one of the open source alternatives). I think we also currently use the Sun StAX parser, but I'm going to try to move that to woodstox next week.
Of course, we need a BUNCH of the Sun API jars. activation, jsr250, jms, jsr181, jaxws, jaxb, jsr173, saaj, etc.... Basically, up to that point, we had been using the JAX-WS reference implementation code generator. For some reason, their code generator jar also required their runtime jar. (which seems completely backwords to me) This commit switched us completely over to our own code generator which allowed us to completely remove the Sun reference impl runtime jar and tools jar. Enjoy! Dan On Friday 17 March 2006 15:39, Davanum Srinivas wrote: > Daniel, > > Does [1] mean that there is no com.sun / jax-ws RI dependendency > anymore in Celtix? > > thanks, > -- dims > > [1] > http://svn.forge.objectweb.org/cgi-bin/viewcvs.cgi/celtix?view=rev&rev= >742 > > On 3/17/06, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > (I apologize in advance for the length of this email... After > > meeting with Jim and Sebastien for the last two days, there are a LOT > > of thoughts swirling around in my head....) > > > > One of the questions that came up in the discussions was something > > along the lines of "if a user wants to replace the Axis 2 ws > > implementation with Celtix, how would they do it?" Or, more > > generally: "In tuscany, if I want to replace XXXX with YYYY where > > YYYY is functionally equivalent, how can I do it?" (XXXX being a > > binding.*, container.*, etc...) > > > > The "simple" answer is something along the lines of: delete the XXXX > > jars, add the YYYY jars, muck with the classpath, done. However, > > that really sucks. Telling users to muck with things down on that > > level is usually not a good idea and can generally result in bad > > things happening. The other problem with this approach is that > > there is no way that a user could use BOTH XXXX and YYYY in the same > > system since XXXX is completely deleted. > > > > One idea I came up with is a concept of "aliasing". All components > > would always register with a very specific name. Instead of > > binding.ws, it would be binding.axis2; instead of container.js, it > > would be container.rhino, etc... Tuscany would then have some > > configuration that would "bind" the specific name to the "generic" > > name. This could come from a config file, a system property, > > etc.... If the user want to change the underlying implementation > > of one of the generic > > > > One advantage of this that the user then has more control in their > > assembly. If they want to use a more "portable" form and allow the > > sca/tuscany runtime to use the default, they can do something like > > "implementation.js" or "binding.ws" and the tuscany runtime would use > > the appropriate one that is configured. However, if the user wants > > the specific version (using some advanced feature of axis or > > something...), they can specifically use "binding.axis2" or > > "implementation.rhino". It allows complete coexistence. In a > > module, you could actually use both "binding.axis2" and > > "binding.celtix" as well as the default "binding.ws" that may or may > > not point to one of them. > > > > > > The next "issue" this brings up is how to provide a usable system if > > the user HASN'T configured anything (zero config) as well as validate > > that a user that has configured something hasn't shot themself in the > > foot. On thought with this is that when something registers with > > the system, it not only registers it's name, but also can return a > > list of services it can provide. Example: Name: binding.axis2, > > Provides: binding.ws > > > > With that additional bit of information, the runtime could > > automatically wire stuff up with no configuration as well as validate > > configuration. (example: I alias "binding.ws" to "binding.jsonrpc". > > That shouldn't work since jsonrpc doesn't provide that service.) > > In the case where there are two or more implementations that provide > > a service, it could be a "first one registered" or "undetermined" or > > anything. The other thing about this is that a single "thing" > > could possibly provide multiple services. Example: Name: > > binding.celtix Provides: binding.ws, binding.corba, binding.blah) > > > > Anyway, I just wanted to start a discussion about this. This is > > going to be important as we start getting Celtix more integrated. > > > > Thanks! > > -- > > J. Daniel Kulp > > Principal Engineer > > IONA > > P: 781-902-8727 C: 508-380-7194 > > [EMAIL PROTECTED] > > -- > Davanum Srinivas : http://wso2.com/blogs/ -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED]
