You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Richard S. Hall (JIRA)" <ji...@apache.org> on 2007/07/09 21:45:04 UTC
[jira] Created: (FELIX-324) Framework constructor should take a
non-mutable property resolver
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-324) Framework constructor should take a
non-mutable property resolver
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511828 ]
Richard S. Hall commented on FELIX-324:
---------------------------------------
On second thought, after talking with Karl, he likes the fact that it is possible to externally change bundle configuration properties by not copying the passed in set of properties (which would be required to actually make it immutable). Therefore, we won't change this to accept a property resolver.
However, in an effort to clean up the API, I think we can at least eliminate the PropertyResolver classes and just use Map directly, since the PropertyResolver interface doesn't really buy us anything (especially since it normally just wraps a map anyway) and it is just more API for someone else to learn.
I will commit changes converting PropertyResolver to Map shortly...
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Work started: (FELIX-324) Framework constructor should take
a non-mutable property resolver
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Work on FELIX-324 started by Richard S. Hall.
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
API Change (Was Re: [jira] Closed: (FELIX-324) Framework constructor
should take a non-mutable property resolver)
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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.
>>
>
>
[jira] Closed: (FELIX-324) Framework constructor should take a
non-mutable property resolver
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.