jboss-dockerfiles / wildfly

Docker image for WildFly project

WildFly Docker image

This is an example Dockerfile with WildFly application server.

---

NOTE

Official builds for this image are now published to https://quay.io/wildfly/wildfly.
Previous repository at https://hub.docker.com/r/jboss/wildfly is no longer updated with new images.

---

WildFly Images

WildFly publishes images to run the application server with different JDK versions. The tag of the image identifies the version of WildFly as well as the JDK version in the images.

For each release of WildFly (e.g. 28.0.0.Final), there are fixed tags for each supported JDK version:

• quay.io/wildfly/wildfly:28.0.0.Final-jdk11
• quay.io/wildfly/wildfly:28.0.0.Final-jdk17
• quay.io/wildfly/wildfly:28.0.0.Final-jdk20

There are also floating tags available to pull the latest release of WildFly on the various JDK:

• quay.io/wildfly/wildfly:latest-jdk11
• quay.io/wildfly/wildfly:latest-jdk17
• quay.io/wildfly/wildfly:latest-jdk20

Finally, there is the latest tag that pull the latest release of WildFly on the latest LTS JDK version:

• quay.io/wildfly/wildfly:latest

---

NOTE

This floating tag may correspond to a different JDK version in future releases of WildFly images.

Instead of using the latest tag, we recommend to use the floating tag with the JDK version mention to guarantee the use of the same JDK version across WildFly releases (e.g. latest-jdk17).

---

Usage

To boot in standalone mode

docker run -it quay.io/wildfly/wildfly

To boot in standalone mode with admin console available remotely

docker run -p 8080:8080 -p 9990:9990 -it quay.io/wildfly/wildfly /opt/jboss/wildfly/bin/standalone.sh -b 0.0.0.0 -bmanagement 0.0.0.0

To boot in domain mode

docker run -it quay.io/wildfly/wildfly /opt/jboss/wildfly/bin/domain.sh -b 0.0.0.0 -bmanagement 0.0.0.0

Application deployment

With the WildFly server you can deploy your application in multiple ways:

1. You can use CLI
2. You can use the web console
3. You can use the management API directly
4. You can use the deployment scanner

The most popular way of deploying an application is using the deployment scanner. In WildFly this method is enabled by default and the only thing you need to do is to place your application inside of the deployments/ directory. It can be /opt/jboss/wildfly/standalone/deployments/ or /opt/jboss/wildfly/domain/deployments/ depending on which mode you choose (standalone is default in the jboss/wildfly image -- see above).

The simplest and cleanest way to deploy an application to WildFly running in a container started from the quay.io/wildfly/wildfly image is to use the deployment scanner method mentioned above.

To do this you just need to extend the quay.io/wildfly/wildfly image by creating a new one. Place your application inside the deployments/ directory with the ADD command (but make sure to include the trailing slash on the deployment folder path, more info). You can also do the changes to the configuration (if any) as additional steps (RUN command).

A simple example was prepared to show how to do it, but the steps are following:

1. Create Dockerfile with following content:

    FROM quay.io/wildfly/wildfly
    ADD your-awesome-app.war /opt/jboss/wildfly/standalone/deployments/
   

2. Place your your-awesome-app.war file in the same directory as your Dockerfile.

3. Run the build with docker build --tag=wildfly-app .

4. Run the container with docker run -it wildfly-app. Application will be deployed on the container boot.

This way of deployment is great because of a few things:

1. It utilizes Docker as the build tool providing stable builds
2. Rebuilding image this way is very fast (once again: Docker)
3. You only need to do changes to the base WildFly image that are required to run your application

Logging

Logging can be done in many ways. This blog post describes a lot of them.

Customizing configuration

Sometimes you need to customize the application server configuration. There are many ways to do it and this blog post tries to summarize it.

Extending the image

To be able to create a management user to access the administration console create a Dockerfile with the following content

FROM quay.io/wildfly/wildfly
RUN /opt/jboss/wildfly/bin/add-user.sh admin Admin#70365 --silent
CMD ["/opt/jboss/wildfly/bin/standalone.sh", "-b", "0.0.0.0", "-bmanagement", "0.0.0.0"]

Then you can build the image:

docker build --tag=jboss/wildfly-admin .

Or for JDK 11, JDK 17+ :

docker build --build-arg dist=ubi9-minimal --build-arg jdk=11 --tag=jboss/wildfly-admin .

Run it:

docker run -it jboss/wildfly-admin

Administration console will be available on the port 9990 of the container.

Building on your own

You don't need to do this on your own, because we prepared a trusted build for this repository, but if you really want:

docker build --rm=true --tag=jboss/wildfly .

Image internals [updated May 15, 2023]

This image extends the eclipse-temurin JDK. Starting with JDK 11, this base OS used is ubi9-minimal. A UBI 9 image to validate the build arguments provided.

This image installs the wildfly server and sets up the JBoss environment similar to jboss/base image. Please refer to the README.md for selected images and more info.

The server is run as the jboss user which has the uid/gid set to 1000.

WildFly is installed in the /opt/jboss/wildfly directory.

Source

The source is available on GitHub.

Issues

Please report any issues or file RFEs on GitHub.

wildfly's Issues

Update to java8 u71 or u72

The base image used by this image has been last updated a year ago and still uses the u51 (!) release of java 8. This leaves all docker wildfly containers based on this image vulnerable to a large number of CVEs http://www.oracle.com/technetwork/topics/security/cpujan2016-2367955.html

I know that this is an issue caused by the base image, however it seems that nobody is interested in fixing this. All it would take is to provide a new build of the base image, as the u71 version is already in the CentOS 7 repositories.

Latest update breaks Java font handling (e.g. renders Jasper Reports unusuable)

The "stix" fonts coming with the underlying CENTOS 7.4 release mess up Java font handling.

java.lang.ArrayIndexOutOfBoundsException: 0
at sun.font.CompositeStrike.getStrikeForSlot(CompositeStrike.java:75)
at sun.font.CompositeStrike.getFontMetrics(CompositeStrike.java:93)
at sun.font.Font2D.getFontMetrics(Font2D.java:415)
at java.awt.Font.defaultLineMetrics(Font.java:2176)
at java.awt.Font.getLineMetrics(Font.java:2246)
at net.sf.jasperreports.engine.fill.SimpleTextLineWrapper.determineLeading(SimpleTextLineWrapper.java:390)
at net.sf.jasperreports.engine.fill.SimpleTextLineWrapper.getGeneralFontInfo(SimpleTextLineWrapper.java:342)
...

Something along the lines of:

USER root
RUN yum erase stix-fonts.noarch
RUN yum erase stix-math-fonts.noarch

should help. [Edit: but doesn't. For some inexplicable reason, the stix fonts are a dependency of openjdk and openjdk is uninstalled when you remove the fonts ???!]

not being able to pull newest 10.1.0.Final tag

When I execute docker pull wildfly:10.1.0.Final, I get a docker image from 3 months ago:

 ~ docker images | grep wildfly | grep 10.1.0.Final
jboss/wildfly                                               10.1.0.Final        ab149aa45b9f        3 months ago        584 MB
 ~ docker pull jboss/wildfly:10.1.0.Final
10.1.0.Final: Pulling from jboss/wildfly
Digest: sha256:2b39a89c16854b12706988b8dd959e7873241b8bbaf4e489abe59c69050a7656
Status: Image is up to date for jboss/wildfly:10.1.0.Final

Checking the build logs, it is indeed an image that was built 3 months ago:
https://hub.docker.com/r/jboss/wildfly/builds/bnir2pcakvwa9qsguypj59g/

Successfully built ab149aa45b9f

Pushing index.docker.io/jboss/wildfly:10.1.0.Final...
Done!
Build finished

However the latest build hints at the latest version having a different hash:
https://hub.docker.com/r/jboss/wildfly/builds/bvjraxtuzpj4hsd2wzwrca7/

Successfully built 6b55314cbdf8

Pushing index.docker.io/jboss/wildfly:10.1.0.Final...
Done!
Build finished

This shows, there is either some issue with images on docker.io, but could be my host as well, not sure.

Java 8 tags?

The way that the maven docker repo does their tags is that they have different tags for different versions of java. Would that be a good fit for the wildfly docker repo?

Get permission denied error

I tried the following command to start a wildfly instance, but I got a permission denied error.

$ docker run -it jboss/wildfly
2015/03/11 05:55:42 permission denied

I can start the instance with -u root option, but the Dockerfile intends to run the program as jboss user.
I wonder the jboss user should be able to log in to execute the command.
Now, jboss user's login shell is /sbin/nologin.

$ docker run -it -u root jboss/wildfly grep jboss /etc/passwd
jboss :x :1000:1000:JBoss user:/opt/jboss:/sbin/nologin

Wildfly 11.0.0.Final tag

Create a tag for Wildfly 11.0.0.Final

Have 10.1.0.Final and latest tags share the same hash

Checking the builds, currently the 'latest' tag is built with the same checkout as '10.1.0.Final'.
It would be nice if these two builds would share the same image with 'latest' only being an alias for the '10.1.0.Final' tag.

OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=256m

Hello,

My name is Patrick Dallaire, I am a intern for Tecsys Inc. in Montreal Canada.

We've been using Wildfly for a long time and for the first time now we are experimenting with Docker.
Now this isn't a big deal, in fact everything still works, but every time we use 'docker log containerName' command we could see the following error message:

OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0

According to what I’ve read, the command line argument for java, -XX:MaxPermSize, was deprecated in Java 8.

Oracle compatibility-guide
Oracle tech notes

This argument is probably used by the wildfly scripts we use to launch our instance. In our case we use:
/opt/jboss/wildfly/bin/standalone.sh -c standalone-full.xml -b 0.0.0.0

The deprecated argument shows up in at the following locations inside our running container:

[root@feaf7375338f jboss]# grep -rnw '/opt/jboss' -e "JAVA_OPTS" | egrep 'MaxPermSize'
/opt/jboss/wildfly/bin/appclient.conf:45:   JAVA_OPTS="-Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true"
/opt/jboss/wildfly/bin/appclient.conf.bat:43:set "JAVA_OPTS=-Xms64M -Xmx512M -XX:MaxPermSize=256M"
/opt/jboss/wildfly/bin/domain.conf:45:   JAVA_OPTS="-Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true"
/opt/jboss/wildfly/bin/domain.conf.bat:46:set "JAVA_OPTS=-Xms64M -Xmx512M -XX:MaxPermSize=256M"
/opt/jboss/wildfly/bin/standalone.conf:50:   JAVA_OPTS="-Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true"
/opt/jboss/wildfly/bin/standalone.conf.bat:49:set "JAVA_OPTS=-Xms64M -Xmx512M -XX:MaxPermSize=256M"

Even though this isn't a big a deal, especially since I can redirect the standard error, I thought you should still be informed.

Have a nice day.

Could PATH include /opt/jboss/wildfly/bin?

Could /opt/jboss/wildfly/bin be added to the PATH environment variable?
That way jboss-cli.sh could be run without having to type "./wildfly/bin/jboss-cli.sh". Also it seems like the working directory should be /opt/jboss/wildfly but I guess it's kind of late to change that now.

Fix permisssions to be able to run the image on OpenShift with random user

Currently, provided the permissions set for /opt/jboss the image does not work on an OpenShift installation OOTB with a restricted SCC (the default). We should change permissions to this (and maybe base) images so that this image can be deployed on OpenSHift OOTB without modifications.

Have multicast enabled

This image doesn't have multicast enabled on its interface. It should be enabled to allow easy clustering.

Unable to see the admin console - solved, sort of

I was having a hard time connecting the the console but sort of solved it, except for one thing. I thought this might help others. There are a couple of things that still don't work/I don't understand, so would be useful to me to get answers for those.

I'm trying to run the latest wildfly 8.2 in a container running on a Mac, so using boot2docker.

I've followed the instructions in https://github.com/jboss-dockerfiles/wildfly/blob/master/README.md and built a new image, adding the following as instructed

FROM jboss/wildfly
RUN /opt/jboss/wildfly/bin/add-user.sh admin admin --silent

I then start the container using
docker run -it -p8080:8080 -p 9990:9990 jboss/wildfly-admin

And then access the app as instructed, but get "This webpage is not available" http://192.168.59.103:9090 and http://192.168.59.103:9090/console
http://192.168.59.103:8080 is fine, but the link to admin console fails with unable to redirect, suggesting the interface the admin console is running on is different

The suggestion in #3 is to bind the management interfaces to 0.0.0.0 like this
docker run -it -p 8123:8080 -p 9123:9990 jboss/wildfly-custom /opt/jboss/wildfly/bin/domain.sh -b 0.0.0.0 -bmanagement 0.0.0.0 -Djboss.management.http.port=8124
NOTE, this also moves from me using standalone.sh to using domain.sh and it also adds -Djboss.management.http.port=8124

This gives me "No Console Active - The server configuration does not appear to have an active console. If you are running a standalone server check the http interface is enabled in the standalone.xml configuration, if you are running a domain the http interface can not be automatically detected so check the host.xml configuration and connect directly."

I try changing the 0.0.0.0 interface above to the boot2docker VM address, 192.168.59.103, but this results in errors on start up so I reverted to 0.0.0.0

[Host Controller] 09:54:07,065 ERROR [org.jboss.msc.service.fail](MSC service thread 1-2) MSC000001: Failed to start service jboss.network.management: org.jboss.msc.service.StartException in service jboss.network.management: JBAS015810: failed to resolve interface management
[Host Controller] at org.jboss.as.server.services.net.NetworkInterfaceService.start(NetworkInterfaceService.java:96) [wildfly-server-8.2.0.Final.jar:8.2.0.Final]
[Host Controller] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
[Host Controller] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
[Host Controller] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_65]
[Host Controller] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_65]
[Host Controller] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]

I then moved back from domain.sh to standalone.sh and removed the -Djboss.management.http.port=8124, so
$ docker run -it -p 8080:8080 -p 9990:9990 jboss/wildfly-admin /opt/jboss/wildfly/bin/standalone.sh -b 0.0.0.0 -bmanagement 0.0.0.0
and I can now access the app at 8080 and the console via the link from the app and directly on 9990

I can add the -Djboss.management.http.port=xxxx back in but the port must match the one specified on the docker run command -p 9990:9990. If I try an other I get a 404

Switching back to domain.sh, I can also access the console but only directly. I can't access it via the link on the page at 8080.

It suggests "if you are running a domain the http interface can not be automatically detected so check the host.xml configuration and connect directly."

This is not clear to me but there is a property in host.xml that matches -Djboss.management.http.port which looks like it defaults to 9990, so looks correct. There are references to bins addresses but we're already specifying these on the docker run command line so I'm really not sure what needs to change here.

I hope this helps others to connect to the console.

Be good to know what is meant by that message though so we know what to change in the host.xml file.

Provide tagged builds

Reported initially as https://issues.jboss.org/browse/WFLY-3996.

Unable to redirect to Administration Console

I'm trying to access Administration Console and getting following message:

Unable to redirect.

An automatic redirect to the Administration Console is not currently available. This is most likely due to the administration console being exposed over a network interface different from the one to which you are connected to.

To access the Administration console you should contact the administrator responsible for this WildFly installation and ask them to provide you with the correct address.

Please advise.

Not able to deploy war jboss/wildfly using docker file

| i am trying to create a image of jboss/wildfly that can be used for war deployment, Below is that docker file i have used for creating image.
But when i run the container with "docker run -p 9990:9990 hello" command jboss server is staring but the war palced in deployment folder is not deploying.
-- | --

FROM jboss/wildfly

## allow custom external configuration
ADD standalone-full-poc.xml /opt/jboss/wildfly/standalone/configuration/

ADD modules /opt/jboss/wildfly/modules/

## Create EAP User
RUN /opt/jboss/wildfly/bin/add-user.sh admin admin@123 --silent

## Add eTransfer war to Deployment folder
ADD eTransfer.war /opt/jboss/wildfly/standalone/deployments/

## Start Jboss EAP
CMD ["/opt/jboss/wildfly/bin/standalone.sh", "-c", "standalone-full-poc.xml", "-b", "0.0.0.0", "-bmanagement", "0.0.0.0"]

Permission problem

hi, i need help to run yum update and yum install maven. But when I run this command I need the root password. Somebody help me?

tks

Building a custom docker image

I'm an absolute docker n00b. We repackage the app server w/ additional modules. I'd like to copy the app server from my local dir into the docker image. I took the wildfly dockerfile as an example, however I can't get past this error. The build works fine, but the server start fails.

# Use latest jboss/base-jdk:7 image as the base
FROM jboss/base-jdk:8

# Set the WILDFLY_VERSION env variable
ENV JBOSS_HOME /opt/jboss/wildfly-10.0.0.CR4

ADD wildfly-10.0.0.CR4 $JBOSS_HOME

# Ensure signals are forwarded to the JVM process correctly for graceful shutdown
ENV LAUNCH_JBOSS_IN_BACKGROUND true

# Expose the ports we're interested in
EXPOSE 8080
EXPOSE 9990

# Set the default command to run on boot
# This will boot WildFly in the standalone mode and bind to all interface
CMD ["/opt/jboss/wildfly-10.0.0.CR4/bin/standalone.sh", "-b", "0.0.0.0", "-bmanagement", "0.0.0.0"]

This fails to run afterwards with this error

java.lang.IllegalArgumentException: Failed to instantiate class "org.jboss.logmanager.handlers.PeriodicRotatingFileHandler" for handler "FILE"
    at org.jboss.logmanager.config.AbstractPropertyConfiguration$ConstructAction.validate(AbstractPropertyConfiguration.java:116)
    at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:335)
    at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:288)
    at org.jboss.logmanager.config.LogContextConfigurationImpl.commit(LogContextConfigurationImpl.java:297)
    at org.jboss.logmanager.PropertyConfigurator.configure(PropertyConfigurator.java:546)
    at org.jboss.logmanager.PropertyConfigurator.configure(PropertyConfigurator.java:97)
    at org.jboss.logmanager.LogManager.readConfiguration(LogManager.java:514)
    at org.jboss.logmanager.LogManager.readConfiguration(LogManager.java:476)
    at java.util.logging.LogManager$3.run(LogManager.java:399)
    at java.util.logging.LogManager$3.run(LogManager.java:396)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.util.logging.LogManager.readPrimordialConfiguration(LogManager.java:396)
    at java.util.logging.LogManager.access$800(LogManager.java:145)
    at java.util.logging.LogManager$2.run(LogManager.java:345)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.util.logging.LogManager.ensureLogManagerInitialized(LogManager.java:338)
    at java.util.logging.LogManager.getLogManager(LogManager.java:378)
    at org.jboss.modules.Main.main(Main.java:470)
Caused by: java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
    at org.jboss.logmanager.config.AbstractPropertyConfiguration$ConstructAction.validate(AbstractPropertyConfiguration.java:114)
    ... 17 more
Caused by: java.io.FileNotFoundException: /opt/jboss/wildfly-10.0.0.CR4/standalone/log/server.log (No such file or directory)
    at java.io.FileOutputStream.open0(Native Method)
    at java.io.FileOutputStream.open(FileOutputStream.java:270)
    at java.io.FileOutputStream.<init>(FileOutputStream.java:213)
    at org.jboss.logmanager.handlers.FileHandler.setFile(FileHandler.java:151)
    at org.jboss.logmanager.handlers.PeriodicRotatingFileHandler.setFile(PeriodicRotatingFileHandler.java:102)
    at org.jboss.logmanager.handlers.FileHandler.setFileName(FileHandler.java:189)
    at org.jboss.logmanager.handlers.FileHandler.<init>(FileHandler.java:119)
    at org.jboss.logmanager.handlers.PeriodicRotatingFileHandler.<init>(PeriodicRotatingFileHandler.java:70)
    ... 22 more
java.lang.IllegalStateException: WFLYSRV0124: Could not create server data directory: /opt/jboss/wildfly-10.0.0.CR4/standalone/data
    at org.jboss.as.server.ServerEnvironment.<init>(ServerEnvironment.java:473)
    at org.jboss.as.server.Main.determineEnvironment(Main.java:297)
    at org.jboss.as.server.Main.main(Main.java:94)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:497)
    at org.jboss.modules.Module.run(Module.java:308)
    at org.jboss.modules.Main.main(Main.java:487)

Mark /opt/jboss/wildfly/standalone/{data,tmp} as data volumes

Wouldn't it be a good idea to mark /opt/jboss/wildfly/standalone/{data,tmp} as data volumes (1) ? They would bypass the Union File System causing a direct write, smaller diffs (2) and smaller container dir size.

(1) https://docs.docker.com/reference/builder/#volume
(2):

$ docker diff 0a
...
C /opt/jboss/wildfly/standalone/tmp
A /opt/jboss/wildfly/standalone/tmp/vfs
A /opt/jboss/wildfly/standalone/tmp/vfs/deployment
A /opt/jboss/wildfly/standalone/tmp/vfs/deployment/deploymentfe48288eca471f39
A /opt/jboss/wildfly/standalone/tmp/vfs/deployment/deploymentfe48288eca471f39/s3-1.8.0.jar-2878891b64f5f965
A /opt/jboss/wildfly/standalone/tmp/vfs/deployment/deploymentfe48288eca471f39/s3-1.8.0.jar-2878891b64f5f965/contents
A /opt/jboss/wildfly/standalone/tmp/vfs/deployment/deploymentfe48288eca471f39/s3-1.8.0.jar-2878891b64f5f965/s3-1.8.0.jar
A /opt/jboss/wildfly/standalone/tmp/vfs/deployment/deploymentfe48288eca471f39/sts-1.8.0.jar-11bf88e6628dc597
A /opt/jboss/wildfly/standalone/tmp/vfs/deployment/deploymentfe48288eca471f39/sts-1.8.0.jar-11bf88e6628dc597/contents
A /opt/jboss/wildfly/standalone/tmp/vfs/deployment/deploymentfe48288eca471f39/sts-1.8.0.jar-11bf88e6628dc597/sts-1.8.0.jar
....

Docker: single root-context app

How can the Docker Wildfly setup be modified to just host a single, root-context app, so that a one-liner running the docker can expose the app at localhost:? This should arguably be a default option, I would think.

duplicate resource

when i remove a .war and deploy the same .war with new changes all is success, but when i reload the server the container fails and when i look the server.log, it say duplicate resource for the .war that i deployed, i dont kno how to solve this issue, i expect that you can help me, sorry if my english is bad, regrads

Image throws: Failed to instantiate class "org.jboss.logmanager.handlers.PeriodicRotatingFileHandler" for handler "FILE"

I'm trying to deploy a wildfly project with the help of docker, but I can't even run the base image:

$ docker run -it jboss/wildfly
=========================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: /opt/jboss/wildfly

  JAVA: /usr/lib/jvm/java/bin/java

  JAVA_OPTS:  -server -XX:+UseCompressedOops  -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true

=========================================================================

OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0
java.lang.IllegalArgumentException: Failed to instantiate class "org.jboss.logmanager.handlers.PeriodicRotatingFileHandler" for handler "FILE"
        at org.jboss.logmanager.config.AbstractPropertyConfiguration$ConstructAction.validate(AbstractPropertyConfiguration.java:116)
        at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:335)
        at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:288)
        at org.jboss.logmanager.config.LogContextConfigurationImpl.commit(LogContextConfigurationImpl.java:297)
        at org.jboss.logmanager.PropertyConfigurator.configure(PropertyConfigurator.java:539)
        at org.jboss.logmanager.PropertyConfigurator.configure(PropertyConfigurator.java:94)
        at org.jboss.logmanager.LogManager.readConfiguration(LogManager.java:514)
        at org.jboss.logmanager.LogManager.readConfiguration(LogManager.java:476)
        at java.util.logging.LogManager$3.run(LogManager.java:399)
        at java.util.logging.LogManager$3.run(LogManager.java:396)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.util.logging.LogManager.readPrimordialConfiguration(LogManager.java:396)
        at java.util.logging.LogManager.access$800(LogManager.java:145)
        at java.util.logging.LogManager$2.run(LogManager.java:345)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.util.logging.LogManager.ensureLogManagerInitialized(LogManager.java:338)
        at java.util.logging.LogManager.getLogManager(LogManager.java:378)
        at org.jboss.modules.Main.main(Main.java:470)
Caused by: java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
        at org.jboss.logmanager.config.AbstractPropertyConfiguration$ConstructAction.validate(AbstractPropertyConfiguration.java:114)
        ... 17 more
Caused by: java.io.FileNotFoundException: /opt/jboss/wildfly/standalone/log/server.log (No such file or directory)
        at java.io.FileOutputStream.open0(Native Method)
        at java.io.FileOutputStream.open(FileOutputStream.java:270)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:213)
        at org.jboss.logmanager.handlers.FileHandler.setFile(FileHandler.java:151)
        at org.jboss.logmanager.handlers.PeriodicRotatingFileHandler.setFile(PeriodicRotatingFileHandler.java:102)
        at org.jboss.logmanager.handlers.FileHandler.setFileName(FileHandler.java:189)
        at org.jboss.logmanager.handlers.FileHandler.<init>(FileHandler.java:119)
        at org.jboss.logmanager.handlers.PeriodicRotatingFileHandler.<init>(PeriodicRotatingFileHandler.java:70)
        ... 22 more
java.lang.IllegalStateException: WFLYSRV0124: Could not create server data directory: /opt/jboss/wildfly/standalone/data
        at org.jboss.as.server.ServerEnvironment.<init>(ServerEnvironment.java:449)
        at org.jboss.as.server.Main.determineEnvironment(Main.java:278)
        at org.jboss.as.server.Main.main(Main.java:94)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:497)
        at org.jboss.modules.Module.run(Module.java:308)
        at org.jboss.modules.Main.main(Main.java:487)

I tried all versions and even build the image locally, it won't work.

About my system:

$ docker --version
Docker version 1.7.1, build 786b29d
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.3 LTS
Release:        14.04
Codename:       trusty
$ uname -r
3.16.0-49-generic

Unable to run yum

Basing a custom docker image off of this one, I find that whenever I try to do a yum install it fails with

Transaction check error:
  file /usr/lib64/libsystemd-daemon.so.0 from install of systemd-libs-219-19.el7.x86_64 conflicts with file from package systemd-container-libs-208.20-6.el7.centos.x86_64
  file /usr/lib64/libsystemd-id128.so.0 from install of systemd-libs-219-19.el7.x86_64 conflicts with file from package systemd-container-libs-208.20-6.el7.centos.x86_64
  file /usr/lib64/libsystemd-journal.so.0 from install of systemd-libs-219-19.el7.x86_64 conflicts with file from package systemd-container-libs-208.20-6.el7.centos.x86_64
  file /usr/lib64/libsystemd-login.so.0 from install of systemd-libs-219-19.el7.x86_64 conflicts with file from package systemd-container-libs-208.20-6.el7.centos.x86_64
  file /usr/lib64/libudev.so.1 from install of systemd-libs-219-19.el7.x86_64 conflicts with file from package systemd-container-libs-208.20-6.el7.centos.x86_64
  file /usr/lib64/security/pam_systemd.so from install of systemd-libs-219-19.el7.x86_64 conflicts with file from package systemd-container-libs-208.20-6.el7.centos.x86_64

Default path inside the container is now /opt/jboss/wildfly

When testing the instructions in README here, it produces errors.
It looks like the default product path is now /opt/jboss/wildfly and not /opt/wildfly anymore

Seb

Missing EXPOSE 9090 ?

Hello,

I just tested 9.0.1 Final and once the container is started, I can reach the port 8080.
However I cannot reach the port 9090.
I see in the logs that the admin console is served on 127.0.0.1:9090 and I did map 9090 to a port however I cannot reach the admin console.

Can it be an issue with the image?

Error in downloading the image

bash-3.2$ docker pull jboss/wildfly
Pulling repository jboss/wildfly
365390553f92: Error pulling image (latest) from jboss/wildfly, operation not supported ry-1.docker.io/v1/, operation not supported
782cf93a8f16: Download complete
7d3f07f8de5f: Download complete
1ef0a50fe8b1: Download complete
20a1abe1d9bf: Error downloading dependent layers
2014/10/31 13:27:06 Error pulling image (latest) from jboss/wildfly, operation not supported
bash-3.2$

creating custom image from local installation

Hi i am trying to create a new image from my local jboss wildfly installation, can i tar it up and import as a docker image ? or how should this be made possible.

I had tried to tar and import, though the image was created i was getting error while running the image.
Error response from daemon: could not find command

Tried creating a dockerfile from scratch but while i build the same it was breaking on RUN with
[8] System error: exec: "/bin/sh": stat /bin/sh: no such file or directory
contents of dockerfile added below
FROM scratch
RUN tar xf ./wildfly.tar
&& mv wildfly /opt/jboss/wildfly
ENV LAUNCH_JBOSS_IN_BACKGROUND true
EXPOSE 8080
CMD ["/opt/jboss/wildfly/bin/standalone.sh", "-b", "0.0.0.0", "-bmanagement", "0.0.0.0"]

any help would be much appreciated

Add an image for 11.0.0.CR1

It would be nice to get docker images for pre-release versions of wildfly. These wouldn't get the latest tag added to them of course.

Unable to mount the volume for deployment

I am trying to mount the deployment folder for docket using docker base image but getting the following error as unable to write. The following command that I run.

Is this something can be included in the base image to fix this issue ?

docker run -it -v /d/babu/installas/deployment:/opt/jboss/wildfly/standalone/deployments/:rw jboss/wildfly

017-06-21T09:32:02.746464536Z =========================================================================
2017-06-21T09:32:02.746469025Z
2017-06-21T09:32:03.569869835Z �[0m09:32:03,567 INFO [org.jboss.modules] (main) JBoss Modules version 1.5.2.Final
2017-06-21T09:32:04.155922174Z �[0m�[0m09:32:04,155 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
2017-06-21T09:32:04.256966545Z �[0m�[0m09:32:04,255 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: WildFly Full 10.1.0.Final (WildFly Core 2.2.0.Final) starting
2017-06-21T09:32:06.585219569Z �[0m�[31m09:32:06,583 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 6) WFLYCTL0013: Operation ("add") failed - address: ([
2017-06-21T09:32:06.585273931Z ("subsystem" => "deployment-scanner"),
2017-06-21T09:32:06.585278567Z ("scanner" => "default")
2017-06-21T09:32:06.585281418Z ]): java.lang.IllegalArgumentException: WFLYDS0024: /opt/jboss/wildfly/standalone/deployments is not writable
2017-06-21T09:32:06.585284035Z at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.(FileSystemDeploymentService.java:279)
2017-06-21T09:32:06.585286804Z at org.jboss.as.server.deployment.scanner.DeploymentScannerAdd.execute(DeploymentScannerAdd.java:124)
2017-06-21T09:32:06.585289326Z at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890) [wildfly-controller-2.2.0.Final.jar:2.2.0.Final]
2017-06-21T09:32:06.585291962Z at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659) [wildfly-controller-2.2.0.Final.jar:2.2.0.Final]
2017-06-21T09:32:06.585294551Z at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) [wildfly-controller-2.2.0.Final.jar:2.2.0.Final]
2017-06-21T09:32:06.585297157Z at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:359) [wildfly-controller-2.2.0.Final.jar:2.2.0.Final]
2017-06-21T09:32:06.585299845Z at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
2017-06-21T09:32:06.585302363Z at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
2017-06-21T09:32:06.585311064Z at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
2017-06-21T09:32:06.585313972Z at org.jboss.threads.JBossThread.run(JBossThread.java:320) [jboss-threads-2.2.1.Final.jar:2.2.1.Final]
2017-06-21T09:32:06.585316552Z
2017-06-21T09:32:06.696214701Z �[0m�[31m09:32:06,695 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem deployment-scanner boot operations"
2017-06-21T09:32:06.698226894Z �[0m�[31m09:32:06,697 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("parallel-subsystem-boot") failed - address: ([]) - failure description: ""WFLYCTL0193: Failed executing subsystem deployment-scanner boot operations""

Failed to load module for org.postgresql

I created module.xml in
/opt/jboss/wildfly/modules/org/postgres/main and downloaded postgresql-9.4.1212.jar in the same folder.
Then I used my customer configuration file. I added datasource and postgres driver in it. But finally I got error:

ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 33) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "datasources"),
("jdbc-driver" => "postgresql")
]) - failure description: "WFLYJCA0041: Failed to load module for driver [org.postgresql]"

I think is a bug for adding postgresql driver, thanks

development mode ?

One of the challenges of docker images are that they are immutable/limited/cut-down and as such rarely have features enabled for making it easy to use with development tools (such as a debugger, incremental/hot deployment etc.).

I'm often asked or suggested how to use Docker from tools, because docker is awesome so it should be easy to use for development too - it often is, but once you start outlining the extra steps and variations different OS and depending on what image you are using we already lost a lot of users.

So we should try and keep it simple to at least do some basics.

It would be great though if we could either incorporate into the images conventions on how to enable such features.

Ideas:

• Have a environment variable (ENABLE_JPDA?) to enable java debugger on a predefined port for java virtual machine launches
• have a known volume mount point for exploded deployments
• have a flag to enable/disable management (probably already fine if all that is needed is to EXPOSE 9990)
• have a -dev as example that have the above enabled (assuming it can't be done in the base image)

WFLYMSG0075 and libaio

I get this warning when starting wildfly in domain mode:

[Server:server-one] 17:28:14,240 WARN  [org.jboss.as.messaging] (MSC service thread 1-5) WFLYMSG0075: AIO wasn't located on this platform, it will fall back to using pure Java NIO. Your platform is Linux, install LibAIO to enable the AIO journal.

I guess it's a HornetQ thing. Would including libaio in the image be a good idea? It seems that if you use it with the wrong filesystem it can slow things down.

Unable to chown files using jboss/wildfly image

In my Dockerfile I ADD a file and then RUN chown on it but I get a permission denied error. The file gets added as user root but I would like it to be set as jboss:jboss. I then ran "docker exec -it my_id bash" to inspect the container and noticed that the shell starts with user jboss. Is there a way to become root user or to be able to chown the file? I also wonder how the shell restriction to jboss user was done.

running wilfly container on openshift origin, the user is however (100004000, root), rather than (jboss, jboss)

I am running docker hub zanata/server which is based on wildfly container, after the application is up, the current running wildfly is (uid=1000040000, gid=0), it should be (jboss,jboss) to be able to access files correctly.

However, I could use following command with openshift to bypass the problem:
oc adm policy add-scc-to-user anyuid -z default

Fedora 24, Openshift: v1.3.1.

Thanks,
Shao

deployment scanner: .../deployments is not writable

Hi...

This is pretty close to Wildfly - EAP 6.3 - I figured a dev here might be able to help?

I saw a few of this permission issue already - (eg here and here)

but none of the solutions are helping any. I first tried mapping the deployments directory:

*-v /opt/deployments:/opt/jboss/jboss-eap-6.3/standalone/deployments/:rw *

so I could keep the ears/wars on my host, then tried adding the ears into the docker...

ADD someearfile.ear /opt/jboss/jboss-eap-6.3/standalone/deployments/

No matter what, I keep getting
java.lang.IllegalArgumentException: JBAS015054: /opt/jboss/jboss-eap-6.3/standalone/deployments is not writable

Here is my Dockerfile... any ideas?
Regards
Daniel

FROM jboss/base-jdk:7

ADD installs/jboss-eap-6.3.0.zip /tmp/jboss-eap-6.3.0.zip
RUN unzip /tmp/jboss-eap-6.3.0.zip

## allow custom external configuration
ADD standalone-custom.xml /opt/jboss/jboss-eap-6.3/standalone/configuration/

### Set Environment
ENV JBOSS_HOME /opt/jboss/jboss-eap-6.3

### Create EAP User
RUN $JBOSS_HOME/bin/add-user.sh jboss mypassword --silent

USER root
RUN chmod 755 /opt/jboss/jboss-eap-6.3/standalone/deployments/*
RUN chown jboss:jboss /opt/jboss/jboss-eap-6.3/standalone/deployments/*
ADD myear.ear /opt/jboss/jboss-eap-6.3/standalone/deployments/
USER jboss

### Configure EAP
RUN echo "JAVA_OPTS=\"\$JAVA_OPTS -Djboss.bind.address=0.0.0.0 -Djboss.bind.address.management=0.0.0.0\""  >> $JBOSS_HOME/bin/standalone.conf

### Open Ports
EXPOSE 8080 9990 9999

### Start EAP
##  ENTRYPOINT $JBOSS_HOME/bin/standalone.sh -c standalone.xml

CMD ["/opt/jboss/jboss-eap-6.3/bin/standalone.sh", "-c", "standalone-custom.xml", "-b", "0.0.0.0", "-bmanagement", "0.0.0.0"]

Cant find hornetq journal files.

Everything runs smooth for me out of the box. But I dont find the directories and files created by hornetq Journaling at the expected place. What happens is even when my message persistance is enabled, ones i restart the container all the persisted messages are lost.

As a workaround i can use some mounted volumes, but as per me the image should support in container persistence as well.

curl error code: 60

Removing intermediate container 1c730522ccc9
Step 6/10 : RUN cd $HOME && curl -O https://download.jboss.org/wildfly/$WILDFLY_VERSION/wildfly-$WILDFLY_VERSION.tar.gz && sha1sum wildfly-$WILDFLY_VERSION.tar.gz | grep $WILDFLY_SHA1 && tar xf wildfly-$WILDFLY_VERSION.tar.gz && mv $HOME/wildfly-$WILDFLY_VERSION $JBOSS_HOME && rm wildfly-$WILDFLY_VERSION.tar.gz && chown -R jboss:0 ${JBOSS_HOME} && chmod -R g+rw ${JBOSS_HOME}
---> Running in 157f4196f460
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:00:02 --:--:-- 0
curl: (60) Peer's Certificate issuer is not recognized.
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.

Unable to see the admin console..

Here is my config:
[oracle@localhost jbwildflyconsole]$ cat Dockerfile
FROM jboss/wildfly
RUN /opt/jboss/wildfly/bin/add-user.sh admin _admin123 --silent
[oracle@localhost jbwildflyconsole]$ cat build.sh
#!/bin/sh
docker build --tag=jboss/wildfly-custom .
[oracle@localhost jbwildflyconsole]$ cat run.sh
#!/bin/sh
#docker run -it -p 8123:8080 -p 9123:9990 jboss/wildfly-custom
docker run -it -p 8123:8080 -p 9123:9990 jboss/wildfly-custom /opt/jboss/wildfly/bin/domain.sh -b 0.0.0.0 -Djboss.management.http.port=8124

---

When I click on "Admin console link" at localhost:8123 or http://172.17.0.20:8080/noredirect.html here is the response:

Your WildFly 8 is running.
Unable to redirect.

An automatic redirect to the Administration Console is not currently available. This is most likely due to the administration console being exposed over a network interface different from the one to which you are connected to.

when I go to localhost:9123 or http://172.17.0.20:9990

no response

Perhaps this is not an issue, but I'm missing something from documentation? Please let me know.

jboss.as MBean subtree missing when using Docker

Hello,

I am using the version of wildfly 9.0.2 final image of the official jboss/wildfly docker.
When access via JMX I can not find the Mbean jboss.as, but I find several others like jboss.modules, jboss.ws, jboss.msc, jboss.jta and core JVM subtrees.

Running Wildfly 9.0.2 in standalone, without docker, I can perfectly find the jboss.as mbean.

I've done a lot of research and would like to know if anyone can help me.

Adding applications to /opt/jboss/wildfly/domain/deployments/ doesn't work in domain-mode

The instructions says " It can be /opt/jboss/wildfly/standalone/deployments/ or /opt/jboss/wildfly/domain/deployments/ depending on which mode you choose (standalone is default in the jboss/wildfly image -- see above)."

But adding applications to /opt/jboss/wildfly/domain/deployments/ doesn't work for Domain mode since there's no deployment scanner associated to domain mode

Default to UTF-8 character encoding

I went round and round trying to figure out why my non-ASCII UTF-8 characters were being changed to ? in all sorts of places when running under this image. I finally noticed that the Linux locale in the container was set to POSIX and added these lines to my downstream Dockerfile:

ENV LC_ALL en_US.UTF-8
ENV LANG en_US.UTF-8
ENV LANGUAGE en_US.UTF-8

That seems to have helped immensely.

en_US.UTF-8 may not be appropriate for a generic Docker image because of the en_US part, but I wonder if there is a way to default to UTF-8 instead of just ASCII without specifying a language and region like that?

At the very least, an addition to the documentation explaining that everyone should add their desired locale settings downstream would be good.

cannot run the container read-only

is there a way to run this image as read-only?

I run the container this way:

docker run --rm --name wildfly  \
  --read-only \
  --tmpfs /opt/jboss/wildfly/standalone/configuration/standalone_xml_history/  \
  --tmpfs /opt/jboss/wildfly/standalone/tmp/vfs/ \
  --tmpfs /opt/jboss/wildfly/standalone/data/ \
  --tmpfs /opt/jboss/wildfly/standalone/log/ \
  jboss/wildfly:10.1.0.Final

but I get the error WFLYDS0024: /opt/jboss/wildfly/standalone/deployments is not writable

the only workaround I've found is to mount /opt/jboss/wildfly/standalone/deployments/ as a volume.

Unable to bind to IPv6

I'm unable to get the wildfly docker container listen to my IPv6 address. I'm starting the container with

docker run -d --net=host jboss/wildfly

but it does only bind to IPv4. If i run wildfly (same config) without docker then it binds correctly to the IPv6 of my host.

Already tried running other services like Nginx with IPv6 and docker (also running with --net=host) and that services are binding to IPv4 and IPv6.

The wildfly output doesn't show any errors ... Any ideas whats wrong?

xmlstarlet not installed

In the switch from Fedora to CentOS as the base, the base effectively lost xmlstarlet. On CentOS, xmlstarlet must be installed through the EPEL repositories.

I opened this issue (jboss-dockerfiles/base#4) awhile back, but it hasn't received any attention. I am referencing it here because the issue affects users of the Wildfly Docker instance and xmlstarlet is referenced in the documentation for configuring Wildfly in Docker.

Until the base version is updated, I created a workaround (https://github.com/jboss-dockerfiles/wildfly) which resolves the problem. It is on Docker Hub (https://hub.docker.com/r/ceagan/wildfly/) as well.

Data Volumes for Wildfly?

I have a question about the layout of the Wildfly Docker container.
Should not define the Dockerfile a Data volume to persist data even when the container shut down?
Like:

VOLUME /opt/jboss/wildfly/standalone
VOLUME /opt/jboss/wildfly/domain

For my understanding this is necessary because wildfly stores runtime informations like timer settings and the transaction log into this directories?
If these directories are not persisted, interrupted transactions (e.g after a crash or restart) would not be continued when wildfly restarts.

I am not sure if wildfly stores this information in these directories but I think this can be an issue?
Maybe it should be explained in the docker repo info? Or am I completly wrong with this aspect?

-Ralph-

Not able to retrieve the latest WildFly image

I rebooted my boot2docker on Mac and tried to pull the WildFly image. It gave an error as shown:

~> docker pull jboss/wildfly
Pulling repository jboss/wildfly
365390553f92: Error pulling image (latest) from jboss/wildfly, operation not supported
supported a: Download complete
782cf93a8f16: Download complete
7d3f07f8de5f: Download complete
1ef0a50fe8b1: Download complete
20a1abe1d9bf: Error downloading dependent layers
2014/11/19 10:57:05 Error pulling image (latest) from jboss/wildfly, operation not supported

This used to work fine as shown at: http://blog.arungupta.me/2014/07/getting-started-with-docker/

Fix links on http://www.jboss.org/docker

Several links are broken after moving the repo to the jboss-dockerfiles org with separate repos.

Dockerfile should not expose ports

Ports 8080 and 9990 should not be exposed by the Dockerfile, because derived containers may want to listen on different ports, such as port 80 for http, but are not able to "un-expose" port 8080.

deployment scanner: java.io.FileNotFoundException (Permission denied)

Following your example:

FROM jboss/wildfly
ADD your-awesome-app.war /opt/jboss/wildfly/standalone/deployments/ 

It adds my war file with ownership of 0:0:

All new files and directories are created with a UID and GID of 0

(source: https://docs.docker.com/reference/builder/#add)

And WildFly (run as jboss:jboss) throws:

10:54:16,507 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0008: Failed checking whether /opt/jboss/wildfly/standalone/deployments your-awesome-app.war was a complete zip: java.io.FileNotFoundException: /opt/jboss/wildfly/standalone/deployments/ your-awesome-app.war (Permission denied)

I'm sure it hasn't got the right permissions:

[root@c3b94a88c7b7 jboss]# ll /opt/jboss/wildfly/standalone/deployments/
total 5048
-rw-r--r-- 1 jboss jboss    8870 Jul  2 17:25 README.txt
-rw------- 1 root  root  5150953 Jul  7 10:44  your-awesome-app.war
-rw-r--r-- 1 jboss jboss     246 Jul  7 10:54  your-awesome-app.war.failed

access to web console, management web site KO why ?

when i use : docker run -it jboss/wildfly
I can't get access to web sites : http://@boot2docker-vm:8080/ 9900/management. solutions please ?

insecure dockerfile

Download happens via http and no sha1 check. This is awful!