Re: Extracting groovy comments and source code

[Alessio Stalla]

I don't know about Groovy specifically, but most parsers discard comments
(and whitespace, line endings, etc.) before building an AST. However, you
can reconstruct the missing text if you have the position information of
each AST node and the original source code available.

On Wed, 29 Sept 2021 at 08:26, Saravanan Palanichamy 
wrote:

> Hello all,
>
> I am trying to do two things
>
> 1) Extract comments from inside a function code (not the function's groovy
> doc, but comments embedded inside the function code itself)
> 2) Extract the source code of the function itself
>
> For example
>
> /* Comments about myFunction *./
> void myFunction() {
> // My first line in the function
> myFirstLine()
>
> // My second line
> secondLine()
> }
>
> I want to extract the two // comments inside the function. I also want to
> be able to get the entire source code of the function (so essentially the
> entire code snippet above) as part of my AST transformations. Is that
> possible? Thank you for your time
>
> regards
> Saravanan
>

Re: Groovy as expression parser

[Alessio Stalla]

In Portofino, we use GroovyScriptEngine which takes care of automatically
recompiling changed files (taking dependencies into account). A typical
application has dozens of such files and it works well for us. However,
those are full-blown classes (even if many of them trivially extend a given
base class) rather than expressions. But you could still collect all the
expressions related to a given resource or page into a single class quite
easily if performance becomes a problem.

On Tue, 27 Oct 2020 at 16:08, Edmond Kemokai  wrote:

> Hi Jason,
>
> I am working on a product that uses Groovy as a dynamic scripting language
> within a Java web app and have been contending with this concern as well.
>
> Some things to consider:
>
> Is it possible to consolidate these 100s of expressions into a fully
> qualified named class?
> With this approach you could then create a singleton of such a class and
> retain that in memory via the java web app session. You could then map the
> expression evaluation to some sort of naming scheme (basically a bunch of
> if/else blocks), or just map each expression to a unique function.
>
> This of course takes away some of the flexibility of being able to run
> arbitrary code.
>
> As to the overhead of constantly compiling these expressions, I can't
> speak to actual numbers but there is definitely an overhead, you'll
> probably need to do your own jvm performance profiling to determine whether
> it is an actual problem.
>
> In my case I am using the java scripting API to evaluate Groovy code, with
> that API it is possible to obtain a compiled instance of the code (
> javax.script.CompiledScript ) that can be rerun multiple times without
> recompiling. This is an alternative way to address compilation overhead.
>
> Hope this helps.
>
> Regards
> Edmond
>
>
>

Re: Deleting files locked by a Java application on Windows

[Alessio Stalla]

Maybe you could rename and overwrite the files.

On Mon, 7 Sep 2020 at 10:42, Manuel Souto Pico 
wrote:

> Hi there again,
>
> Unfortunately the suggested solution --method deleteOnExit()-- didn't
> really help. I thought it was working but for some reason the files I had
> to delete were not locked at that particular moment. Maybe because the Java
> application had been running but idle for some time... I don't know, the
> lock (or the lock release) seems to happen a bit randomly.
>
> In any case, I'm still looking for a good workaround.
>
> In the absence of anything better, I will use ByteArrayOutputStream, as I
> explained in my original message, to deplete the locked files (deleting
> their contents) and then kill the application and run a post-processing bat
> script that deletes empty files. I know this is a hack, but I don't see how
> else I can do this.
>
> Tips welcome.
>
> Cheers, Manuel
>
> Manuel Souto Pico  escreveu no dia domingo,
> 6/09/2020 à(s) 23:01:
>
>> Thank you so much, J. David.
>>
>> Your suggestion works like a charm. Really grateful for that, and really
>> glad I asked in this list :-)
>>
>> I will update the Stackoverflow page.
>>
>> Have a great day.
>> Cheers, Manuel
>>
>> J. David Beutel  escreveu no dia domingo, 6/09/2020 à(s)
>> 22:37:
>>
>>> Hi Manuel,
>>>
>>> I don't know if this would work, but have you tried File.deleteOnExit()?
>>>
>>> Cheers,
>>> 11011011
>>>
>>>
>>> On 2020-09-06 08:26 , Manuel Souto Pico wrote:
>>> > Hi there,
>>> >
>>> > This is my first message to this list.
>>> >
>>> > I am a translator who writes scripts in groovy every now and then to
>>> > automate some tasks, although I'm not really a programmer.
>>> >
>>> > I have written a script that downloads some plugins (jar files) and
>>> > the script runs within the Java environment that uses those plugins.
>>> > The script must download the latest version of the plugin,
>>> > overwrite it if it already exists locally and delete any other
>>> > (earlier) versions of the same plugin.
>>> >
>>> > For example, the script downloads remote
>>> > file plugin-omt-package-1.6.3.jar from a certain URL, and must delete,
>>> > say, existing local file plugin-omt-package-1.6.2.jar.
>>> >
>>> > The problem:
>>> >
>>> > However, existing local files are locked by my Java application
>>> > (within which the groovy script runs) so the script doesn't delete
>>> > them. Apparently there is a bug on Windows (not on Linux) which is why
>>> > a Java application cannot easily release the lock.
>>> >
>>> > Somebody explains the bug in this thread
>>> >
>>> https://stackoverflow.com/questions/4179145/release-java-file-lock-in-windows/48489019#48489019
>>> >
>>> > I have followed the suggestion in that page and tried to
>>> > use ByteArrayOutputStream in my delete_other_versions function:
>>> >
>>> > ByteArrayOutputStream bos = new ByteArrayOutputStream(0);
>>> > FileOutputStream fos = new FileOutputStream( new File(path_to_file) );
>>> > bos.writeTo(fos);
>>> > fos.close();
>>> >
>>> > System.gc()
>>> > file.delete() // me beating about the bush
>>> >
>>> > My full code is here:
>>> > https://gist.github.com/msoutopico/7b2b340e9cec830f4b2ce207575e7525
>>> >
>>> > That seems to delete the content of the files (I can see they have now
>>> > a size of 0 kb), but not the files themselves.
>>> >
>>> > I would be grateful for further suggestions for workarounds about ways
>>> > I could manage to delete them.
>>> >
>>> > Thanks in advance.
>>> >
>>> > Cheers, Manuel
>>> >
>>> >
>>>
>>>

Re: What projects use Groovy as its main development language ?

[Alessio Stalla]

Projects built with Portofino (https://portofino.manydesigns.com) all use
Groovy as their main implementation language (alongside
JavaScript/TypeScript and maybe some Java).
I've worked on several such projects, but they're all closed-source. A
couple of publicly accessible ones are two applications that we (my former
employer) did for the local University. One is a platform for running
online recruitment procedures (https://concorsi.unige.it/home/?__language=en),
the other, which is Italian only I think, is a platform to match
high-school students with work experiences at the University (
https://alternanza-scuola-lavoro.unige.it/welcome).
They're both a few years old and built with Portofino 4 and (I think)
Groovy 2.4. So they're MVC web applications.
We've since released Portofino 5 that is REST +  Angular instead of MVC,
but it hasn't gained much traction so far.

On Thu, 2 Jul 2020 at 08:32, Kostas Saidis  wrote:

> Groovy has been my language of choice for some time now (replacing Java)
> and I use it extensively in as many projects as I can.
>
> The two most significant ones are the following.
>
> 1. Groovy lies at the heart and soul of the Clyze packaging tool for
> Android apps (clyze.com); the Clyze core contains about 25K SLOC of
> Groovy.
> The tool aims to make the management of ProGuard / R8 configurations as
> easy as possible for Android teams and it is currently in an early
> access state (we have only announced it on local groups here in Greece,
> so it is really coming to life as we speak). We have been developing it
> at the PLaST lab of the University of Athens for some time now, where I
> provide service as a visiting lecturer in Software Engineering, while
> the whole Clyze effort is lead by Yannis Smaragdakis (the lab director,
> Professor @ UoA and a well-known PL -and especially static analysis-
> researcher in top-notch events like SPLASH, PLDI, etc). BTW, if you' re
> into Android, we currently look forward to collecting as much feedback
> as possible for the tool, so feel free to experiment with it and contact
> me for any comments, thoughts or insights!
>
> 2. Groovy drives the back-end of Butterfly, the digital repository
> product we have developed at Niovity, a company that offers digital
> library / institutional repository solutions, mainly. Butterfly contains
> about 40K SLOC of Groovy.
>
> Cheers,
> Kostas
>
> On 27/6/2020 1:24 π.μ., MG wrote:
> > A quick survey: Who on this mailing list works on or knows of a
> > project where Groovy is the main language of development, i.e. it is
> > not used as "just" a script or DSL language in addition to e.g. Java ?
> > If possible name the company/country/project and give some impression
> > of the size of the project (lines of code, # of people working on it,
> > etc), timeframe of development, and whether it is os or commercial (or
> > both) G-)
> >
> > Thanks in advance,
> > cheers,
> > mg
> >
> >
> >
>
>

Re: please help : GroovyCastException: why ?

[Alessio Stalla]

If the user scripts are already existing, which version of Groovy were they
targeting? I've seen this behavior (of treating identifiers starting with
an uppercase letter as potential class names) for my entire life as a
Groovy developer, which started several years ago.

On Tue, 25 Feb 2020 at 10:19, Mickaël SALMON  wrote:

> Unfortunatly yes, that's what I need to do, passing an Article instance
> into a variable named "Article", not "article" like it should be ...
> Because of existing user scripts which must continue to work without
> refactoring.
>
> How can I deal with it ?
> --
> *From:* MG 
> *Sent:* Monday, February 24, 2020 23:30
> *To:* users@groovy.apache.org ; Mickaël SALMON <
> m...@sylob.com>
> *Subject:* Re: please help : GroovyCastException: why ?
>
> Article articleTmp = (Article) Article;
>
> in Groovy is the same as
>
> Article articleTmp = (Article) Article.getClass();
>
> in Java.
>
> Article.getClass()
>
> is of type Class, so casting it to Article will fail - what you
> want to do ist pass an Article instance, not the class, I presume...
>
> hth,
> mg
>
>
> On 24/02/2020 18:24, Mickaël SALMON wrote:
>
> Hello,
>
> I'm using last Groovy version (3.0.1) in my Java application to run user
> defined scripts (Java based).
> Here is how a script is executed (sorry for the formatting) :
>
>public Object eval(String scriptName, String script, Map Object> mapVariable)
>throws CochiseException {
>groovy.lang.Script groovyScript = this.scriptCache.get(scriptName);
>if (groovyScript == null) {
>groovyScript = new GroovyShell().parse(script);
>this.scriptCache.put(scriptName, groovyScript);
>}
>groovyScript.setBinding(new Binding(mapVariable));
>return groovyScript.run();
>}
>
> I have the following exception when I pass the object "Article" of class
> "com.sylob.cochise.dm1.ejb.entite.article.Article" in the Map of variables :
>
> org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast
> object 'interface com.sylob.cochise.dm1.ejb.entite.article.Article' with
> class 'java.lang.Class' to class
> 'com.sylob.cochise.dm1.ejb.entite.article.Article'
>
>
> Here is the script :
>
> import com.sylob.cochise.dm1.ejb.entite.article.Article;
>
> println "CL import Article : " +  Article.class.getClassLoader()
> println "CL var Article: " + Article.getClass().getClassLoader()
>
> Article articleTmp = (Article) Article;
> // ... some stuff
>
>
> This not seem to be a classLoader problem, because same class loader is
> used to load both com.sylob.cochise.dm1.ejb.entite.article.Article class
> in the script and "Article" object in the calling application.
> Also tested with 2.5.9, same error.
>
> What's wrong here ?
>
> Thanks.
>
>
>

Re: [ANNOUNCE] Apache Groovy 3.0.0 released

[Alessio Stalla]

Great job folks!
Looking forward to including Groovy 3 in Portofino 6! :)

On Tue, 11 Feb 2020 at 04:37, Andrei Karneyenka / Claz.org 
wrote:

> Congratulations to all us Groovy users :-) This is truly a great moment.
> Thanks to the Groovy team and to contributors for your hard work and
> dedication !
>
> On Mon, Feb 10, 2020 at 8:06 AM Paul King  wrote:
>
>> Dear community,
>>
>> The Apache Groovy team is pleased to announce version 3.0.0 of Apache
>> Groovy.
>> Apache Groovy is a multi-faceted programming language for the JVM.
>> Further details can be found at the https://groovy.apache.org website.
>>
>> We are sure you'll enjoy the features in this new version of Groovy.
>> Your feedback on any unintentional glitches is welcome.
>>
>> This release includes 15 bug fixes/improvements since RC3 as outlined
>> in the changelog:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12345566
>> (There are over 500 new features, improvements and bug fixes since Groovy
>> 2.5!)
>>
>> Sources, convenience binaries, downloadable documentation and an SDK
>> bundle can be found at: https://groovy.apache.org/download.html
>> We recommend you verify your installation using the information on that
>> page.
>>
>> Jars are also available within the major binary repositories.
>>
>> We welcome your help and feedback and in particular want to thank
>> everyone who contributed to this release. We value all forms of
>> contribution from our contributors past and present but special
>> mention for this release should be made to Daniel Sun for his
>> instrumental contributions to the Parrot parser and Eric Milles for
>> his recent improvements to Groovy's static compiler.
>>
>> For more information on how to report problems, and to get involved,
>> visit the project website at https://groovy.apache.org/
>>
>> Best regards,
>>
>> The Apache Groovy team.
>>
>
>
> --
> Andrei Karneyenka,
> Founder, Claz.org
>

Re: [ANNOUNCE] Apache Groovy 2.5.4 released

[Alessio Stalla]

It says 2.5.4 in the title but 2.5.3 in the actual article.

On Mon, 12 Nov 2018 at 13:07, Remko Popma  wrote:

> Blogged: https://blogs.apache.org/groovy/entry/groovy-2-5-4-released
>
> Please share on social media.
>
> On Monday, November 12, 2018, Paul King  wrote:
>
>> Dear community,
>>
>> The Apache Groovy team is pleased to announce version 2.5.4 of Apache
>> Groovy.
>> Apache Groovy is a multi-faceted programming language for the JVM.
>> Further details can be found at the http://groovy.apache.org website.
>>
>> This release is a maintenance release of the GROOVY_2_5_X branch.
>> It is strongly encouraged that all users using prior
>> versions on this branch upgrade to this version.
>>
>> This release includes 15 bug fixes/improvements as outlined in the
>> changelog:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12344270
>>
>> Sources, convenience binaries, downloadable documentation and an SDK
>> bundle can be found at: http://www.groovy-lang.org/download.html
>> We recommend you verify your installation using the information on that
>> page.
>>
>> Jars are also available within the major binary repositories.
>>
>> We welcome your help and feedback and in particular want
>> to thank everyone who contributed to this release.
>>
>> For more information on how to report problems, and to get involved,
>> visit the project website at https://groovy.apache.org/
>>
>> Best regards,
>>
>> The Apache Groovy team.
>>
>

Re: [DISCUSS] Groovy 2.6 potential retirement to focus on Groovy 3.0

[Alessio Stalla]

2 for me as well.

Il mer 13 giu 2018, 09:11 David Dawson 
ha scritto:

> I would vote 2.
>
> Actually, i would vote 3) abandon 2.6 immediately.
>
> No projects I have any knowledge of still use jdk 7.
>
> *From:* pa...@asert.com.au
> *Sent:* 13 June 2018 08:06
> *To:* users@groovy.apache.org
> *Reply to:* users@groovy.apache.org
> *Subject:* [DISCUSS] Groovy 2.6 potential retirement to focus on Groovy
> 3.0
>
>
> Hi everyone,
>
> There was some discussion at gr8conf about how to speed up delivery of
> Groovy 3.0. Some of that discussion was around the scope of what we want to
> include and have yet to complete in 3.0 but I won't discuss that right now.
>
> One of the other discussion points was Groovy around 2.6. As many of you
> know, we have released alpha versions of Groovy 2.6. That version is a
> backport of most but not all of Groovy 3.0 to JDK7 including the Parrot
> parser (though it isn't enabled by default). The purpose of this version
> has always been to assist people/projects wanting to use the Parrot parser
> but who might be stuck on JDK7. So in some sense it is an intermediate
> version to assist with porting towards Groovy 3.0. While that is still a
> noble goal in theory, in practice, many of our users are already on JDK8
> and we have limited resources to work on many potential areas.
>
> With that in mind, we'd like to understand the preferences in our user
> base for the following two options:
>
> Option 1: please continue releasing the best possible 2.6 even if that
> slows down the final release of Groovy 3.0 and delays further work on
> better support for JDK9+.
>
> Option 2: please release one more alpha of 2.6 over the next month or so
> which will become the best version to use to assist porting for users stuck
> on JDK7 and then focus on 3.0. The 2.6 branch will essentially be retired
> though we will consider PRs from the community for critical fixes.
>
> Feedback welcome.
>
> Cheers, Paul.
>
>
>

Re: @Groovy Champions: Groovy Development Funding ?

[Alessio Stalla]

There is also BountySource https://www.bountysource.com/
I would love to see Groovy there!

On 22 February 2018 at 00:00, MG  wrote:

> Hi Mario,
>
> thank you for the input. If I interpret the information on the webpage
> correctly, the system works for one-on-one funding of tasks between e.g. a
> developer and a stakeholder for specific tasks of a project. I don't know
> if this would work in the case of Groovy, because here we would probably
> have a larger number of  people giving smaller amounts to fund a
> development goal together...
>
> Cheers,
> mg
>
>
>
> On 21.02.2018 15:50, Mario Garcia wrote:
>
> I thought this could be worth sharing.
>
> The company I work for developed some time ago, Tribe (
> https://tribe.taiga.io/)
>
> Tribe is a task-based employment marketplace for product development. It
> was created with software development in mind. The tasks can be managed
> through the open sourced Taiga management platform (https://taiga.io/).
> So tasks could be managed in the context of a project.
>
> More details about Tribe (how it works, payments...) :
>
> https://tribe.taiga.io/help/how-it-works
>
> I hope this helps
> Mario
>
> 2018-02-18 17:17 GMT+01:00 MG :
>
>> Hi Eric,
>>
>> thank you for the suggestion. Do you know how much money they take for
>> their service and if they accept Paypal (I just thought about this, and not
>> accepting Paypal is imho close to a knockout, to keep the entry barrier as
>> low as possible; that would exclude Kickstarter according to their FAQ, but
>> here one could probably assume that many potential Groovy backers would
>> already have an account...).
>>
>> Do they support specific funding foals also (which typically attract more
>> funding), or is a subscription only model ?
>>
>> Cheers,
>> mg
>>
>>
>>
>> On 18.02.2018 14:15, Eric Kinsella wrote:
>>
>> I know of some indie game developers and podcasters that are using
>> Patreon. A possible alternative to something like KickStarter/Indiegogo
>> with more of a subscription model which could even be $1/month.
>>
>> https://www.patreon.com
>>
>> What is Patreon? - video
>> https://www.youtube.com/watch?time_continue=1=rwvUjAv6pxg
>>
>> Cheers,
>> Eric Kinsella
>>
>>
>> On Fri, Feb 16, 2018 at 12:37 PM, MG  wrote:
>>
>>> That should be no problem, I would be happy to do a Groovy "thank you"
>>> mug o.s.  :-)
>>>
>>>
>>> On 16.02.2018 17:11, Mario Garcia wrote:
>>>
>>> +1 but also keep in mind that sometimes could be also something as
>>> simple as a "grateful box pack" with a T-shirt, sticker or a mug. I would
>>> love that too.
>>>
>>> Mario
>>>
>>> El 16 feb. 2018 11:49 a. m., "Jochen Theodorou" 
>>> escribió:
>>>


 Am 16.02.2018 um 03:27 schrieb Paul King:

> Actually, Apache also accept donations but I think the standard policy
> is that it isn't then directed back to a specific project.
>

 I actually am of the impression that this is the only policy... might
 be wrong here.

 I think in general we would be in favor of doing this so long as it was
> done well - and most of us wonder whether we have the time to
> market/advertise it well. I also suspect that having a well-defined goal
> (like what JUnit 5 did to some degree) greatly helps to attract some
> one-off investment interest.
>

 +1

 bye Jochen

>>>
>>>
>>
>>
>
>

Re: Advanced binding of methods by name in a template via the binding map

[Alessio Stalla]

I answered: http://stackoverflow.com/a/42202684/296025
But that won't solve your problem, I'm afraid.

On 13 February 2017 at 08:03, OmniTrade  wrote:

> Hi All,
>
> I won't bore you with the gritty details here since they are already well
> described on StackOverflow.
>
> It seems that few people have the chops to tackle this question. It sounds
> solvable and maybe some of the pros here can attempt it.
>
> http://stackoverflow.com/questions/41196600/how-do-i-bind-
> all-methods-of-a-certain-name-in-an-object-into-a-template-via-the
>
> Rumour has it that there is also a 500 point reward for the canonical
> answer.
>
> Good Luck.
>

Re: Groovy hot deploy in production

[Alessio Stalla]

In Portofino applications we allow to hot reload Groovy code using
GroovyScriptEngine. It is great for development and handy for fixing quick
issues in production too, but if it's mission critical I wouldn't rely on
it yet. Even if it has improved much over time (thanks to Jochen's work!)
sometimes it can happen that something is not properly updated - be it for
some hard to find Groovy bug still left around, or frameworks caching
classes and not properly releasing them, or your own code keeping objects
around e.g. in the HTTP session. So the occasional application server
reload is still needed even if it's quite rare. I'm talking about
relatively low traffic business type applications with maybe hundreds of
users top. For a busy network application with a lot of framework code and
frequent hot reloads things are likely to get worse quicker.

On 21 June 2016 at 20:40, Erwin Müller  wrote:

> Just have a data storage for persistent data, and let the Groovy code
> access that data in an atomic way.
> Just a simple synchronized map would be sufficient as the data storage.
> That way, you won't need to storage any data in your Groovy code.
> It's just important to use atomic types like primitive types (int, float)
> or AtomicInt, AtomicBoolean, and read-only types, like String, InetAddress,
> joda.DateTime.
> Later in the development you can exchange the simple synchronized map with
> MemotyDb if you want to.
>
> For example,
>
> class DataStorage {
> private Map storage;
> DataStorage() {
> this.storage=Collections.synchronizedMap(new HashMap());
> }
> public void addUser(name);
> public void setUserPassword(name, password);
> public String getUserPassword(name);
> public void setUserTCP(name, tcp);
> public String getUserTCP(name);
> public void setUserUDP(name, udp);
> public String getUserUDP(name);
> }
>
> Tue Jun 21 2016 20:01:42 CEST from "Aplomb Chen"  
> Subject:
> Re: Groovy hot deploy in production
> I am developing chat servers which need hold user information in server
> memory like the tcp or udp channels and other user session data.
>
> Hot deployments will be useful that I can keep the user information in
> memory and upgrade the business code for new features. So that those chat
> users won't need re-login again, otherwise I need restart chat servers for
> the upgrade which will easily cause login storm.
>
> Currently my plan is using groovy for hot deploy, I will do switching
> GroovyClassLoader every time when I need upgrade code, which means in
> groovy code, I can not hold any memory, I think the advantage is I can
> control to upgrade groovy scripts after the code is updated on server and
> demand our developers not hold any memory in groovy scripts, this is like
> how PHP does, right?
>
> For further thinking, to resolve the NOT hold any memory demand, I am
> thinking about implement MemoryDB (May like Redis, but much more simpler)
> for groovy scripts, so that developers can save objects to MemoryDB in
> runtime.
>
> Do you think this is a reasonable design? Please advice, much appreciated!
>
> On Tue, Jun 21, 2016 at 11:54 PM, Domingo Suárez Torres <
> domingo.sua...@gmail.com
> >
> wrote:
>
>> I always avoid hot deployments, I prefer to have multiple running JVMs
>> and a proxy or load balancer in front.
>>
>>
>>
>> On Tue, Jun 21, 2016 at 9:18 AM Erwin Müller > >
>> wrote:
>>
>>> Why not have start and stop hooks for such stuff?
>>>
>>> Have an interface with onStart() and onStop() methods, and call them
>>> when you load and unload a class.
>>>
>>> If you really need modularity, use OSGi.
>>>
>>> Regards, Erwin.
>>>
>>> Sun Jun 19 2016 15:00:56 CEST from "Aplomb Chen" >> > Subject:
>>> Groovy hot deploy in production
>>>
>>> Hi Guys,
>>>
>>>
>>>
>>> Will you use groovy hot deploy in production environment? Is it reliable
>>> to do so?
>>>
>>>
>>>
>>> I am worried that it may have issue when you are doing below,
>>>
>>> 1, Defined a Array as class attribute, make it has 1 objects, next
>>> time code hot deploy that the array is erased in code, then that must be an
>>> memory leak, right?
>>>
>>> 2, If you execute a periodic timertask in a groovy, next time code hot
>>> deployed, if the timetask is no longer needed from your code, but the
>>> started timertask will still be running, right?
>>>
>>>
>>>
>>> If we demands developers avoid using class attributes or starting any
>>> thread thing as a development rule, will hot deploy still be good for
>>> production?
>>>
>>>
>>>
>>> Aplomb
>>>
>>>
>>>
>>> Best regards
>>>
>>>
>>>
>>>
>>> --
>>> Erwin Müller - erwin.muel...@deventm.org
>>> 

Re: Hierarchy of singletons howto?

[Alessio Stalla]

An object of class Bar *is-a* Foo in the example. Therefore, the one
instance of Bar is also an instance of Foo. Therefore, there are *two*
instances of Foo. Therefore, Foo is not a singleton.

Of course the AST transformation in generating a private constructor. It
wouldn't be a proper singleton otherwise.


On 1 April 2016 at 22:59, Winnebeck, Jason <jason.winneb...@windstream.com>
wrote:

> I think it's reasonable to have two singletons related by hierarchy. My
> guess is that the AST is making a private constructor, which makes the
> class closed for extension. A possible workaround would be to make a base
> class equal to Foo that is not a Singleton, then a Foo extends Base and Bar
> extends Base as Singleton (or use an interface).
>
> Jason
>
> -Original Message-
> From: OC [mailto:o...@ocs.cz]
> Sent: Friday, April 01, 2016 3:39 PM
> To: users@groovy.apache.org
> Subject: Re: Hierarchy of singletons howto?
>
> At least one of us two must have missed something in Object-Oriented-101.
>
> There is exactly one instance of class Foo.
>
> And there is exactly one instance of class Bar, whose functionality is
> derived from Foo.
>
> Consider the factory pattern: there are two related classes, A and B
> extends A. If it so happens that each of them needs a factory class, then
> is is self-evident that
>
> (a) both AFactory and BFactory need to be singletons (as any factory out
> there)
> (b) BFactory should extend AFActory, for just as B's functionality extends
> A's functionality, the same applies for their factories.
>
> And one can implement the functionality easily, e.g., using
>
> ===
> class Foo {
>   static instance=newInstance()
> }
> class Bar extends Foo {
>   static instance=newInstance()
> }
> ===
>
> it works like a charm, only -- unlike @Singleton -- it is not lazy (and if
> turned to lazy, it would not be threadsafe).
>
> Thanks and all the best,
> OC
>
> On 1. 4. 2016, at 11:48, Alessio Stalla <alessiosta...@gmail.com> wrote:
>
> > Your requirement is logically inconsistent. If there is only one
> possible instance of Foo, there cannot be /another/ instance of Foo which
> is also a Bar.
> >
> > On 1 April 2016 at 04:28, OC <o...@ocs.cz> wrote:
> > Hello there,
> >
> > how do you make a hierarchy of classes, each of which happens to be a
> singleton?
> >
> > The naïve solution simply does not work:
> >
> > ===
> > 85 /tmp>  > @Singleton class Foo { }
> > @Singleton class Bar extends Foo { }
> >
> > println "Foo: ${Foo.instance}, Bar: ${Bar.instance}"
> > 86 /tmp> groovy qq
> > Caught: java.lang.IllegalAccessError: tried to access method
> Foo.()V from class Bar
> > java.lang.IllegalAccessError: tried to access method Foo.()V from
> class Bar
> > at Bar.(qq.groovy)
> > at Bar.(qq.groovy)
> > at qq.run(qq.groovy:4)
> > 87 /tmp>
> > ===
> >
> > What is the proper way to achieve this?
> >
> > Thanks a lot,
> > OC
> >
> >
>
> --
> This email message and any attachments are for the sole use of the
> intended recipient(s). Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient, please
> contact the sender by reply email and destroy all copies of the original
> message and any attachments.
>

Re: Hierarchy of singletons howto?

[Alessio Stalla]

Your requirement is logically inconsistent. If there is only one possible
instance of Foo, there cannot be /another/ instance of Foo which is also a
Bar.

On 1 April 2016 at 04:28, OC  wrote:

> Hello there,
>
> how do you make a hierarchy of classes, each of which happens to be a
> singleton?
>
> The naïve solution simply does not work:
>
> ===
> 85 /tmp>  @Singleton class Foo { }
> @Singleton class Bar extends Foo { }
>
> println "Foo: ${Foo.instance}, Bar: ${Bar.instance}"
> 86 /tmp> groovy qq
> Caught: java.lang.IllegalAccessError: tried to access method Foo.()V
> from class Bar
> java.lang.IllegalAccessError: tried to access method Foo.()V from
> class Bar
> at Bar.(qq.groovy)
> at Bar.(qq.groovy)
> at qq.run(qq.groovy:4)
> 87 /tmp>
> ===
>
> What is the proper way to achieve this?
>
> Thanks a lot,
> OC
>
>

Re: @Log annotation inside Groovy Script

[Alessio Stalla]

Hi,
you don't have to pass the logger around. You can configure it once in the
main script and ask for it in child scripts. Every time you invoke
java.util.logging.Logger.getLogger('my-script-logger'), the same logger is
returned. This is true also if you use log4j or logback (better) instead of
java.util.logging.

On 9 January 2016 at 02:15, Gerald Wiltse  wrote:

> Thank you both for your feedback.  In my case, I don't think either
> suggestion will work.  Our scripts are all executed by a third party
> application. We do not have control over most environment items, nor can I
> pass startup options to the scripts. This puts me in a corner case, which
> makes me feel like I'm going against the grain on this.
>
> For this case, everything must take place in the script, or in calls I
> make from the script to other scripts, and then subsequent classes. I
> already call children scripts, and pass in objects through binding.  (def
> shell = new GroovyShell(bindings).parse( scriptBody ))
>
> I'm considering a few alternatives for logging:
>
> 1. Creating a logger in step 1, passing it along to scripts and classes i
> call
> a.   Tedious, yet seemingly straightforward
> b.   I assume possible, correct if wrong
> 2. Creating a logger in step 1, using reflection/stacktrace to get
> references back to it
> a.   Seems like I could make it work, but I don't even know if
> actually possible
> b.   From what i've read, seems pretty ill-advised for efficiency
> reasons
>
> To be honest, I don't like either, and it seems that there is no elegant
> way to do the logging the way I am envisioning. Usually that means "You're
> doing it wrong".  I guess here, that means the third party app didn't
> intend for people to be instantiating, calling custom classes, etc.  It was
> intended to be more basic.  They also don't support grape and a few other
> items that have made me engineer some things that would have otherwise been
> simple in a vanilla groovy environment.
>
> Thanks again for everyone's help.
>
>
>
> Gerald R. Wiltse
> jerrywil...@gmail.com
>
>
> On Fri, Jan 8, 2016 at 4:31 PM, Shil Sinha  wrote:
>
>> Hi Gerald,
>>
>> You can apply AST transformations to script classes using
>> http://docs.groovy-lang.org/latest/html/documentation/#_ast_transformation_customizer
>> .
>>
>> In your case, you'd need a script (called config.groovy in this example)
>> that looks like this:
>>
>> withConfig(configuration) { ast(groovy.util.logging.Log) }
>>
>> When you run a script that you want @Log applied to (MyScript.groovy in
>> this example), you'd call it as follows:
>>
>> groovy -configscript config.groovy MyScript.groovy
>>
>>
>>
>> On Fri, Jan 8, 2016 at 2:55 PM, Nelson, Erick [HDS] <
>> erick.nel...@hdsupply.com> wrote:
>>
>>> I’m not sure if there is a better way to handle script logging.
>>>
>>> The annotations is for classes and you cannot apply it to your script
>>> class.
>>>
>>> Another  disadvantage is that I don’t think you can use the logger in
>>> static methods.
>>>
>>>
>>>
>>> What you can do is ‘override’ the groovy Script class (the class that
>>> your script is an instance of, kindof) by use the BaseScript annotation
>>>
>>> Example:
>>>
>>> Define your wrapper like this…
>>>
>>>
>>>
>>> -bash-4.1$ cat MyScript.groovy
>>>
>>> abstract class MyScript extends Script {
>>>
>>> java.util.logging.Logger log
>>>
>>> @Override def run () {
>>>
>>> log = java.util.logging.Logger.getLogger('')
>>>
>>> // any other startup stuff here….
>>>
>>> runMyScript()
>>>
>>>   // any other shutdown stuff here…
>>>
>>> }
>>>
>>> abstract def runMyScript()
>>>
>>> }
>>>
>>>
>>>
>>> Note that I have added a script variable called log that you can then
>>> use in your script.
>>>
>>>
>>>
>>> Then in your script do something like this…
>>>
>>>
>>>
>>> @groovy.transform.BaseScript(MyScript)
>>>
>>> import groovy.util.*
>>>
>>> log.info 'hello'
>>>
>>> log.severe 'hello'
>>>
>>>
>>>
>>> sample run….
>>>
>>>
>>>
>>> -bash-4.1$ groovy -Djava.util.logging.config.file=logging.properties
>>> test.groovy
>>>
>>> Jan 8, 2016 11:53:04 AM java.util.logging.LogManager$RootLogger log
>>>
>>> INFO: hello
>>>
>>> Jan 8, 2016 11:53:04 AM java.util.logging.LogManager$RootLogger log
>>>
>>> SEVERE: hello
>>>
>>>
>>>
>>> The advantage here is that you can now add any other startup and
>>> shutdown code in the base script class’s run method.
>>>
>>>
>>>
>>> *From:* Gerald Wiltse [mailto:jerrywil...@gmail.com]
>>> *Sent:* Friday, January 08, 2016 11:01 AM
>>> *To:* users@groovy.apache.org
>>> *Subject:* @Log annotation inside Groovy Script
>>>
>>>
>>>
>>> I just got @Log to work in some test classes, then learned that  @Log
>>> annotations do not work in scripts. Is this true? If so, is there some
>>> workaround that exists?  I assume this is true for all @annotations and
>>> scripts, so it seems pretty sad if there's no way to do it.
>>>
>>>
>>>
>>>