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
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 a
> écrit
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 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 central
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 func
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 configur
Thank you Jon!
On Fri, Jan 4, 2019 at 5:35 PM Jonathan Gallimore <
jonathan.gallim...@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 wrote:
>
> > Thanks Jon.
> >
>
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 wrote:
> Thanks Jon.
>
> I don't have any aim to replace service-jar.xml approach. We will just add
> another YAML based configuration support. T
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
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.
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 provi
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
wrote:
> I think we sho
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 wrote:
>
> Sounds like a good plan. :)
>
> Bruno Baptista
> https://twitter.com/brunobat_ <
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
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
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.
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 wrote:
> Hi Bruno, Jean-Louis
>
> My initial attempt is to remove constant string literals from the codebase
> but only i
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 specif
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 wrote:
> Hi Gurkan,
>
> I agree we have a problem with the documentation of the
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 t
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-co
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{
pu
20 matches
Mail list logo
