You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avro.apache.org by Szabó András <ba...@gmail.com> on 2011/11/04 03:21:35 UTC

avro + osgi problem

Hi,

I just started to develop osgi bundles, and I wrote a small server/client
bundle just for testing avro.

The protocol is simple:
protocol Heartbeat {
int ping(string id);
}

When i am using the same test code in a simple java application, everything
works fine.

If I am running the bundles with the osgi framework (equinox), I always get
-1 as response from ping call. There was no exception thrown.

I use avro 1.5.4, every dependency is a separate bundle.

I hope there will be someone who can help me.

Thanks,
  Bandesz

Re: avro + osgi problem

Posted by Holger Hoffstätte <ho...@googlemail.com>.
On 04.11.2011 03:21, Szabó András wrote:
> If I am running the bundles with the osgi framework (equinox), I always get
> -1 as response from ping call. There was no exception thrown.

Avro as standalone bundle(s) doesn't really work in OSGi at all
(especially not the ipc and compiler parts) since it assumes a flat class
path, has various static caches and uses Class.forName() to map schemas to
non-Avro classes. Most of these problems are relatively easy to fix, but
require some API changes; they are simply the consequences of bad, but
common Java practices.

As temporary "workaround" all your bundles will need to embed all required
avro bundles, not unlike your typical bloated web app: at least core, ipc,
paranamer. jackson & optionally netty (for the new transport) are bundles
and might work as they are, but to be on the safe side you could embed
them too. This will obviously create quite a bit of bloat, but at least it
will "work".

I have had an Avro-based transparent OSGi RPC transport working for
several months now as part of a full RemoteServiceAdmin stack, but had to
stop working on it due to changing priorities, which is why I haven't
pursued this further as upstream initiative. If someone wants to file a
long-term "OSGi compliance" bug (maybe for 2.0) I would be quite happy to
help.

-h