D-Bus

[Guido Spadotto]

Hi all,
 I've searched for this a bit but found nothing useful, so I'm here to
ask you:
"Do you know if there's any bundle-ized version of the Java D-Bus
implementation available somewhere?"

Thanks,
 Guido

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[cmoulliard]

I don't think so but you can try to transform it into an OSGI bundle
using pax url wrap command :

http://wiki.ops4j.org/display/paxurl/Wrap+Protocol

Question : What do you plan to do with Java D bus ?

Regards,

Charles Moulliard
Senior Enterprise Architect
Apache Camel Committer

*****************************
blog : http://cmoulliard.blogspot.com
twitter : http://twitter.com/cmoulliard



On Wed, Oct 28, 2009 at 12:31 PM, Guido Spadotto <gspadotto@...> wrote:

> Hi all,
> I've searched for this a bit but found nothing useful, so I'm here to ask
> you:
> "Do you know if there's any bundle-ized version of the Java D-Bus
> implementation available somewhere?"
>
> Thanks,
> Guido
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Guido Spadotto]

Charles Moulliard wrote:
> I don't think so but you can try to transform it into an OSGI bundle
> using pax url wrap command :
>
> http://wiki.ops4j.org/display/paxurl/Wrap+Protocol
>
> Question : What do you plan to do with Java D bus ?
It's not me directly that needs D-Bus, but a partner in the EU project
I'm currently in.
He needs to do some sort of Inter Process Communication for services
running outside of
the OSGi container.

The problem is that it seems that there is some native JNI stuff in
between, which worries me.

Thanks for the info.

Guido

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[cmoulliard]

Why don't you use ActiveMq queuing engine as integration platform
between OSGI containers or Apache CXF - Distributed OSGI :
http://cxf.apache.org/distributed-osgi-reference.html ?

Regards,

Charles Moulliard
Senior Enterprise Architect
Apache Camel Committer

*****************************
blog : http://cmoulliard.blogspot.com
twitter : http://twitter.com/cmoulliard



On Wed, Oct 28, 2009 at 3:45 PM, Guido Spadotto <gspadotto@...> wrote:

> Charles Moulliard wrote:
>>
>> I don't think so but you can try to transform it into an OSGI bundle
>> using pax url wrap command :
>>
>> http://wiki.ops4j.org/display/paxurl/Wrap+Protocol
>>
>> Question : What do you plan to do with Java D bus ?
>
> It's not me directly that needs D-Bus, but a partner in the EU project I'm
> currently in.
> He needs to do some sort of Inter Process Communication for services running
> outside of
> the OSGi container.
>
> The problem is that it seems that there is some native JNI stuff in between,
> which worries me.
>
> Thanks for the info.
>
> Guido
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Guido Spadotto]

Charles Moulliard wrote:
> Why don't you use ActiveMq queuing engine as integration platform
> between OSGI containers or Apache CXF - Distributed OSGI :
> http://cxf.apache.org/distributed-osgi-reference.html ?
>  
My friend has to integrate with some Linux apps for a throw-away demo,
so he's been looking
for the quickest way of doing this.

I'll keep in mind Dist. OSGi for future architectural choices.

Thanks once again.

Guido

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[cmoulliard]

It is very easy to use Apache Camel top of Apache Felix or better
Apache Felix Karaf :

http://camel.apache.org/tutorial-osgi-camel-part2.html

You create two different bundles.

1) Bundle A

This bundle contains a spring DSL xml file with routes defined like this :

from().
.to()
.to()
.to(ActiveMq:queueShared)

deployed in your server OSGI (1)

2) Bundle B

from(ActiveMq:queueShared).
.to()
.to()

deployed in your server OSGI (2)

Remark : ActiveMQ propose different transport connector like
TCP/SSL/HTTP(s) protocol :

Regards,

Charles Moulliard
Senior Enterprise Architect
Apache Camel Committer

*****************************
blog : http://cmoulliard.blogspot.com
twitter : http://twitter.com/cmoulliard



On Wed, Oct 28, 2009 at 4:05 PM, Guido Spadotto <gspadotto@...> wrote:

>
> Charles Moulliard wrote:
>>
>> Why don't you use ActiveMq queuing engine as integration platform
>> between OSGI containers or Apache CXF - Distributed OSGI :
>> http://cxf.apache.org/distributed-osgi-reference.html ?
>>
>
> My friend has to integrate with some Linux apps for a throw-away demo, so
> he's been looking

> for the quickest way of doing this.
>
> I'll keep in mind Dist. OSGi for future architectural choices.
>
> Thanks once again.
>
> Guido
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Christopher Armstrong-5]

Hi

I have done this before.

I used Java-DBus in a thesis project, and modified it to work on OSGi.  
There are multiple issues to sort through, and it really needs a re-
design or compatibility layer to get it to work properly with OSGi.

Some of the things you will need to do:
1) Compiling the relevant parts of libmatthew. This can be done by  
modifying the Makefiles. Note that you need relevant headers for the  
native code component of libmatthew unix library (the JNI stuff is a  
bit of a pain).
2) Compiling DBus-Java for OSGi. Again, it should be reasonably simple  
to generate a Makefile
3) You need code that establishes a DBusConnection and can extract  
objects. This is fairly straightforward. The main issue will be if you  
have multiple bundles that need the connection, in which case you will  
have to write some code to publish it into the OSGi service registry  
(its a singleton and behaves as such). You will also need code to  
manage the connection object so that you can withdraw it when the  
connection is dropped).
4) DBus-Java Signal handling. Unfortunately, this suffers the same  
problem as a lot of normal Java code, in that it uses reflection to  
determine the signal handling class when it comes time to deliver a  
DBus "signal". The best solution would be to translate the signal  
handlers, within the DBus-Java bundle you create, and then re-publish  
them with an OSGi event handling mechanism such as EventAdmin.
5) The component that needs to be communicated with will need Java  
classes generated for its interfaces. There is a tool in DBus-Java to  
do this, and the generated source code files can be easily put into a  
bundle.

Given the amount of work, its not really worth it unless you need to  
communicate with an existing component that uses the DBus. For new  
code, use something suggested by one of the other authors, especially  
if this is for a throw-away demo.

Cheers
Chris

On 28/10/2009, at 12:31 PM, Guido Spadotto wrote:

> Hi all,
> I've searched for this a bit but found nothing useful, so I'm here  
> to ask you:
> "Do you know if there's any bundle-ized version of the Java D-Bus  
> implementation available somewhere?"
>
> Thanks,
> Guido
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

--------
Christopher Armstrong
carmstrong@...






---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Guido Spadotto]

Christopher Armstrong wrote:

> Hi
> [...]
> 1) Compiling the relevant parts of libmatthew. This can be done by
> modifying the Makefiles. Note that you need relevant headers for the
> native code component of libmatthew unix library (the JNI stuff is a
> bit of a pain).
> 2) Compiling DBus-Java for OSGi. Again, it should be reasonably simple
> to generate a Makefile
> 3) You need code that establishes a DBusConnection and can extract
> objects. This is fairly straightforward. The main issue will be if you
> have multiple bundles that need the connection, in which case you will
> have to write some code to publish it into the OSGi service registry
> (its a singleton and behaves as such). You will also need code to
> manage the connection object so that you can withdraw it when the
> connection is dropped).
> 4) DBus-Java Signal handling. Unfortunately, this suffers the same
> problem as a lot of normal Java code, in that it uses reflection to
> determine the signal handling class when it comes time to deliver a
> DBus "signal". The best solution would be to translate the signal
> handlers, within the DBus-Java bundle you create, and then re-publish
> them with an OSGi event handling mechanism such as EventAdmin.
> 5) The component that needs to be communicated with will need Java
> classes generated for its interfaces. There is a tool in DBus-Java to
> do this, and the generated source code files can be easily put into a
> bundle.

Thanks Chris, much appreciated.

I don't think my demo justifies this amount of work,
nevertheless your suggestions will become precious
whenever I'll *have to* integrate OSGi and D-Bus.

Best,
 Guido

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...