Roo 1.2 trunk - NPE on lookup of Project Metadata during file copy - is it me?

[krimple]

Hey, Roo add-on people...

I am wondering if this is me - I am putting together a jqueryui add-on as a sample for the upcoming MEAP add-on chapter of Roo in Action. I am working in trunk, because by the time the book is finished and published we'll all be on the 1.2 line, and I would like to be as accurate as possible.

I'm not sure if I'm doing something wrong, or if there is a bug in the metadata container. I used addon create simple to set up my add-on, and am busy copying files into the project structure to install jQuery. Looking through the other add-ons, I'm extending the AbstractOperations class to provide file directory copy commands, but it's failing in this simple add-on.

The OperationsImpl class is defined this way:

@Component
@Service
public class JqueryuiOperationsImpl extends AbstractOperations implements JqueryuiOperations {
	private static final char SEPARATOR = File.separatorChar;

Then, in a command (for the curious, jqueryui setup), I do this:

        String webappPath = projectOperations.getPathResolver().getIdentifier(Path.SRC_MAIN_WEBAPP, "/");
        copyDirectoryContents("js/*.js", webappPath + "js", true);
        copyDirectoryContents("images/*.png", webappPath + "images", true);
        copyDirectoryContents("style/*.css", webappPath + "css", true);

Incidentally, for those getting started, quick tip: you can always add the debugging flags to your roo.sh script:

# Hop, hop, hop...
java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005 \
-Dis.apple.terminal=$APPLE_TERMINAL $ROO_OPTS -Droo.args="$*" -DdevelopmentMode=false -Dorg.osgi.framework.storage="$ROO_

and then use the remote debugger to run. I'm using the osgi start and osgi uninstall commands to add and remove the add-on bundles. Don't forget the development mode command to turn on stack traces.

Anyhoo...

I get a NPE because when the projectOperations asks for the path resolver, via the Project Meta-Data, it gets hung up looking for the meta-data and returns a null. Therefore the projectOperations.getPathResolver() call is null, which throws a null pointer exception for the .getIdentifier() method. Seems like the metadata isn't there.

I am using the nightly CI build of 1.2 from 8/7. I would be happy to share my add-on code (as I plan on donating it with roobot once the chapter is going).

Soooo.... is this a bug or something I'm doing wrong?

Thanks,

Ken

[krimple]

Oh, one more important thing...

Before I attempted to use projectOperations.getPathResolver()... I did this:

        String webappPath = "src/main/webapp/";
        copyDirectoryContents("js/*.js", webappPath + "js", true);

when I do that, it recurses up the directory path trying to find the top level, and bombs with:

roo> development mode 
Development mode set to true
roo> jqueryui setup   
java.lang.NullPointerException
    at org.springframework.roo.file.undo.CreateDirectory.<init>(CreateDirectory.java:40)
    at org.springframework.roo.process.manager.internal.DefaultFileManager.createDirectory(DefaultFileManager.java:90)
    at org.springframework.roo.classpath.operations.AbstractOperations.copyDirectoryContents(AbstractOperations.java:66)
    at org.rooina.addons.jqueryui.JqueryuiOperationsImpl.install(JqueryuiOperationsImpl.java:54)
    at org.rooina.addons.jqueryui.JqueryuiCommands.installTags(JqueryuiCommands.java:79)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.springframework.roo.support.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:191)
    at org.springframework.roo.process.manager.ProcessManagerHostedExecutionStrategy$1.callback(ProcessManagerHostedExecutionStrategy.java:49)
    at org.springframework.roo.process.manager.internal.DefaultProcessManager.doTransactionally(DefaultProcessManager.java:180)
    at org.springframework.roo.process.manager.internal.DefaultProcessManager.execute(DefaultProcessManager.java:143)
    at org.springframework.roo.process.manager.ProcessManagerHostedExecutionStrategy.execute(ProcessManagerHostedExecutionStrategy.java:47)
    at org.springframework.roo.shell.AbstractShell.executeCommand(AbstractShell.java:191)
    at org.springframework.roo.shell.jline.JLineShell.promptLoop(JLineShell.java:374)
    at org.springframework.roo.shell.jline.JLineShell.run(JLineShell.java:135)
    at java.lang.Thread.run(Thread.java:680)

The blowup happens on the second line of code up there- on the copyDirectoryContents method. So copyDirectoryContents won't work with a path that doesn't include a fully-formed path. It looks like it needs an absolute file path as internally there are creations of java.io.File objects with those names.

[Alan Stewart]

Soooo.... is this a bug

Probably yes

or something I'm doing wrong?

Probably no!

The distribution was built for 1.1.5 on Friday and so it may be too late to do anything about it now. We're waiting on STS integration sign-off. I'll try to reproduce the issue tomorrow.

Alan

[krimple]

I love your responses, Alan!

I am happy to get a fix in the git trunk for 1.2 as soon as we can reproduce. That way the chapter development can continue and we can help find any little bugs in the addon framework in 1.2 as we go along.

Thanks again!

Ken

[Alan Stewart]

Ken, I can't repropduce your issue as it works for me, however, as you created your add-on with the addon create simple command, you will have a FileManager reference in your operations impl class, but you also have extended AbstractOperations which also has a protected FileManager reference. I get NPEs on any fileManager method call when leaving the operations impl reference in but it all works OK if you use remove this reference and use the parent's. I don't know from your code if you have both.
Alan

[krimple]

Alan,

That seemed to get me past it. I at least now I'm getting a DOM error, which is fine by me and something I'm now able to debug.

So, it actually was pilot error on my part. Removing the file manager injection and reference fixed it.

Ken

Ken, I can't repropduce your issue as it works for me, however, as you created your add-on with the addon create simple command, you will have a FileManager reference in your operations impl class, but you also have extended AbstractOperations which also has a protected FileManager reference. I get NPEs on any fileManager method call when leaving the operations impl reference in but it all works OK if you use remove this reference and use the parent's. I don't know from your code if you have both.
Alan