You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Bernd Wiswedel-2 <Be...@gmail.com> on 2009/12/01 09:58:04 UTC

Re: DOSGi - Dynamic Web Services (no service interface at compile time)

Hi David,

Option (1) sounds good to me. Two follow-up questions so far:
(a) I need to create the services at runtime (it's not just that I'm missing
the dependency on the bundle that defines the interface -- it's really
created at runtime depending on some protocol that the user defines in the
GUI of my RCP, which he eventually exposes via a "Publish" button). Do you
have any tips on how to generate the class file that defines the service? As
far as I understand I will need to create a temporary java file and
programmatically write java code and then compile it in the background in
order to pass the class to the service registry. I'm thinking of a
counterpart to the DynamicClientFactory which handles all the technical
parts. Ideally I would have some control on the wsdl generation to make sure
that the wsdl looks the same for the same protocol, independent of the cxf
version.
(b) Does the "service.exported.interfaces=" support wildcards like, e.g. 
"org.foo.MyService*", or is '*' a very special value?

Thanks!
 Bernd
-- 
View this message in context: http://old.nabble.com/DOSGi---Dynamic-Web-Services-%28no-service-interface-at-compile-time%29-tp26545343p26588092.html
Sent from the cxf-user mailing list archive at Nabble.com.


Re: DOSGi - Dynamic Web Services (no service interface at compile time)

Posted by David Bosschaert <da...@gmail.com>.
Hi Bernd,

On your questions:

(a) instead of going the route of generating the java source code and
compiling that (which should work) you could take a look at libraries
like CGLib (http://cglib.sourceforge.net) or ASM
(http://forge.ow2.org/projects/asm) they should allow you to do this
without having to involve javac. Because of licensing issues depending
on javac can be difficult if you need to redistribute your product. I
think using them should work, but I never tried them with CXF-DOSGi.
(b) the asterisk '*' is a special value. It means "all
interfaces/classes passed as the first argument to the
BundleContext.registerService() call". No other wildcards are
currently supported. However you can easily implement your own
wildcard logic and put a collection or array of interface/class names
on the service.exported.interfaces property. (This property is of type
'String+' which is used in OSGi specs to say that the property value
can be of type: String, Collection<String> or String[])

On the question of having influence on the generated WSDL, I'm not too
sure about how to do that from CXF-DOSGi yet, I know that in the Aegis
databinding you can control this somewhat. Maybe Eoghan, Sergey or
Benson know more about how to do that from DOSGi?

Best regards,

David

2009/12/1 Bernd Wiswedel-2 <Be...@gmail.com>:
>
> Hi David,
>
> Option (1) sounds good to me. Two follow-up questions so far:
> (a) I need to create the services at runtime (it's not just that I'm missing
> the dependency on the bundle that defines the interface -- it's really
> created at runtime depending on some protocol that the user defines in the
> GUI of my RCP, which he eventually exposes via a "Publish" button). Do you
> have any tips on how to generate the class file that defines the service? As
> far as I understand I will need to create a temporary java file and
> programmatically write java code and then compile it in the background in
> order to pass the class to the service registry. I'm thinking of a
> counterpart to the DynamicClientFactory which handles all the technical
> parts. Ideally I would have some control on the wsdl generation to make sure
> that the wsdl looks the same for the same protocol, independent of the cxf
> version.
> (b) Does the "service.exported.interfaces=" support wildcards like, e.g.
> "org.foo.MyService*", or is '*' a very special value?
>
> Thanks!
>  Bernd
> --
> View this message in context: http://old.nabble.com/DOSGi---Dynamic-Web-Services-%28no-service-interface-at-compile-time%29-tp26545343p26588092.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
>