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
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*
