I tried to create the Groovy script with v1.8.5. I had to modify the script's Grab config as below:


import groovyx.net.http.RESTClient

@Grab(group='org.codehaus.groovy.modules.http-builder', module='http-builder', version='0.5.2')
@GrabExclude('xml-apis:xml-apis')

def job = new RESTClient( 'http://localhost:8080/JobDemo/')
...

The fix is in there if you want to patch.

I'm currently working with Roo-1.1.5 and I'm able to build roo-source in my development machine (Windows XP). Now I'want to use the same dev shell from with in STS. For that, I'm trying to create an assembly. The command is failing with the following message

[INFO] Final Memory: 47M/494M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5:assembly (default-cli) on project org.springframework.roo.root: Error reading assemblies: No assembly descriptors found. -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]

Steps described in the provided readme.txt and script file are specific to *nix platforms. Please help me to solve this issue.

Thanks,
Kallada

I ran into one showstopper though. My data has one-to-many bidirectional links. The resultant code generates infinite recursion problems as it tries to jump back and forth descending into the parent-child links forever.

I know this is fixable for hand written code: http://wiki.fasterxml.com/JacksonFeatureBiDirReferences
but for roo code, it defines the point at which you have to quit scripting roo and start "normal" work as one needs to write getters for all set/reference members, or use the above annotations.

In my app, the perfect solution is to return a rest reference in place of attempting to marshal a referenced object. Maybe some day when roo is more json friendly.

Ken

It's very easy, just follow the readme.txt instructions.

Actually it's a simple mvn clean install (with maven 3 and Java 6 and a MAVEN_OPTS for mempry), but you need to configure gpg before (very easy in Mac, not to difficult in windows and not too bad in Ubuntu) But you tell us in a previous POST how to avoid the signature step ;)

Then a ln -s in *NIX:
sudo ln -s $ROO_HOME/bootstrap/roo-dev /usr/bin/roo-dev
sudo chmod +x /usr/bin/roo-dev

In windows, add roo-dev to the path.

You can even debug Roo importing the projects in Eclipse. Existing in workspace if you previously run mvn install eclipse:clean eclipse:eclipse

LOL, no worries!

We work across the room from each other at Chariot anyway, and we've known each other for 20+ years! He's the experimentalist - PenCasts, Prezi presentations, etc... Someone we worked with used to call us the Bopsi Twins back in the 90's when we worked for a training / consulting outfit.

For those reading, he's at the Technophile Blog, and is a very deep expert in all things Spring Integration, and other enterprise Springy things. We both teach Spring for Chariot. See our upcoming training events page for course schedule.

Also looking forward to your ROO Addons chapter in MEAP.

What about another pen-cast, the one you did is a great resource.

As always a lot to take back and a lot to learn.

You are correct, you can leave a flow but when you return to the flow you MUST use the flowExecutionUrl otherwise a new flow instance is started.

The Cart can normally be accessed by two actions:
1. Add to Cart.
2. View Cart.

Of course every product on the site will have an 'Add to Cart' button but essentially it is just two actions. It should be possible to fix up both cases with the correct flowExecutionUrl.

The whole thing about web flows are that they post back to the flow URL with a special flow execution key - it's ?execution=ensn, where e means execution, and s means step. So you'll see things like ?execution=e3s12 - your user's Flow Execution ID 3, step 12. Every time you call the servlet again, it rewrites the URL and puts the next highest # on it. So you start with e1s1, then go to e1s2 and so on. If you remove the ?execution= from your URL, it starts a new webflow. And by default I think any given client is allowed 5 concurrent flows, and once you hit the sixth one, the first one is garbage collected.

There are a few variables, at least in the view that you can use - I'm not 100% sure if you have access to them in your executions or whether Web Flow adds them afterward (and it's something I'm going to research). One of them is flowExecutionKey, the other is flowExecutionUrl - each could be useful if you could preserve them. You probably have access to the numerical values via the RequestContext variable in your beans, if you injected it as flowRequestContext.

Another angle would be to create a flow execution listener, and capture the flow keys, storing them somewhere, like in your session. Then you could have a helper that builds the URL for you, and if no stored execution lives in your session, you could generate a URL without the ?execution= setting. There are probably too many edge conditions in this idea but it sounds like an avenue to research.

Thanks for the very informative post, it's much appreciated.

I have a question about Web Flow that I just cannot seem to find out the definitive answer. So, I am asking you for your thoughts and maybe advice...

It is: If a user clicks on a page that is outside of the flow and later returns to the flow, are the contents (variables etc) of the first flow lost?

In the real world, a user, after adding a product to the cart, may well go off and search the site for another product to buy. In doing so, they have left the flow.

Thanks

Lyndon