Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: pass (nike.apache.org: domain of heavy@ungoverned.org designates
 67.222.39.60 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=ungoverned.org;
	h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User;
	b=5uo0BNe+iRRWMD+aGUDU52QJ8ScbnjL9RMeSYleq58peAZo6cxhvkNYjOWfFiypGaY64IBm22LnwY3wbI6EiEQlUf+WEEgeW6Ytoe7w6c7RxRFMLYEjLubQdYyvoJBp+;
Message-ID: <4D66AA3B.6070302@ungoverned.org>
Date: Thu, 24 Feb 2011 13:58:03 -0500
From: "Richard S. Hall" <heavy@ungoverned.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: dev@felix.apache.org
Subject: Re: Setting system properties for
 FelixConstants.FRAMEWORK_SYSTEMPACKAGES_EXTRA
References: <AANLkTi=jDhpmrWB8U=eC0e+1Z6VKW=-9ta+rY7=_cTYw@mail.gmail.com>
	<4D666B6B.8090308@ungoverned.org>
	<AANLkTi=P24Y0PVxog7J12=Rj88Tb+Rg1dtS+o94+qGJc@mail.gmail.com>
	<4D6694B8.9010700@ungoverned.org>
	<AANLkTinGr--ncyV3fGZ8GHT+QWhRYmFmHHTb5EtSgNTm@mail.gmail.com>
 <AANLkTikrKky_T=8WTuakRTHK6s2YUqdk+Ckj09nBvzbA@mail.gmail.com>
In-Reply-To: <AANLkTikrKky_T=8WTuakRTHK6s2YUqdk+Ckj09nBvzbA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 2/24/11 13:35, Alex Karasulu wrote:
> On Thu, Feb 24, 2011 at 8:31 PM, Alex Karasulu<akarasulu@apache.org>  wrote:
>> On Thu, Feb 24, 2011 at 7:26 PM, Richard S. Hall<heavy@ungoverned.org>  wrote:
>>>
>>> On 2/24/11 10:28, Alex Karasulu wrote:
>>>> Hi Richard,
>>>>
>>>> On Thu, Feb 24, 2011 at 4:30 PM, Richard S. Hall<heavy@ungoverned.org>
>>>>   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.

It sounds like you are expecting your host application to be able to 
load internal bundle classes using its own class loader and this cannot 
work.

-> richard

>> Does that make sense?
>>
>> Thanks,
>> Alex
>>
>>> Sorry.
>>>
>>> ->  richard
>>>
>>>> Best,
>>>> Alex
>>>>
>>>>> On 02/24/2011 01:14 AM, Alex Karasulu wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> I have a situation where I would like to set the
>>>>>> FelixConstants.FRAMEWORK_SYSTEMPACKAGES_EXTRA property in my pom for
>>>>>> use with surefire. I would like to supply all the packages that would
>>>>>> be on the Import-Packages attribute if the manifest is generated for
>>>>>> everything on the "test" classpath.
>>>>>>
>>>>>> I have a class that embeds Felix for plugins in one module. Then
>>>>>> another integration test module tests that Felix embedding class. The
>>>>>> problem is I get CCE exceptions if I access plugin interfaces to test
>>>>>> the plugin so I would like to have the build construct the list of
>>>>>> extra system packages so I don't have to manually update these values
>>>>>> in the code.
>>>>>>
>>>>>> Is there a hack anyone uses for this?
>>>>>>
>>>>>> Thanks in advance,
>>>>>> Alex