Just wanted everyone to be aware that there is another slight API change
as part of our preparation for a 1.0 release...
In the last change we moved the property resolver and activator list
arguments from the Felix.start() method to the Felix constructor. In
this change we have done away with the property resolver concept
altogether and now just use a Map.
The benefits are that we were able to delete four classes related to
property resolvers, do not need to introduce yet another concept for
people to understand, and simplify creating Felix instances since the
default property resolver implementation simply wrapped a map any way.
The only change in to port to this new API is changing this:
new Felix(new MutablePropertyResolverImpl(configMap), list);
To this:
new Felix(configMap, list);
I have updated the embedding documentation at:
http://cwiki.apache.org/confluence/display/FELIX/Launching+and+Embedding+Apache+Felix
This should be the last API change...
-> richard
Richard S. Hall (JIRA) wrote:
[
https://issues.apache.org/jira/browse/FELIX-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard S. Hall closed FELIX-324.
---------------------------------
Resolution: Fixed
Modified the Felix constructor to accept a Map rather than a PropertyResolver
instance...this allowed us to delete the four PropertyResolver-related classes
and it simplifies constructing a Felix instance. I will update the
documentation on this.
Framework constructor should take a non-mutable property resolver
-----------------------------------------------------------------
Key: FELIX-324
URL: https://issues.apache.org/jira/browse/FELIX-324
Project: Felix
Issue Type: Improvement
Components: Framework
Affects Versions: 1.0.0
Reporter: Richard S. Hall
Assignee: Richard S. Hall
Fix For: 1.0.0
As part of our effort to improve Felix' public API for the 1.0.0 release, I
think we should probably change the constructor to take a PropertyResolver
instead of a MutablePropertyResolver. I believe the original choice of
MutablePropertyResolver was to avoid having to copy the passed in configuration
properties, but it is probably safer if the framework makes its own copy, which
will prevent attempts to externally modify the configuration properties at run
time.
