As you may have heard, JBoss AS 7 is now packaged in Fedora 17. It can be installed using the YUM package manager:
yum install jboss-as
This package not only puts JBoss AS 7 on your system, it also makes it a bonafide system service. You start the service using the service command:
service jboss-as start
The service runs as the jboss-as user. The main installation directory is /usr/share/jboss-as, though the executables are in /usr/bin and the logs in /var/log/jboss-as.
JBoss Tools: Prerequisties
It's necessary to create a management user in order for JBoss Tools to control the server:
JBoss Tools: What works
JBoss Tools detects the installation when the scanner is pointed at /usr/share/jboss-as and properly sets up a server runtime. (The server configuration needs to be updated to mark the server as externally managed since JBoss Tools is not privy to the startup scripts anymore, nor would the user have the proper permissions). Navigating the management interface in the Server view works as expected.
JBoss Tools: What doesn't work
What JBoss Tools is unable to do is deploy an application to the server (for example the numberguess quickstart). The problem is that JBoss Tools tries to copy files into the /usr/share/jboss-as/standalone/deployments directory, but doesn't have permission to write to this directory.
An obvious quickfix is to add the user to the jboss-as group and change the permission of /var/lib/jboss-as/standalone/deployments to 664 w/ the group sticky flag set (so that the file is written with the group set to jboss-as).
However, I think the way it should work is that JBoss Tools should deploy the application using the management interface. Currently, this would require deploying the application as a packaged war. The server runtime can be configured to deploy a packaged war, but JBoss Tools still tries to copy the archive to the deployment folder rather than using the management interface deployment API.
Ideally, JBoss Tools should support incremental deployment over the management interface rather than a direct file system copy. Another approach would be to tell the management interface to look in a different location for a deployment (maybe that's possible already).
Long story short, I don't see a way currently to use JBoss Tools with JBoss AS 7 installed from the RPM package because of permission issues. Changing the file permissions and elevating the permissions of the user is one workaround. Ideally, though, JBoss Tools would support this use case without requiring any special customization. It would also be nice if JBoss Tools could add a management user (replacing the call to the add-user.sh command). Finally, it would be great if JBoss Tools could start and stop the jboss-as service (through the use of sudo).
This is new territory for JBoss Tools and I'm excited to see us get to a seamless out of the box experience.
Btw, if there is a way to do this, we should create another set of screenshots for how to deploy the application to JBoss AS 7 using JBoss Tools as an addendum to the slideshow I linked to above. I'd be happy to make those screenshots if I know how to get JBoss Tools to stop copying files directly to the deployment directory.
Dan, thanks a million for doing this - I tried the earlier versions of JBoss AS 7 on Fedora but at that time the permissions was so bad I couldn't even run AS7 as root and haven't had time since to try it.
You suggestion about using management API is fine, but will not happen as long as AS7 management API does not provide a way to do incremental updates (i.e. update jsf, html etc.) and if you have a 10-20 mb EAR you have to upload that constantly - it would make the iterative development experience rather bad. Thus we have not focused on this usecase.
What you can do is open the server editor and click the "Deployment" tab - here you can see it has three options:
Deploy to AS7 (the default)
Deploy to Workspace (will be stored inside eclipse workspace)
Deploy to custom location (you decide where it goes)
If the two last options are greyed out for you then it is because you are using an older version of JBoss Tools which did not talk to the management interface to add custom locations - since Beta2 that should though happen. I recommend you try with Beta3.
Let me know how that goes.
p.s. its a shame Fedora doesn't allow you to run AS7 as a user so you can identify the secret key that would avoid having to add a management user ;(
Thanks for the insight. I'll try out those strategies and report back.
I forgot to mention that I am using the JBoss Developer Studio 5 Beta 3 (i.e., the latest and greatest). I'll stay current with the latest development releases as I explore this scenario.
Btw, Fedora does provide a way to run an instance of JBoss AS 7 as a user. The command jboss-as-cp creates a new installation in your home directory (location of choice) that consists only of the writable files, with links to all the read-only files (call it a skinny instance). That's the second scenario to research. I had trouble with it in the Fedora Beta (could have been user error), so I need to give it a try with the final release.
While I agree that deploying huge archives on each cycle is not good for iterative development, I still think it should be supported. It's just a matter of pushing the archive over the management interface rather than a direct copy.
Incremental updates over the management interface would be killer.
Btw, I'll likely retract my request to have JBoss Tools start the system service. That's probably out of scope for JBoss Tools server runtimes. However, if there is a way in JBoss Tools to use a shell command (I believe there is an integrated shell) that will do the trick.
This issue is partly documentation, partly feature request. We can probably come up with documentation to make it work as is, but if we can close the gap on the requests, that documentation will read better
JBoss + Fedora FTW!
As you mentioned, the jboss-as-cp script is meant to be use in scenarios like developing on JBT. If it doesn't work - we need to fix it This is also the goal of the JBoss Fedora Spin, so it'll be usefull for everyone to have it working.
Let's do it!
To be a little clearer on what I'm going to test:
- User instance: Use jboss-as-cp to create a user instance of JBoss AS 7, then get JBoss Tools to control and deploy to it
- System instance: Change the permissions of the deployment directory and ensure that JBoss Tools can deploy via it's file copy approach (both exploded/incremental and packaged)*
- Also use the Eclipse command shell to enter the command to start and stop the service to self-contain tutorial to Eclipse
* If JBoss Tools could deploy the packaged archive over the management interface, then the permission change wouldn't be necessary for deploying the packaged archive (the exploded/incremental use case would still require the permissions change)
#1 is the default and preferred use case.
#2 Could be tricky, as the file permission will be changed and you need to make sure, the jboss-as CLI for example is able to undeploy it fully afterwards. But again, this is not ideal case, because the system wide service should be used for "production" deployments, not development.
The lab results are in!
I created a fresh Fedora 17 installation on a virtual machine, installed JBoss AS 7 using yum (yum install jboss-as), installed JBoss Developer Studio 5 Beta 3 and gave another crack at these use cases.
Preparing a user instance with jboss-as-cp
I'm happy to report that jboss-as-cp works as expected. Here's what I did to create a test a new "user instance":
mkdir $HOME/applications jboss-as-cp -l $HOME/applications/jboss-as-user-instance
* Not that the -c option doesn't work in the jboss-as-cp command because the switch statement is missing a colon after the "c". It should be:
while getopts "hc:l:" OPTION
JBOSS_BASE_DIR=$HOME/applications/jboss-as-user-instance /usr/share/jboss-as/bin/standalone.sh -c standalone-web.xml
Verify it's running:
With that working, I switched over to JBoss Tools to setup the server runtime to work against that externally managed instance.
Deploying to the user instance from JBoss Tools
I began by defining a new server runtime. This can be done one of two ways:
- Pointing the JBoss Tools runtime scanner at /usr/share/jboss-as and letting it detect and create both the server runtime and server
- Adding a new JBoss AS 7.1 server runtime, setting the home directory (of the runtime) to /usr/share/jboss-as and adding a server to match
It's important to check the box "Server is external managed. Assume server is started." (for this part, at least).
By default, JBoss Tools is going to use the JBoss deploy folder (/usr/share/jboss-as/standalone/deployments) to perform deployments. You can see this by double clicking on the server in the Servers view and switching to the Deployment tab.
That's obviously not what we want. We need JBoss Tools to deploy into our user instance ($HOME/applications/jboss-as-user-instance/deployments). In theory, this is done one of two ways:
- Checking the radio button "Use workspace metadata"
- Checking the radio button "Use a custom deploy folder"
- Deploy Directory: /home/username/applications/jboss-as-user-instance/deployments
- Temporary Deploy Directory: /home/username/applications/jboss-as-user-instance
In addition to changing where JBoss Tools deploys the application, this also adds a deployment scanner entry in standalone-web.xml:
<deployment-scanner name="JBossToolsScanner1" path="/home/username/workspace/.metadata/.plugins/org.jboss.ide.eclipse.as.core/JBoss_AS_7.1_Server/deploy" scan-interval="5000"/>
<deployment-scanner name="JBossToolsScanner1" path="/home/username/applications/jboss-as-user-instance/deployments" scan-interval="5000"/>
Save the configuration and start (connect to) the server by clicking the play button in the Servers tab.
In theory, I should now be able to import a web project (such as numberguess from the JBoss quickstarts), drag it to the server and it should deploy. However, all I get is #fail.
JBoss Tools is copying the folders into the deployment directory specified in the server configuration, but it's failing to copy any files. Here's a listing showing what it does copy:
./log ./log/server.log ./log/boot.log ./tmp ./tmp/vfs ./tmp/vfs/temp4d99614473916964 ./tmp/work ./tmp/work/jboss.web ./tmp/work/jboss.web/default-host ./tmp/auth ./deployments ./deployments/jboss-as-helloworld.war ./deployments/jboss-as-helloworld.war/WEB-INF ./deployments/jboss-as-helloworld.war/WEB-INF/lib ./deployments/jboss-as-helloworld.war/WEB-INF/classes ./deployments/jboss-as-helloworld.war/WEB-INF/classes/org ./deployments/jboss-as-helloworld.war/WEB-INF/classes/org/jboss ./deployments/jboss-as-helloworld.war/WEB-INF/classes/org/jboss/as ./deployments/jboss-as-helloworld.war/WEB-INF/classes/org/jboss/as/quickstarts ./deployments/jboss-as-helloworld.war/WEB-INF/classes/org/jboss/as/quickstarts/helloworld ./deployments/jboss-as-helloworld.war/META-INF ./deployments/jboss-as-helloworld.war/META-INF/maven ./deployments/jboss-as-helloworld.war/META-INF/maven/org.jboss.as.quickstarts ./deployments/jboss-as-helloworld.war/META-INF/maven/org.jboss.as.quickstarts/jboss-as-helloworld ./configuration ./configuration/logging.properties ./configuration/mgmt-users.properties ./configuration/standalone-web.xml
Here is the message in the Eclipse error log:
!ENTRY org.jboss.ide.eclipse.as.core 4 1644298242 2012-06-01 03:11:10.100 !MESSAGE Full publish failed for module jboss-as-helloworld !SUBENTRY 1 org.eclipse.wst.server.core 4 1644298251 2012-06-01 03:11:10.100 !MESSAGE Error copying file META-INF/MANIFEST.MF: Permission denied !SUBENTRY 1 org.eclipse.wst.server.core 4 1644298251 2012-06-01 03:11:10.100 !MESSAGE Error copying file META-INF/maven/org.jboss.as.quickstarts/jboss-as-helloworld/pom.properties: Permission denied !SUBENTRY 1 org.eclipse.wst.server.core 4 1644298251 2012-06-01 03:11:10.100 !MESSAGE Error copying file META-INF/maven/org.jboss.as.quickstarts/jboss-as-helloworld/pom.xml: Permission denied !SUBENTRY 1 org.eclipse.wst.server.core 4 1644298251 2012-06-01 03:11:10.100 !MESSAGE Error copying file WEB-INF/classes/org/jboss/as/quickstarts/helloworld/HelloService.class: Permission denied !SUBENTRY 1 org.eclipse.wst.server.core 4 1644298251 2012-06-01 03:11:10.100 !MESSAGE Error copying file WEB-INF/classes/org/jboss/as/quickstarts/helloworld/HelloWorldServlet.class: Permission denied !SUBENTRY 1 org.eclipse.wst.server.core 4 1644298251 2012-06-01 03:11:10.100 !MESSAGE Error copying file WEB-INF/beans.xml: Permission denied !SUBENTRY 1 org.eclipse.wst.server.core 4 1644298251 2012-06-01 03:11:10.100 !MESSAGE Error copying file index.html: Permission denied
I have no clue where it's trying to copy the files, but clearly it's trying to put them someplace it shouldn't. This indicates to me it's trying to write files outside of my home directory (it's implausable that a file write would fail inside my home directory, where it should be copying the files).
I hypothesize that JBoss Tools (or something in WST) is not properly sandboxing the deployment directory from the installation directory.
Controlling the user instance from JBoss Tools
With a bit of tweaking, I was able to figure out how to get JBoss Tools to control the user instance so that it works just like a normal server inside of Eclipse.
- Delete the existing server, then add a new server as before. This time, keep the box "Server is external managed" unchecked.
- Switch to the Deployment tab and check either "Use workspace metadata" or "Use a custom deploy folder" as explained above
- Switch back to the Overview tab and click on "Open launch configuration"
- Uncheck the box "Always update program arguments related to the runtime"
- In the Program arguments textarea, make sure the --server-config=standalone-web.xml
- In the VM arguments textarea, remove any properties that contain the path /usr/share/jboss-as and add these properties:
- Click OK
- If necessary, save the Server configuration
Make sure JBoss AS is not running in a terminal. Then click on the play button in the Servers tab. You should see JBoss AS starting up in the Eclipse Console tab.
Unfortunately, deployment still fails with the same error as above. How the server is started seems unrelated to the deployment problem.
We remain at an impasse until we can figure out why JBoss Tools (or WST) is not properly copying the files to the custom deployment directory.
(If there is a way to get more verbose information from the logs, let me know and I'll report that information).
I like the idea of jboss-as-cp, but I don't think it has the right name. I'd like to propose the following alternatives:
- jboss-as-instance (consistent with the equivalent command for tcServer)
- jboss-as-create-instance (a bit more explicit about what it's doing)
- jboss-as-new-instance (a bit shorter, just as clear)*
- jboss-as-create (implies instance, if we really want to keep it short)
* my preferred choice so far
It would be nice if JBoss Tools could perform the setup done by jboss-as-cp. It's not necessary to use the jboss-as-cp as it's just a few copy commands. I envision this as another checkbox in the Server setup wizard. I don't think this is specific to Linux, so it's reasonable to make it a general option when defining a JBoss AS 7 server.
The code that creates the directories are the exact same code that copies files.
So this is very strange.
Any chance the location of tmp and deployment is on two different file systems ?
Then the mv function could fail (really annoying bug because Java can't tell us if paths are on different filesystems)
To know if this is the case go to deployment tab and set the "Temporary deployment folder" to a temp folder that is on the same filesystem as where your are deploying to.
The location of the tmp and deployment directories are on the same filesystem.
However, the location of the JBoss AS *installation* and the user instance (where the tmp and deployment folders are located) are different filesystems. In other words, / and /home are two different filesystems (they are different logical volumes).
I think I've narrowed down the issue. I don't know how to solve it yet, but I at least know the precise circumstances that cause the problem.
First, I ruled out any issue with the JBoss Tools install or a discrepancy with what the Fedora package installs by working with a zip download from jboss.org. I extracted the zip file, setup a new runtime and server, started it and successfully deployed the helloworld application. So that works as expected.
My suspicion is that the problem occurs when JBoss Tools can't write to the JBoss AS installation. To prove this, I followed these steps:
- I changed the ownership of the entire JBoss AS installation to root (both user and group permission)
- I created a management user (admin / admin123) and verified I could use jboss-cli -c as non-root to connect to it
- I started the server as the root user
- I setup a new runtime and server for this installation, marked it as externally managed and set the management user to admin / admin123
- I configured the server to use a custom deploy folder (both deployments and tmp) that are owned by my user (i.e., not owned by root)
- I started the server in JBoss Tools, effectively connecting to the server, and verified that the deployment scanner was updated to scan the custom deploy folder
- I attempted to deploy the helloworld application by dragging the project folder to the server
Once again, the deployment failed. It created the directories in the custom deploy folder, but reported the same error as above when attempting to write the files.
My hypothesis is that the error message we are seeing is a veil. It's possible the failure is coming from an operation further up the chain. From changing the ownership of the installation to root, it's pretty clear that JBoss Tools is attempting to write something into the installation directory when it shouldn't be.
So, the problem isn't that JBoss Tools is trying to put the files in the wrong place. The problem is that it's trying to perform a write operation in the installation sometime between when it creates the directories and when it moves the files into them. It may have something to do with the manifest file, though that's just a stab in the dark.
You should be able to reproduce this on OSX since it's also a *nix operation system (though I suppose Windows also has file permission controls).