Hi David,
I lost track a little of how you do this - so lets re-iterate your
approach to make sure I understand this properly ...
* The Framework launch API takes a number of string properties
* You use the embedded server to launch AS7 in the same VM
* Some artefacts are on the (flat) classpath of the framework launcher
* You instruct modules through sysprops to load some packages from the
flat launcher classpath
The problem is how you feed the framework launch props to the osgi
subsystem, right?
My suggestion was that you modify the osgi subsystem configuration
before you start the subsystem.
This does not work because the configuration is read only once at server
startup, right?
This should still work (
https://issues.jboss.org/browse/AS7-5882),
however it should not be a blocker for
your TCK setup task. So I guess it is ok for the thing that starts the
embedded server to set a few system properties.
That should work unless the TCK explicitly tests that the props on the
framework launcher API are not visible through sysprops.
cheers
--thomas
On 10/31/2012 12:49 PM, David Bosschaert wrote:
Hi Thomas,
For the framework launcher I need to be able to pass additional
framework properties to the subsystem. These properties are used by the
TCK but could be used by anyone who uses the Framework Launching API.
There is an issue with your suggestion of using the DMR management API
for setting these properties.
The properties are static, so changes in them always requires a
framework restart.
They are currently read during the parsing of the model and not re-read
after that. So they are read before the OSGi Framework is activated and
passed to the FrameworkBuilderFactory right when the server is booted.
In order to set these properties through the DMR I need to activate the
server, otherwise there is no DMR access.
I can set the properties before activating the OSGi Subsystem through
the DMR, but for them to be picked up the OSGi subsystem needs to delay
reading them until the subsystem is actually activated.
Any thoughts how this is best achieved?
David
_______________________________________________
jboss-osgi-dev mailing list
jboss-osgi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-osgi-dev
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx