Java object conversion using ConfigSlurper

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Java object conversion using ConfigSlurper

adithyank
Team,

ConfigSlurper can be used to parse groovy-styled configurations and get them as ConfigObject. As an additional feature, either ConfigSlurper can be enhanced or a new class can be written to return java object itself from the configuration. Example below

config.groovy

myownconfig {
      name = 'Threadpool'
     displayLabel = "Thread Pool"
     threadCount = 12
}
----------------------------------------------

MyConfig.java

public class MyConfig
{
     String name;
     String displayLabel
     int threadCount
}
-----------------------------------------------
Usage:

MyConfig myConfig = new ConfigClassConver().object('myownconfig', MyConfig.class)
println myConfig.name
println ...
-----------------------------------------------


I have implemented this functionality for one of my project needs. If the team feels, it can be added groovy itself, then the discussion can proceed in what could be the class name, what features, etc.

What I have given is a sample only. There are couple of other features, like ConfigSlurper.merge(), parsing multiple files in one directory (optionally, recursive too), etc.

I feel this will be a good addition to groovy itself.

Pls comment

Regards,

K Adithyan
India
Reply | Threaded
Open this post in threaded view
|

Re: Java object conversion using ConfigSlurper

Daniel.Sun
I think it is useful especially for Java developers. PR is welcome.

P.S. it would be better if the Java class is a Java bean(with getters and
setters)

Cheers,
Daniel.Sun



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Reply | Threaded
Open this post in threaded view
|

Re: Java object conversion using ConfigSlurper

adithyank
Ok. Thanks Daniel.

I will proceed in the below way.

Pls advice

1. I will write new class `ConfigCustomObjectBuilder` in
   `ConfigSlurper.groovy` to convert given ConfigObject to custom class
instance

2. I will add below new method in ConfigObject

   T getAs(Class<T> dataStructure)
   {
       return ConfigCustomObjectBuilder.build(ConfigObject, Class<T>
dataStructure)
   }

3. So, the callers of the method can do the below steps

   a. ConfigObject co = new ConfigSlurper().parse(...)
   b. Do required co.merge(...)
   c. MyConfig mc = co.getAs(MyConfig)
   d. use mc further

4. Optionally, we can implement `asType(Class)` method in `ConfigObject`
class
   so that callers can use below syntax

   c. MyConfig mc = co as MyConfig

Regards,

K Adithyan
India
--




Daniel.Sun wrote
> I think it is useful especially for Java developers. PR is welcome.
>
> P.S. it would be better if the Java class is a Java bean(with getters and
> setters)





--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Reply | Threaded
Open this post in threaded view
|

Re: Java object conversion using ConfigSlurper

Daniel.Sun
I think it is nice for me :-)

Cheers,
Daniel.Sun



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Reply | Threaded
Open this post in threaded view
|

Re: Java object conversion using ConfigSlurper

Mario Garcia
Hi, good work :) 

It seems a nice feature, but I'm wondering why having two different methods doing the same ? asType and getAs. 
  • I think is always better to avoid having two methods doing the same, specially when asType can be called both directly or via sugar syntax. 
  • I also think the use case fits asType perfectly, as it's mentioned in its Groovydoc entry: "Converts a given object to a type" 
IMHO I would stick only to asType.

Mario

El mar., 15 may. 2018 a las 9:36, Daniel.Sun (<[hidden email]>) escribió:
I think it is nice for me :-)

Cheers,
Daniel.Sun



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Reply | Threaded
Open this post in threaded view
|

Re: Java object conversion using ConfigSlurper

adithyank
Hi Mario Garcia,

Groovy already has Map coercion feature with which the methods of any class
can be delegated to the closures in Map. This uses `as` keyword.

If we implement `asType(Class)` in `ConfigObject` (ConfigObject already
implements Map), some of the functionalities of existing coercion may be
affected. I am not sure !

If we implement 'getAs(Class)`, existing coercion will be unaffected. So, I
will prefer `getAs(Class)` first.

Note : Any ways, while testing, I will test these behaviors...

Pls advice



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Reply | Threaded
Open this post in threaded view
|

Re: Java object conversion using ConfigSlurper

Jesper Steen Møller
Hi Adithyank

On 16 May 2018, at 12.52, adithyank <[hidden email]> wrote:

Hi Mario Garcia,

Groovy already has Map coercion feature with which the methods of any class
can be delegated to the closures in Map. This uses `as` keyword.

If we implement `asType(Class)` in `ConfigObject` (ConfigObject already
implements Map), some of the functionalities of existing coercion may be
affected. I am not sure !

Using "as <classname>" already works, so there's already a pretty simple way to do what you're suggesting:

ConfigObject co = new ConfigSlurper().parse("""
myownconfig {
    name = 'Threadpool'
    displayLabel = "Thread Pool"
    threadCount = 12
}""")

public class MyConfig
{
     String name
     String displayLabel
     int threadCount
}

def myConfig = co.myownconfig as MyConfig

println "${myConfig.displayLabel} - ${myConfig.threadCount}"

(try it in Groovy Console)

-Jesper
MG
Reply | Threaded
Open this post in threaded view
|

Re: Java object conversion using ConfigSlurper

MG
In reply to this post by adithyank
I guess it boils down to whether the semantics/intention of getAs is different from asType or not (no Groovy magic expected ?...)

-------- Ursprüngliche Nachricht --------
Von: adithyank <[hidden email]>
Datum: 16.05.18 12:52 (GMT+01:00)
Betreff: Re: Java object conversion using ConfigSlurper

Hi Mario Garcia,

Groovy already has Map coercion feature with which the methods of any class
can be delegated to the closures in Map. This uses `as` keyword.

If we implement `asType(Class)` in `ConfigObject` (ConfigObject already
implements Map), some of the functionalities of existing coercion may be
affected. I am not sure !

If we implement 'getAs(Class)`, existing coercion will be unaffected. So, I
will prefer `getAs(Class)` first.

Note : Any ways, while testing, I will test these behaviors...

Pls advice



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
MG
Reply | Threaded
Open this post in threaded view
|

Re: Java object conversion using ConfigSlurper

MG
In reply to this post by adithyank
I guess it boils down to whether the semantics/intention of getAs is different from asType or not (no Groovy magic expected ?...)

-------- Ursprüngliche Nachricht --------
Von: adithyank <[hidden email]>
Datum: 16.05.18 12:52 (GMT+01:00)
Betreff: Re: Java object conversion using ConfigSlurper

Hi Mario Garcia,

Groovy already has Map coercion feature with which the methods of any class
can be delegated to the closures in Map. This uses `as` keyword.

If we implement `asType(Class)` in `ConfigObject` (ConfigObject already
implements Map), some of the functionalities of existing coercion may be
affected. I am not sure !

If we implement 'getAs(Class)`, existing coercion will be unaffected. So, I
will prefer `getAs(Class)` first.

Note : Any ways, while testing, I will test these behaviors...

Pls advice



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Reply | Threaded
Open this post in threaded view
|

Re: Java object conversion using ConfigSlurper

adithyank
In reply to this post by MG
Yes Jesper,

It works. But, If that `MyConfig` class has fields of `List` or `Map` types,
then it does not work. I am looking this feature as a way of converting
`ConfigObject` (inturn Map<String, Map&lt;Stirng, Map&lt;String,
Map&lt;String>>>>....) of any levels to its respective java object with
nested `List<anyclass>`, `Map<anyclass>`, `Other classes`.

Now, what decision can we take? Below are the options

1. I will look on the existing coercion codes to some how fit this use case
of creating nested objects recursively
or
2. `T ConfigObject.getAs(Class<T>)` can be implemented without affecting the
existing semantics of `Map as SomeClass`

Pls advice



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
12