I'm the confused one :) I was conflating the two. Daniel Kulp pointed
org.apache.cxf.dosgi.frontend.jaxws. If the first is true, the jaxb
databinding is used instead of aegis. If the second property is true,
> I'm confused. Generally, it's Aegis versus JAX-B and Simple versus
> JAX-WS. Are you really replacing Simple with JAX-WS, or are you
> replacing both?
>
> On Fri, Jun 5, 2009 at 2:13 PM, Josh Holtzman <
jholtzman@...> wrote:
>
>> I'm finally coming back to looking at this issue. I've added a Jira and a
>> patch at
https://issues.apache.org/jira/browse/CXF-2252>>
>> Let me know if there's anything I can do to clean up the patch. Since the
>> current Aegis databinding remains the default, I'm hoping that this patch
>> can be merged without causing any problems.
>>
>> Thanks,
>> Josh
>>
>> Josh Holtzman wrote:
>>
>>> Right. In the SOA world, the WSDL is the service contract. In the Java
>>> world, the interface is the service contract. I therefore see no problem
>>> using JAX-WS annotations on the Java interfaces, since they describe how to
>>> translate between Java and WSDL.
>>>
>>> Thanks,
>>> Josh
>>>
>>> Eoghan Glynn wrote:
>>>
>>>> Sorry Josh, I didn't notice your response before replying to Sergey.
>>>>
>>>> So in your case, it wouldn't actually be an issue that the JAX-WS
>>>> annotations were present on the OSGi service class?
>>>>
>>>> Cheers,
>>>> Eoghan
>>>>
>>>> 2009/5/12 Josh Holtzman <
jholtzman@...>:
>>>>
>>>>
>>>>> Hi Eoghan,
>>>>> Yes, it would most likely require JAX-WS annotations on the service
>>>>> interfaces rather than the impl classes, but IMHO it doesn't break the
>>>>> OSGI
>>>>> service model. Perhaps I should explain my use case.
>>>>>
>>>>> We are building an open source system that must be able to operate in
>>>>> both a
>>>>> co-located (one JVM) and distributed topology. For the co-located
>>>>> flavor,
>>>>> we don't want to incur the overhead of web service serialization... we
>>>>> want
>>>>> direct access to the java services as they were published to the OSGI
>>>>> service registry. For the distributed topology, we want to allow
>>>>> adopting
>>>>> institutions to swap out individual services for their own
>>>>> implementations
>>>>> in other languages. And finally, we want our service clients to be
>>>>> ignorant
>>>>> of the current topology. Service developers should enable their
>>>>> services to
>>>>> be available remotely (by publishing with the osgi.remote property and
>>>>> using
>>>>> JAX-WS annotations), but should not necessarily expect the services to
>>>>> be
>>>>> remote.
>>>>>
>>>>> Providing a JAX-WS configuration option shouldn't impact folks wanting
>>>>> to
>>>>> stick with aegis/simple. But it does allow projects that want all of
>>>>> the
>>>>> benefits of DOSGI to make their web service contracts usable outside of
>>>>> the
>>>>> CXF world.
>>>>>
>>>>> Thanks,
>>>>> Josh
>>>>>
>>>>>
>>>>> Eoghan Glynn wrote:
>>>>>
>>>>>
>>>>>> Hi Josh,
>>>>>>
>>>>>> I'm not entirely sold on the desirability of using JAX-WS with dOSGi.
>>>>>>
>>>>>> Wouldn't this require that the original OSGi service class was
>>>>>> annotated with @WebService, @WebMethod etc?
>>>>>>
>>>>>> And wouldn't this defeat the whole purpose of dOSGi in a sense? i.e.
>>>>>> if the remotability isn't enabled transparently on a largely unchanged
>>>>>> OSGi application, why not just write a straight JAX-WS server-side
>>>>>> application from the get-go?
>>>>>>
>>>>>> Sorry if I'm slightly missing the point here. I just wanted to think
>>>>>> through the implications of using a databinding/frontend that's more
>>>>>> intrusive than Aegis/simple.
>>>>>>
>>>>>> Cheers,
>>>>>> Eoghan
>>>>>>
>>>>>> 2009/5/11 Josh Holtzman <
jholtzman@...>:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> I just read David Bosschaert's blog entry [1] addressing questions
>>>>>>> about
>>>>>>> his
>>>>>>> RFC 119 webinar. One of his answers sparked another question, and
>>>>>>> rather
>>>>>>> than contact him directly, I decided to give the wider CXF community a
>>>>>>> crack
>>>>>>> at it.
>>>>>>>
>>>>>>> I'd like to have the option to specify which databinding strategy to
>>>>>>> use
>>>>>>> with DOSGI. Currently, the Aegis databinding is "hard wired". I
>>>>>>> recognize
>>>>>>> that this makes sense for most use cases, since it relieves the
>>>>>>> developer
>>>>>>> from any wsdl or xsd responsibilities. But it doesn't make sense for
>>>>>>> cross-platform use cases (which, interestingly, David mentions right
>>>>>>> after
>>>>>>> the question "Why don't you use JaxWS?").
>>>>>>>
>>>>>>> The default wsdls produced by the Aegis databinding are not easily
>>>>>>> usable
>>>>>>> cross-platform. I wouldn't want to provide a developer with a wsdl
>>>>>>> that
>>>>>>> specifies arg0, arg1, and arg2 as argument names, for example.
>>>>>>>
>>>>>>> Is there interest in allowing the databinding strategy to be
>>>>>>> configurable
>>>>>>> in
>>>>>>> the DOSGI reference implementation? If so, I'd be happy to work on a
>>>>>>> patch.
>>>>>>>
>>>>>>> [1]
>>>>>>>
>>>>>>>
>>>>>>>
http://coderthoughts.blogspot.com/2009/05/questions-from-rfc-119-webinar.html>>>>>>>
>>>>>>> Thanks,
>>>>>>> Josh
>>>>>>>
>>>>>>> --
>>>>>>> Josh Holtzman
>>>>>>> Educational Technology Services, UC Berkeley
>>>>>>>
jholtzman@...
>>>>>>> 510.529.9225
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> --
>>>>> Josh Holtzman
>>>>> Educational Technology Services, UC Berkeley
>>>>>
jholtzman@...
>>>>> 510.529.9225
>>>>>
>>>>>
>>>>>
>>>>>
>> --
>> Josh Holtzman
>> Educational Technology Services, UC Berkeley
>>
jholtzman@...
>> 510.529.9225
>>
>>
>>