On Thu, Feb 24, 2011 at 8:58 PM, Richard S. Hall <[email protected]> wrote: > On 2/24/11 13:35, Alex Karasulu wrote: >> >> On Thu, Feb 24, 2011 at 8:31 PM, Alex Karasulu<[email protected]> >> wrote: >>> >>> On Thu, Feb 24, 2011 at 7:26 PM, Richard S. Hall<[email protected]> >>> wrote: >>>> >>>> On 2/24/11 10:28, Alex Karasulu wrote: >>>>> >>>>> Hi Richard, >>>>> >>>>> On Thu, Feb 24, 2011 at 4:30 PM, Richard S. Hall<[email protected]> >>>>> wrote: >>>>>> >>>>>> I am not sure how the instance of the framework is being created, but >>>>>> if >>>>>> you >>>>>> are creating it directly then it won't see configuration properties >>>>>> that >>>>>> are >>>>>> set as system properties. However, if the launcher is used to start >>>>>> the >>>>>> framework, then the launcher automatically copies any configuration >>>>>> properties from the system properties. >>>>> >>>>> I am manually passing in the configuration property for the extra >>>>> system packages before initializing Felix. Right now I just statically >>>>> pass in the comma delimited set of fixed packages and it works like a >>>>> champ. >>>>> >>>>> The problem is when the host application uses exported interfaces in >>>>> the plugin bundles. In dynamic environments where users drop in plugin >>>>> bundles that I do not know of in advance I have to dynamically build >>>>> the set of system packages. >>>>> >>>>> I was thinking of this possible solution: >>>>> >>>>> (1) scan manifests of jars on the classpath >>>>> (2) if the jar is a bundle, add that bundle's Import-Package elements >>>>> to the system package extras configuration setting value >>> >>> Yup sorry meant the exported packages here. You understood that below. >>> >>>>> This works for at initialization time which is sufficient for my >>>>> needs. Wondering if there's an easier way to do this without writing >>>>> rot code like this. >>>> >>>> I guess I don't totally understand. For starters, I don't understand how >>>> the >>>> host application can use exported packages from the plugins, since this >>>> isn't something so easy to accomplish. Then I don't really understand >>>> how >>>> you cannot know which plugins are involved, since this is a testing >>>> scenario >>>> it sounds. >>> >>> In the testing scenario we know the plugins used to test. However it >>> occurred to me that we might want this in production. >>> >>>> Perhaps we are using different terminology or I am just not >>>> seeing the overall architecture of the situation. >>> >>> No worries I probably did a terrible job explaining it. OK let me >>> quickly explain at a high level. >>> >>> We're writing an LDAP API over at directory. The LDAP protocol has >>> some natural points of extension: Controls and Extended operations. We >>> wanted to make these Controls and Extended ops pluggable so Felix came >>> to mind. >>> >>> We embed a Felix instance into (for all practical purposes lets say) >>> the API jar to load plugins so the API can handle new Controls and new >>> Extended operations. There are two parts to a plugin: >>> >>> (1) Exported interfaces and simple POJOs for new Control and >>> ExtendedRequest and ExtendedResponses >>> (2) Hidden bundle private codec classes that handle protocol >>> encoding and decoding for these types. And these elements snap into >>> the CODEC machinery. The bundle activator of the plugin does this. >>> >>> It is foreseeable that users will drop a new Control extension bundle >>> into our plugin directory. Say this new Control is called FooControl. >>> The user might want to create a new FooControl object instance with >>> the API. The problem is this is causing a CCE because the host loaded >>> FooControl class is not the same as the bundle's FooControl. This is >>> why I want FooControl's path on the host's system extras packages >>> given to Felix. >> >> Doh, sorry FooControl bundle's exported packages on the host's system >> extras packages. > > Again, I may not totally understand, but... > > Typically, the way something like this works is the host application puts > some shared API on the class path and shares it from the system bundle, > which in your case sounds like it would be the Controls and Extended > interfaces. Then bundles come along and import these packages and provide > implementations that the host can use. Here you can follow a service-based > approach or an extender-based approach. > > For the service-based approach, there is no need for the host to directly > instantiate internal bundle classes because it gets the actual service > object from the service registry. For the extender-based approach, the host > will often need to create an instance of some internal bundle class and it > uses Bundle.loadClass() to load it and reflection to instantiate it.
OK that sheds some light. Thanks for your advice. Best, Alex
