Hi Davd, > The bundle that registers the service could create this custom class loader with its bundle class loader as its parent, and with appropriate imports for that bundle the custom class loader would be able to resolve external references in your bag of class bytes. This would include the import of the package that holds your service interface. The life cycle of > the class loader and the service registration would be tied to the life cycle of this implementation bundle.
This looks like being the winning answer. My proposed hack with installing a fragment bundle has the undesired side-effect of triggering a refresh of the parent bundle (which is especially good fun if the parent is the one doing the install). As you point out the parent class loader does need to be able to resolve the service interface(s); maybe we can restrict these interfaces to some closed list of packages, otherwise this may be a legitimate usage of "DynamicImport-Package: com.acme.*". > In this way your creation of a custom class loader is "simply" an implementation detail of your bundle. If you're going to be materializing > a bag of bytes into a class, you're going to need a class loader *somewhere*, so you're not *adding* any additional smell. ;-) Yes, I'm now convinced of that. Users of the proxy object should not need to access the object's implementation class, so it shouldn't be a problem that it wasn't loaded by any bundle class loader. If anyone claims that they need such access (e.g. to re-instantiate a previously serialized object), we take them outside and shoot them. ;-) Thanks, Chris _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
