Roland et al What if we approached the problem form a different angle and simply did away with parameter linking in HttpCore altogether? Hierarchy building is used only in a handful of high level protocol classes and always for representing an ultra-trivial parent / child relationship.
This would enable us to get rid of a lots of complexity and push the decision about the specifics of parameter resolution to out of core to higher level modules such as HttpClient. This would also render the whole 'unsetting parameter' issue an implementation detail each upstream project can choose to solve differently. The existing parameter linking code can be replaced with a trivial two level stack of HttpParams. Would that solve the problem for you? Cheers, Oleg On Sat, 2008-01-05 at 10:42 +0100, Roland Weber wrote: > Roland Weber wrote: > > how are we going to "unset" a parameter that is defined > > somewhere higher up in the hierarchy? The example at hand > > is the default proxy. An application defines a default > > proxy in the client parameters, but wants a specific > > request to be sent without the proxy. Setting the value > > to null in the request parameters doesn't work, since > > null means "look higher up in the hierarchy". > > This problem is an incarnation of > https://issues.apache.org/jira/browse/HTTPCORE-65 > > > Option A: > > Define a global "Void" object that can be used to > > explicitly unset any parameter value. Since the global > > object does not match the expected type of parameters, > > the check for "Void" has to be done before casting > > the value to the target type. > > Moving the check for the "Void" object into the params > > implementations will not work, since each param impl > > can be put into a hierarchy. If it's in the hierarchy, > > it has to return the object to cancel recursion, only > > the outmost impl can be allowed to do the null conversion. > > The global Void object could be handled in the type > specific getter methods, and in static helpers for > non-default types. > > cheers, > Roland > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
