You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tamaya.apache.org by Mark Struberg <st...@yahoo.de> on 2014/12/27 11:19:18 UTC
[DISCUSS] writable/mutable PropertySource
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
Re: [DISCUSS] writable/mutable PropertySource
Posted by Werner Keil <we...@gmail.com>.
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" <at...@gmail.com>:
> 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 <rm...@gmail.com>:
>
> > 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" <st...@yahoo.de> 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*
>
Re: [DISCUSS] writable/mutable PropertySource
Posted by Anatole Tresch <at...@gmail.com>.
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 <rm...@gmail.com>:
> 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" <st...@yahoo.de> 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*
Re: [DISCUSS] writable/mutable PropertySource
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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" <st...@yahoo.de> 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
>