[
https://issues.apache.org/jira/browse/FELIX-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549435
]
Richard S. Hall commented on FELIX-393:
---------------------------------------
I have created a patch for this issue, which I will attach. I wanted to give a
chance for additional feedback since this will impact anyone who is embedding
Felix and relies on auto-property processing. This is what I did:
1. Re-ordered the steps so that cached bundles are reloaded before activating
system bundle (this was necessary to ensure that cached bundles were reloaded
before processing custom framework activators.
2. Inserted standard framework service activators (e.g., package admin, start
level) at the beginning of the custom activator list to ensure that framework
services are available for custom framework activators.
3. Modified Main to implement BundleActivator and implemented auto-property
processing in start() method of activator. This required that I put Main's
config properties map into a static variable since there is no way to iterate
over all configuration properties via the BundleContext.
Only (3) should impact people, since this means that Felix will no longer
process auto-properties like before, but generally speaking it doesn't make
sense for Felix to be doing this anyway. These changes did raise some issues:
1. Since the old approach was inside Felix it could use the framework logger to
log events, where the new approach cannot. Of course, the framework logger was
always System.out during startup so not much changes, except that it won't be
able to leverage FELIX-428 either.
2. I don't like the fact that Main's activator cannot activate all of the
config properties through BundleContext since it cannot iterate over all keys,
which resulted in me putting the config properties map in Main into a
static...of course, this is more of an OSGi API limitation.
3. I realized why doing this that custom framework activators are really fairly
fragile since the framework is not really active yet and we have do a better
job of documenting that when using this approach that these framework
activators should do as little work as possible.
So, can I get any feedback on any of this?
> Should auto-property processing be moved to the launcher
> --------------------------------------------------------
>
> Key: FELIX-393
> URL: https://issues.apache.org/jira/browse/FELIX-393
> Project: Felix
> Issue Type: Improvement
> Components: Framework
> Reporter: Richard S. Hall
> Assignee: Richard S. Hall
> Priority: Minor
>
> It seems like auto-property handling (i.e., auto-install and auto-start) is
> misplaced in the framework. This functionality seems to be more conceptually
> related to the launcher than the framework.
> I believe it would be pretty straightforward to move this functionality from
> the framework subproject to the main subproject. Should we?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
