You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Gurkan Erdogdu <cg...@gmail.com> on 2019/01/02 07:20:58 UTC
[DISCUSS] Regarding TomEE and OpenEJB related system properties
Hello
There are lots of known and unknown system properties in the current code
base. I would like to introduce TomEESystemProperties and
OpenEJBSystemProperties classes to hold these system property constants and
provide clear comment what it does. For example:
class TomEESystemProperties{
public static final String TOMEE_FORCE_RELOADABLE =
"tomee.force-reloadable";
....
}
class OpenEJBSystemProperties{
public static final String OPENEJB_CROSSCONTEXT_PROPERTY =
"openejb.crosscontext";
....
}
WDYT?
Regards.
Gurkan
Re: [DISCUSS] Regarding TomEE and OpenEJB related system properties
Posted by Gurkan Erdogdu <cg...@gmail.com>.
I created a pull request, https://github.com/apache/tomee/pull/343
New maven project tomee-config is introduced with single class,
TomEESystemConfig. This will include all system properties for tomee.*
Also updated TomcatWebAppBuilder to remove some tomee.* properties and use
the config class provided. Need to remove all others from the code base and
use this class.
Can you please check?
On Wed, Jan 2, 2019 at 1:31 PM Jean-Louis Monteiro <jl...@tomitribe.com>
wrote:
> Agreed. For such a critical and low level need on the system, I'm not so
> fan about creating a hard dependency on a spec and an implementation.
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Wed, Jan 2, 2019 at 11:26 AM Roberto Cortez <radcortez@yahoo.com.invalid
> >
> wrote:
>
> > I think we should stay away from MP Config for now.
> >
> > TomEE does a lot more regarding substitution and config on several places
> > that MP Config doesn’t support.
> >
> > > On 2 Jan 2019, at 09:55, Bruno Baptista <br...@gmail.com> wrote:
> > >
> > > Sounds like a good plan. :)
> > >
> > > Bruno Baptista
> > > https://twitter.com/brunobat_ <https://twitter.com/brunobat_>
> > >
> > > On 02/01/19 09:47, Gurkan Erdogdu wrote:
> > >> For me, using services-jar.xml approach is not so visible to users.
> All
> > >> defaults are configured in this file and packaged within JAR file.
> Users
> > >> are not able to read the parameter explanation from services-jar.xml
> > files.
> > >> Also, services.-jar.xml is somebit different from using the system
> > >> properties to turn-on/off something. I am also thinking to introduce
> > YAML
> > >> based configuration.
> > >>
> > >> But first step is to centralise all of these system parameters into
> two
> > >> classes. Maybe, we will see that some of them are unnecessary etc.
> > >>
> > >> On Wed, Jan 2, 2019 at 12:44 PM Bruno Baptista <br...@gmail.com>
> > wrote:
> > >>
> > >>> Yes, there is.
> > >>>
> > >>> This is also the most basic MP spec and nothing prevents us from
> using
> > >>> it everywhere.
> > >>>
> > >>> There might be Jakarta EE restrictions in how to handle
> configurations
> > >>> that need to be assessed.
> > >>>
> > >>> Overall, I think that if we are going to mess with configs, we should
> > >>> use state of the art.
> > >>>
> > >>> Cheers
> > >>>
> > >>> Bruno Baptista
> > >>> https://twitter.com/brunobat_
> > >>>
> > >>>
> > >>> On 02/01/19 09:35, Jean-Louis Monteiro wrote:
> > >>>> I think with microprofile-config we may have a chicken and the egg
> > >>> problem,
> > >>>> isn't it?
> > >>>> --
> > >>>> Jean-Louis Monteiro
> > >>>> http://twitter.com/jlouismonteiro
> > >>>> http://www.tomitribe.com
> > >>>>
> > >>>>
> > >>>> On Wed, Jan 2, 2019 at 10:30 AM Bruno Baptista <br...@gmail.com>
> > >>> wrote:
> > >>>>> Hi Gurkan,
> > >>>>>
> > >>>>> I agree we have a problem with the documentation of the different
> > >>>>> properties and that we need to improve it.
> > >>>>>
> > >>>>> Doing the inventory and using the proposed syntax looks ok to me
> but
> > I
> > >>>>> also think we should go even further.
> > >>>>>
> > >>>>> How about to migrate all the properties to use microprofile-config?
> > >>>>>
> > >>>>> Cheers.
> > >>>>>
> > >>>>> Bruno Baptista
> > >>>>> https://twitter.com/brunobat_
> > >>>>>
> > >>>>>
> > >>>>> On 02/01/19 07:20, Gurkan Erdogdu wrote:
> > >>>>>> Hello
> > >>>>>> There are lots of known and unknown system properties in the
> current
> > >>> code
> > >>>>>> base. I would like to introduce TomEESystemProperties and
> > >>>>>> OpenEJBSystemProperties classes to hold these system property
> > constants
> > >>>>> and
> > >>>>>> provide clear comment what it does. For example:
> > >>>>>>
> > >>>>>> class TomEESystemProperties{
> > >>>>>> public static final String TOMEE_FORCE_RELOADABLE =
> > >>>>>> "tomee.force-reloadable";
> > >>>>>> ....
> > >>>>>> }
> > >>>>>>
> > >>>>>> class OpenEJBSystemProperties{
> > >>>>>> public static final String OPENEJB_CROSSCONTEXT_PROPERTY =
> > >>>>>> "openejb.crosscontext";
> > >>>>>> ....
> > >>>>>> }
> > >>>>>>
> > >>>>>> WDYT?
> > >>>>>> Regards.
> > >>>>>> Gurkan
> > >>>>>>
> >
> >
>
Re: [DISCUSS] Regarding TomEE and OpenEJB related system properties
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
Agreed. For such a critical and low level need on the system, I'm not so
fan about creating a hard dependency on a spec and an implementation.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Wed, Jan 2, 2019 at 11:26 AM Roberto Cortez <ra...@yahoo.com.invalid>
wrote:
> I think we should stay away from MP Config for now.
>
> TomEE does a lot more regarding substitution and config on several places
> that MP Config doesn’t support.
>
> > On 2 Jan 2019, at 09:55, Bruno Baptista <br...@gmail.com> wrote:
> >
> > Sounds like a good plan. :)
> >
> > Bruno Baptista
> > https://twitter.com/brunobat_ <https://twitter.com/brunobat_>
> >
> > On 02/01/19 09:47, Gurkan Erdogdu wrote:
> >> For me, using services-jar.xml approach is not so visible to users. All
> >> defaults are configured in this file and packaged within JAR file. Users
> >> are not able to read the parameter explanation from services-jar.xml
> files.
> >> Also, services.-jar.xml is somebit different from using the system
> >> properties to turn-on/off something. I am also thinking to introduce
> YAML
> >> based configuration.
> >>
> >> But first step is to centralise all of these system parameters into two
> >> classes. Maybe, we will see that some of them are unnecessary etc.
> >>
> >> On Wed, Jan 2, 2019 at 12:44 PM Bruno Baptista <br...@gmail.com>
> wrote:
> >>
> >>> Yes, there is.
> >>>
> >>> This is also the most basic MP spec and nothing prevents us from using
> >>> it everywhere.
> >>>
> >>> There might be Jakarta EE restrictions in how to handle configurations
> >>> that need to be assessed.
> >>>
> >>> Overall, I think that if we are going to mess with configs, we should
> >>> use state of the art.
> >>>
> >>> Cheers
> >>>
> >>> Bruno Baptista
> >>> https://twitter.com/brunobat_
> >>>
> >>>
> >>> On 02/01/19 09:35, Jean-Louis Monteiro wrote:
> >>>> I think with microprofile-config we may have a chicken and the egg
> >>> problem,
> >>>> isn't it?
> >>>> --
> >>>> Jean-Louis Monteiro
> >>>> http://twitter.com/jlouismonteiro
> >>>> http://www.tomitribe.com
> >>>>
> >>>>
> >>>> On Wed, Jan 2, 2019 at 10:30 AM Bruno Baptista <br...@gmail.com>
> >>> wrote:
> >>>>> Hi Gurkan,
> >>>>>
> >>>>> I agree we have a problem with the documentation of the different
> >>>>> properties and that we need to improve it.
> >>>>>
> >>>>> Doing the inventory and using the proposed syntax looks ok to me but
> I
> >>>>> also think we should go even further.
> >>>>>
> >>>>> How about to migrate all the properties to use microprofile-config?
> >>>>>
> >>>>> Cheers.
> >>>>>
> >>>>> Bruno Baptista
> >>>>> https://twitter.com/brunobat_
> >>>>>
> >>>>>
> >>>>> On 02/01/19 07:20, Gurkan Erdogdu wrote:
> >>>>>> Hello
> >>>>>> There are lots of known and unknown system properties in the current
> >>> code
> >>>>>> base. I would like to introduce TomEESystemProperties and
> >>>>>> OpenEJBSystemProperties classes to hold these system property
> constants
> >>>>> and
> >>>>>> provide clear comment what it does. For example:
> >>>>>>
> >>>>>> class TomEESystemProperties{
> >>>>>> public static final String TOMEE_FORCE_RELOADABLE =
> >>>>>> "tomee.force-reloadable";
> >>>>>> ....
> >>>>>> }
> >>>>>>
> >>>>>> class OpenEJBSystemProperties{
> >>>>>> public static final String OPENEJB_CROSSCONTEXT_PROPERTY =
> >>>>>> "openejb.crosscontext";
> >>>>>> ....
> >>>>>> }
> >>>>>>
> >>>>>> WDYT?
> >>>>>> Regards.
> >>>>>> Gurkan
> >>>>>>
>
>
Re: [DISCUSS] Regarding TomEE and OpenEJB related system properties
Posted by Roberto Cortez <ra...@yahoo.com.INVALID>.
I think we should stay away from MP Config for now.
TomEE does a lot more regarding substitution and config on several places that MP Config doesn’t support.
> On 2 Jan 2019, at 09:55, Bruno Baptista <br...@gmail.com> wrote:
>
> Sounds like a good plan. :)
>
> Bruno Baptista
> https://twitter.com/brunobat_ <https://twitter.com/brunobat_>
>
> On 02/01/19 09:47, Gurkan Erdogdu wrote:
>> For me, using services-jar.xml approach is not so visible to users. All
>> defaults are configured in this file and packaged within JAR file. Users
>> are not able to read the parameter explanation from services-jar.xml files.
>> Also, services.-jar.xml is somebit different from using the system
>> properties to turn-on/off something. I am also thinking to introduce YAML
>> based configuration.
>>
>> But first step is to centralise all of these system parameters into two
>> classes. Maybe, we will see that some of them are unnecessary etc.
>>
>> On Wed, Jan 2, 2019 at 12:44 PM Bruno Baptista <br...@gmail.com> wrote:
>>
>>> Yes, there is.
>>>
>>> This is also the most basic MP spec and nothing prevents us from using
>>> it everywhere.
>>>
>>> There might be Jakarta EE restrictions in how to handle configurations
>>> that need to be assessed.
>>>
>>> Overall, I think that if we are going to mess with configs, we should
>>> use state of the art.
>>>
>>> Cheers
>>>
>>> Bruno Baptista
>>> https://twitter.com/brunobat_
>>>
>>>
>>> On 02/01/19 09:35, Jean-Louis Monteiro wrote:
>>>> I think with microprofile-config we may have a chicken and the egg
>>> problem,
>>>> isn't it?
>>>> --
>>>> Jean-Louis Monteiro
>>>> http://twitter.com/jlouismonteiro
>>>> http://www.tomitribe.com
>>>>
>>>>
>>>> On Wed, Jan 2, 2019 at 10:30 AM Bruno Baptista <br...@gmail.com>
>>> wrote:
>>>>> Hi Gurkan,
>>>>>
>>>>> I agree we have a problem with the documentation of the different
>>>>> properties and that we need to improve it.
>>>>>
>>>>> Doing the inventory and using the proposed syntax looks ok to me but I
>>>>> also think we should go even further.
>>>>>
>>>>> How about to migrate all the properties to use microprofile-config?
>>>>>
>>>>> Cheers.
>>>>>
>>>>> Bruno Baptista
>>>>> https://twitter.com/brunobat_
>>>>>
>>>>>
>>>>> On 02/01/19 07:20, Gurkan Erdogdu wrote:
>>>>>> Hello
>>>>>> There are lots of known and unknown system properties in the current
>>> code
>>>>>> base. I would like to introduce TomEESystemProperties and
>>>>>> OpenEJBSystemProperties classes to hold these system property constants
>>>>> and
>>>>>> provide clear comment what it does. For example:
>>>>>>
>>>>>> class TomEESystemProperties{
>>>>>> public static final String TOMEE_FORCE_RELOADABLE =
>>>>>> "tomee.force-reloadable";
>>>>>> ....
>>>>>> }
>>>>>>
>>>>>> class OpenEJBSystemProperties{
>>>>>> public static final String OPENEJB_CROSSCONTEXT_PROPERTY =
>>>>>> "openejb.crosscontext";
>>>>>> ....
>>>>>> }
>>>>>>
>>>>>> WDYT?
>>>>>> Regards.
>>>>>> Gurkan
>>>>>>
Re: [DISCUSS] Regarding TomEE and OpenEJB related system properties
Posted by Bruno Baptista <br...@gmail.com>.
Sounds like a good plan. :)
Bruno Baptista
https://twitter.com/brunobat_
On 02/01/19 09:47, Gurkan Erdogdu wrote:
> For me, using services-jar.xml approach is not so visible to users. All
> defaults are configured in this file and packaged within JAR file. Users
> are not able to read the parameter explanation from services-jar.xml files.
> Also, services.-jar.xml is somebit different from using the system
> properties to turn-on/off something. I am also thinking to introduce YAML
> based configuration.
>
> But first step is to centralise all of these system parameters into two
> classes. Maybe, we will see that some of them are unnecessary etc.
>
> On Wed, Jan 2, 2019 at 12:44 PM Bruno Baptista <br...@gmail.com> wrote:
>
>> Yes, there is.
>>
>> This is also the most basic MP spec and nothing prevents us from using
>> it everywhere.
>>
>> There might be Jakarta EE restrictions in how to handle configurations
>> that need to be assessed.
>>
>> Overall, I think that if we are going to mess with configs, we should
>> use state of the art.
>>
>> Cheers
>>
>> Bruno Baptista
>> https://twitter.com/brunobat_
>>
>>
>> On 02/01/19 09:35, Jean-Louis Monteiro wrote:
>>> I think with microprofile-config we may have a chicken and the egg
>> problem,
>>> isn't it?
>>> --
>>> Jean-Louis Monteiro
>>> http://twitter.com/jlouismonteiro
>>> http://www.tomitribe.com
>>>
>>>
>>> On Wed, Jan 2, 2019 at 10:30 AM Bruno Baptista <br...@gmail.com>
>> wrote:
>>>> Hi Gurkan,
>>>>
>>>> I agree we have a problem with the documentation of the different
>>>> properties and that we need to improve it.
>>>>
>>>> Doing the inventory and using the proposed syntax looks ok to me but I
>>>> also think we should go even further.
>>>>
>>>> How about to migrate all the properties to use microprofile-config?
>>>>
>>>> Cheers.
>>>>
>>>> Bruno Baptista
>>>> https://twitter.com/brunobat_
>>>>
>>>>
>>>> On 02/01/19 07:20, Gurkan Erdogdu wrote:
>>>>> Hello
>>>>> There are lots of known and unknown system properties in the current
>> code
>>>>> base. I would like to introduce TomEESystemProperties and
>>>>> OpenEJBSystemProperties classes to hold these system property constants
>>>> and
>>>>> provide clear comment what it does. For example:
>>>>>
>>>>> class TomEESystemProperties{
>>>>> public static final String TOMEE_FORCE_RELOADABLE =
>>>>> "tomee.force-reloadable";
>>>>> ....
>>>>> }
>>>>>
>>>>> class OpenEJBSystemProperties{
>>>>> public static final String OPENEJB_CROSSCONTEXT_PROPERTY =
>>>>> "openejb.crosscontext";
>>>>> ....
>>>>> }
>>>>>
>>>>> WDYT?
>>>>> Regards.
>>>>> Gurkan
>>>>>
Re: [DISCUSS] Regarding TomEE and OpenEJB related system properties
Posted by Gurkan Erdogdu <cg...@gmail.com>.
Thanks all.
Hope clear all conflicts. Jon, can you now merge the PR?
Regards.
Gurkan
On Mon, Jan 7, 2019 at 5:21 PM Jean-Louis Monteiro <jl...@tomitribe.com>
wrote:
> Yes I agree and take it as you describe so it's all good. It's definitely a
> step forward
>
> Le lun. 7 janv. 2019 à 12:21, Gurkan Erdogdu <cg...@gmail.com> a
> écrit :
>
> > Hello Jean-Louis and team,
> > I want to emphasize again that this PR will not change anything regarding
> > system properties. Its sole aim is to centralize all literal system
> > properties into its own module. Maybe, for the future, if needed, we can
> > update this module to add more configuration related functions. Currently
> > all literal constants are distributed around the codebase. Before adding
> > any more property, we need to discuss it first in here. So, one can
> easily
> > find the used property this way.
> > Regards.
> > Gurkan
> >
> > On Mon, Jan 7, 2019 at 1:30 PM Jean-Louis Monteiro <
> > jlmonteiro@tomitribe.com>
> > wrote:
> >
> > > Just want to make sure we don't forget System Properties were meant to
> be
> > > used to override configuration and not to be the main configuration
> > system
> > > for TomEE.
> > >
> > > We can discuss it and decide to change our mind and TomEE, but as per
> > now,
> > > I'm not really keen to relying on system properties to configure TomEE.
> > I'd
> > > rather take the opportunity to yank some system properties when
> possible.
> > >
> > >
> > >
> > > --
> > > Jean-Louis Monteiro
> > > http://twitter.com/jlouismonteiro
> > > http://www.tomitribe.com
> > >
> > >
> > > On Fri, Jan 4, 2019 at 7:28 AM Gurkan Erdogdu <cg...@gmail.com>
> > wrote:
> > >
> > > > Thanks Jon.
> > > >
> > > > I don't have any aim to replace service-jar.xml approach. We will
> just
> > > add
> > > > another YAML based configuration support. Therefore, all tomee.xml,
> > > > resources.xml etc will be stay in there. YAML is just an additional
> > > > feature.
> > > >
> > > > Introducing new module , tomee-config, allow us to centralise all
> > > > configuration into one place and all other modules can use it via
> > > > dependency. In the future, we can remove all configuration codes from
> > > > openejb-core, etc. into this module. There are lots of system
> > properties
> > > > using in different modules, therefore each such module will add their
> > > > properties into TomEESystemConfig class and then use it.
> > > >
> > > > Currently, openejb-core is a one large module. We may also think to
> > > divide
> > > > this module into smaller modules which are having special purpose.
> > > >
> > > > Hope it clears your concerns.
> > > >
> > > > Regards.
> > > > Gurkan
> > > >
> > > > On Thu, Jan 3, 2019 at 11:30 PM Jonathan Gallimore <
> > > > jonathan.gallimore@gmail.com> wrote:
> > > >
> > > > > I commented on your PR - thanks for sending that over. I think it
> > would
> > > > be
> > > > > worthwhile structuring the class with the constants in such a way
> > that
> > > > the
> > > > > javadoc could end up on the website via David's site generation
> code.
> > > > That
> > > > > would be extremely cool and I'm sure a very useful piece of
> > > > documentation.
> > > > >
> > > > > While I appreciate your service-jar.xml visibility comment, I
> suspect
> > > > that
> > > > > is because of something missing in its documentation, as opposed to
> > an
> > > > > issue with the design choice. I don't necessarily object to
> something
> > > > that
> > > > > can parse the config in YAML (I believe there is something that
> > handles
> > > > > JSON already), providing the existing config mechanism in XML, with
> > the
> > > > > defaults in service-jar.xml continued to work, and that I wouldn't
> be
> > > > > forced to migrate from XML to YAML. Many users make use of
> tomee.xml
> > > and
> > > > > resources.xml in a huge number of applications. Forcing a migration
> > on
> > > > them
> > > > > to YAML "just because" doesn't make sense to me. The concept of the
> > > > > service-jar.xml is a very core design concept in TomEE and I would
> > not
> > > be
> > > > > favour of changing it unless there was a really good rationale and
> a
> > > > better
> > > > > design proposed and discussed.
> > > > >
> > > > > I agree that system properties can lead to "magic" parameters that
> > > aren't
> > > > > well documented, and I'm definitely in favour of improving the
> > > > > documentation of those properties. The ability to override config
> > with
> > > > > system properties, however, is useful and also widely used so we'll
> > > need
> > > > to
> > > > > keep it.
> > > > >
> > > > > Jon
> > > > >
> > > > > On Wed, Jan 2, 2019 at 9:53 AM Gurkan Erdogdu <cgerdogdu@gmail.com
> >
> > > > wrote:
> > > > >
> > > > > > For me, using services-jar.xml approach is not so visible to
> users.
> > > All
> > > > > > defaults are configured in this file and packaged within JAR
> file.
> > > > Users
> > > > > > are not able to read the parameter explanation from
> > services-jar.xml
> > > > > files.
> > > > > > Also, services.-jar.xml is somebit different from using the
> system
> > > > > > properties to turn-on/off something. I am also thinking to
> > introduce
> > > > YAML
> > > > > > based configuration.
> > > > > >
> > > > > > But first step is to centralise all of these system parameters
> into
> > > two
> > > > > > classes. Maybe, we will see that some of them are unnecessary
> etc.
> > > > > >
> > > > > > On Wed, Jan 2, 2019 at 12:44 PM Bruno Baptista <
> brunobat@gmail.com
> > >
> > > > > wrote:
> > > > > >
> > > > > > > Yes, there is.
> > > > > > >
> > > > > > > This is also the most basic MP spec and nothing prevents us
> from
> > > > using
> > > > > > > it everywhere.
> > > > > > >
> > > > > > > There might be Jakarta EE restrictions in how to handle
> > > > configurations
> > > > > > > that need to be assessed.
> > > > > > >
> > > > > > > Overall, I think that if we are going to mess with configs, we
> > > should
> > > > > > > use state of the art.
> > > > > > >
> > > > > > > Cheers
> > > > > > >
> > > > > > > Bruno Baptista
> > > > > > > https://twitter.com/brunobat_
> > > > > > >
> > > > > > >
> > > > > > > On 02/01/19 09:35, Jean-Louis Monteiro wrote:
> > > > > > > > I think with microprofile-config we may have a chicken and
> the
> > > egg
> > > > > > > problem,
> > > > > > > > isn't it?
> > > > > > > > --
> > > > > > > > Jean-Louis Monteiro
> > > > > > > > http://twitter.com/jlouismonteiro
> > > > > > > > http://www.tomitribe.com
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Jan 2, 2019 at 10:30 AM Bruno Baptista <
> > > brunobat@gmail.com
> > > > >
> > > > > > > wrote:
> > > > > > > >
> > > > > > > >> Hi Gurkan,
> > > > > > > >>
> > > > > > > >> I agree we have a problem with the documentation of the
> > > different
> > > > > > > >> properties and that we need to improve it.
> > > > > > > >>
> > > > > > > >> Doing the inventory and using the proposed syntax looks ok
> to
> > me
> > > > > but I
> > > > > > > >> also think we should go even further.
> > > > > > > >>
> > > > > > > >> How about to migrate all the properties to use
> > > > microprofile-config?
> > > > > > > >>
> > > > > > > >> Cheers.
> > > > > > > >>
> > > > > > > >> Bruno Baptista
> > > > > > > >> https://twitter.com/brunobat_
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> On 02/01/19 07:20, Gurkan Erdogdu wrote:
> > > > > > > >>> Hello
> > > > > > > >>> There are lots of known and unknown system properties in
> the
> > > > > current
> > > > > > > code
> > > > > > > >>> base. I would like to introduce TomEESystemProperties and
> > > > > > > >>> OpenEJBSystemProperties classes to hold these system
> property
> > > > > > constants
> > > > > > > >> and
> > > > > > > >>> provide clear comment what it does. For example:
> > > > > > > >>>
> > > > > > > >>> class TomEESystemProperties{
> > > > > > > >>> public static final String TOMEE_FORCE_RELOADABLE =
> > > > > > > >>> "tomee.force-reloadable";
> > > > > > > >>> ....
> > > > > > > >>> }
> > > > > > > >>>
> > > > > > > >>> class OpenEJBSystemProperties{
> > > > > > > >>> public static final String
> > OPENEJB_CROSSCONTEXT_PROPERTY =
> > > > > > > >>> "openejb.crosscontext";
> > > > > > > >>> ....
> > > > > > > >>> }
> > > > > > > >>>
> > > > > > > >>> WDYT?
> > > > > > > >>> Regards.
> > > > > > > >>> Gurkan
> > > > > > > >>>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSS] Regarding TomEE and OpenEJB related system properties
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
Yes I agree and take it as you describe so it's all good. It's definitely a
step forward
Le lun. 7 janv. 2019 à 12:21, Gurkan Erdogdu <cg...@gmail.com> a écrit :
> Hello Jean-Louis and team,
> I want to emphasize again that this PR will not change anything regarding
> system properties. Its sole aim is to centralize all literal system
> properties into its own module. Maybe, for the future, if needed, we can
> update this module to add more configuration related functions. Currently
> all literal constants are distributed around the codebase. Before adding
> any more property, we need to discuss it first in here. So, one can easily
> find the used property this way.
> Regards.
> Gurkan
>
> On Mon, Jan 7, 2019 at 1:30 PM Jean-Louis Monteiro <
> jlmonteiro@tomitribe.com>
> wrote:
>
> > Just want to make sure we don't forget System Properties were meant to be
> > used to override configuration and not to be the main configuration
> system
> > for TomEE.
> >
> > We can discuss it and decide to change our mind and TomEE, but as per
> now,
> > I'm not really keen to relying on system properties to configure TomEE.
> I'd
> > rather take the opportunity to yank some system properties when possible.
> >
> >
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> >
> > On Fri, Jan 4, 2019 at 7:28 AM Gurkan Erdogdu <cg...@gmail.com>
> wrote:
> >
> > > Thanks Jon.
> > >
> > > I don't have any aim to replace service-jar.xml approach. We will just
> > add
> > > another YAML based configuration support. Therefore, all tomee.xml,
> > > resources.xml etc will be stay in there. YAML is just an additional
> > > feature.
> > >
> > > Introducing new module , tomee-config, allow us to centralise all
> > > configuration into one place and all other modules can use it via
> > > dependency. In the future, we can remove all configuration codes from
> > > openejb-core, etc. into this module. There are lots of system
> properties
> > > using in different modules, therefore each such module will add their
> > > properties into TomEESystemConfig class and then use it.
> > >
> > > Currently, openejb-core is a one large module. We may also think to
> > divide
> > > this module into smaller modules which are having special purpose.
> > >
> > > Hope it clears your concerns.
> > >
> > > Regards.
> > > Gurkan
> > >
> > > On Thu, Jan 3, 2019 at 11:30 PM Jonathan Gallimore <
> > > jonathan.gallimore@gmail.com> wrote:
> > >
> > > > I commented on your PR - thanks for sending that over. I think it
> would
> > > be
> > > > worthwhile structuring the class with the constants in such a way
> that
> > > the
> > > > javadoc could end up on the website via David's site generation code.
> > > That
> > > > would be extremely cool and I'm sure a very useful piece of
> > > documentation.
> > > >
> > > > While I appreciate your service-jar.xml visibility comment, I suspect
> > > that
> > > > is because of something missing in its documentation, as opposed to
> an
> > > > issue with the design choice. I don't necessarily object to something
> > > that
> > > > can parse the config in YAML (I believe there is something that
> handles
> > > > JSON already), providing the existing config mechanism in XML, with
> the
> > > > defaults in service-jar.xml continued to work, and that I wouldn't be
> > > > forced to migrate from XML to YAML. Many users make use of tomee.xml
> > and
> > > > resources.xml in a huge number of applications. Forcing a migration
> on
> > > them
> > > > to YAML "just because" doesn't make sense to me. The concept of the
> > > > service-jar.xml is a very core design concept in TomEE and I would
> not
> > be
> > > > favour of changing it unless there was a really good rationale and a
> > > better
> > > > design proposed and discussed.
> > > >
> > > > I agree that system properties can lead to "magic" parameters that
> > aren't
> > > > well documented, and I'm definitely in favour of improving the
> > > > documentation of those properties. The ability to override config
> with
> > > > system properties, however, is useful and also widely used so we'll
> > need
> > > to
> > > > keep it.
> > > >
> > > > Jon
> > > >
> > > > On Wed, Jan 2, 2019 at 9:53 AM Gurkan Erdogdu <cg...@gmail.com>
> > > wrote:
> > > >
> > > > > For me, using services-jar.xml approach is not so visible to users.
> > All
> > > > > defaults are configured in this file and packaged within JAR file.
> > > Users
> > > > > are not able to read the parameter explanation from
> services-jar.xml
> > > > files.
> > > > > Also, services.-jar.xml is somebit different from using the system
> > > > > properties to turn-on/off something. I am also thinking to
> introduce
> > > YAML
> > > > > based configuration.
> > > > >
> > > > > But first step is to centralise all of these system parameters into
> > two
> > > > > classes. Maybe, we will see that some of them are unnecessary etc.
> > > > >
> > > > > On Wed, Jan 2, 2019 at 12:44 PM Bruno Baptista <brunobat@gmail.com
> >
> > > > wrote:
> > > > >
> > > > > > Yes, there is.
> > > > > >
> > > > > > This is also the most basic MP spec and nothing prevents us from
> > > using
> > > > > > it everywhere.
> > > > > >
> > > > > > There might be Jakarta EE restrictions in how to handle
> > > configurations
> > > > > > that need to be assessed.
> > > > > >
> > > > > > Overall, I think that if we are going to mess with configs, we
> > should
> > > > > > use state of the art.
> > > > > >
> > > > > > Cheers
> > > > > >
> > > > > > Bruno Baptista
> > > > > > https://twitter.com/brunobat_
> > > > > >
> > > > > >
> > > > > > On 02/01/19 09:35, Jean-Louis Monteiro wrote:
> > > > > > > I think with microprofile-config we may have a chicken and the
> > egg
> > > > > > problem,
> > > > > > > isn't it?
> > > > > > > --
> > > > > > > Jean-Louis Monteiro
> > > > > > > http://twitter.com/jlouismonteiro
> > > > > > > http://www.tomitribe.com
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Jan 2, 2019 at 10:30 AM Bruno Baptista <
> > brunobat@gmail.com
> > > >
> > > > > > wrote:
> > > > > > >
> > > > > > >> Hi Gurkan,
> > > > > > >>
> > > > > > >> I agree we have a problem with the documentation of the
> > different
> > > > > > >> properties and that we need to improve it.
> > > > > > >>
> > > > > > >> Doing the inventory and using the proposed syntax looks ok to
> me
> > > > but I
> > > > > > >> also think we should go even further.
> > > > > > >>
> > > > > > >> How about to migrate all the properties to use
> > > microprofile-config?
> > > > > > >>
> > > > > > >> Cheers.
> > > > > > >>
> > > > > > >> Bruno Baptista
> > > > > > >> https://twitter.com/brunobat_
> > > > > > >>
> > > > > > >>
> > > > > > >> On 02/01/19 07:20, Gurkan Erdogdu wrote:
> > > > > > >>> Hello
> > > > > > >>> There are lots of known and unknown system properties in the
> > > > current
> > > > > > code
> > > > > > >>> base. I would like to introduce TomEESystemProperties and
> > > > > > >>> OpenEJBSystemProperties classes to hold these system property
> > > > > constants
> > > > > > >> and
> > > > > > >>> provide clear comment what it does. For example:
> > > > > > >>>
> > > > > > >>> class TomEESystemProperties{
> > > > > > >>> public static final String TOMEE_FORCE_RELOADABLE =
> > > > > > >>> "tomee.force-reloadable";
> > > > > > >>> ....
> > > > > > >>> }
> > > > > > >>>
> > > > > > >>> class OpenEJBSystemProperties{
> > > > > > >>> public static final String
> OPENEJB_CROSSCONTEXT_PROPERTY =
> > > > > > >>> "openejb.crosscontext";
> > > > > > >>> ....
> > > > > > >>> }
> > > > > > >>>
> > > > > > >>> WDYT?
> > > > > > >>> Regards.
> > > > > > >>> Gurkan
> > > > > > >>>
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSS] Regarding TomEE and OpenEJB related system properties
Posted by Gurkan Erdogdu <cg...@gmail.com>.
Hello Jean-Louis and team,
I want to emphasize again that this PR will not change anything regarding
system properties. Its sole aim is to centralize all literal system
properties into its own module. Maybe, for the future, if needed, we can
update this module to add more configuration related functions. Currently
all literal constants are distributed around the codebase. Before adding
any more property, we need to discuss it first in here. So, one can easily
find the used property this way.
Regards.
Gurkan
On Mon, Jan 7, 2019 at 1:30 PM Jean-Louis Monteiro <jl...@tomitribe.com>
wrote:
> Just want to make sure we don't forget System Properties were meant to be
> used to override configuration and not to be the main configuration system
> for TomEE.
>
> We can discuss it and decide to change our mind and TomEE, but as per now,
> I'm not really keen to relying on system properties to configure TomEE. I'd
> rather take the opportunity to yank some system properties when possible.
>
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Fri, Jan 4, 2019 at 7:28 AM Gurkan Erdogdu <cg...@gmail.com> wrote:
>
> > Thanks Jon.
> >
> > I don't have any aim to replace service-jar.xml approach. We will just
> add
> > another YAML based configuration support. Therefore, all tomee.xml,
> > resources.xml etc will be stay in there. YAML is just an additional
> > feature.
> >
> > Introducing new module , tomee-config, allow us to centralise all
> > configuration into one place and all other modules can use it via
> > dependency. In the future, we can remove all configuration codes from
> > openejb-core, etc. into this module. There are lots of system properties
> > using in different modules, therefore each such module will add their
> > properties into TomEESystemConfig class and then use it.
> >
> > Currently, openejb-core is a one large module. We may also think to
> divide
> > this module into smaller modules which are having special purpose.
> >
> > Hope it clears your concerns.
> >
> > Regards.
> > Gurkan
> >
> > On Thu, Jan 3, 2019 at 11:30 PM Jonathan Gallimore <
> > jonathan.gallimore@gmail.com> wrote:
> >
> > > I commented on your PR - thanks for sending that over. I think it would
> > be
> > > worthwhile structuring the class with the constants in such a way that
> > the
> > > javadoc could end up on the website via David's site generation code.
> > That
> > > would be extremely cool and I'm sure a very useful piece of
> > documentation.
> > >
> > > While I appreciate your service-jar.xml visibility comment, I suspect
> > that
> > > is because of something missing in its documentation, as opposed to an
> > > issue with the design choice. I don't necessarily object to something
> > that
> > > can parse the config in YAML (I believe there is something that handles
> > > JSON already), providing the existing config mechanism in XML, with the
> > > defaults in service-jar.xml continued to work, and that I wouldn't be
> > > forced to migrate from XML to YAML. Many users make use of tomee.xml
> and
> > > resources.xml in a huge number of applications. Forcing a migration on
> > them
> > > to YAML "just because" doesn't make sense to me. The concept of the
> > > service-jar.xml is a very core design concept in TomEE and I would not
> be
> > > favour of changing it unless there was a really good rationale and a
> > better
> > > design proposed and discussed.
> > >
> > > I agree that system properties can lead to "magic" parameters that
> aren't
> > > well documented, and I'm definitely in favour of improving the
> > > documentation of those properties. The ability to override config with
> > > system properties, however, is useful and also widely used so we'll
> need
> > to
> > > keep it.
> > >
> > > Jon
> > >
> > > On Wed, Jan 2, 2019 at 9:53 AM Gurkan Erdogdu <cg...@gmail.com>
> > wrote:
> > >
> > > > For me, using services-jar.xml approach is not so visible to users.
> All
> > > > defaults are configured in this file and packaged within JAR file.
> > Users
> > > > are not able to read the parameter explanation from services-jar.xml
> > > files.
> > > > Also, services.-jar.xml is somebit different from using the system
> > > > properties to turn-on/off something. I am also thinking to introduce
> > YAML
> > > > based configuration.
> > > >
> > > > But first step is to centralise all of these system parameters into
> two
> > > > classes. Maybe, we will see that some of them are unnecessary etc.
> > > >
> > > > On Wed, Jan 2, 2019 at 12:44 PM Bruno Baptista <br...@gmail.com>
> > > wrote:
> > > >
> > > > > Yes, there is.
> > > > >
> > > > > This is also the most basic MP spec and nothing prevents us from
> > using
> > > > > it everywhere.
> > > > >
> > > > > There might be Jakarta EE restrictions in how to handle
> > configurations
> > > > > that need to be assessed.
> > > > >
> > > > > Overall, I think that if we are going to mess with configs, we
> should
> > > > > use state of the art.
> > > > >
> > > > > Cheers
> > > > >
> > > > > Bruno Baptista
> > > > > https://twitter.com/brunobat_
> > > > >
> > > > >
> > > > > On 02/01/19 09:35, Jean-Louis Monteiro wrote:
> > > > > > I think with microprofile-config we may have a chicken and the
> egg
> > > > > problem,
> > > > > > isn't it?
> > > > > > --
> > > > > > Jean-Louis Monteiro
> > > > > > http://twitter.com/jlouismonteiro
> > > > > > http://www.tomitribe.com
> > > > > >
> > > > > >
> > > > > > On Wed, Jan 2, 2019 at 10:30 AM Bruno Baptista <
> brunobat@gmail.com
> > >
> > > > > wrote:
> > > > > >
> > > > > >> Hi Gurkan,
> > > > > >>
> > > > > >> I agree we have a problem with the documentation of the
> different
> > > > > >> properties and that we need to improve it.
> > > > > >>
> > > > > >> Doing the inventory and using the proposed syntax looks ok to me
> > > but I
> > > > > >> also think we should go even further.
> > > > > >>
> > > > > >> How about to migrate all the properties to use
> > microprofile-config?
> > > > > >>
> > > > > >> Cheers.
> > > > > >>
> > > > > >> Bruno Baptista
> > > > > >> https://twitter.com/brunobat_
> > > > > >>
> > > > > >>
> > > > > >> On 02/01/19 07:20, Gurkan Erdogdu wrote:
> > > > > >>> Hello
> > > > > >>> There are lots of known and unknown system properties in the
> > > current
> > > > > code
> > > > > >>> base. I would like to introduce TomEESystemProperties and
> > > > > >>> OpenEJBSystemProperties classes to hold these system property
> > > > constants
> > > > > >> and
> > > > > >>> provide clear comment what it does. For example:
> > > > > >>>
> > > > > >>> class TomEESystemProperties{
> > > > > >>> public static final String TOMEE_FORCE_RELOADABLE =
> > > > > >>> "tomee.force-reloadable";
> > > > > >>> ....
> > > > > >>> }
> > > > > >>>
> > > > > >>> class OpenEJBSystemProperties{
> > > > > >>> public static final String OPENEJB_CROSSCONTEXT_PROPERTY =
> > > > > >>> "openejb.crosscontext";
> > > > > >>> ....
> > > > > >>> }
> > > > > >>>
> > > > > >>> WDYT?
> > > > > >>> Regards.
> > > > > >>> Gurkan
> > > > > >>>
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSS] Regarding TomEE and OpenEJB related system properties
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
Just want to make sure we don't forget System Properties were meant to be
used to override configuration and not to be the main configuration system
for TomEE.
We can discuss it and decide to change our mind and TomEE, but as per now,
I'm not really keen to relying on system properties to configure TomEE. I'd
rather take the opportunity to yank some system properties when possible.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Fri, Jan 4, 2019 at 7:28 AM Gurkan Erdogdu <cg...@gmail.com> wrote:
> Thanks Jon.
>
> I don't have any aim to replace service-jar.xml approach. We will just add
> another YAML based configuration support. Therefore, all tomee.xml,
> resources.xml etc will be stay in there. YAML is just an additional
> feature.
>
> Introducing new module , tomee-config, allow us to centralise all
> configuration into one place and all other modules can use it via
> dependency. In the future, we can remove all configuration codes from
> openejb-core, etc. into this module. There are lots of system properties
> using in different modules, therefore each such module will add their
> properties into TomEESystemConfig class and then use it.
>
> Currently, openejb-core is a one large module. We may also think to divide
> this module into smaller modules which are having special purpose.
>
> Hope it clears your concerns.
>
> Regards.
> Gurkan
>
> On Thu, Jan 3, 2019 at 11:30 PM Jonathan Gallimore <
> jonathan.gallimore@gmail.com> wrote:
>
> > I commented on your PR - thanks for sending that over. I think it would
> be
> > worthwhile structuring the class with the constants in such a way that
> the
> > javadoc could end up on the website via David's site generation code.
> That
> > would be extremely cool and I'm sure a very useful piece of
> documentation.
> >
> > While I appreciate your service-jar.xml visibility comment, I suspect
> that
> > is because of something missing in its documentation, as opposed to an
> > issue with the design choice. I don't necessarily object to something
> that
> > can parse the config in YAML (I believe there is something that handles
> > JSON already), providing the existing config mechanism in XML, with the
> > defaults in service-jar.xml continued to work, and that I wouldn't be
> > forced to migrate from XML to YAML. Many users make use of tomee.xml and
> > resources.xml in a huge number of applications. Forcing a migration on
> them
> > to YAML "just because" doesn't make sense to me. The concept of the
> > service-jar.xml is a very core design concept in TomEE and I would not be
> > favour of changing it unless there was a really good rationale and a
> better
> > design proposed and discussed.
> >
> > I agree that system properties can lead to "magic" parameters that aren't
> > well documented, and I'm definitely in favour of improving the
> > documentation of those properties. The ability to override config with
> > system properties, however, is useful and also widely used so we'll need
> to
> > keep it.
> >
> > Jon
> >
> > On Wed, Jan 2, 2019 at 9:53 AM Gurkan Erdogdu <cg...@gmail.com>
> wrote:
> >
> > > For me, using services-jar.xml approach is not so visible to users. All
> > > defaults are configured in this file and packaged within JAR file.
> Users
> > > are not able to read the parameter explanation from services-jar.xml
> > files.
> > > Also, services.-jar.xml is somebit different from using the system
> > > properties to turn-on/off something. I am also thinking to introduce
> YAML
> > > based configuration.
> > >
> > > But first step is to centralise all of these system parameters into two
> > > classes. Maybe, we will see that some of them are unnecessary etc.
> > >
> > > On Wed, Jan 2, 2019 at 12:44 PM Bruno Baptista <br...@gmail.com>
> > wrote:
> > >
> > > > Yes, there is.
> > > >
> > > > This is also the most basic MP spec and nothing prevents us from
> using
> > > > it everywhere.
> > > >
> > > > There might be Jakarta EE restrictions in how to handle
> configurations
> > > > that need to be assessed.
> > > >
> > > > Overall, I think that if we are going to mess with configs, we should
> > > > use state of the art.
> > > >
> > > > Cheers
> > > >
> > > > Bruno Baptista
> > > > https://twitter.com/brunobat_
> > > >
> > > >
> > > > On 02/01/19 09:35, Jean-Louis Monteiro wrote:
> > > > > I think with microprofile-config we may have a chicken and the egg
> > > > problem,
> > > > > isn't it?
> > > > > --
> > > > > Jean-Louis Monteiro
> > > > > http://twitter.com/jlouismonteiro
> > > > > http://www.tomitribe.com
> > > > >
> > > > >
> > > > > On Wed, Jan 2, 2019 at 10:30 AM Bruno Baptista <brunobat@gmail.com
> >
> > > > wrote:
> > > > >
> > > > >> Hi Gurkan,
> > > > >>
> > > > >> I agree we have a problem with the documentation of the different
> > > > >> properties and that we need to improve it.
> > > > >>
> > > > >> Doing the inventory and using the proposed syntax looks ok to me
> > but I
> > > > >> also think we should go even further.
> > > > >>
> > > > >> How about to migrate all the properties to use
> microprofile-config?
> > > > >>
> > > > >> Cheers.
> > > > >>
> > > > >> Bruno Baptista
> > > > >> https://twitter.com/brunobat_
> > > > >>
> > > > >>
> > > > >> On 02/01/19 07:20, Gurkan Erdogdu wrote:
> > > > >>> Hello
> > > > >>> There are lots of known and unknown system properties in the
> > current
> > > > code
> > > > >>> base. I would like to introduce TomEESystemProperties and
> > > > >>> OpenEJBSystemProperties classes to hold these system property
> > > constants
> > > > >> and
> > > > >>> provide clear comment what it does. For example:
> > > > >>>
> > > > >>> class TomEESystemProperties{
> > > > >>> public static final String TOMEE_FORCE_RELOADABLE =
> > > > >>> "tomee.force-reloadable";
> > > > >>> ....
> > > > >>> }
> > > > >>>
> > > > >>> class OpenEJBSystemProperties{
> > > > >>> public static final String OPENEJB_CROSSCONTEXT_PROPERTY =
> > > > >>> "openejb.crosscontext";
> > > > >>> ....
> > > > >>> }
> > > > >>>
> > > > >>> WDYT?
> > > > >>> Regards.
> > > > >>> Gurkan
> > > > >>>
> > > >
> > >
> >
>
Re: [DISCUSS] Regarding TomEE and OpenEJB related system properties
Posted by Gurkan Erdogdu <cg...@gmail.com>.
Thank you Jon!
On Fri, Jan 4, 2019 at 5:35 PM Jonathan Gallimore <
jonathan.gallimore@gmail.com> wrote:
> Thanks for the explanation, I appreciate it. As long as there's no
> objections I'll merge the PR in.
>
> Jon
>
> On Fri, Jan 4, 2019 at 6:28 AM Gurkan Erdogdu <cg...@gmail.com> wrote:
>
> > Thanks Jon.
> >
> > I don't have any aim to replace service-jar.xml approach. We will just
> add
> > another YAML based configuration support. Therefore, all tomee.xml,
> > resources.xml etc will be stay in there. YAML is just an additional
> > feature.
> >
> > Introducing new module , tomee-config, allow us to centralise all
> > configuration into one place and all other modules can use it via
> > dependency. In the future, we can remove all configuration codes from
> > openejb-core, etc. into this module. There are lots of system properties
> > using in different modules, therefore each such module will add their
> > properties into TomEESystemConfig class and then use it.
> >
> > Currently, openejb-core is a one large module. We may also think to
> divide
> > this module into smaller modules which are having special purpose.
> >
> > Hope it clears your concerns.
> >
> > Regards.
> > Gurkan
> >
> > On Thu, Jan 3, 2019 at 11:30 PM Jonathan Gallimore <
> > jonathan.gallimore@gmail.com> wrote:
> >
> > > I commented on your PR - thanks for sending that over. I think it would
> > be
> > > worthwhile structuring the class with the constants in such a way that
> > the
> > > javadoc could end up on the website via David's site generation code.
> > That
> > > would be extremely cool and I'm sure a very useful piece of
> > documentation.
> > >
> > > While I appreciate your service-jar.xml visibility comment, I suspect
> > that
> > > is because of something missing in its documentation, as opposed to an
> > > issue with the design choice. I don't necessarily object to something
> > that
> > > can parse the config in YAML (I believe there is something that handles
> > > JSON already), providing the existing config mechanism in XML, with the
> > > defaults in service-jar.xml continued to work, and that I wouldn't be
> > > forced to migrate from XML to YAML. Many users make use of tomee.xml
> and
> > > resources.xml in a huge number of applications. Forcing a migration on
> > them
> > > to YAML "just because" doesn't make sense to me. The concept of the
> > > service-jar.xml is a very core design concept in TomEE and I would not
> be
> > > favour of changing it unless there was a really good rationale and a
> > better
> > > design proposed and discussed.
> > >
> > > I agree that system properties can lead to "magic" parameters that
> aren't
> > > well documented, and I'm definitely in favour of improving the
> > > documentation of those properties. The ability to override config with
> > > system properties, however, is useful and also widely used so we'll
> need
> > to
> > > keep it.
> > >
> > > Jon
> > >
> > > On Wed, Jan 2, 2019 at 9:53 AM Gurkan Erdogdu <cg...@gmail.com>
> > wrote:
> > >
> > > > For me, using services-jar.xml approach is not so visible to users.
> All
> > > > defaults are configured in this file and packaged within JAR file.
> > Users
> > > > are not able to read the parameter explanation from services-jar.xml
> > > files.
> > > > Also, services.-jar.xml is somebit different from using the system
> > > > properties to turn-on/off something. I am also thinking to introduce
> > YAML
> > > > based configuration.
> > > >
> > > > But first step is to centralise all of these system parameters into
> two
> > > > classes. Maybe, we will see that some of them are unnecessary etc.
> > > >
> > > > On Wed, Jan 2, 2019 at 12:44 PM Bruno Baptista <br...@gmail.com>
> > > wrote:
> > > >
> > > > > Yes, there is.
> > > > >
> > > > > This is also the most basic MP spec and nothing prevents us from
> > using
> > > > > it everywhere.
> > > > >
> > > > > There might be Jakarta EE restrictions in how to handle
> > configurations
> > > > > that need to be assessed.
> > > > >
> > > > > Overall, I think that if we are going to mess with configs, we
> should
> > > > > use state of the art.
> > > > >
> > > > > Cheers
> > > > >
> > > > > Bruno Baptista
> > > > > https://twitter.com/brunobat_
> > > > >
> > > > >
> > > > > On 02/01/19 09:35, Jean-Louis Monteiro wrote:
> > > > > > I think with microprofile-config we may have a chicken and the
> egg
> > > > > problem,
> > > > > > isn't it?
> > > > > > --
> > > > > > Jean-Louis Monteiro
> > > > > > http://twitter.com/jlouismonteiro
> > > > > > http://www.tomitribe.com
> > > > > >
> > > > > >
> > > > > > On Wed, Jan 2, 2019 at 10:30 AM Bruno Baptista <
> brunobat@gmail.com
> > >
> > > > > wrote:
> > > > > >
> > > > > >> Hi Gurkan,
> > > > > >>
> > > > > >> I agree we have a problem with the documentation of the
> different
> > > > > >> properties and that we need to improve it.
> > > > > >>
> > > > > >> Doing the inventory and using the proposed syntax looks ok to me
> > > but I
> > > > > >> also think we should go even further.
> > > > > >>
> > > > > >> How about to migrate all the properties to use
> > microprofile-config?
> > > > > >>
> > > > > >> Cheers.
> > > > > >>
> > > > > >> Bruno Baptista
> > > > > >> https://twitter.com/brunobat_
> > > > > >>
> > > > > >>
> > > > > >> On 02/01/19 07:20, Gurkan Erdogdu wrote:
> > > > > >>> Hello
> > > > > >>> There are lots of known and unknown system properties in the
> > > current
> > > > > code
> > > > > >>> base. I would like to introduce TomEESystemProperties and
> > > > > >>> OpenEJBSystemProperties classes to hold these system property
> > > > constants
> > > > > >> and
> > > > > >>> provide clear comment what it does. For example:
> > > > > >>>
> > > > > >>> class TomEESystemProperties{
> > > > > >>> public static final String TOMEE_FORCE_RELOADABLE =
> > > > > >>> "tomee.force-reloadable";
> > > > > >>> ....
> > > > > >>> }
> > > > > >>>
> > > > > >>> class OpenEJBSystemProperties{
> > > > > >>> public static final String OPENEJB_CROSSCONTEXT_PROPERTY =
> > > > > >>> "openejb.crosscontext";
> > > > > >>> ....
> > > > > >>> }
> > > > > >>>
> > > > > >>> WDYT?
> > > > > >>> Regards.
> > > > > >>> Gurkan
> > > > > >>>
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSS] Regarding TomEE and OpenEJB related system properties
Posted by Jonathan Gallimore <jo...@gmail.com>.
Thanks for the explanation, I appreciate it. As long as there's no
objections I'll merge the PR in.
Jon
On Fri, Jan 4, 2019 at 6:28 AM Gurkan Erdogdu <cg...@gmail.com> wrote:
> Thanks Jon.
>
> I don't have any aim to replace service-jar.xml approach. We will just add
> another YAML based configuration support. Therefore, all tomee.xml,
> resources.xml etc will be stay in there. YAML is just an additional
> feature.
>
> Introducing new module , tomee-config, allow us to centralise all
> configuration into one place and all other modules can use it via
> dependency. In the future, we can remove all configuration codes from
> openejb-core, etc. into this module. There are lots of system properties
> using in different modules, therefore each such module will add their
> properties into TomEESystemConfig class and then use it.
>
> Currently, openejb-core is a one large module. We may also think to divide
> this module into smaller modules which are having special purpose.
>
> Hope it clears your concerns.
>
> Regards.
> Gurkan
>
> On Thu, Jan 3, 2019 at 11:30 PM Jonathan Gallimore <
> jonathan.gallimore@gmail.com> wrote:
>
> > I commented on your PR - thanks for sending that over. I think it would
> be
> > worthwhile structuring the class with the constants in such a way that
> the
> > javadoc could end up on the website via David's site generation code.
> That
> > would be extremely cool and I'm sure a very useful piece of
> documentation.
> >
> > While I appreciate your service-jar.xml visibility comment, I suspect
> that
> > is because of something missing in its documentation, as opposed to an
> > issue with the design choice. I don't necessarily object to something
> that
> > can parse the config in YAML (I believe there is something that handles
> > JSON already), providing the existing config mechanism in XML, with the
> > defaults in service-jar.xml continued to work, and that I wouldn't be
> > forced to migrate from XML to YAML. Many users make use of tomee.xml and
> > resources.xml in a huge number of applications. Forcing a migration on
> them
> > to YAML "just because" doesn't make sense to me. The concept of the
> > service-jar.xml is a very core design concept in TomEE and I would not be
> > favour of changing it unless there was a really good rationale and a
> better
> > design proposed and discussed.
> >
> > I agree that system properties can lead to "magic" parameters that aren't
> > well documented, and I'm definitely in favour of improving the
> > documentation of those properties. The ability to override config with
> > system properties, however, is useful and also widely used so we'll need
> to
> > keep it.
> >
> > Jon
> >
> > On Wed, Jan 2, 2019 at 9:53 AM Gurkan Erdogdu <cg...@gmail.com>
> wrote:
> >
> > > For me, using services-jar.xml approach is not so visible to users. All
> > > defaults are configured in this file and packaged within JAR file.
> Users
> > > are not able to read the parameter explanation from services-jar.xml
> > files.
> > > Also, services.-jar.xml is somebit different from using the system
> > > properties to turn-on/off something. I am also thinking to introduce
> YAML
> > > based configuration.
> > >
> > > But first step is to centralise all of these system parameters into two
> > > classes. Maybe, we will see that some of them are unnecessary etc.
> > >
> > > On Wed, Jan 2, 2019 at 12:44 PM Bruno Baptista <br...@gmail.com>
> > wrote:
> > >
> > > > Yes, there is.
> > > >
> > > > This is also the most basic MP spec and nothing prevents us from
> using
> > > > it everywhere.
> > > >
> > > > There might be Jakarta EE restrictions in how to handle
> configurations
> > > > that need to be assessed.
> > > >
> > > > Overall, I think that if we are going to mess with configs, we should
> > > > use state of the art.
> > > >
> > > > Cheers
> > > >
> > > > Bruno Baptista
> > > > https://twitter.com/brunobat_
> > > >
> > > >
> > > > On 02/01/19 09:35, Jean-Louis Monteiro wrote:
> > > > > I think with microprofile-config we may have a chicken and the egg
> > > > problem,
> > > > > isn't it?
> > > > > --
> > > > > Jean-Louis Monteiro
> > > > > http://twitter.com/jlouismonteiro
> > > > > http://www.tomitribe.com
> > > > >
> > > > >
> > > > > On Wed, Jan 2, 2019 at 10:30 AM Bruno Baptista <brunobat@gmail.com
> >
> > > > wrote:
> > > > >
> > > > >> Hi Gurkan,
> > > > >>
> > > > >> I agree we have a problem with the documentation of the different
> > > > >> properties and that we need to improve it.
> > > > >>
> > > > >> Doing the inventory and using the proposed syntax looks ok to me
> > but I
> > > > >> also think we should go even further.
> > > > >>
> > > > >> How about to migrate all the properties to use
> microprofile-config?
> > > > >>
> > > > >> Cheers.
> > > > >>
> > > > >> Bruno Baptista
> > > > >> https://twitter.com/brunobat_
> > > > >>
> > > > >>
> > > > >> On 02/01/19 07:20, Gurkan Erdogdu wrote:
> > > > >>> Hello
> > > > >>> There are lots of known and unknown system properties in the
> > current
> > > > code
> > > > >>> base. I would like to introduce TomEESystemProperties and
> > > > >>> OpenEJBSystemProperties classes to hold these system property
> > > constants
> > > > >> and
> > > > >>> provide clear comment what it does. For example:
> > > > >>>
> > > > >>> class TomEESystemProperties{
> > > > >>> public static final String TOMEE_FORCE_RELOADABLE =
> > > > >>> "tomee.force-reloadable";
> > > > >>> ....
> > > > >>> }
> > > > >>>
> > > > >>> class OpenEJBSystemProperties{
> > > > >>> public static final String OPENEJB_CROSSCONTEXT_PROPERTY =
> > > > >>> "openejb.crosscontext";
> > > > >>> ....
> > > > >>> }
> > > > >>>
> > > > >>> WDYT?
> > > > >>> Regards.
> > > > >>> Gurkan
> > > > >>>
> > > >
> > >
> >
>
Re: [DISCUSS] Regarding TomEE and OpenEJB related system properties
Posted by Gurkan Erdogdu <cg...@gmail.com>.
Thanks Jon.
I don't have any aim to replace service-jar.xml approach. We will just add
another YAML based configuration support. Therefore, all tomee.xml,
resources.xml etc will be stay in there. YAML is just an additional
feature.
Introducing new module , tomee-config, allow us to centralise all
configuration into one place and all other modules can use it via
dependency. In the future, we can remove all configuration codes from
openejb-core, etc. into this module. There are lots of system properties
using in different modules, therefore each such module will add their
properties into TomEESystemConfig class and then use it.
Currently, openejb-core is a one large module. We may also think to divide
this module into smaller modules which are having special purpose.
Hope it clears your concerns.
Regards.
Gurkan
On Thu, Jan 3, 2019 at 11:30 PM Jonathan Gallimore <
jonathan.gallimore@gmail.com> wrote:
> I commented on your PR - thanks for sending that over. I think it would be
> worthwhile structuring the class with the constants in such a way that the
> javadoc could end up on the website via David's site generation code. That
> would be extremely cool and I'm sure a very useful piece of documentation.
>
> While I appreciate your service-jar.xml visibility comment, I suspect that
> is because of something missing in its documentation, as opposed to an
> issue with the design choice. I don't necessarily object to something that
> can parse the config in YAML (I believe there is something that handles
> JSON already), providing the existing config mechanism in XML, with the
> defaults in service-jar.xml continued to work, and that I wouldn't be
> forced to migrate from XML to YAML. Many users make use of tomee.xml and
> resources.xml in a huge number of applications. Forcing a migration on them
> to YAML "just because" doesn't make sense to me. The concept of the
> service-jar.xml is a very core design concept in TomEE and I would not be
> favour of changing it unless there was a really good rationale and a better
> design proposed and discussed.
>
> I agree that system properties can lead to "magic" parameters that aren't
> well documented, and I'm definitely in favour of improving the
> documentation of those properties. The ability to override config with
> system properties, however, is useful and also widely used so we'll need to
> keep it.
>
> Jon
>
> On Wed, Jan 2, 2019 at 9:53 AM Gurkan Erdogdu <cg...@gmail.com> wrote:
>
> > For me, using services-jar.xml approach is not so visible to users. All
> > defaults are configured in this file and packaged within JAR file. Users
> > are not able to read the parameter explanation from services-jar.xml
> files.
> > Also, services.-jar.xml is somebit different from using the system
> > properties to turn-on/off something. I am also thinking to introduce YAML
> > based configuration.
> >
> > But first step is to centralise all of these system parameters into two
> > classes. Maybe, we will see that some of them are unnecessary etc.
> >
> > On Wed, Jan 2, 2019 at 12:44 PM Bruno Baptista <br...@gmail.com>
> wrote:
> >
> > > Yes, there is.
> > >
> > > This is also the most basic MP spec and nothing prevents us from using
> > > it everywhere.
> > >
> > > There might be Jakarta EE restrictions in how to handle configurations
> > > that need to be assessed.
> > >
> > > Overall, I think that if we are going to mess with configs, we should
> > > use state of the art.
> > >
> > > Cheers
> > >
> > > Bruno Baptista
> > > https://twitter.com/brunobat_
> > >
> > >
> > > On 02/01/19 09:35, Jean-Louis Monteiro wrote:
> > > > I think with microprofile-config we may have a chicken and the egg
> > > problem,
> > > > isn't it?
> > > > --
> > > > Jean-Louis Monteiro
> > > > http://twitter.com/jlouismonteiro
> > > > http://www.tomitribe.com
> > > >
> > > >
> > > > On Wed, Jan 2, 2019 at 10:30 AM Bruno Baptista <br...@gmail.com>
> > > wrote:
> > > >
> > > >> Hi Gurkan,
> > > >>
> > > >> I agree we have a problem with the documentation of the different
> > > >> properties and that we need to improve it.
> > > >>
> > > >> Doing the inventory and using the proposed syntax looks ok to me
> but I
> > > >> also think we should go even further.
> > > >>
> > > >> How about to migrate all the properties to use microprofile-config?
> > > >>
> > > >> Cheers.
> > > >>
> > > >> Bruno Baptista
> > > >> https://twitter.com/brunobat_
> > > >>
> > > >>
> > > >> On 02/01/19 07:20, Gurkan Erdogdu wrote:
> > > >>> Hello
> > > >>> There are lots of known and unknown system properties in the
> current
> > > code
> > > >>> base. I would like to introduce TomEESystemProperties and
> > > >>> OpenEJBSystemProperties classes to hold these system property
> > constants
> > > >> and
> > > >>> provide clear comment what it does. For example:
> > > >>>
> > > >>> class TomEESystemProperties{
> > > >>> public static final String TOMEE_FORCE_RELOADABLE =
> > > >>> "tomee.force-reloadable";
> > > >>> ....
> > > >>> }
> > > >>>
> > > >>> class OpenEJBSystemProperties{
> > > >>> public static final String OPENEJB_CROSSCONTEXT_PROPERTY =
> > > >>> "openejb.crosscontext";
> > > >>> ....
> > > >>> }
> > > >>>
> > > >>> WDYT?
> > > >>> Regards.
> > > >>> Gurkan
> > > >>>
> > >
> >
>
Re: [DISCUSS] Regarding TomEE and OpenEJB related system properties
Posted by Jonathan Gallimore <jo...@gmail.com>.
I commented on your PR - thanks for sending that over. I think it would be
worthwhile structuring the class with the constants in such a way that the
javadoc could end up on the website via David's site generation code. That
would be extremely cool and I'm sure a very useful piece of documentation.
While I appreciate your service-jar.xml visibility comment, I suspect that
is because of something missing in its documentation, as opposed to an
issue with the design choice. I don't necessarily object to something that
can parse the config in YAML (I believe there is something that handles
JSON already), providing the existing config mechanism in XML, with the
defaults in service-jar.xml continued to work, and that I wouldn't be
forced to migrate from XML to YAML. Many users make use of tomee.xml and
resources.xml in a huge number of applications. Forcing a migration on them
to YAML "just because" doesn't make sense to me. The concept of the
service-jar.xml is a very core design concept in TomEE and I would not be
favour of changing it unless there was a really good rationale and a better
design proposed and discussed.
I agree that system properties can lead to "magic" parameters that aren't
well documented, and I'm definitely in favour of improving the
documentation of those properties. The ability to override config with
system properties, however, is useful and also widely used so we'll need to
keep it.
Jon
On Wed, Jan 2, 2019 at 9:53 AM Gurkan Erdogdu <cg...@gmail.com> wrote:
> For me, using services-jar.xml approach is not so visible to users. All
> defaults are configured in this file and packaged within JAR file. Users
> are not able to read the parameter explanation from services-jar.xml files.
> Also, services.-jar.xml is somebit different from using the system
> properties to turn-on/off something. I am also thinking to introduce YAML
> based configuration.
>
> But first step is to centralise all of these system parameters into two
> classes. Maybe, we will see that some of them are unnecessary etc.
>
> On Wed, Jan 2, 2019 at 12:44 PM Bruno Baptista <br...@gmail.com> wrote:
>
> > Yes, there is.
> >
> > This is also the most basic MP spec and nothing prevents us from using
> > it everywhere.
> >
> > There might be Jakarta EE restrictions in how to handle configurations
> > that need to be assessed.
> >
> > Overall, I think that if we are going to mess with configs, we should
> > use state of the art.
> >
> > Cheers
> >
> > Bruno Baptista
> > https://twitter.com/brunobat_
> >
> >
> > On 02/01/19 09:35, Jean-Louis Monteiro wrote:
> > > I think with microprofile-config we may have a chicken and the egg
> > problem,
> > > isn't it?
> > > --
> > > Jean-Louis Monteiro
> > > http://twitter.com/jlouismonteiro
> > > http://www.tomitribe.com
> > >
> > >
> > > On Wed, Jan 2, 2019 at 10:30 AM Bruno Baptista <br...@gmail.com>
> > wrote:
> > >
> > >> Hi Gurkan,
> > >>
> > >> I agree we have a problem with the documentation of the different
> > >> properties and that we need to improve it.
> > >>
> > >> Doing the inventory and using the proposed syntax looks ok to me but I
> > >> also think we should go even further.
> > >>
> > >> How about to migrate all the properties to use microprofile-config?
> > >>
> > >> Cheers.
> > >>
> > >> Bruno Baptista
> > >> https://twitter.com/brunobat_
> > >>
> > >>
> > >> On 02/01/19 07:20, Gurkan Erdogdu wrote:
> > >>> Hello
> > >>> There are lots of known and unknown system properties in the current
> > code
> > >>> base. I would like to introduce TomEESystemProperties and
> > >>> OpenEJBSystemProperties classes to hold these system property
> constants
> > >> and
> > >>> provide clear comment what it does. For example:
> > >>>
> > >>> class TomEESystemProperties{
> > >>> public static final String TOMEE_FORCE_RELOADABLE =
> > >>> "tomee.force-reloadable";
> > >>> ....
> > >>> }
> > >>>
> > >>> class OpenEJBSystemProperties{
> > >>> public static final String OPENEJB_CROSSCONTEXT_PROPERTY =
> > >>> "openejb.crosscontext";
> > >>> ....
> > >>> }
> > >>>
> > >>> WDYT?
> > >>> Regards.
> > >>> Gurkan
> > >>>
> >
>
Re: [DISCUSS] Regarding TomEE and OpenEJB related system properties
Posted by Gurkan Erdogdu <cg...@gmail.com>.
For me, using services-jar.xml approach is not so visible to users. All
defaults are configured in this file and packaged within JAR file. Users
are not able to read the parameter explanation from services-jar.xml files.
Also, services.-jar.xml is somebit different from using the system
properties to turn-on/off something. I am also thinking to introduce YAML
based configuration.
But first step is to centralise all of these system parameters into two
classes. Maybe, we will see that some of them are unnecessary etc.
On Wed, Jan 2, 2019 at 12:44 PM Bruno Baptista <br...@gmail.com> wrote:
> Yes, there is.
>
> This is also the most basic MP spec and nothing prevents us from using
> it everywhere.
>
> There might be Jakarta EE restrictions in how to handle configurations
> that need to be assessed.
>
> Overall, I think that if we are going to mess with configs, we should
> use state of the art.
>
> Cheers
>
> Bruno Baptista
> https://twitter.com/brunobat_
>
>
> On 02/01/19 09:35, Jean-Louis Monteiro wrote:
> > I think with microprofile-config we may have a chicken and the egg
> problem,
> > isn't it?
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> >
> > On Wed, Jan 2, 2019 at 10:30 AM Bruno Baptista <br...@gmail.com>
> wrote:
> >
> >> Hi Gurkan,
> >>
> >> I agree we have a problem with the documentation of the different
> >> properties and that we need to improve it.
> >>
> >> Doing the inventory and using the proposed syntax looks ok to me but I
> >> also think we should go even further.
> >>
> >> How about to migrate all the properties to use microprofile-config?
> >>
> >> Cheers.
> >>
> >> Bruno Baptista
> >> https://twitter.com/brunobat_
> >>
> >>
> >> On 02/01/19 07:20, Gurkan Erdogdu wrote:
> >>> Hello
> >>> There are lots of known and unknown system properties in the current
> code
> >>> base. I would like to introduce TomEESystemProperties and
> >>> OpenEJBSystemProperties classes to hold these system property constants
> >> and
> >>> provide clear comment what it does. For example:
> >>>
> >>> class TomEESystemProperties{
> >>> public static final String TOMEE_FORCE_RELOADABLE =
> >>> "tomee.force-reloadable";
> >>> ....
> >>> }
> >>>
> >>> class OpenEJBSystemProperties{
> >>> public static final String OPENEJB_CROSSCONTEXT_PROPERTY =
> >>> "openejb.crosscontext";
> >>> ....
> >>> }
> >>>
> >>> WDYT?
> >>> Regards.
> >>> Gurkan
> >>>
>
Re: [DISCUSS] Regarding TomEE and OpenEJB related system properties
Posted by Bruno Baptista <br...@gmail.com>.
Yes, there is.
This is also the most basic MP spec and nothing prevents us from using
it everywhere.
There might be Jakarta EE restrictions in how to handle configurations
that need to be assessed.
Overall, I think that if we are going to mess with configs, we should
use state of the art.
Cheers
Bruno Baptista
https://twitter.com/brunobat_
On 02/01/19 09:35, Jean-Louis Monteiro wrote:
> I think with microprofile-config we may have a chicken and the egg problem,
> isn't it?
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Wed, Jan 2, 2019 at 10:30 AM Bruno Baptista <br...@gmail.com> wrote:
>
>> Hi Gurkan,
>>
>> I agree we have a problem with the documentation of the different
>> properties and that we need to improve it.
>>
>> Doing the inventory and using the proposed syntax looks ok to me but I
>> also think we should go even further.
>>
>> How about to migrate all the properties to use microprofile-config?
>>
>> Cheers.
>>
>> Bruno Baptista
>> https://twitter.com/brunobat_
>>
>>
>> On 02/01/19 07:20, Gurkan Erdogdu wrote:
>>> Hello
>>> There are lots of known and unknown system properties in the current code
>>> base. I would like to introduce TomEESystemProperties and
>>> OpenEJBSystemProperties classes to hold these system property constants
>> and
>>> provide clear comment what it does. For example:
>>>
>>> class TomEESystemProperties{
>>> public static final String TOMEE_FORCE_RELOADABLE =
>>> "tomee.force-reloadable";
>>> ....
>>> }
>>>
>>> class OpenEJBSystemProperties{
>>> public static final String OPENEJB_CROSSCONTEXT_PROPERTY =
>>> "openejb.crosscontext";
>>> ....
>>> }
>>>
>>> WDYT?
>>> Regards.
>>> Gurkan
>>>
Re: [DISCUSS] Regarding TomEE and OpenEJB related system properties
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
I think with microprofile-config we may have a chicken and the egg problem,
isn't it?
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Wed, Jan 2, 2019 at 10:30 AM Bruno Baptista <br...@gmail.com> wrote:
> Hi Gurkan,
>
> I agree we have a problem with the documentation of the different
> properties and that we need to improve it.
>
> Doing the inventory and using the proposed syntax looks ok to me but I
> also think we should go even further.
>
> How about to migrate all the properties to use microprofile-config?
>
> Cheers.
>
> Bruno Baptista
> https://twitter.com/brunobat_
>
>
> On 02/01/19 07:20, Gurkan Erdogdu wrote:
> > Hello
> > There are lots of known and unknown system properties in the current code
> > base. I would like to introduce TomEESystemProperties and
> > OpenEJBSystemProperties classes to hold these system property constants
> and
> > provide clear comment what it does. For example:
> >
> > class TomEESystemProperties{
> > public static final String TOMEE_FORCE_RELOADABLE =
> > "tomee.force-reloadable";
> > ....
> > }
> >
> > class OpenEJBSystemProperties{
> > public static final String OPENEJB_CROSSCONTEXT_PROPERTY =
> > "openejb.crosscontext";
> > ....
> > }
> >
> > WDYT?
> > Regards.
> > Gurkan
> >
>
Re: [DISCUSS] Regarding TomEE and OpenEJB related system properties
Posted by Bruno Baptista <br...@gmail.com>.
Hi Gurkan,
I agree we have a problem with the documentation of the different
properties and that we need to improve it.
Doing the inventory and using the proposed syntax looks ok to me but I
also think we should go even further.
How about to migrate all the properties to use microprofile-config?
Cheers.
Bruno Baptista
https://twitter.com/brunobat_
On 02/01/19 07:20, Gurkan Erdogdu wrote:
> Hello
> There are lots of known and unknown system properties in the current code
> base. I would like to introduce TomEESystemProperties and
> OpenEJBSystemProperties classes to hold these system property constants and
> provide clear comment what it does. For example:
>
> class TomEESystemProperties{
> public static final String TOMEE_FORCE_RELOADABLE =
> "tomee.force-reloadable";
> ....
> }
>
> class OpenEJBSystemProperties{
> public static final String OPENEJB_CROSSCONTEXT_PROPERTY =
> "openejb.crosscontext";
> ....
> }
>
> WDYT?
> Regards.
> Gurkan
>
Re: [DISCUSS] Regarding TomEE and OpenEJB related system properties
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
Going with small steps is desired indeed.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Wed, Jan 2, 2019 at 10:39 AM Gurkan Erdogdu <cg...@gmail.com> wrote:
> Hi Bruno, Jean-Louis
>
> My initial attempt is to remove constant string literals from the codebase
> but only in these two classes. After this removal period, we can further
> update the architecture using microprofile config or any other way.
>
> So, there will be only 2 classes to hold:
>
> - TomEE specific properties
> - OpenEJB specific properties
>
> and replace all string literals with constants from these classes.
>
> If it is ok, I will introduce two new classes and all further configuration
> parameters will be defined in it.
>
> Regards.
> Gurkan
>
> On Wed, Jan 2, 2019 at 12:34 PM Jean-Louis Monteiro <
> jlmonteiro@tomitribe.com> wrote:
>
> > Hey Gurkan,
> >
> > I am ok to better document the system properties.
> >
> > Few comments though...
> >
> > - I probably dreamt it, but I think there is an object that tries to load
> > openejb.XXX and falls back to tomee.XXX if not found. Not sure if it's
> > there or not.
> >
> > - I think system properties have been abused over the year and that's the
> > reason why we are in the current situation.
> > They were meant to be used to override any configuration in the system.
> But
> > they are now used as a default configuration system which is bad in my
> > opinion. If we need configuration we should use a proper configuration
> > system. tomee.xml is very extensible and you can provide defaults for a
> > service using service-jar.xml
> > If it would have been done this way, system properties could have been
> used
> > to override the configuration as today, but they would have been more
> > consistent in terms of names. But also, the configuration would be
> clearly
> > documented in the services-jar.xml with proper defaults.
> >
> > I am not sure if that is too late to go this path and start deprecating
> old
> > system properties.
> >
> > Hope it helps
> > Jean-Louis
> >
> >
> >
> >
> >
> >
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> >
> > On Wed, Jan 2, 2019 at 8:21 AM Gurkan Erdogdu <cg...@gmail.com>
> wrote:
> >
> > > Hello
> > > There are lots of known and unknown system properties in the current
> code
> > > base. I would like to introduce TomEESystemProperties and
> > > OpenEJBSystemProperties classes to hold these system property constants
> > and
> > > provide clear comment what it does. For example:
> > >
> > > class TomEESystemProperties{
> > > public static final String TOMEE_FORCE_RELOADABLE =
> > > "tomee.force-reloadable";
> > > ....
> > > }
> > >
> > > class OpenEJBSystemProperties{
> > > public static final String OPENEJB_CROSSCONTEXT_PROPERTY =
> > > "openejb.crosscontext";
> > > ....
> > > }
> > >
> > > WDYT?
> > > Regards.
> > > Gurkan
> > >
> >
>
Re: [DISCUSS] Regarding TomEE and OpenEJB related system properties
Posted by Gurkan Erdogdu <cg...@gmail.com>.
Hi Bruno, Jean-Louis
My initial attempt is to remove constant string literals from the codebase
but only in these two classes. After this removal period, we can further
update the architecture using microprofile config or any other way.
So, there will be only 2 classes to hold:
- TomEE specific properties
- OpenEJB specific properties
and replace all string literals with constants from these classes.
If it is ok, I will introduce two new classes and all further configuration
parameters will be defined in it.
Regards.
Gurkan
On Wed, Jan 2, 2019 at 12:34 PM Jean-Louis Monteiro <
jlmonteiro@tomitribe.com> wrote:
> Hey Gurkan,
>
> I am ok to better document the system properties.
>
> Few comments though...
>
> - I probably dreamt it, but I think there is an object that tries to load
> openejb.XXX and falls back to tomee.XXX if not found. Not sure if it's
> there or not.
>
> - I think system properties have been abused over the year and that's the
> reason why we are in the current situation.
> They were meant to be used to override any configuration in the system. But
> they are now used as a default configuration system which is bad in my
> opinion. If we need configuration we should use a proper configuration
> system. tomee.xml is very extensible and you can provide defaults for a
> service using service-jar.xml
> If it would have been done this way, system properties could have been used
> to override the configuration as today, but they would have been more
> consistent in terms of names. But also, the configuration would be clearly
> documented in the services-jar.xml with proper defaults.
>
> I am not sure if that is too late to go this path and start deprecating old
> system properties.
>
> Hope it helps
> Jean-Louis
>
>
>
>
>
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Wed, Jan 2, 2019 at 8:21 AM Gurkan Erdogdu <cg...@gmail.com> wrote:
>
> > Hello
> > There are lots of known and unknown system properties in the current code
> > base. I would like to introduce TomEESystemProperties and
> > OpenEJBSystemProperties classes to hold these system property constants
> and
> > provide clear comment what it does. For example:
> >
> > class TomEESystemProperties{
> > public static final String TOMEE_FORCE_RELOADABLE =
> > "tomee.force-reloadable";
> > ....
> > }
> >
> > class OpenEJBSystemProperties{
> > public static final String OPENEJB_CROSSCONTEXT_PROPERTY =
> > "openejb.crosscontext";
> > ....
> > }
> >
> > WDYT?
> > Regards.
> > Gurkan
> >
>
Re: [DISCUSS] Regarding TomEE and OpenEJB related system properties
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
Hey Gurkan,
I am ok to better document the system properties.
Few comments though...
- I probably dreamt it, but I think there is an object that tries to load
openejb.XXX and falls back to tomee.XXX if not found. Not sure if it's
there or not.
- I think system properties have been abused over the year and that's the
reason why we are in the current situation.
They were meant to be used to override any configuration in the system. But
they are now used as a default configuration system which is bad in my
opinion. If we need configuration we should use a proper configuration
system. tomee.xml is very extensible and you can provide defaults for a
service using service-jar.xml
If it would have been done this way, system properties could have been used
to override the configuration as today, but they would have been more
consistent in terms of names. But also, the configuration would be clearly
documented in the services-jar.xml with proper defaults.
I am not sure if that is too late to go this path and start deprecating old
system properties.
Hope it helps
Jean-Louis
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Wed, Jan 2, 2019 at 8:21 AM Gurkan Erdogdu <cg...@gmail.com> wrote:
> Hello
> There are lots of known and unknown system properties in the current code
> base. I would like to introduce TomEESystemProperties and
> OpenEJBSystemProperties classes to hold these system property constants and
> provide clear comment what it does. For example:
>
> class TomEESystemProperties{
> public static final String TOMEE_FORCE_RELOADABLE =
> "tomee.force-reloadable";
> ....
> }
>
> class OpenEJBSystemProperties{
> public static final String OPENEJB_CROSSCONTEXT_PROPERTY =
> "openejb.crosscontext";
> ....
> }
>
> WDYT?
> Regards.
> Gurkan
>