Nice work! -- dims
On 3/17/06, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > > 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] > -- Davanum Srinivas : http://wso2.com/blogs/
