Hey Guys, Sorry if this is the wrong place to post this, but it looks like a good place to share my Avro/OSGi experiences. First, I'm not using Avro in a conventional fashion. I'm only using Avro for serialization through the Datum Readers and Writers directly.
I wrapped up Avro, Avro IPC, and the dependencies into a single bundle. Here is the pom: http://subversion.assembla.com/svn/appdapter/trunk/maven/ext.bundle.apache_avro/pom.xml When I first started using Avro in OSGi, I ran into casting exceptions when I had my Avro generated classes in a separate bundle from the loader. My generated classes weren't available to a generic method which was trying to load and cast record using a SpecificDatumReader. My solution was to put my generated classes into a FragmentBundle which attaches itself to the Avro bundle. I wrote more about it here: http://www.robokind.org/posts/avro_osgi/avro_osgi.html 2012/1/5 Holger Hoffstätte (Commented) (JIRA) <[email protected]> > > [ > https://issues.apache.org/jira/browse/AVRO-987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13180838#comment-13180838] > > Holger Hoffstätte commented on AVRO-987: > ---------------------------------------- > > Some comments for Scott: > > * repeating the package dependencies so that they are correct is somewhat > unavoidable with plain Java projects ( regardless of build system) since > many libraries simply dump they crap all over the package space. However, > the correct imports & exports can often be calculated automatically by the > plugin's heuristics, so later on it is likely possible to trim the list of > explicit imports/export statements to the bare minimum where necessary. > Overly explicit fencing at the beginning is a good idea. Note that this > gets easier the more of your dependencies are already bundles; if you only > depend on bundles you often have to do *nothing* at all. Most of > commons/netty/jackson will automagically work correctly. > > * adding the necessary plugin configuration bits as properties in each > subproject is already as minimal for the pom as it can possibly get; this > is actually a pretty good approach. Normally the whole <plugin> section is > duplicated. > > * +1 for breaking the build if forName is used; it shouldn't be used > anywhere anyway. > > > > Make Avro OSGi ready > > -------------------- > > > > Key: AVRO-987 > > URL: https://issues.apache.org/jira/browse/AVRO-987 > > Project: Avro > > Issue Type: New Feature > > Components: java > > Reporter: Ioannis Canellos > > Attachments: AVRO-987-patch.txt > > > > > > It would be really nice to be able to use Avro inside OSGi. To achieve > this two things are required: > > i) Provide proper MANIFEST.MF. > > ii) Deal with potential class loading issues. Avro uses Class.forName a > lot and that is not very OSGi friendly. > > -- > This message is automatically generated by JIRA. > If you think it was sent incorrectly, please contact your JIRA > administrators: > https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa > For more information on JIRA, see: http://www.atlassian.com/software/jira > > > -- Matt Stevenson.
