Glad I could help; I was just restating what others had suggested ;-) Yes, fragments can be a bit tricky. Depending on their imports and exports, and the attachment policy of the host, it might be necessary to re-resolve the host in order to attach it.
Also, if deserialization is required at the other end, that sounds like another service or API that the provider bundle could supply, but you'd also want the materialized classes to be a part of the public API. /djk On Mar 20, 2012, at 4:59 AM, <[email protected]> wrote: > 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 _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
