A JBoss Project

Red Hat

Posts tagged with 'wildfly'

The current Docker tooling for Eclipse does not support Docker 1.7.1. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=473743 for more information.

Last week at DevNation I had the chance to show some of the cool features that we provide in JBoss Developer Studio, including the Docker tooling that we’ve built for Eclipse Mars and that was released last week^[1].

I also recorded a screencast that highlights some of those Docker tooling features. The video shows how to:

Connect to a local Docker engine (0:32)
Start a PostgreSQL container with a custom username and password (1:52)
Build a custom image for Wildfly to include the PostgreSQL JDBC driver and configure a datasource (3:20)
Start a WildFly container linked to PostgreSQL, with exposed ports and a volume mounted on the host machine (6:44)
Import a Quickstart project using JBoss Central (8:30)
Deploy the project on the WildFly container using a Server Adapter with custom settings (9:55)
Connect to the JVM using the Remote Debugging tools (13:25)

I commented all the tasks as I recorded this screencast to highlight the important steps. Beware that if you run 'boot2docker', you’ll need to use a specific IP address instead of 'localhost' when creating the Server adapter in Eclipse (trust me, I made this mistake before…)..

The dockerfile and its associated resources (module.xml, standalone.xml and JDBC driver) used during the demo is available on GitHub, so feel free to clone the repo and play with it ;-)

Keep in mind that some wizards showed in this screencast may be refactored in the near future, as we target Eclipse Mars SR1 at the end of September for a more complete version of the Docker tooling.

Feel free to discuss features and report bugs with us on the Docker component of Linux Tools at Eclipse.org. As usual, feedback is welcome!

Enjoy!
Xavier Coulon
@xcoulon

1. Docker tooling is part of Developer Studio since version 9.0.0.Beta1 and JBoss Tools users can install it from Eclipse Marketplace or from our Update site

You may have noticed over the years, that your server view’s context menu has an option labeled "Port Monitoring". You may have also noticed that when using JBoss servers, nothing was ever available there. Recent commits have finally remedied this decade-long omission of a useful feature.

TCP/IP Monitor

The WTP platform includes a TCP/IP monitor as a standalone entity. You can use it manually, which I’ll explain now, but the real magic happens when integrated with our server adapters.

There are two primary pieces to the TCP/IP Monitor. First, there’s a preference page, where you can add port mappings and enable or disable monitoring on that port. Secondly, there’s a TCP/IP Monitor view.

The Preference Page

To see the preference page for port monitoring, you’ll want to go to Window Preferences Run/Debug TCP/IP Monitor. You’ll see the page depicted below.

The general concept of the tool is that, in order to monitor a given port (for example localhost:8080), you "Add…" a monitor that listens on some new port (7460) and redirects all traffic to the target destination (localhost:8080). Once this is enabled, only requests to your "Local Port", in this case 7460, can be monitored. Traffic that goes directly to 8080 is bypassing the monitor entirely.

If you click "Add…", you’ll see a few fields to fill out. The "Local Monitoring Port" is the new port that will position itself between origin and destination. Below that, the "Host name" and "Port" represent your actual intended destination. Traffic can be either declared as HTTP or TCP/IP in nature, and you can set a timeout.

Once you’ve added a monitor, you can click on it in the preference page and select "Start", to activate the monitoring on that port.

The View

Once monitoring of traffic has been enabled, you can go ahead and open the view. Window → Show View → Other → TCP/IP Monitor. If you had a wildfly started (either externally or using the server adapters), you could go to http://localhost:7460/ in the browser. The TCP/IP monitoring will be updated with requests and traffic information as shown below.

Clicking on each individual request will show you both the request on the left side, and the response on the right. It will preview images that were requested, or simply display the contents of any text requests and responses. Headers are also shown for both the request and the response.

Integration with the Servers View

While everything seems to work nicely in the above simple example, tools need to make sure that they make requests to the new Local Port rather than the actual destination. Our recent commits focussed on this deficiency.

To see this in action with the Servers View, you’ll want to open your Servers View. You hopefully already have a WildFly instance installed there, which you can go ahead and start now. When you right-click on your Server Adapter, you’ll see a "Monitoring" menu item. We currently have support for monitoring requests on two ports: the HTTP port (8080, typically) and the management port (9990).

After that, you can create a web project with a servlet or a simple html file and deploy it to the server. If you then right-click on your resource and select Run As → Run On Server, you should see the browser open up to the URL http://localhost:7460/YourProject/index.html (or similar URL). In this way, the tools have made sure to make all requests to the Local Port when port monitoring is enabled, but to make all requests to the actual destination port when monitoring is disabled.

When your server is in a management-enabled profile, requests made to the WildFly Management port will also show up in the TCP/IP monitor for inspection.

Conclusion

So there we have it: A long-standing omission has finally been put in place. What’s more, other server adapters don’t integrate with this feature as completely as we do. If you were to run the same experiment on the Tomcat adapter, and execute the "Run As → Run on Server" action for a web project’s servlet or html file, the browser will still open up on port 8080, rather than the Local Port which can be used for monitoring. When targeting JBoss and WildFly servers, though, these actions behave as a user would expect and hope.

So get in there and monitor some traffic! Grab a nightly build from our downloads section, or just use our nightly update site directly:

http://download.jboss.org/jbosstools/updates/nightly/mars/

Rob Stryker

Debugging externally-launched Java applications has always been possible in Eclipse via the Remote Java Application launch configuration type, so long as you manually add the host and debug port to the launch configuration. A few years ago, you may have seen an enhancement we here at JBoss Tools provided, making it easier to connect your sourcecode in Eclipse to an externally-launched process.

Well, history tends to repeat itself, and more enhancements are in the pipeline that make this even easier. We expect the enhancements in this blog to be present in JBoss Tools 4.3.0.Alpha2, so be prepared ;) You can track the progress at JBIDE-19397, or try it out by installing our nightly build.

While the changes you’ll read here today apply to all running java applications, I’ll be focussing on debugging an externally launched WildFly for this article.

The JMX Navigator

JBoss Tools has shipped a JMX Navigator for several years. Changes in the past year have brought with it an enhancement to the JMX Navigator in our most recent release. An extension to the JMX Navigator can now also auto-detect locally running processes, and allow a user to browse their JMX tree.

Not only can we can automatically detect all running java processes, we can also see which ones have been run with the proper debug flags such that a remote debugger can connect to it.

How can this be used with WildFly?

WildFly has the ability to be launched with the --debug flag. This will expose the port 8787 for a debugger to connect to. But if you didn’t know the port, and your startup was taking longer than you’d like, or it was scrolling too fast for your liking, and your google is broken, you could simply right-click the new process in the JMX Navigator and select Connect Debugger. This is an incremental improvement over our past work, because it’s been trimmed down from a right-click action on a project, followed by a dialog, to just the right-click action on the process directly.

This sounds too easy… show me

Alright, I’ll show you.

Set up your environment

First, in JBoss Tools, go ahead and make yourself a new server adapter for WildFly. You can use any of the configuration options you want, really. It shouldn’t make a difference at all.

The only thing you must do, though, is when creating your server adapter, make sure you check Server lifecycle is externally managed.

Once this is done, we can make a simple Dynamic Web Project with a Servlet. To do this, select File → New → Dynamic Web Project and follow the wizard’s instructions. After that, right-click your project, and select File → New → Servlet. A stub file will be generated for you, but we’d like to have it respond something, so let’s go ahead and change the doGet method as follows:

	protected void doGet(HttpServletRequest request, HttpServletResponse response)
			throws ServletException, IOException {
		String ret = "Hello World: " + System.currentTimeMillis();
		response.getOutputStream().write(ret.getBytes());
	}

Let’s also go ahead and set a breakpoint here, just so we can see when it gets hit later on.

Start the Server via Command Line

In a terminal, you can browse to your WildFly installation and simply run the following:

./standalone.sh --debug

Deploy the project

In your project, browse to your servlet’s java file and select it in the Package Explorer, Project Explorer, Navigator, or whichever other view you prefer. Right-click on it, and select Run as → Run on Server… to deploy it.

This action will attempt to start your server, so if you didn’t make sure to check the Server lifecycle is externally managed checkbox during creation, you may run into problems. If you did, though, your server adapter is configured to take no action during 'start'.

In the terminal, you should see some output indicating the module was published.

06:12:01,896 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-16) JBAS015876: Starting deployment of "DWS.war" (runtime-name: "DWS.war")
06:12:01,947 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-14) JBAS017534: Registered web context: /DWS
06:12:02,009 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018565: Replaced deployment "DWS.war" with deployment "DWS.war"

You should also notice that the internal web browser has opened up to your servlet in JBoss Tools, and shows some content… but your breakpoint wasn’t hit. Your remote debugger hasn’t been connected.

So connect the debugger!

If it’s not already open, go ahead and open your JMX Navigator view. You should see a few entries already under Local Processes, since Eclipse is running, and so is WildFly.

You can just go ahead and click Connect Debugger. Now, if you switch to the browser that was opened previously and refresh the page, your breakpoint should be hit, and it should browse to your servlet’s code.

To detach the debugger, you can right-click the same entry again and simply click "Disconnect Debugger".

Can’t you already launch a server with a debugger attached?

Yes, you can. But not all developers will want the debugger connected at all times. They may have custom startup scripts, or personal preferences such that they prefer to always launch via command line, but still wish for convenient access to the debugger. When a server is launched in debug mode from inside eclipse, you cannot disconnect the debugger without also stopping the server. This enhancement allows you to keep the two actions separate, which, we hope, makes our tools more useful for a wider range of individuals.

Conclusion

While small enhancements like this might seem small or incremental, they add up to lots of changes that make your development experience faster, smoother, and more flexible for a wider range of developers and all their divergent personal preferences. We hope you like it.

Rob Stryker

If you’ve already gotten started with trying out Docker and JBoss Tools, and want to see what other options are available, this blog post will explain how to run Wildfly in a Docker container and configure it for management tasks and managed deployments.

Customizing your Dockerfile

Since the default jboss/wildfly Docker configuration doesn’t expose the management port by default, we’ll need to customize it, and this means writing your very first Dockerfile. Our goals here are to add a management user to the Dockerfile, and also to expose the management ports when running the container.

First, you’ll want to make a folder on your filesystem that you can play around in. I’ll name mine docker_jbds_wf_mgmt - Inside this folder, we’ll make a new file named Dockerfile and give it the following content:

FROM jboss/wildfly:latest

USER jboss
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"]

You can see that we’re extending the original jboss/wildfly container. In the above RUN command, we’re also adding a management user. Feel free to customize the password as you wish.

Exposing actual or sensitive passwords in a publicly accessible Dockerfile is dangerous. Make sure to only use example credentials in publicly available Dockerfiles.

Finally, we’re making sure that when the Docker container runs standalone.sh, it is also making sure to bind the management port to all possible hosts, helping to expose it for use.

Building your new Dockerfile

You can give your new configuration any name you want when building it. I’ll build mine here, and give it the name wildfly-mgmt :

docker build --tag=wildfly-mgmt .

Running your new Dockerfile

To run your new configuration, run the following command, replacing the last parameter with what name you chose when building the Dockerfile.

docker run -it -p 8080:8080 -p 9990:9990  wildfly-mgmt

Note that, unlike the previous post, we do not need to launch with custom volume mappings. All we need is the addition of the management port.

Configuring a Server in JBoss Tools

When creating the server remember to set the host to be dockerhost ( at least on OSX and Windows ) as shown above.

Since we’ve configured the server to be remote, and for communication with the server to be handled over the management port, we mark it as Remote and controlled by Management Operations in the second page of the New Server wizard. We also don’t require a runtime here, though we may need one later when creating a functional web project with classes. For now, we won’t create one. You’ll also note that we have marked that the Server lifecycle is externally managed, which means we won’t be starting or stopping the server via JBoss Tools, since you’ll be controlling that via Docker on your own.

On the next page, you’ll note that our remote runtime details are optional. Since the server is configured only for management operations, we have no real need to know where the filesystem is located or how to access it. We can safely ignore this page and just proceed through it.

Now, your server is created, but we still need to set the management credentials. First, double-click your Server in the Servers View to open the Server Editor. Then, set your credentials as you did in your Dockerfile as shown below. You’ll note that some default values are already there, and so you’ll need to delete them and set your own values.

Creating Your Web Project

In this example, we can create a very simple web project by browsing to File → New → Dynamic Web Project, Once the web project is created, we can create a simple index.html in the WebContent folder.

Starting the Server

Now that everything’s set up in Eclipse, we can start our Docker container as we mentioned before:

docker run -it -p 8080:8080 -p 9990:9990  wildfly-mgmt

Starting the Server Adapter

In Eclipse, we can now right-click our server, and select Start. This shouldn’t launch any commands, since we marked the server as Externally Managed. The server adapter is configured to check over the management port at dockerhost:9990 to see if the server is up or not, so it should quickly move to a state of [Started, Synchronized].

Deploying the Web Application

We can now right-click on our index.html project, and select Run As → Run On Server and follow the on-screen directions to deploy our web application. We should then notice the Eclipse internal browser pop up and display the content of our index.html files.

Conclusion

In this second example, we’ve seen how to install and configure a Wildfly Docker image customized for management operations in JBoss Tools.

To summarize, here are the steps needed:

Create your own 'Dockerfile` that uses the existing jboss/wildfly configuration, but also adds a management user and starts server with the management port exposed
Start Docker with 8080 and 9990 mapped
Configure the server to run on dockerhost, using Remote management settings and have lifecycle externally managed

As you hopefully noted, this kind of setup is much more straightforward (no messing with paths); unfortunately it does have a downside since all publishes are full publishes over the management API. Because of this, incremental updates will not work in this case.

In a future example, I hope that we’ll see how to create an image customized for SSH access, which will allow starting and stopping the server and support incremental updates.

Rob Stryker

So you’ve heard the buzzwords and all the hype around Docker, but you haven’t had the chance to play around with it yet or see if it fits your needs. You’re already an avid user of JBoss Tools, and are fairly familiar with starting and stopping your local or remote Wildfly installation, and deploying web applications to it.

If this describes you, and you’re interested in trying out Docker, then this blog is targeted to you.

Docker Installation

Docker’s installation method differs based on your platform. You’ll want to review Docker’s Installation guides for your respective platforms.

To make things unified across the various platform, we recommend you go and map dockerhost to the ip of where your docker instance is running.

By default on Linux that will be 127.0.0.1, so you would add the following line to your /etc/hosts file:

127.0.0.1 dockerhost

But on OSX and Windows it will be a unique IP you can get by running boot2docker ip (i.e. 192.168.59.122). In that case the following should be added:

192.168.59.122 dockerhost

From now on you can use dockerhost in all your applications and get to it no matter what OS you are running on.

Running the default wildfly image

Wildfly has published their docker images for public consumption. You can browse them at the docker registry, or go to http://www.jboss.org/docker/ for more information.

These images are JBoss' standard Docker images and they do not expose more features than just the bare minimum for production and reuse. This first blog will show how to use them as-is, but going forward we will show how to configure them to be a bit more useful for development use cases.

To make sure your docker installation has worked, and that Wildfly can start without any errors, you can do the following:

docker run -it -p 8080:8080 jboss/wildfly

This command will run the Docker image for jboss/wildfly in its default state, no customizations and map port 8080 on your dockerhost to 8080 of the running jboss/wildfly container.

Once this is run, the command will not only start up your container, but also launch the server in standalone mode, and connect a terminal to it so you can see the output.

You should also now be able to see WildFly default startup page on http://dockerhost:8080.

Assuming you see the console output, and the server runs with no errors and you can access the welcome browser via dockerhost then you’re set up and ready for the next step.

To terminate the container, you can simply press Ctrl+C. If, for some reason, your image has frozen, and Ctrl+C isn’t working, you can also run the following commands to kill it forcefully.

First list running containers:

[root@localhost docker]$ docker ps
CONTAINER ID        IMAGE                  COMMAND                CREATED             STATUS              PORTS                    NAMES
f70149043400        jboss/wildfly:latest   "/opt/jboss/wildfly/   58 seconds ago      Up 58 seconds       0.0.0.0:8080->8080/tcp   ecstatic_darwin

Here I only have one container running; you might have more. But to kill any container, you execute docker kill f70149043400, replacing the given hash with your value from CONTAINER ID column.

Externally Managed Local Server With Deployment Folder Mapping

Since the Docker image in this example does not have SSH enabled, and the Wildfly server is not exposing the Management port, we will need to configure JBoss Tools to use custom filesystem deployments. The way to do this is to map in a local folder from our host into our container.

And since we start Wildfly via the Docker image, on the command-line. we’ll want to configure our Server Adapter in JBoss Tools to be an externally managed server, so it will not manage the start nor stop of the server.

Mapping a deployment folder

For this example, we’ll make a temporary directory somewhere on our host, and tell our Docker container to treat that as the standalone/deployments folder inside the container. In this way, changes made to the folder can be visible in both the host and container.

Mapping Folders may cause IO errors for SELinux!* To ensure your container can actually read and write to the folder, you’ll need to run setenforce 0 to disable SELinux, or, alternatively, give Docker the permissions and exceptions in SELinux. See this stackoverflow post for more information.

[root@localhost jbds_wf_external]$  mkdir /home/rob/tmp/dockertest1
[root@localhost jbds_wf_external]$  docker run -it -p 8080:8080 \
-v /home/rob/tmp/dockertest1:/opt/jboss/wildfly/standalone/deployments/:rw  jboss/wildfly

The ':rw' at the end is important, since without it the docker container cannot write to it, only read.

If you were to now place a .war file inside /home/rob/tmp/dockertest1, it will be picked up by the deployment scanner, and visible in a web browser. Take note of the folder, since we’ll use that in the configuration of the Server Adapter.

Making your Server Adapter

The final step of this example is to create your Wildfly 8.2 server adapter in JBoss Tools, and to create and deploy a web application to your temporary folder, which in my case is /home/rob/tmp/dockertest1

First, we’ll open the Servers View and create a new Wildfly 8.x server adapter. Since we’re exposing our container’s ports on dockerhost, we need to set the host to dockerhost.

The server should still be marked as Local and Controlled by Filesystem and shell operations as shown below.

Since we’re hacking a Local Filesystem server adapter to work for Docker, we’ll still need a local runtime in this example, so point it to any locally installed WildFly server you have.

In JBIDE-19388 we are looking at ways to avoid requiring this step.

Configuring your Server Adapter

Once your server is created, you’ll find it in the Servers View, where we can double-click it to open the Server Editor. From here, we can make what configuration changes we’ll need. First, we’ll need to make sure the server is Externally Managed. This means JBoss Tools will not attempt to start and stop it from Eclipse, it is expecting you the user handles that via Docker.

Next, we’ll need to disable the tooling for keeping deployment scanners in sync with the locations JBoss Tools expects to be deploying. Since we’ve already mapped the folder in via the Docker command line, we won’t need any additions to the deployment scanners at all.

And finally, on the Deployment tab of the Server Editor, we’ll want to mark the default deploy folder to be a Custom location, and choose the folder that we previously mapped in via Docker’s command line, as shown below:

Once all this is done, we can save the editor, and our server adapter is configured properly.

Make a Web Project

Starting the Server

Now that everything’s set up in Eclipse, we can start our Docker container as we mentioned before:

docker run -it -p 8080:8080 -v /home/rob/tmp/dockertest1:/opt/jboss/wildfly/standalone/deployments/:rw  jboss/wildfly

Starting the Server Adapter

In Eclipse, we can now right-click our server, and select Start. This shouldn’t launch any commands, since we marked the server as Externally Managed. The server adapter is configured to check dockerhost:8080 to see if the server is up or not, so it should quickly move to a state of [Started, Synchronized].

Deploying the Web Application

Congratulations - you just used JBoss Tools to deploy a local running Docker hosted WildFly server.

What could be better ?

The default docker image is restricted by default. This means it does not have the Management port exposed, nor JMX nor file system access via SSH.

All this means that currently you have to go through some setup to use them from existing tools, but luckily we are doing two things:

we will post more blogs explaning how to enable some of these features to use todays tools (not just JBoss Tools) with 'raw' docker.
we are working on making the steps simpler when using Docker 'raw'

Conclusion

In this first example, we’ve seen how to install and configure the default Wildfly Docker images.

To summarize, here are the steps needed:

Start Docker with 8080 mapped and with /opt/jboss/wildfly/standalone/deployments mounted as volume
Configure server to run on dockerhost, be externally managed and Custom deploy to the volume above

In future examples, we’ll see how to extend those images for Management or SSH/SCP usecases.

Rob Stryker

In our recent milestone releases of JBoss Tools 4.2 we’ve started gathering additional data from those who are have agreed sending back anonymous usage data to us (Thank you!).

Reminder: As always, this is my personal interpretation of the data and again it is early days for the data collection. These numbers are just for the last month of beta testers thus do take these absolute numbers with a grain of salt!

In any case I find the numbers interesting and thought I would share since there are some lessons to be learned.

JBoss Server Usage

One of the data points are which JBoss servers users create.

Mind you we don’t collect the exact version of the server installed, just which server adapter users are using - i.e. EAP 6.1 also covers EAP 6.2 and 6.3, WildFly 8 covers 8.0 and 8.1 etc.

The numbers above shows the last two weeks of server creation by our beta users. Not surprisingly majority of users are using the community version of the latest JBoss servers (AS 7.1 and WildFly 8), and it’s great to see the third most used server is the free for development/enterprise supported EAP 6.1/6.2/6.3.

Oldie but goodie

What I find funny is that there are still users using the latest/greatest development tools, but who runs JBoss AS 3.2 - this was last released back in 2006! Talk about dedication :)

Importance of Multiple runtime support

What the list shows to me is the importance of development tools need to support multiple versions because even though most are using latest/greatest runtime there are still a great bunch of users that will be using older versions of runtimes. Many developers tend to forget or blissfully ignore this.

I’m convinced as users move to our release that gathers these data we will start see even higher numbers of "older" runtime usage.

Deploy Only Server

What is a bit disconcerting is how few seem to know about our Deploy only server (in this list noted as systemCopyServer ). This server allows you to use Eclipse’s support for incremental deployments to any directory locally or remotely available. Really useful for deploying to a non-JBoss server, a remote PHP or just a plain html app.

You should try it out!

File New Server Basic Deploy Only

Combine this with our LiveReload support and you get a great and fast workflow!

Uptake of Eclipse versions

Another data item we have insight to is the uptake of Eclipse versions.

The graph above is our recorded startups of Eclipse Java EE installs since January pr. week. Be aware the versions listed are the EPP versions, not Eclipse release train versions - I’ll do the mapping for you below.

Two things to note: the "Drop" at the end is just the effect of the numbers ending middle of the month, the "Dip" in mid April I’m not sure what is but we see it across all our Google analytics thus I expect it was an Google Analytics anomoly. The numbers have since stabilized, that said…lets interpret!

This graph shows how Eclipse Kepler SR1 release (2.0.1) usage is dropping as users upgrade to Kepler SR2 release (2.0.2) - this are most likely the effect of users using Eclipse built-in update mechanism to upgrade.

What also can be seen is that the latest stable release (4.4.0) uptake is gaining faster than total Eclipse version usage (the faint lines are even older eclipse versions). Meaning total usage of JBoss Tools is up/stable. Eclipse isn’t dead yet :)

I wish Google Analytics had a way to show this graph cumulative instead of per line…anyone up for a data extraction and visualization project ? I’ll give you access to the data to play with.

Uptake of Eclipse Luna

Finally, my personal main interest was to see what the uptake of Eclipse Luna is.

You can see what effect a GA release of Eclipse has. The red line is Eclipse Luna going from a couple of hundreds starts to now 7.000 starts pr. week since its release - but do notice that there is no corresponding drop (yet) in Kepler. Looks like most are installing Luna next to their Kepler installs (my theory at least ;)

This mimicks previous years uptake patterns and once everyone gets back from vacation and Luna SR1 release comes out it should be close to the level of Eclipse Kepler installs. Good to see users continue to picking up latest greatest features and bugfixes!

I’ll go look at the numbers again in a few months to see if the trend continues.

If there is some additonal data you are interested or questions about the above let me know in comments and I’ll try include/answer it!

Have fun!

Max Rydahl Andersen
@maxandersen

Looking for older posts ? See the Archived entries.

Posts tagged with 'wildfly'

TCP/IP Monitor

The Preference Page

The View

Integration with the Servers View

Conclusion

The JMX Navigator

How can this be used with WildFly?

This sounds too easy…​ show me

Set up your environment

Start the Server via Command Line

Deploy the project

So connect the debugger!

Can’t you already launch a server with a debugger attached?

Conclusion

Customizing your Dockerfile

Building your new Dockerfile

Running your new Dockerfile

Configuring a Server in JBoss Tools

Creating Your Web Project

Starting the Server

Starting the Server Adapter

Deploying the Web Application

Conclusion

Docker Installation

Running the default wildfly image

Externally Managed Local Server With Deployment Folder Mapping

Mapping a deployment folder

Making your Server Adapter

Configuring your Server Adapter

Make a Web Project

Starting the Server

Starting the Server Adapter

Deploying the Web Application

What could be better ?

Conclusion

JBoss Server Usage

Oldie but goodie

Importance of Multiple runtime support

Deploy Only Server

Uptake of Eclipse versions

Uptake of Eclipse Luna

This sounds too easy… show me