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.
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
