OSGi support?

[ieugen]

Hello,

Are you interested in accepting a contribution that provides OSGi support for the client?

Thanks,

[flyaruu]

Hi, I've tried to use the OSGi bundle, but I run into trouble as it imports the 'com.google.gson.internal.bind.util' package from GSON. GSON does not export this package, so I don't see how I can ever resolve this bundle.

So possible solutions I see:

• Convince GSON that this package should be exported
• Copy the package to someplace inside this project, so this import is no longer needed. The package has only one class: ISO8601Utils.java and AFAIK does not reference any other classes in the project.
• Create a separate bundle that exposes just this package

[ieugen]

@flyaruu : thank you for the info. I did not get to the poin of using the bundle - I just made basic first steps. What framework are you using to deploy the bundles?

Until a fix is found in this bundle or GSON you could wrap the bundle and rewrite the manifests.
ServiceMix project does that to a lot of third party libraries [1]

It's quite easy to do and they might have it allready [3] . They have version 2.1 of gson.

[1] https://github.com/apache/servicemix-bundles/
[2] https://bnd.bndtools.org/chapters/390-wrapping.html
[3]http://search.maven.org/#search%7Cga%7C1%7Cservicemix%20gson
[4] http://search.maven.org/#artifactdetails%7Corg.apache.servicemix.bundles%7Corg.apache.servicemix.bundles.gson%7C2.1_1%7Cbundle

[flyaruu]

Good to know, I could not figure out how it could have worked: Sanity restored.
I'm running the bundle in a vanilla Felix 5.6.10 container.

I'm aware of the wrapped ServiceMix bundles, I need quite a few of those to get this running, but GSON is already an OSGi bundle, so the servicemix bundling is not needed (and I guess that is why there is no more servicemix version after 2.1). The thing is that it does not export the com.google.gson.internal.bind.util, I suspect intentionally, as there is 'internal' in the name.

I've copied the 'ISO8601Utils.java' class from GSON to Kube client, that did the trick, I'm don't know if that is acceptable.

Finally I ran into a classloader issue, that was fixed by registering a type adapter:

registerTypeAdapter(Quantity.class,quantityTypeAdapter)

After that, it works from OSGi.

I can put them in a pull request if you want.

[ieugen]

Hi,

Thanks for the feedback. A PR would be nice. I'm not with kubernetes-client project but if the changes are simple I think it will be accepted.

What are you trying to buid with OSGi in Kubernetes?

I've copied the 'ISO8601Utils.java' class from GSON to Kube client, that did the trick, I'm don't know if that is acceptable.

Sometimes this is agood approach. If the library is not suitable to turn into a osgi bundle then a good approach is to embed the class(es) of the jar and bundle them into your project.

With Kubernetes client I believe we might be able to cleanup the code a bit since depending on internal API is troublesome on the long term - upstream can break that any time without notice.

Can we use something else than ISO8601Utils ?

[ieugen]

@flyaruu : I've checked the code and ISO8601Utils is sued to parse sql dates from string and render to string. I believe that Java 8 has built-in support for doing that and we might remove that class and cleanupt the code that way.

I've opened #304 to track progress on this.