| DynamicImport-Package question while patching DataNucleus for OSGi [message #730566] |
Wed, 28 September 2011 16:04  |
|
I'm in the process of patching DataNucleus to build better OSGi jars. As such, I've got its POMs configured to use maven-bundle-plugin and I have one question, which is one of practicality versus correctness:
What are the ramifications if I add "DynamicImport-Package: *" just in case there are package dependencies that aren't caught by maven-bundle-plugin?
As I understand it, OSGi class loader(s) will search packages statically declared in Import-Package, and only if not found, will begin searching in packages according to DynamicImport-Package. This seems reasonable given that transparent persistence (ORM) products might need to instantiate not only persistable user classes, but also compile- or run-time generated query classes (like criteria/query classes), as well as product-specific plugins that the product might go looking for.
Any practical advice is appreciated. Unless I hear otherwise, I'm going to add it, if only to make the experience better for the end user.
Thanks,
Matthew
|
|
|
|
|
|
| Re: DynamicImport-Package question while patching DataNucleus for OSGi [message #730581 is a reply to message #730572] |
Wed, 28 September 2011 16:22  |
|
Yes, I agree about correct manifests, but it is impossible for an ORM to know about a user's classes at the time the ORM's bundle manifests are created. The ORM is more of a framework, not a user bundle.
If I don't include a "DynamicImport-Package: *", then will the user be able to control things enough without having to wrap the ORM bundles with bnd or something to allow the ORM to instantiate user classes via reflection?
Should the ORM use OSGi-specific means to instantiate user classes via reflection that would allow an ORM manifest to be free from "DynamicImport-Package: *" and would still make it easy for the ORM to just work in OSGi?
|
|
|
|
Powered by
FUDForum. Page generated in 0.03562 seconds
] 
Search
Help
Register
Login
Home
