Add OSGi metadata

[GoogleCodeExporter]

What steps will reproduce the problem?
N/A

What is the expected output? What do you see instead?
META-INF/MANIFEST.MF should contain OSGi headers.

What version of the product are you using? On what operating system?
N/A

Please provide any additional information below.
To effectively deploy into an OSGi container no two jars/modules should export 
the same package - so this might require some refactoring.

Original issue reported on code.google.com by AaronJWh...@gmail.com on 26 Nov 2012 at 4:32

[GoogleCodeExporter]

protostuff-uberjar includes OSGI metadata (from Thomas Kock)

"To effectively deploy into an OSGi container no two jars/modules should export 
the same package - so this might require some refactoring."
OSGi is intrusive.  The package structure cannot be changed because the other 
modules relies on default access.

Original comment by david.yu...@gmail.com on 26 Nov 2012 at 5:06

[GoogleCodeExporter]

Thanks for the pointer towards the uberjar I didn't know that existed.

I've had some success getting Protostuff to work in OSGi, but I am now running 
into an issue where it seems RuntimeSchema (or some classes it uses) is caching 
Class instances passed in to it.

Such that the first time I call RuntimeSchema.getSchema( clazz ); things work 
wonderfully. however If the bundle containing the clazz I am getting a Schema 
for is changed and I call RuntimeSchema.getSchema (clazz ); again with a 
different instance of the same class (the same fully qualified class name, but 
from a different classloader, and usually containing different byte code) it 
seems that the Schema returned the second time around is still using a cached 
copy of the first class instance (of the same fully qualified name) passed to 
it.

This causes ClassCastException's because everything else is using the updated 
version of the class but Protostuff.

The only way I can currently work around this is to reload the 
protostuff-uberjar bundle, which wipes out all the static data.

I can see two possible solutions, maybe one is a short term fix and the other 
is a longer term solution.

1. Add a method to RuntimeSchema or some other class (don't really care where) 
which allows me to empty out all the static caches. Maybe this already exists 
for use in unit tests or such?

2. Rework the codebase to not store things in static caches, everything needed 
to serialize/de-serialize a class should be contained in the returned Schema 
object, and all via instance variables. So that when the Schema instance is 
eventually garbage collected. Nothing remains in any static variables anywhere.

Or I would be glad to hear about another possible solution.

Original comment by AaronJWh...@gmail.com on 25 Jan 2013 at 3:52

[GoogleCodeExporter]

Also I noticed some usages of TCCL to load classes, these should be replaced 
with getClass().getClassLoader() instead.

Original comment by AaronJWh...@gmail.com on 25 Jan 2013 at 4:13

[GoogleCodeExporter]

So after digging around in the code I found that if I pass in a new IdStrategy 
to RuntimeSchema.getSchema() the class instances are not cached between calls 
(unless I use the same IdStrategy instance)

As RuntimeSchema uses a default static IdStrategy kept in RuntimeEnv.

Original comment by AaronJWh...@gmail.com on 25 Jan 2013 at 7:02

[GoogleCodeExporter]

Yes.  You can even provide your own IdStrategy that can be updated at runtime, 
to accommodate your dynamic class changes.

Original comment by david.yu...@gmail.com on 25 Jan 2013 at 7:08