-
-
Notifications
You must be signed in to change notification settings - Fork 872
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added OSGi dynamic import #377
Conversation
…er bundles (usually bundle that contains the beans serialized by MapDB)
This is a really poor way to support OSGi. The proper one is a better Serialization strategy in general, one that isn't as 'entrenched' in the MapDB's internals as the current one. I will actually vote against this change, if there is such a possibility... Sorry. |
@niclash in general I could agree, but I don't understand a thing, how MapDB could introspect the client POJOs to serialize/desrialize them without loading the class definition? Perhaps a possible solution could be to use an external serializer and store data rough into the index, for example using ProtoBuf and pass the serialized form to MapDB, moving the resposability of serialize/deserialize into the client app? |
I know how OSGII support works in TopLink, it is complex to do it correctly. In mapdb jar I want option to have custom class loaders. And JAR should be correctly annotated. Rest should be in separate jar. I will look at this in a few days before 1.1 is released |
We are also using MapDb in an OSGi project, and what we have done is roughly; public interface StorageService { public interface StorageTransaction { So, we end up having client code do something like; storage.transact( context, "secret", tx -> { And in that transact() call we not only manages a MapDb transaction, but also establishes the Thread Context Classloader, which MapDb uses. And we do JacksonSerialization, but I think this approach would also work with the built-in Pojo serialization. AND, we disallow cross-bundle access to databases, so each bundle has its own MapDB FileDB, which is encrypted. This also enforces good design. |
How about just providing your own class loader? Something like:
|
That is good for the default serializer case, yes. |
Hi Jan, |
Andrea, <quote> I would add; By not using Dynamic-Import, the bundles won't be started if packages are missing, but with Dynamic-Import, this guarantee doesn't exist. Also, framework end up struggling to do dynamic update/refresh when Dynamic-Import is involved, perhaps not a super-important feature in production, but very helpful during development. If one is designing to be OSGi-friendly (honors to Jan for trying), the proper solution is for the client to either provide the classloader or provide a type which uses a classloader that can be used. If neither of those can be managed, for instance API compatibility must be maintained, then the TCCL is the option before Dynamic-Import. |
Hi Niclas,
|
Hi Niclas and Jan, |
Agree the proper way of fixing this is adding support to specify a classloader. However TCCL is not a workaround in many cases. @njbartlett wrote this up here: http://njbartlett.name/2010/08/30/osgi-readiness-loading-classes.html Therefore I think in many cases we can only do a In cases where you have control of the TCCL you can set it yourself before your call to MapDB. I'd like to echo the props to @jankotek for adding support for OSGi thus far. |
@gravelld I can not reopen this issue. Could you please create a new bug for MapDB, with a few points what should be tested in 2.0? |
Added definition to OSGi descriptor to let the MapDB bundle load the classes from other bundles. This is necessary when a bundle uses loadClass and want to laod class definition exposed by other bundle, not included at compile time.