You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Arnaud Simon (JIRA)" <qp...@incubator.apache.org> on 2008/05/05 10:40:55 UTC
[jira] Created: (QPID-1018) Client properties centralization
Client properties centralization
---------------------------------
Key: QPID-1018
URL: https://issues.apache.org/jira/browse/QPID-1018
Project: Qpid
Issue Type: Improvement
Components: Java Client
Affects Versions: M3
Reporter: Arnaud Simon
Fix For: M3
Currently client props are distributed all over the code. It would be more coherent and easy to document if we centralized them.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (QPID-1018) Client properties centralization
Posted by "Arnaud Simon (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598225#action_12598225 ]
Arnaud Simon commented on QPID-1018:
------------------------------------
As discussed during our weekly meeting it would be a better idea to access properties through accessors. The following solutions could be adopted:
1) We use a class and provide getters for each property
2) We use an enum and provide (type, default-value, value, etc..)
I would suggest we go for the second solution as it's the most flexible one. So we should have something like:
///-----
MAX_PREFETCH("boolean", true, Boolean.getBoolean("max_prefetch"));
Conf(String type, Object defaultVal, Object val)
{
_type = type;
_defaultVal = defaultVal;
_val = val;
}
public String getType()
{
return _type;
}
public Object getVal()
{
return _val;
}
.....
We can discuss what property descriptors we like to have, I would say the minimum list is:
- name
- type
- description
- default value
- value
> Client properties centralization
> ---------------------------------
>
> Key: QPID-1018
> URL: https://issues.apache.org/jira/browse/QPID-1018
> Project: Qpid
> Issue Type: Improvement
> Components: Java Client
> Affects Versions: M3
> Reporter: Arnaud Simon
> Assignee: Arnaud Simon
> Fix For: M3
>
>
> Currently client props are distributed all over the code. It would be more coherent and easy to document if we centralized them.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-1018) Client properties centralization
Posted by "Arnaud Simon (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Arnaud Simon updated QPID-1018:
-------------------------------
Fix Version/s: (was: M4)
> Client properties centralization
> ---------------------------------
>
> Key: QPID-1018
> URL: https://issues.apache.org/jira/browse/QPID-1018
> Project: Qpid
> Issue Type: Improvement
> Components: Java Client
> Affects Versions: M3
> Reporter: Arnaud Simon
> Assignee: Arnaud Simon
>
> Currently client props are distributed all over the code. It would be more coherent and easy to document if we centralized them.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (QPID-1018) Client properties centralization
Posted by "Rafael H. Schloming (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598290#action_12598290 ]
Rafael H. Schloming commented on QPID-1018:
-------------------------------------------
I can see why it is useful to have a uniform way for the configuration object to internally fetch its values, however I don't see the point of exposing enums as part of the interface to the code. Is there some reason I'm missing that the natural interface, i.e. Configuration.getFoo() is inadequate? So far I don't see anything that Configuration.BLAH.getValue() provides for the calling code beyond Configuration.getBlah(), whereas a natural set of getters can easily be turned into an interface or abstract class which can be swapped out wholesale with whatever mechanism we want behind it.
> Client properties centralization
> ---------------------------------
>
> Key: QPID-1018
> URL: https://issues.apache.org/jira/browse/QPID-1018
> Project: Qpid
> Issue Type: Improvement
> Components: Java Client
> Affects Versions: M3
> Reporter: Arnaud Simon
> Assignee: Arnaud Simon
> Fix For: M3
>
>
> Currently client props are distributed all over the code. It would be more coherent and easy to document if we centralized them.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (QPID-1018) Client properties centralization
Posted by "Arnaud Simon (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Arnaud Simon reassigned QPID-1018:
----------------------------------
Assignee: Arnaud Simon
> Client properties centralization
> ---------------------------------
>
> Key: QPID-1018
> URL: https://issues.apache.org/jira/browse/QPID-1018
> Project: Qpid
> Issue Type: Improvement
> Components: Java Client
> Affects Versions: M3
> Reporter: Arnaud Simon
> Assignee: Arnaud Simon
> Fix For: M3
>
>
> Currently client props are distributed all over the code. It would be more coherent and easy to document if we centralized them.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (QPID-1018) Client properties centralization
Posted by "Arnaud Simon (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12594202#action_12594202 ]
Arnaud Simon commented on QPID-1018:
------------------------------------
I have added a client prop class in: org.apache.qpid.client.configuration
The following format is used:
/**
* Description of the property XX
* type: the property type
*/
public static final String XX_PROP_NAME = "qpid.foo";
public static final String XX_DEFAULT = "26000";
> Client properties centralization
> ---------------------------------
>
> Key: QPID-1018
> URL: https://issues.apache.org/jira/browse/QPID-1018
> Project: Qpid
> Issue Type: Improvement
> Components: Java Client
> Affects Versions: M3
> Reporter: Arnaud Simon
> Assignee: Arnaud Simon
> Fix For: M3
>
>
> Currently client props are distributed all over the code. It would be more coherent and easy to document if we centralized them.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (QPID-1018) Client properties centralization
Posted by "Rafael H. Schloming (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598267#action_12598267 ]
Rafael H. Schloming commented on QPID-1018:
-------------------------------------------
I think I prefer option (1) since it permits the correct type to be reterned, e.g.:
getMaxPrefetch() --> boolean, vs MAX_PREFETCH.getVal() --> Object
I also don't see how option (2) is more flexible in a useful way. Granted it does provide the code with more information about the property, but I don't see why the calling code would ever care about anything other than what the current value of the property is. In fact I would think any logic that depends on that information should go behind the getter, not in the calling code.
> Client properties centralization
> ---------------------------------
>
> Key: QPID-1018
> URL: https://issues.apache.org/jira/browse/QPID-1018
> Project: Qpid
> Issue Type: Improvement
> Components: Java Client
> Affects Versions: M3
> Reporter: Arnaud Simon
> Assignee: Arnaud Simon
> Fix For: M3
>
>
> Currently client props are distributed all over the code. It would be more coherent and easy to document if we centralized them.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (QPID-1018) Client properties centralization
Posted by "Rob Godfrey (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598284#action_12598284 ]
Rob Godfrey commented on QPID-1018:
-----------------------------------
Personally I prefer a variant of option 2; where the type information is preserved...
Something like
abstract public class ConfigurationProperty<T extends Object>
{
private static final Logger _logger = LoggerFactory.getLogger(ConfigurationProperty.class);
static final Map<String, ConfigurationProperty<? extends Object>> _propertiesMap = new HashMap<String, ConfigurationProperty<? extends Object>>();
private final String _name;
private T _value;
protected ConfigurationProperty(Class<T> clazz, String name, String systemProperty, T defaultValue)
{
_name = name;
T value = null;
if(systemProperty != null && System.getProperties().containsKey(systemProperty))
{
String systemPropertyValue = System.getProperty(systemProperty);
try
{
Constructor<T> constructor = clazz.getConstructor(String.class);
value = constructor.newInstance(systemPropertyValue);
}
catch (NoSuchMethodException e)
{
_logger.error("Unable to find constructor for class "
+ clazz.getName()
+ " for configuration property "
+ name, e);
}
catch (InvocationTargetException e)
{
_logger.error("Unable to execute constructor for class "
+ clazz.getName()
+ " for configuration property "
+ name, e);
}
catch (IllegalAccessException e)
{
_logger.error("Unable to access constructor for class "
+ clazz.getName()
+ " for configuration property "
+ name, e);
}
catch (InstantiationException e)
{
_logger.error("Error while attempting to construct for class "
+ clazz.getName()
+ " for configuration property "
+ name
+ " using value '"
+ systemPropertyValue
+"'", e);
}
_propertiesMap.put(_name, this);
}
if(value == null)
{
value = defaultValue;
}
_value = value;
}
final public String getName()
{
return _name;
}
final public T getValue()
{
return _value;
}
And then:
public class CommonConfigurationProperty<T extends Object> extends ConfigurationProperty<T>
{
protected CommonConfigurationProperty(final Class<T> clazz,
final String name,
final String systemProperty,
final T defaultValue)
{
super(clazz, name, systemProperty, defaultValue);
}
public static final ConfigurationProperty<Boolean> USE_BIASED_JOB_QUEUE =
new CommonConfigurationProperty(Boolean.class,
"UseBiasedJobQueue",
"org.apache.qpid.common.useBiasedJobQueue",
Boolean.FALSE);
}
which would allow you to do
CommonConfigurationPropert.USE_BIASED_JOB_QUEUE,getValue() -> [Bb]oolean
But also ensure that we get the system properties etc in a uniform way. Also it leaves open for sub classes (particularly the server properties) to update the values of properties based on some other configuration mechanism (not just java system properties)..
> Client properties centralization
> ---------------------------------
>
> Key: QPID-1018
> URL: https://issues.apache.org/jira/browse/QPID-1018
> Project: Qpid
> Issue Type: Improvement
> Components: Java Client
> Affects Versions: M3
> Reporter: Arnaud Simon
> Assignee: Arnaud Simon
> Fix For: M3
>
>
> Currently client props are distributed all over the code. It would be more coherent and easy to document if we centralized them.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.