Nukes on OSX - ear not copied, deployed but does not map?

[kgelner]

I followed the instructions located here:

http://www.jboss.org/developers/projects/nukes/build

with the exception that I am using Postgres instead of mySql (to get that to work I had to add the line "nukes.database=postgresql" to the build/local.properties file that was created by my copying up the build/etc/postgressql.properties, but I digress...).

Now the build from "build" seems to work OK, as does the build from the "nukes" directory - though at the end of that build the nukes.ear file was oddly not copied to the jboss server/default/deploy directory.

I copied that to JBoss myself, made sure my nukes DB was created with the generated DDL file, created a "nukes" user in the DB, then created a "nukes" directory in jboss/server/default.

Then I started JBoss. I could see Nukes deploying, it seemed all went well - here's a snippet at the end of the deployment process:

23:06:18,076 INFO [EARDeployer] Started J2EE application: file:/Users/kgelner/JavaTools/jboss-3.2.3RC1/server/default/deploy/nukes.ear
23:06:18,077 INFO [MainDeployer] Deployed package: file:/Users/kgelner/JavaTools/jboss-3.2.3RC1/server/default/deploy/nukes.ear

So everything looks great, except that the URL http://localhost:8080/nukes/ does not work - I just get an invalid request page from JBoss and a mapping error in the log:

23:06:27,033 INFO [Engine] StandardHost[localhost]: MAPPING configuration error for request URI /nukes/

Any idea how the mapping could be wrong? It seems like I'm on the verge of having this work.

Thanks,

---> Kendall

[kgelner]

I ran across this useful WIKI page on Nukes installation:

http://jboss.org/wiki/Wiki.jsp?page=InstallUninstallUpgrade

And followed the instructions there. Those directions do work better, in that the second build phase copies the installer EAR file as it should (although for the last step, running build deploy-installer, I had to create the variable "nukes.deploy.dir" and set it to "default" to have the installer work). I can run the installer OK, go through all the steps, and at the end it says it installed OK. I can see the nukes directory in Jboss with all the sar files for the modules I selected, and see the nukes.ear file. But still when I try the nukes URL (localhost:8080/nukes) I get a mapping error. Is this an error in the current build that I need to wait a day or two to clear out?

Thanks,

---> Kendall

[thepriz]

The install process has changed a little. You don't have to copy the build/etc/postgressql.properties file to the build directory. You just have to change the nukes.database property in the local.properties file to postgressql. This tells nukes to also use the postgressql.properties file in the build/etc directory.

[kgelner]

I finally am up and running. Two comments on the fixes required:

1) There is no "local.properties" (at least in the snapshot I downloaded). The most correct action to take for everyone out there wanting to build seems to be to copy the build/etc/local.properties.sample to build/local.properties, then edit the desired DB name (like postgresql). You can ignore all that other stuff I posted related to local.properties.

2) That still doesn't quite get you all the way. After building in build and distrib as described in my other messages, and then running the installer - everything is in place OK EXCEPT that for some reason the nukes.ear/META-INF/application.xml gets created without a tag being replaced - the tag "@nukes.context-root@" lingers behind and needs to be replaced with "/nukes". Then you can re-jar the ear file (jar -Mcvf nukes.ear <allnukefiles including META-INF>) and copy that back into jboss/server/default/deploy. Mine installation worked fine after that. I thought I looked at that file yesterday but guess I overlooked it.

Possibly if nukes.context-root were defined in the local.properties as "@nukes-context.root@" (or if the template application.xml were altered the other way) it would work. I'll investigate later, I'm just happy to be able to play with nukes for the moment (now there's a statement that should raise a few security filters somewhere).