Should the documentation for Iago still indicate a need to recompile for ParrotConfig changes?

[Michael Zalimeni]

Hi (mainly a question for WamBamBoozle),

I noticed the following in Iago's README.md:

Don't assume that you can skip the package/unzip steps if you're just changing a config file. You need to re-package and unzip again.

I tested out changing victims and log references in the web.scala config file, then creating my own config (a small edit of web.scala) and running with that. Both seemed to work just fine. Is this line outdated? Are there any known issues with running a config that was not compiled with the iago project?

(This question is leading to another: what is the best way to package Iago so that it can be run with different config files, without recompiling, in order to create a neatly test suite for several Java services?)

Thanks!

[Tom Howland]

Since the iago launcher generates configuration files based on the launcher configuration file, the concern is that if we change one of the generated files, we may later overwrite that if the change isn't perfectly reflected in the launcher config.

what is the best way to package Iago so that it can be run with different config files, without recompiling, in order to create a neatly test suite for several Java services?

Having several different launcher configurations available for testing should work fine.

--

---
You received this message because you are subscribed to the Google Groups "Iago Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to iago-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Zalimeni]

Thanks WamBamBoozle! A few clarifying questions:

Since the iago launcher generates configuration files ...

 

So what I'm hearing is that the generated files mentioned in that link are actually dependent on the configs in place at compile/package-time.

1. Are parrot-feeder.scala and parrot-server.scala the "generated configuration files" you're referring to?
   
2. Is it only launcher.scala, or also the other (e.g. web.scala) potential launcher configs that affect the output files?
3. What specific portions/fields of launcher.scala (or other launcher config files) determine the output files? It seems that minor changes don't affect the runs, even if sourcing an outside scala file that wasn't present at compile-time. Trying to understand the relationships here, though I would understand if you told me to go read the source (I'm a Java developer, so I'm trying to avoid parsing a lot of Scala for now to understand the innards).

the concern is that if we change one of the generated files, we may later overwrite that if the change isn't perfectly reflected in the launcher config

Is the concern only for the generated files being overwritten, or will Iago fail to start a run if certain changes are made to the launcher config .scala file without recompiling? 

Would there be a good way, in your opinion, to extend Iago through a pom file so that it can still assemble properly, without exposing all of Iago's internals? What I have in mind is similar to what jwstric2 did with https://github.com/jwstric2/iago-javahttpprocessor, but without depending on the "service-292" artifact, which doesn't seem intended for extension as a long-term solution.

[Tom Howland]

Answers inter-mixed

On Tue, Dec 16, 2014 at 10:48 AM, Michael Zalimeni <mzal...@gmail.com> wrote:

Thanks WamBamBoozle! A few clarifying questions:

Since the iago launcher generates configuration files ...

 

So what I'm hearing is that the generated files mentioned in that link are actually dependent on the configs in place at compile/package-time.

1. Are parrot-feeder.scala and parrot-server.scala the "generated configuration files" you're referring to?

yes 

1. 
   
2. Is it only launcher.scala, or also the other (e.g. web.scala) potential launcher configs that affect the output files?

yes 

1. What specific portions/fields of launcher.scala (or other launcher config files) determine the output files? It seems that minor changes don't affect the runs, even if sourcing an outside scala file that wasn't present at compile-time. Trying to understand the relationships here, though I would understand if you told me to go read the source (I'm a Java developer, so I'm trying to avoid parsing a lot of Scala for now to understand the innards).

As long as the only thing you change is the launcher config everything is beautiful. Re-run the launcher to your hearts content. Every time you do, you re-generate the other files.

 

the concern is that if we change one of the generated files, we may later overwrite that if the change isn't perfectly reflected in the launcher config

Is the concern only for the generated files being overwritten, or will Iago fail to start a run if certain changes are made to the launcher config .scala file without recompiling?

the former

 

Would there be a good way, in your opinion, to extend Iago through a pom file so that it can still assemble properly, without exposing all of Iago's internals? What I have in mind is similar to what jwstric2 did with https://github.com/jwstric2/iago-javahttpprocessor, but without depending on the "service-292" artifact, which doesn't seem intended for extension as a long-term solution.

Maybe. I've been experimenting with a version of Iago that has no launcher, and no scala configuration files either. Just lots of command line switches.

[Michael Zalimeni]

Thanks again WBB.

As long as the only thing you change is the launcher config everything is beautiful. Re-run the launcher to your hearts content. Every time you do, you re-generate the other files.

I think I've been misunderstanding. I forgot these files are generated on each execution of the Iago jar - so then there is no issue with, say, distributing the packaged .zip of the project, and then creating new launcher config .scala files to execute with AFTER that packaging/distribution has occurred. That is what I wanted to do - and I believe I now understand that is possible. The documentation seems to imply that all launcher config .scala files have to be packaged with Iago before it can be executed, even if no other source has been changed. It seems things are a lot simpler than that if you are only changing the launcher config.

Would love to see the command-line version! I think my team could definitely get into using it over the packaged version.