You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Deepal Jayasinghe (JIRA)" <ji...@apache.org> on 2005/09/05 10:00:32 UTC
[jira] Created: (AXIS2-200) Properties vs Parameters
Properties vs Parameters
------------------------
Key: AXIS2-200
URL: http://issues.apache.org/jira/browse/AXIS2-200
Project: Apache Axis 2.0 (Axis2)
Type: Wish
Components: core
Reporter: Deepal Jayasinghe
In the current implementation I sow when we ask for parameter it returns deploy time parameter if there is no property with the given name. I think that is wrong , properties are things that we use at the run time , one handler would add a property to MC (or any context) and some other handler would use that .
If some handler want to access deployment time parameters (comes via configuration files), it should access them via getParamter();
So I think we should not return Parameters when we ask for properties , if the requested property is not there return null.
comments ..........
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXIS2-200) Properties vs Parameters
Posted by "Sanjiva Weerawarana (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-200?page=comments#action_12322635 ]
Sanjiva Weerawarana commented on AXIS2-200:
-------------------------------------------
+1 for separating runtime properties from configuration parameters.
> Properties vs Parameters
> ------------------------
>
> Key: AXIS2-200
> URL: http://issues.apache.org/jira/browse/AXIS2-200
> Project: Apache Axis 2.0 (Axis2)
> Type: Wish
> Components: core
> Reporter: Deepal Jayasinghe
>
> In the current implementation I sow when we ask for parameter it returns deploy time parameter if there is no property with the given name. I think that is wrong , properties are things that we use at the run time , one handler would add a property to MC (or any context) and some other handler would use that .
> If some handler want to access deployment time parameters (comes via configuration files), it should access them via getParamter();
> So I think we should not return Parameters when we ask for properties , if the requested property is not there return null.
> comments ..........
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (AXIS2-200) Properties vs Parameters
Posted by "Deepal Jayasinghe (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-200?page=all ]
Deepal Jayasinghe resolved AXIS2-200:
-------------------------------------
Resolution: Fixed
Fixed by Axis2-194
> Properties vs Parameters
> ------------------------
>
> Key: AXIS2-200
> URL: http://issues.apache.org/jira/browse/AXIS2-200
> Project: Apache Axis 2.0 (Axis2)
> Type: Wish
> Components: core
> Reporter: Deepal Jayasinghe
>
> In the current implementation I sow when we ask for parameter it returns deploy time parameter if there is no property with the given name. I think that is wrong , properties are things that we use at the run time , one handler would add a property to MC (or any context) and some other handler would use that .
> If some handler want to access deployment time parameters (comes via configuration files), it should access them via getParamter();
> So I think we should not return Parameters when we ask for properties , if the requested property is not there return null.
> comments ..........
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira