I think this can all be handled with just two properties:

org.apache.cxf.dosgi.databinding=[ jaxb | xmlbeans | aegis (default) ]
org.apache.cxf.dosgi.frontend=[ jaxws | jaxrs | simple (default) ]

This way, you can just mix and match.  Does that meet your needs?

I haven't seen a ClientProxyFactoryBean equivalent that uses JAX-RS in the way that JaxWsProxyFactoryBean creates client proxies for JAX-WS. Is that what you're working on?

Josh

Sergey Beryozkin wrote:
Hi,

I'm planning to integrate JAX-RS runtime into a DOSGi as well.

One can consider that
org.apache.cxf.dosgi.frontend.simple

is a default property.

org.apache.cxf.dosgi.frontend.jaxws

would cause a jaxws frontend be used.

Perhaps

org.apache.cxf.dosgi.frontend.jaxrs

can indicate that JAX-RS should be used.

Now both jaxws and jaxrs can use JAXB, and as Dan said even simple
frontend can use JAXB. And all of them can use Aegis

So as far as databinding is concerned, should it be rather org.apache.cxf.dosgi.frontend.jaxws.databinding.jaxb org.apache.cxf.dosgi.frontend.jaxws.databinding.xmlbeans

org.apache.cxf.dosgi.frontend.simple.databinding.jaxb
org.apache.cxf.dosgi.frontend.simple.databinding.aegis (default)

org.apache.cxf.dosgi.frontend.jaxrs.databinding.jaxb
org.apache.cxf.dosgi.frontend.jaxrs.databinding.aegis

etc

so that a databinding can be applied selectively, on a per-frontend
basis ?

May be properties like org.apache.cxf.dosgi.databinding.jaxb can serve
as a global property which has to apply to all frontends, that is if is
is set then even a simple frontend should use JAXB, but a property like

org.apache.cxf.dosgi.frontend.simple.databinding.aegis

can be used to override it

cheers, Sergey


-----Original Message-----
From: Josh Holtzman [mailto:[email protected]] Sent: 05 June 2009 21:30
To: [email protected]
Subject: Re: Configuring DOSGI to use JAX-WS

I'm the confused one :) I was conflating the two. Daniel Kulp pointed this out in the Jira ticket, and I've changed the patch so it now watches for two properties: org.apache.cxf.dosgi.databinding.jaxb and 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, the jaxws frontend is used rather than the simple frontend.

Josh

Benson Margulies wrote:
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 <[email protected]>
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 <[email protected]>:

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 <[email protected]>:


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
[email protected]
510.529.9225




--
Josh Holtzman
Educational Technology Services, UC Berkeley
[email protected]
510.529.9225



--
Josh Holtzman
Educational Technology Services, UC Berkeley
[email protected]
510.529.9225




--
Josh Holtzman
Educational Technology Services, UC Berkeley
[email protected]
510.529.9225

Reply via email to