I think we mix topics here no? PS have no write API but can be re-queried to do a diff and create a changeset (event?). This is diff things no?
So it should be another topic IMO Le 27 déc. 2014 15:23, "John D. Ament" <[email protected]> a écrit : > 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* > > >
