Maven 2.x JBoss Plugin

startAndWait mojo needs a security manager

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 1.4.0
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    1

Description

The startAndWait mojo is not able to run successfully because it doesn't have an RMI security manager set up.

org.jboss.jmx.adaptor.rmi.RMIAdaptor (no security manager: RMI class loader disabled)

A security manager should be configured and a default security policy should be provided with the plugin.

Issue Links

Activity

Hide
Fuzail added a comment -

As a workaround you can specify the jbossall-client.jar as a dependency to the plugin

Show
Fuzail added a comment - As a workaround you can specify the jbossall-client.jar as a dependency to the plugin
Hide
Paul Gier added a comment -

Fixed in r10991.

Show
Paul Gier added a comment - Fixed in r10991.
Hide
Paul Gier added a comment -

Fuzail, you're right, that will work also. But I thought it would be nice to be able to call "startAndWait" without any additional configuration.

Show
Paul Gier added a comment - Fuzail, you're right, that will work also. But I thought it would be nice to be able to call "startAndWait" without any additional configuration.
Hide
Fuzail added a comment -

The change for the security manager fails on Windows systems that use the default temp directory. This is due to the spaces in the file path "Documents and Settings".

Show
Fuzail added a comment - The change for the security manager fails on Windows systems that use the default temp directory. This is due to the spaces in the file path "Documents and Settings".
Hide
Paul Gier added a comment -

When does the error happen? When creating the temp file? I don't have access to Windows so I can't reproduce this.
As a workaround, I could change the code so that if the temp file cannot be created, then the plugin still tries to run like it did before the security manager config was added.

Show
Paul Gier added a comment - When does the error happen? When creating the temp file? I don't have access to Windows so I can't reproduce this. As a workaround, I could change the code so that if the temp file cannot be created, then the plugin still tries to run like it did before the security manager config was added.
Hide
Paul Gier added a comment -

I found a Windows machine to use and was able to reproduce the problem. After trying various combinations of pounding my keyboard and banging my head against the wall, it seems that temp directory used for the security policy is not the problem. The problem is caused by the spaces in the path to the local Maven repository. If you change the local Maven repo to something without spaces, then all works as expected.

mvn jboss:start-and-wait -Dmaven.repo.local=c:\test\maven-repo

Conversely, the problem can be reproduced on Linux by setting the local repository to a path with spaces.

This seems to be related to an old bug in the surefire plugin (SUREFIRE-123).

I also tried this out with a snapshot of Maven 3, and the problem seems to be resolved. So I think there was a problem in the way Maven 2.x handled it's classpath.
At this point I don't know of an easy fix for this, so I will try to document the issue in the site docs to prevent other people from getting stuck on this in the future.

Show
Paul Gier added a comment - I found a Windows machine to use and was able to reproduce the problem. After trying various combinations of pounding my keyboard and banging my head against the wall, it seems that temp directory used for the security policy is not the problem. The problem is caused by the spaces in the path to the local Maven repository. If you change the local Maven repo to something without spaces, then all works as expected.
mvn jboss:start-and-wait -Dmaven.repo.local=c:\test\maven-repo
Conversely, the problem can be reproduced on Linux by setting the local repository to a path with spaces. This seems to be related to an old bug in the surefire plugin (SUREFIRE-123). I also tried this out with a snapshot of Maven 3, and the problem seems to be resolved. So I think there was a problem in the way Maven 2.x handled it's classpath. At this point I don't know of an easy fix for this, so I will try to document the issue in the site docs to prevent other people from getting stuck on this in the future.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: