On Sat Dec 27 2014 at 9:18:44 AM Anatole Tresch <[email protected]> wrote:
> OK, lets perhaps think on the alternatives how to provide mutability: > > *1) directly add setters on PropertySource/Configuration* > -> IMO bad, since > - it requires probably extended synchronization mechisms, which > makes it slow in a > multi-threaded environment (see java.util.preferences) > - when multiple changes are happening for each change to full event > queue is activated > to publish the change to listeners > - it is better to validate a change, when you know the whole set of > changes that shoiuld be > applied > > *2) Add an accessor for getting a mutable variant of the instance to > change.* > -> Bad because it duplicates lot of the code of the base source/config > -> What happens if multiple "changers" are working in parallel > > *3) Add the possibility to simply pass a ChangeSet with all changes to be > applied to a config source/config* > -> Validation is easily possible > -> the change set is immutable > -> The change set can be versioned (on creation) enabling optimistic > locking mechanisms > -> THe change set can similarly reused as change event to inform the > listeners on the changes > done > > Variant 3 currently was my personal favoured one (there is a ChangeSet and > a ChangeSetBuilder in core). > > *For all 3 variants there is an additional decision:* > > *a) is the mutability functionality provided on the interfaces OOTB* > *b) is the mutability functionality provided as a separate interface, thath > optionally can be implemented* > > Let us know, if you see even more alternatives here... > > Anatole > > > I think the ChangeSet approach is the easiest to follow. I would have it return a future of some kind to represent the fact that it could take a while to complete. > > 2014-12-27 14:11 GMT+01:00 Werner Keil <[email protected]>: > > > Well there's even a Java standard, JSR 107 baking that kind of thing into > > their spec/API while dropping Enterprise level support for e.g. > > transactions;-| > > > > We need at a proper way to dynamically add, modify or refresh properties > at > > runtime. Without having to compile the code again;-) > > Whether a particular reference was then mutable or immutable, is less > > critical. > > There's of course always a memory penalty if you have to add or recreate > > objects rather than updating existing ones, but it seems that kind of > waste > > most developers are happy to pay nowadays, especially on the EE side, > > probably more careful about that in the Embedded world, but I don't see > > most of it relevant to even SE Embedded from the recent discussion and > > scope;-) > > > > Werner > > Am 27.12.2014 12:32 schrieb "Anatole Tresch" <[email protected]>: > > > > > As I said, there was certainly demand for it. In reality I think, it is > > > rarely used, or even worse the consequences of config changes can be > > > drastic and must be well managed in all more complex cases. So I dont > see > > > it in the API. I can imagine to take it up as an implementation thread. > > > Perhaps we define some kind of mix-in interface for it, that can be > > > implemented however useful. But that is just an idea. Also the current > > code > > > (aka "dormant", but I will still maintain it and adapt it along the > > > discussion we have, regardless what Mark thinks on it) has nothing of > it > > in > > > its API module. > > > > > > 2014-12-27 11:29 GMT+01:00 Romain Manni-Bucau <[email protected]>: > > > > > > > I guess i am the one having spoken of it so let me make it more > > explicit > > > if > > > > needed. I want it for all the reason you mentionned but I never > wanted > > > it > > > > in our API. I would have liked it in our APIs. We > can...should...split > > > > write and read API. It also mdans it can wait read paft is clear and > > > done. > > > > Le 27 déc. 2014 11:22, "Mark Struberg" <[email protected]> a écrit : > > > > > > > > > Hi! > > > > > > > > > > Do we need a writable PropertySource in our API? > > > > > > > > > > I don't think we do. But let me explain the _why_! > > > > > > > > > > > > > > > I DO understand that administrators and ops lords&ladies need a way > > to > > > > > sometimes change certain configuration at runtime. They might even > be > > > > > interested in a graphical UI! > > > > > > > > > > But still we don't need that in our API. It would be really easy > for > > > each > > > > > Container (or even as own jar) to add a new PropertySource with a > > very > > > > high > > > > > ordinal (basically overriding default values). And this > > > > > MutablePropertySourceImpl could e.g. store the configured values in > > the > > > > > database etc. > > > > > > > > > > > > > > > The effect would be that admins could easily tweak those values > (and > > > even > > > > > make them persistent). And all that without us having to take care > of > > > it. > > > > > > > > > > > > > > > The question is now whether we write this into the spec or let > > > container > > > > > vendors deal with it? > > > > > > > > > > > > > > > LieGrue, > > > > > strub > > > > > > > > > > > > > > > > > > > > > -- > > > *Anatole Tresch* > > > Java Engineer & Architect, JSR Spec Lead > > > Glärnischweg 10 > > > CH - 8620 Wetzikon > > > > > > *Switzerland, Europe Zurich, GMT+1* > > > *Twitter: @atsticks* > > > *Blogs: **http://javaremarkables.blogspot.ch/ > > > <http://javaremarkables.blogspot.ch/>* > > > > > > *Google: atsticksMobile +41-76 344 62 79* > > > > > > > > > -- > *Anatole Tresch* > Java Engineer & Architect, JSR Spec Lead > Glärnischweg 10 > CH - 8620 Wetzikon > > *Switzerland, Europe Zurich, GMT+1* > *Twitter: @atsticks* > *Blogs: **http://javaremarkables.blogspot.ch/ > <http://javaremarkables.blogspot.ch/>* > > *Google: atsticksMobile +41-76 344 62 79* >
