|
If you were logged in you would be able to see more operations.
|
|
|
|
Issue Links:
|
Depends
|
|
|
|
This issue is depended on by:
|
|
SFOS-905
Move from direct inherited configuration to a "Cluster" CD that defines the cluster
|
|
|
|
|
|
|
| Compatibility: |
may break builds or test process
|
|
The ManagedConfiguration subclass of Hadoop's Configuration class does not override Configuration.set(), (key,value) pairs set are passed up to the superclass. But the superclass's values are not read on a get(); the results of a set() get discarded. This stops any bits of code that call Configuration.set() from working.
Most code that does this is example client code or test code. There is a risk that something inside does it, code that will now break
Options
1. Propagate the set() to the underlying component; pass SF errors back as runtime errors
-works if the underlying component only has one ManagedComponent, causes shared-state problems if there is more than one
2. Propagate the set() to the superclass, but read those values when enumerating all property tuples, and in a get() operation. They should get priority over the smartfrog attribute
3. cache it in some other mechanism (like a local Properties instance)
|
|
Description
|
The ManagedConfiguration subclass of Hadoop's Configuration class does not override Configuration.set(), (key,value) pairs set are passed up to the superclass. But the superclass's values are not read on a get(); the results of a set() get discarded. This stops any bits of code that call Configuration.set() from working.
Most code that does this is example client code or test code. There is a risk that something inside does it, code that will now break
Options
1. Propagate the set() to the underlying component; pass SF errors back as runtime errors
-works if the underlying component only has one ManagedComponent, causes shared-state problems if there is more than one
2. Propagate the set() to the superclass, but read those values when enumerating all property tuples, and in a get() operation. They should get priority over the smartfrog attribute
3. cache it in some other mechanism (like a local Properties instance) |
Show » |
|
Bug
ManagedConfiguration effectively discards all values it is set() with
Instead of being bound to a Prim which was read on demand, a configuration uses the superclass to store and marshall all content; we just fill it in from a Prim, or, soon, more than one Prim.
It will also be possible to move away from a subclass altogether, instead using the base Configuration and JobConf classes, with static methods to bind them. This will make the code less brittle and less dependent on changes to Configuration.