Am 07.11.2018 um 01:13 schrieb Thibault Kruse:
Properties also support loadFromXml(), and I guess nobody wants to
suggest using .gxml as different extension?
While using specifc extensions for XML files carries the risk of the XML
schema information inside a file not matching the
To give everyone something they can agree on to hate ;-) : I use
.groperties (i.e. without the "p") for the homemade Groovy based
property files in our project. For me settings.groperties it is easier
to read than the (obvious) .gproperties choice, and has a groovy
memnonic quality...
Am
I agree with Daniil.
@xml: In that case OpenOffice and MS Office documents should just have
the extension .xml.zip since they are just zipped XML files.
While it is correct that one can discern the type of XML dialect used in
an XML file from its header, for many applications it is still
> The GProperties language is the same language or a subset of the
> Properties language
which doesn’t mean that same extension should be used, see example with
.java/.groovy.
> Even with standard Properties, users are free to add keys for
> interpolation to their values, or add SQL
> I propose to use "gproperties" as file extension.
'.properties' is the correct file extension for GProperties. There are
several reasons:
* The GProperties language is the same language or a subset of the
Properties language
* Even with standard Properties, users are free to add keys for
Hi Andres,
Because of the potential security issues, code execution is abandoned
now( SEE
https://github.com/apache/groovy/commit/1d20e307251aedde4f73abe879e2b548f2d16a17
).
The idea of GProperties is from a big project I developed, it's really
useful in that project, so I want to
What I gather from this discussion so far:
1. Use a custom file extension ".gproperties" instead of "properties".
2. Disable code execution by default.
3. Do not use a System property to disable code execution, rather use a
constructor argument (may be final) and/or getter/setter.
4. Do not add
+1 to using a different file extension for gproperties
Le mar. 6 nov. 2018 à 11:32, Daniil Ovchinnikov <
daniil.ovchinni...@jetbrains.com> a écrit :
> we can not replace Properties in existing groovy
> code easily because we have to change the file extension
>
>
> Exactly this.
>
> Also please
> we can not replace Properties in existing groovy
> code easily because we have to change the file extension
Exactly this.
Also please consider tooling. We already have support for .properties in
IntelliJ based on file extension.
If .properties would be used for GProperties, then user should
Hi Jochen,
Agreed.
To be frank, I wish I could use Guava in apache groovy project, but I
have never proposed to use it because of its big size ;)
Cheers,
Daniel.Sun
-
Daniel Sun
Apache Groovy committer
Blog: http://blog.sunlan.me
Twitter: @daniel_sun
--
Sent from:
> Gesendet: Sonntag, 04. November 2018 um 01:43 Uhr
> Von: "Thibault Kruse"
> An: dev@groovy.apache.org
> Betreff: Re: About the enhanced version of `Properties`, i.e. `GProperties`
[...]
> If not, that would leave importing and interpolation, but as I said
> there
"include" and "import" have different meaning, so "import" is better
according to current implementation.
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Hi Thibault,
I understandd what you meant. Just a few improvement was finished ;-)
P.S. Unbalanced curlies will not be considered, because curlies are
valid characters for the value of property.
Cheers,
Daniel.Sun
--
Sent from:
I have mentioned that the current PR code is vulnerable to infinite
cycles, unbalanced curlies, nested curlies in the value, and curlies
in the value from an interpolated property. I am not sure if you were
considering testing those cases. I would recommend you to extract a
method
Hi Thibault,
As quite a few people worry about the security issues, I have removed
evaluating script feature.
Here is the latest implementation with some essential groovydoc:
https://github.com/apache/groovy/blob/master/src/main/groovy/groovy/util/GProperties.groovy
And here
For reference, the YAML language was used for configuration in rails,
here is one article describing the consequences of a given security
flaw:
https://www.kalzumeus.com/2013/01/31/what-the-rails-security-issue-means-for-your-startup/
On Sun, Nov 4, 2018 at 1:22 PM Daniel.Sun wrote:
>
> Hi
Hi Thibault,
Thanks for reviewing the new minor feature for 3.0.0.
As 3.0.0 is alpha now, we can collect feedback from groovy users
and refine it all the time before 3.0.0 is released. I will consider your
suggestions carefully.
Actually groovy provides many re-invented wheels,
Actually, I don't really see the regex approach ever reaching maturity
for evaluation expressions. Just the simple property "foo=${'}'}" and
its variants are probably impossible to handle with regexes, (because
finding the the end of a groovy expression without a parser s hard).
An actual Parser
Just a quick 0.9... Euro cents:
1. Without having looked at the proposal in too much detail, I feel you
raise some valid points.
2. With regards to backwards compatibility, I feel we should not be too
worried, since afaiu the differing file extension should keep these
problems to a
Hi all,
thanks Daniel for making the suggestion and PR.
BTW there already is an extension in
http://commons.apache.org/proper/commons-configuration/userguide/howto_properties.html#Using_PropertiesConfiguration
including a syntax to include other properties files, to be considered
(though that
No. GProperties to Properties is similar with GString to String, GProperties
is much more powerful than Properties, so I recommend groovy users use
GProperties where Properties is used. If GProperties only process the file
with new file extension, we can not replace Properties in existing groovy
Did you consider using different file extension?
—
Daniil Ovchinnikov
JetBrains
> On 2 Nov 2018, at 18:39, Daniel.Sun wrote:
>
> I've added some doc to show the usage:
>
>
I've added some doc to show the usage:
https://github.com/apache/groovy/blob/3775edeabde19eb5229e840ec2ffc1dcf90634db/src/main/groovy/groovy/util/GProperties.groovy
Cheers,
Daniel.Sun
-
Daniel Sun
Apache Groovy committer
Blog: http://blog.sunlan.me
Twitter: @daniel_sun
--
Sent
Here are some tests to show its usage:
https://github.com/apache/groovy/blob/96e94cf80ca4fc8449231e2f92508bca516bce87/src/test/groovy/util/GPropertiesTest.groovy
and here are the relevant properties files:
1,
?
From: Daniel Sun
Sent: Thursday, November 1, 2018 10:05 PM
To: d...@groovy.incubator.apache.org
Subject: About the enhanced version of `Properties`, i.e. `GProperties`
Hi all,
I propose to implement an enhanced version of `Properties`, i.e.
`GProperties`, which can interpolate values
Hi all,
I propose to implement an enhanced version of `Properties`, i.e.
`GProperties`, which can interpolate values of properties and import other
properties in classpath.
Here is the PR: https://github.com/apache/groovy/pull/818
Any thoughts?
( Andres's opinion
26 matches
Mail list logo
