headers
Daniel Marreco | 22 May 2013 22:52
Picon
Favicon

[groovy-user] broken groovy JARs in repositories

Hi,

I am getting checksum errors for all the groovy AND groovy-all 1.6.* jars in
both codehaus and maven central repositories.

Tried to download jar manually and tried to open them, happens they are all
broken.

Anybody knows anything about it?

Thanks in advance,
Daniel

--
View this message in context: http://groovy.329449.n5.nabble.com/broken-groovy-JARs-in-repositories-tp5715519.html
Sent from the groovy - user mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
Permalink | Reply | 1 comment |
headers
OC | 22 May 2013 17:07
Picon

[groovy-user] Tend to forgetting each...

Hello there,

I've found I repeatedly tend to forget 'each', i.e., I tend to write

someCollection { ... }

instead of

someCollection.each { ... }

I wonder, is that just me, or happens this to others, too? To be quite frank I am considering whether to tweak
the runtime to automatically perform 'each' in such cases through methodMissing, or whether it would
bring more harm than benefits :P

All the best,
OC

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
Permalink | Reply | 1 comment |
headers
Schalk W. Cronjé | 22 May 2013 07:11
Picon

[groovy-user] XML size (Was: XmlSlurper no GC

XmlSlurper performance aside; as a side-note, I have to wonder why you are shipping 25MB SOAP messages around instead of deferring the big blobs of data to MTOM attachments.


--
Schalk W. Cronjé
[Sent from mobile phone]



-------- Original message --------
From: jochen <at> eddelbuettel.net
Date: 21/05/2013 22:56 (GMT+00:00)
To: user <at> groovy.codehaus.org,youknowwho <at> heroicefforts.net
Subject: Re: [groovy-user] XmlSlurper no GC


Jess,
 
I've had my hand on the XmlSlurper sources just recently. Its categorization as "lazy evaluation" only extends to GPath queries (where it builds a hierarchy of Iterators instead of collecting nodes into new lists) and node structure manipulation (where new node content is represented by Builder closures until the XML is streamed out again). But it still creates a full in-memory representation of its (groovy.util.slurpersupport.)Nodes in the parse method based on SAX events. So we end up with something that is closer to DOM than StAX. It's all implemented in Java, not compiled Groovy. Anyway, given the dimensions of your typical XMLs, it probably isn't a wise choice.
 
What I find interesting is that you describe that it makes a difference, whether any queries are carried out or not. Could you send me a full sample (code and data)? I might find some time early next week to investigate. A recently accepted pull request of mine is going to make the network of Node references that the GC needs to come to terms with still a slight bit more complicated (by keeping a parent node reference) come Groovy 2.2.x.
 
I still believe that Groovy XML processing is utterly brilliant, but the JVM should sure be able to recapture the memory utilized along the way.
 
Cheers
 
Jochen (eddel+)
youknowwho <at> heroicefforts.net hat am 21. Mai 2013 um 16:34 geschrieben:
youknowwho <at> heroicefforts.net hat am 21. Mai 2013 um 16:34 geschrieben:

Background, I'm contemplating upwards of 25MB SOAP responses coming across the wire to me and vainly holding on to the illusion that the syntactically beautiful XmlSlurper would ever scale, memory wise, to support concurrent processing of such requests in a JEE server environment.  Oh, I can hear the I told you so's echoing from my teammates already.  :)

 

I have a Groovy script that simply reads a 25MB message from disk and does some light processing using XmlSlurper.  With a 128MB heap, it just manages to run (oh StAX how I envy you now).  However, if I run this block in a loop, then I get an OOME.  Once the root GPathResult returned by the parse invocation is queried, then it appears that memory is never GC'd.  I see no explicit cleanup methods on any of these classes.  I've tried scoping in a closure, explicitly assigning nulls, etc. and nothing seems to work.  Other allocations, big arrays, etc. are GC'd as expected.  Are there known memory leak issues in this implementation or maybe Sun's underlying SAX implementation (JDK 1.6)?

 

Also, has anyone calculated the overhead added by XmlSlurper to XML of size X?

 

 

thanks,

 

-Jess


 
Permalink | Reply | 0 comments |
headers
Schleis, David M. | 21 May 2013 23:32
Picon

[groovy-user] Groovy not working with Rhino JS to Java call

Mirth Connect is an open source integration engine with specific support for

HL7 (healthcare) messages.

Internally it uses the Rhino JavaScript engine which of course runs JavaScript, but also allows calling code from custom Java packages (found in jar files in the custom-lib).

 

I have written a simple Groovy class and then created the jar using the GroovyWrapper (http://docs.codehaus.org/display/GROOVY/WrappingGroovyScript)

 

The code runs without error, but I find that when I try to do something Groovy, the call is simply ignored.

For example:

 

        def orderList = orders.split("\n")

        return orderList[0]

 

returns the expected single line (orderList[0]) when running in the IDE, but returns the entire multi-line string (orders) when run from Mirth (Rhino).

 

Admittedly, this is my first attempt at running compiled Groovy from Java, so the chances that I am missing something completely obvious are high, but I have spent some time on this before calling for help.

 

Can anyone offer some guidance on how I might solve this issue?

 

Thank you.

 

Permalink | Reply | 4 comments |
headers
Schleis, David M. | 21 May 2013 23:16
Picon

[groovy-user] Jar-red Groovy not working from Rhino JS to Java call

Mirth Connect is an open source integration engine with specific support for

HL7 (healthcare) messages.

Internally it uses the Rhino JavaScript engine which of course runs JavaScript, but also allows calling code from custom Java packages (found in jar files in the custom-lib).

 

I have written a simple Groovy class and then created the jar using the GroovyWrapper (http://docs.codehaus.org/display/GROOVY/WrappingGroovyScript)

 

The code runs without error, but I find that when I try to do something Groovy, the call is simply ignored.

For example:

 

        def orderList = orders.split("\n")

        return orderList[0]

 

returns the expected single line (orderList[0]) when running in the IDE, but returns the entire multi-line string (orders) when run from Mirth (Rhino).

 

Admittedly, this is my first attempt at running compiled Groovy from Java, so the chances that I am missing something completely obvious are high, but I have spent some time on this before calling for help.

 

Can anyone offer some guidance on how I might solve this issue?

 

Thank you.

 

Permalink | Reply | 0 comments |
headers
youknowwho | 21 May 2013 16:34

[groovy-user] XmlSlurper no GC

Background, I'm contemplating upwards of 25MB SOAP responses coming across the wire to me and vainly holding on to the illusion that the syntactically beautiful XmlSlurper would ever scale, memory wise, to support concurrent processing of such requests in a JEE server environment.  Oh, I can hear the I told you so's echoing from my teammates already.  :)

 

I have a Groovy script that simply reads a 25MB message from disk and does some light processing using XmlSlurper.  With a 128MB heap, it just manages to run (oh StAX how I envy you now).  However, if I run this block in a loop, then I get an OOME.  Once the root GPathResult returned by the parse invocation is queried, then it appears that memory is never GC'd.  I see no explicit cleanup methods on any of these classes.  I've tried scoping in a closure, explicitly assigning nulls, etc. and nothing seems to work.  Other allocations, big arrays, etc. are GC'd as expected.  Are there known memory leak issues in this implementation or maybe Sun's underlying SAX implementation (JDK 1.6)?

 

Also, has anyone calculated the overhead added by XmlSlurper to XML of size X?

 

 

thanks,

 

-Jess

Permalink | Reply | 3 comments |
headers
OC | 21 May 2013 11:40
Picon

[groovy-user] in-consistence :)

Hello there,

I've bumped into one slight inconsistence with 'in' -- is this the presumed behaviour?

groovy:000> String in Class
===> false
groovy:000> String instanceof Class
===> true
groovy:000> 

Thanks,
OC

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
Permalink | Reply | 1 comment |
headers
theirish81 | 21 May 2013 08:33
Picon
Gravatar

[groovy-user] ClassLoaders and garbage collection

Hello everyone,
I'm not that big expert of garbage collection and classloaders, but there's
something that puzzles me and it's very important for me to find an answer
to this.
I've been told that a class can be collected when 
1) all the instances of that class have lost all references. Hence, they're
marked for collection
2) all the classes loaded by the same classloader have no referenced
instances
3) the classloader that loaded is no referenced anymore

I'm experiencing an unexpected behavior with the groovyclassloader.
Let's take this sample code:

We have 2 classloaders extending GroovyClassLoader. the XClassLoader loads a
java.util.Date, while the WoodClassLoader parses a class on the fly.
Both classloaders override finalize() to give us a hint the classloader is
marked for collection.
Finally the instance overrides finalize() as well to let us now the object
is marked for collection as well.

I would expect to see:
- dead instance
- Death of wood class loader
- Death of X class laoder

I've read facts suggesting the wood classloader could take more time to be
collected. And that's fine.
But here what I get:

And this can go on and on thousands hits... what am I missing? Will the ever
get collected? If not, I'm in a big big problem

Thanks in advance

Simone

--
View this message in context: http://groovy.329449.n5.nabble.com/ClassLoaders-and-garbage-collection-tp5715489.html
Sent from the groovy - user mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
Permalink | Reply | 3 comments |
headers
xunitc | 20 May 2013 13:45
Picon

[groovy-user] Is there a groovy way to change a string bit please?

 Hi.

I have a string: 
def str = "111000";

And I want change the last bit to 1 (or other changes).
I know I can not use these under groovy 2.1.3:
str[-1] = '1';
str[0] = '0';
str[1..2] = '00';

So, is there a simple groovy way to do these please?

-----
Xunitc
--
View this message in context: http://groovy.329449.n5.nabble.com/Is-there-a-groovy-way-to-change-a-string-bit-please-tp5715478.html
Sent from the groovy - user mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
Permalink | Reply | 12 comments |
headers
Pawel Slusarz | 19 May 2013 22:00

[groovy-user] arrays equals and hashCode

Greetings,

It seems Groovy arrays don't obey the javadoc hashCode contract
(http://docs.oracle.com/javase/6/docs/api/java/lang/Object.html#hashCode()).
Specifically, array equality is computed by comparing array elements,
but hashCode is computed based on the object reference. We ran into this
issue at work when trying to use byte arrays as keys in a HashMap
(instead of Strings). I do not see this unexpected behavior documented
anywhere, so I thought I'd post it here for discussion.

Below are some non-exhaustive test cases. Out of these, only the last
test, using Strings, passes. All others fail on the hashCode assertion.

Regards,
Paul

// ran with groovy 2.1.3, osx, jdk 1.6, junit 4

     <at> Test
    void testBytePrimitiveArray() {
        byte[] b1 = new byte[2]
        byte[] b2 = new byte[2]
        assert b1 == b2
        assert b1.hashCode() == b2.hashCode() //fails
    }

     <at> Test
    void testByteObjectArray() {
        Byte[] b1 = new Byte[2]
        Byte[] b2 = new Byte[2]
        assert b1 == b2
        assert b1.hashCode() == b2.hashCode()  //fails
    }

     <at> Test
    void testIntArray() {
        int[] i1 = new int[2]
        int[] i2 = new int[2]
        assert i1 == i2
        assert i1.hashCode() == i2.hashCode() //fails
    }

     <at> Test
    void testCharArray() {
        char[] c1 = new char[2]
        char[] c2 = new char[2]
        assert c1 == c2
        assert c1.hashCode() == c2.hashCode() //fails
    }

     <at> Test
    void testString() {
        String s1 = "dog"
        String s2 = "dog"
        assert s1 == s2
        assert s1.hashCode() == s2.hashCode() //passes
    }

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
Permalink | Reply | 0 comments |
headers
OC | 19 May 2013 14:35
Picon

[groovy-user] Would it be possible to forbid auto-prefixing 'this.'?

Hello there,

would it be possible to tell the compiler _NOT_ to try "this.foo" when it compiles "foo"? So that "foo" would
mean just a variable, and if there's none, fail. If I want to try for a property, I write "this.foo" anyway.

Thanks,
OC

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
Permalink | Reply | 2 comments |

Gmane