Configuring OSGi framework properties for the Framework launcher
by David Bosschaert
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
13 years, 11 months
Initial R5 Framework implementation
by Thomas Diesler
Folks,
I put together the first cut of an R5 Framework implementation.
All the existing R4.2 tests pass. There however a few R5 APIs that are
not yet implemented.
Guillaume, perhaps you could check jbosgi-framework-3.0.0.Alpha1 against
Karaf-3.3?
cheers
--thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
14 years
Karaf-2.2 on jbosgi
by Thomas Diesler
Folks,
I updated branch jbosgi603 to fix the shutdown issue.
David, perhaps you could take a look at MODULES-143 - AFAIK this would
be the last thing that prevents Karaf to run on jbosgi-framework.
cheers
--thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
14 years
[ARQ-1152] Add support for OSGi types as ArquillianResource
by Thomas Diesler
Hi Aslak,
could you pls review this patch
<https://github.com/tdiesler/arquillian-container-osgi/commit/e5dbe10fd37e...>
for the above functionality?
We have still have the BundleAssociation,BundleContextAssociation
ThreadLocal hacks in place. The resource providers (i.e.
BundleContextProvider, StartLevelProvider, PackageAdminProvider,
BundleProvider) all use these associations to get their respective
onject instances. I wonder if there is meanwhile a better way of doing this.
cheers
--thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
14 years
AS7-5639 Add OSGi Launcher to AS7
by Thomas Diesler
Hi David,
I'm wondering how the org.osgi.core class sharing is supposed to work
with this. If the AS7 internal framework is getting those types from the
org.osgi.core module and the launcher/client gets them from the syscp
they cannot be assigned - so the client could not consume/provide those
types through the framework API.
cheers
--thomas
> On 10/09/2012 09:57 AM, David Bosschaert wrote:
>>
>> This can only be done with value types from the syscp, right?
>>
>> Yes, correct.
>>
>> This code should not not be needed
>> if (ctrl.getMode() == Mode.ACTIVE)
>> return ctrl.getValue();
>> ctrl.setMode(Mode.ACTIVE);
>>
>> I don't follow what you mean here? Where are you seeing that code? Or
>> what is it a replacement for?
>>
>
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
14 years
DOSGi import issue
by David Bosschaert
Hi all,
I was looking again at getting CXF-DOSGi working on AS7.2 master and
came across the following issue.
There are a fairly large number of bundles.
One bundle (spring-context) has an optional import on another bundle
(optionally imports package org.springframework.aop.support). However in
this use-case the import isn't actually optional in that the total
system doesn't work without this optional import.
Now when it goes through resolution (in AS7/OSGi) of spring-context the
bundle exporting org.springframwork.aop.support is actually already
installed (and started). Still when debugging through the linking
process of spring-context, the optional import isn't provided (it's not
in the the list of dependencies provided to Module.link()).
So I'm wondering about this. On the one hand, since the import is
optional it seems like what it does is allowable. On the other hand
you'd expect that it attempts to at least import all optional imports
that are available at resolution time.
Any thoughts?
Cheers,
David
14 years
