JBoss.orgCommunity Documentation

JBoss Server Manager Reference Guide

Svetlana Mukhina

Version: 4.0.0


1. Quick Start with JBoss Server
1.1. Key Features of JBoss Server
1.2. Starting JBoss Server
1.3. Stopping JBoss Server
1.4. Deploying an Application to a Server
1.5. Publishing to JBoss Server
2. Runtimes and Servers in JBoss AS-Tools
2.1. Runtimes
2.1.1. Installing a new runtime
2.1.2. Detecting an existing runtime
2.1.3. Duplicating an AS < 6.x runtime configuration
2.2. Servers
2.2.1. Creating a New Server
2.2.2. Creating Remote Servers
3. JBoss Server Editor
3.1. Server Editor - Overview Page
3.1.1. General Information
3.1.2. Management Login Credentials
3.1.3. Server Behavior
3.1.4. Publishing
3.1.5. Server Timeouts
3.1.6. Application Reload Behavior
3.1.7. Server State Detectors
3.1.8. Ports
3.1.9. Local Server Launch Configuration
3.1.10. Remote Server Launch Configuration
3.2. Server Editor - Deployment Page
4. JBoss Perspective
4.1. The Servers view
4.1.1. Servers view Toolbar
4.1.2. Servers view Structure
4.1.3. Drag-n-Drop to Servers view
4.2. Server Log View
4.3. Relevant Resources Links
5. Projects
5.1. Faceted Projects Overview
5.2. Adding Facets to a Project
5.3. Relevant Resources Links
6. Deploying Modules
6.1. Deploying on the Package Explorer
6.1.1. Deploying with Run On Server Wizard
6.2. Deploying with Servers View
6.3. Redeploying with Finger Touch
7. Project Archives
7.1. Project Archives View
7.1.1. Overview
7.1.2. Creating an Archive
7.1.3. Archive Actions
7.1.4. Publishing to Server
7.1.5. Relevant Resources Links
8. TPTP Support
8.1. TPTP Profiling
8.2. Relevant Resources Links

This chapter covers the basics of working with the JBoss Server.

There are two times to deploy your application:

When you create some types of JBoss Tools™ projects, such as Seam, JSF or Struts with the New Project or Import Project wizards, they will include the Target Runtime and Target Server sections. You can deploy the application through the appropriate configuration in these sections during project creation.



Other projects, such as those from WebTools™, allow you to target your project to a runtime for classpath evaluation purposes, but do not automatically deploy your application to the matching server adapter. (Remember, not all runtimes have an associated server. Some may be used solely for classpath evaluation.) Projects that behave this way include the Dynamic Web project, EJB Project, Utility Project, Enterprise Application Project, and others. You can, however, deploy these existing applications to a server. To do so, first right-click the server you'd like to publish to in the Servers view. Then select Add and Remove Projects from the context menu.


If this application or module is not currently assigned to the selected server, it will be in the left-hand column, which lists modules available to be deployed. Clicking on your target module, and then on the Add > button will move the selected module to the right-hand module list. When you click finish, the module is now targeted to be deployed on the server. It may not publish immediately, however. The auto-publisher is disabled unless the server is already in started mode. You may need to force a publish event on the server, as described above, or simply wait until later. When you start your server, the modules will also be published.


Note

It is now possible to deploy OSGI (Open Services Gateway initiative framework) projects to the JBoss Enterprise Application Platform 6 or JBoss Application Server 7.

The publishing of all the modules added to a Server is performed automatically when starting a Server.

Automatically publishing changes made to the workspace is enabled by default, allowing the workspace to remain in sync with the publish folder. However this autopublisher is only enabled when the server is in started mode. If you need to control when to publish the changes, just disable the automatic publish in the Server Editor (see ???) and use the Publish to Server () button which will incrementally publish the workspace.

This section has provided some basic information that will allow you to use the common features provided by the JBoss server. However, JBoss server includes a great deal more functionality, which will be discussed in subsequent chapters.

In this chapter we will discuss how to install and configure JBoss runtimes and servers.

Runtimes in JBoss Tools provide key functionality for creating, running, and debugging J2EE applications. They provide classpath entries for projects, and are instrumental in starting, stopping, and publishing to the various server adapters. In their simplest form, though, a Runtime is nothing more than a representation of key information about a server configuration which can be used to provide classpath entries or other information important for the server lifecycles.

For AS7 / EAP6 related servers, the runtime consists of a server home, a JRE compatible with the server, and the configuration file used to describe the specific details about the server. For earlier versions of JBoss Application Server, the Runtime consists of the server home and JRE, as well as a configuration folder, and a configuration name.

In order to get started creating, running, and debugging J2EE applications, we should create our runtime and server instances.

In JBoss Tools, the main purpose of Server Runtimes is to point to a server installation somewhere on disk. In our case, this will be a JBoss installation. It can then be used for two primary purposes, as mentioned above:

You can install runtimes into Eclipse by selecting WindowPreferences menu and then selecting ServerRuntime Environments from the categories available on the left.


From this preference page you can see all declared runtimes along with their types. Here, it is possible to edit or remove existing runtimes, as well as add a new one.

To create a JBoss runtime click the Add button and choose the appropriate type of runtime from the JBoss Community category.


Note:

Now there is a separation between .org servers (the JBoss Community category) and product server that comes with JBoss EAP in JBDS ( the JBoss Enterprise Middleware category).

Note:

JBoss Tools provides server adapters for all versions of the JBoss Application Server and JBoss Enterprise Application Platform. We currently recommend you use a fully supported JBoss Enterprise 6.0 server adapter.

You will also note a Deploy-Only Runtime type. This type does not provide a classpath for WTP projects. It is used solely by it's server type for the purpose of setting up a simple deploy directory for users who do not wish to make use of starting, stopping, or debugging their projects inside Eclipse.


The following tables describe all the available options for JBoss runtimes.



As a result of having each runtime represent a specific configuration rather than the server installation as a whole, it is very likely you will create several different runtimes to test each of your configurations. With this in mind, it becomes important to ensure your runtimes, and later your servers, are given descriptive names that help you to remember which is which.

Click the Finish button to see your new runtime in the list.

Note:

For the most part, changes to runtimes will be persisted, and all dependent servers will be updated according to those changes. However, you should be aware that if multiple servers depend on the same runtime, modifications to that runtime will change several servers, not just one.

As a word of warning, renaming your runtime will cause all servers targeting that runtime to lose their reference. This may manifest itself by the server being unable to start, or publish. The most visible way to verify that your server is in a consistent state is to double left-click on the server to open the Server Editor, and look in the OverviewRuntime EnvironmentIf the combo has no selected item, your server is in an inconsistant state. To fix this, simply select the newly renamed runtime from the combo box, and save the editor.

JBoss Tools features the ability to search, detect and add existing JBoss server runtimes installed on your system. If you don't have an existing runtime you can download one through the Download option or Section 2.1.1, “Installing a new runtime” will guide you through the creation process. To begin searching for your existing JBoss runtime select WindowPreferencesJBoss ToolsJBoss Runtimes.


The JBoss Tools Runtimes preference page is split into two different sections. One section defines Paths to be searched for installed server runtimes, the other section defines the runtime detectors available when the paths in the previous section are checked.

The Add button in the Paths section opens a file system browser window. Select the directory you wish to have recursively searched for JBoss runtimes. The directory will be searched and all found servers will be displayed as a list in the Searching for runtimes dialog. From the returned list, choose the runtimes you wish to make available by clicking the box beside each runtime and clicking the OK button.

Note

If you are using a full JBoss Developer Studio installation, runtime detection now recognizes the ESB runtime distributed as part of the JBoss Service-Oriented Architecture Platform runtimes during a scan. If you are using the a-la-carte installation options provided by JBoss Tools, you may or may not benefit from this enhancement depending on what plugins you have installed.


The path you searched is now added to a list in the JBoss Tools Runtime Detection dialog Paths section. All the paths in this section will be automatically searched when a new workspace is created. This is convenient in that it allows you to quickly create a new workspace with your runtime settings much easier to replicate. If you wish for a path to be searched on each and every startup, then check the checkbox in the Every start column associated with it.


If you don't have a runtime already downloaded, you can download a free community application server through the Download button.

Important

No official support is available for community application servers (this includes enterprise customers using JBoss Developer Studio).

Clicking on the Download button will display a new screen of available runtimes that can be downloaded. Highlight the server you wish to download and install, and click the OK button.


A new dialog will appear asking you to specify an Install folder and Download folder; the option to Delete archive after installing is checked by default. Once you have specified the two paths above, click the OK button and the server will begin downloading.


Once the server has been downloaded and installed, you will notice that the path to the new server now appears in the Paths section of the JBoss Tools Runtime Detection dialog.


WTP servers are Eclipse-representations of a back end server installation. They are used to start or stop servers, deploy to servers, or debug code that will run on the server. They also keep track of the modules (JARs, WARs, etc) you deploy to the server, and allow you to undeploy those modules (see Section 6.1.1, “Deploying with Run On Server Wizard”).

Servers can be started or stopped via the Servers view in your workbench. They are usually backed by a runtime object representing that server's configuration details.

There are many ways to get to the new server wizard. One way is to select FileNewOther...Server. This should show the wizard like below.


A server object keeps track of the command line arguments for starting or stopping a server process. The runtime keeps track of the location of the installation and is used to help generate these command line arguments.

The New server wizard allows you to name the server via the Server name field, or you can use a generated default name.

You can select one of the already-created runtimes from the Server runtime environment combo box. If there is no runtime that matches your needs, press the Add... link nearby to bring up the wizard for creating a new runtime (see Figure 2.3, “Adding a JBoss EAP 6.0 Runtime”). To make changes to an existing runtime, go to server preferences by pressing the Configure runtime environments... link. Be aware that any changes you make here may change other servers dependent on that runtime. We reccommend creating new runtimes for each different scenario.

If the server you want to create does not have any installed runtime yet, the combobox and the links are absent.


If there is no runtime when creating your server, the next page of the wizard will be identical to the runtime page mentioned in the previous section. This page guides you through creating a runtime for your server.

After either targeting your server to an existing runtime, or creating a new runtime, the final page of the wizard presents a summary of the selected options, giving you a chance to verify that you have selected the appropriate runtime.


You will also see several other options here. The first option reads Server is externally managed. Assume server is started. This option indicates that starting the server should actually take no action, launch no java command, and assume that the user is managing the server lifecycle on his own.

The second option reads Listen on all interfaces to allow remote connections. This option is most often required when using the tools to control a remote server. Effectively, this adds the -b 0.0.0.0 flags to the server's launch command, which allows your server to respond to requests on all hostnames.

The third option reads Expose your management port as the server's hostname. This option helps ensure that attempts to connect to your server over the management port actually succeed. If your server adapter does not have this option selected, requests to run management commands may be rejected. This should not be a problem for any server adapters representing a local server instance. Locally, JBoss passes around a filesystem token for management authorizations. However, if your server adapter is representing a remote server, failure to expose the management ports may lead to an inability to communicate with the remote instance.

Not all of these options will show for all servers. JBoss 7.0.0 and 7.0.1 for example do not support the -b binding flag, while versions < 7.0 do not have the same remote management options. Be aware that this list changes based on the context of what server types you are creating.

Click the Finish button to complete the process of the server creation.

Now that we have created our runtimes and servers, we can explore the services and tools provided by the JBoss Server Manager.

This chapter describes how to manage and change the settings and behaviour of an existing JBoss AS-Tools Server Adapter. The server editor is the primary vehicle for users to modify the behavior and settings for their server, including what launch arguments to use, how to discover if the server is started, and many others.

By double-clicking on any server, an window will appear allowing you to edit the servers settings.


The Overview page is an important entry-point to modify settings for your server. This page has the following sections.

  • General Information

  • Management Login Credentials

  • Server Behavior

  • Publishing

  • Timeouts

  • Application Reload Behavior

  • Server State Detector

  • Server Ports


The server adapter tries to automatically detect the ports it needs for integrating with a JBoss Server by default. It does this typically by parsing through configuration files, searching for some XPath, and using the values found as the chosen port. The Server Ports section in the Server editor provides fields to customize the ports that the tooling will use to communicate with the server. Above, you see a name, a text box with an integer value representing the port, a checkbox toggling automatic detection, and a hyperlink to dive deeper into the discovery details. Sometimes, it is necessary to override this automatic detection if you are using a custom configuration. As shown above, the tools need to know how to accurately discover the web port and the management port. Recent servers allow for more accurate detection by also discovering the port offset setting.

A Note on Port Offsets

The JBoss Application Servers allow for a port offset to be declared. Essentially, a port offset is an integer to be added to all ports on startup. So if your server is set to have a web port 8080, but you provide a port offset of 200, the web port (and all other ports) will be 200 higher. This allows you to start multiple servers on the same machine without port conflicts.

The simplest way to ensure that the tooling is pinging or communicating on the correct port is to uncheck Detect Automatically. This sets the text field as editable, and you can simply type the correct port. To look deeper at the actual settings of how the port is discovered, or to modify this behavior, click the Configure... link to bring up the wizard for adjusting the settings for the ports.


Click the Edit XPath button for the chosen port to configure its XPath's values.


In this dialog, you can customize the XPath and an optional attribute name to discover the proper port string. The dialog provides a preview button to see the results that match the XPath. Ideally, you'll want to craft an XPath that matches only one result. You can limit the files to be searched by use of a fileset pattern. This will help limit other files from matching the result set, and ensuring an accurate detection of the proper port.

The Server editor window also allows you to modify the server's launch configuration. The settings are available by clicking the the Open launch configuration link in the General Information section of the editor. The resulting window provides tabs for setting command line arguments, main, classpaths and other things that are relevant to launching the server.


The first tab shows the JBoss server arguments

Note:

Please note that some of the values in the Launch Configurations for JBoss Servers are strictly enforced in order to avoid inconsistencies between server's and their configured runtime.

For example, if you change the launch configuration program arguments to "-c myConfig" but do not change the targeted runtime configuration, then your program arguments will be ignored. The configuration of the server runtime "wins" so to speak. This ensures consistency. Therefore, if you change the location of the runtime, your launch configurations will automatically pick that up.

Non-critical or custom arguments can be passed in or overridden with no problem at all. It is only arguments that otherwise conflict with the data in the runtime that will not be respected.

On the second tab you find the main class used for launching JBoss AS (the default is org.jboss.Main). This value can be changed if necessary.

Until JBoss Tools 3.0.0.GA the servers classpath was read only, but that caused problems for users wanting to add their own JARs in the startup classpath. That is relevant if you need to patch the server, add a custom charset or other tweaks that require early access to the classpath.

Now all servers have a custom 'server runtime classpath container', which is there by default and point to the default JARs in JBoss. You can now adjust the classpath. Then just make sure this container is there if you want the classpath to be picked up.


If for some reason you have a launch configuration without this container, the Restore Default Entries button should add it properly. Also, the Restore Default Entries button will remove any extra entries you added yourself.

Using Deployment tab you configure local deployment settings.


Using the group of radio buttons in the Default Settings section a user can set where the application will be deployed to. By default it is deployed to a folder inside the user's workspace metadata, located inside [workspaceDirecotry]\.metadata\.plugins. If you would like the application to be deployed to your JBoss server's deploy folder, select the Use the JBoss deploy folder option. The option to specify a custom deploy folder is also available.

You should also see a checkbox available labeled Deploy projects as compressed archives. This option forces all of your publish operations to result in a zipped archive output file. Rather than an exploded directory war, for example, you would end up with a zipped .war file.


As shown above, the bottom section of this editor page allows customizations on a per-module basis. For example, if you want one of your modules to be published to a custom directory, while the rest live happily inside the server's deploy folder, you can now override this setting here. If you'd like to change the output file name from the assumed MyProject.war to the OtherName.war, this is also possible.

To begin editing these values, simply click on the cell you wish to edit. All paths should be absolute, or, relative to the default deploy directory as chosen in the top section of the editor page. Be aware that when publishing, we require the temporary folder to be on the same filesystem as the final deploy location. If this constraint is not satisfied, publish will often fail. Do not forget to save the editor before these results can take effect.

This chapter describes how to manage installed JBoss Servers™ via the JBoss Perspective. The Servers view will primarily be discussed.

The Servers view is built on the Common Navigator Framework allowing extensions and is using label decorators that make the UI compact enough without loosing the vital information.

Let's have a detailed look at the Servers view and its constituent components.


The Servers view displays all defined servers as well as their current status (that is whether they are started or stopped) in square brackets next to the server name.


The following table lists possible server statuses.


You can control a server behavior as well as adjust a number of server preferences through the context menu.


All available context menu commands are described in the following table.


Under the server element in the Servers view, you can see modules that are currently deployed to the server and some server extensions that provide additional information on the server.

The context menu for any module allows you to remove it from the server and force a full or incremental republish upon it.


The Filesets category in the Servers view provides a way to filter files.

To add a new file filter, right-click the Filesets category and select the Create File Filter option.

The New File Filter wizard should appear.


The wizard asks you to enter the filter name and add includes and excludes patterns. The preview box underneath provides a list of files matched to the defined patterns (see the figures bellow).

In order to set up a default fileset relative to the fixed configuration of the server runtime, use the following variable: ${jboss_config}, i. e. you should enter server/${jboss_config}/ in the Root Directory option. This allows you to modify the runtime's configuration and not have to manually update paths.


Notice, that the Browse button still returns an absolute path:


After the filter is created, you can explore it by expanding the Filesets category in the Servers view.

It is now possible to edit files directly from the Filesets category. Double clicking on a file from Filesets opens up the editor automatically, or you can use the Edit File context menu command.


To delete a file filter (or just a file) from the Filesets, right-click a file filter or file and select the Delete File Filter or Delete File command.


If you want to set filesets for some server types, select WindowPreferences and then select ServerDefault from the categories available on the left.


On this preference page you can add a fileset to any server type or to all servers at once. To do this you should select the server type in the combo box and click the Add fileset... button. In the opened New File Filter wizard follow the steps described in Section 4.1.2.1, “Filesets” and finally click the Apply button on the preference page.

The defined file filter will be automatically added to new servers during their creation.

The XML Configuration category allows you to quickly browse to descriptor files in your server's deploy directory and check or change the values. Basically, XML Configuration includes XML XPaths, where an XPath is a path used to access some specific part of an XML document.

The XML Configuration category itself contains only a list of categories. Ports are provided by default and display many of the most commonly used ports in the JBoss Server™.


By right-clicking on the XML Configuration node you can create a new category. Besides, context menu for XML Configuration category makes possible to disable it. You can disable any category in the bottom part of the Servers view. Look for them in the Inactive Categories afterwards to re-enable.


By right-clicking on the Ports category, or any other category in XML Configuration, you can create a new XPath.


After that, the dialog shown below will appear.


The goal here is to get an end result where the XPath matches up with a necessary property. With that in mind, let's look how it works. If the property you want to reach is the value of the name attribute in the element <mbean>, then your XPath Patten should end with mbean and your Attribute Name should be name, as demonstrated in the next figure.

...
<server>
...
    <mbean code="org.jboss.ejb.EJBDeployer" 
                   name="jboss.ejb:service=EJBDeployer" xmbean-dd="">
  
     <!-- Inline XMBean Descriptor BEGIN -->
         <xmbean>
             <description>
                    The EJBDeployer responsible for ejb jar deployment</description> 
               ...
         </xmbean>
     </mbean>
</server>

Tip:

Notice when you type the fields autocomplete to help you locate exactly what XPath you're looking for.

If your desired field is the text of an element <description>, your XPath Patten should end with description and Attribute Name field should be left blank. When finished, click the Preview button to see how many matches are found for that particular XPath.


The most popular of the projects we deal with are the J2EE ones, such as Dynamic Web Project, EJB Project, or EAR project. JBoss Tools™ web projects include Struts, JSF and Seam projects. These are referred to as faceted projects. This chapter will cover facets, which are used to provide a consistent structure and packaging features to any type of project.

This section will cover the facets added by JBoss Tools and show how you can configure them in a project by adding new ones or modifying existing facet configurations.

One way to configure the facets is doing it while organizing a new project. To demonstrate this create a new Dynamic Web Project by clicking on the Dynamic Web Project option in the Create Projects section of JBoss Central.


Click the Next button and you will see a Dynamic Web Project page like on the figure below.

The first page of most WTP projects allows you to target a specific runtime, which represents a server's library location. It will also provide you the ability to add this project to an EAR project and select a preselected default set of facets, called a configuration, rather than manually select each required facet.

Selecting the runtime allows the project to install the proper classpaths to the project so it knows what code to compile against.


Click the Modify button next to the Configuration section to open a wizard which allows you to modify the chosen configuration. The wizard is shown in the image below.


Here part of the listed facets are those which are provided by WTP. Some of them are added by JBoss Tools. They are:

  • BIRT Charting Runtime Component

  • BIRT Reporting Runtime Component

  • CDI (Contexts and Dependency Injection)

  • CXF 2.x Web Services

  • JAX-RS (REST Web Services)

  • JAXB

  • JBoss Portlets

  • JBoss Web Services Core

  • JPA

  • Seam 2

On this wizard page you can enable or disable any facet as well as change its version. What you should note here is that some facets or facets versions may conflict with each other. In case of incompatibility you will be notified in the combobox underneath.


When switching on the Runtimes tab on the right you will see the current server Runtime.


On this tab you can also create a new Server Runtime and make it primary by enabling it and then clicking the Make Primary button.

Clicking on the OK button will save the chosen configuration of the facets and return you to the Dynamic Web Project wizard (see Figure 5.2, “New Dynamic Web Project”). Additional pages in the wizard are specific to either the project type or the facets selected.

If you need to configure the facets for an existing project, right click on the project, select Properties and then select Project Facets. This will bring up the Project Facets wizard (see Figure 5.3, “Project Facets Wizard”), where you can create your own custom facets configuration.

In this chapter it will be described how to deploy modules onto the server.

There are several ways to deploy to a server, provided by the Web Tools Platform (WTP) and some additional methods provided by JBoss Tools. These methods are described further in this chapter.

The root elements of the Servers View are the server objects. Expanding these, you will see the modules listed. With this in mind, we suggest two more ways to deploy resources onto the server.

For the first method, you should right click on a server and select the Add and Remove menu item.


This will bring up a dialog (see Figure 6.2, “Add or Remove Projects”) that allows you to either publish projects or modules to a server, or remove them from the server. If the selected module is a project like a Dynamic Web project, EJB project, or EAR project, it will be published as through Run on Server wizard, with a best-guess full package. If, however, the selected element is an archive from the Project Archives view (see Section 7.1, “Project Archives View”), it will be published according to the rules of that module type.

Nested beneath each server, there is a list of modules. Each module displays the module name, as well as decorated information on the module's various states. Right-clicking on the desired module and selecting Full Publish will force a full rebuild of the entire module.


Here, Incremental Publish is meant to enable publishing of only those parts where changes have been made.

Every application, whether Plain Old Java, J2EE, or some other language altogether, needs to be packaged in some way. In Java-related projects, many people use ANT.

But JBoss Tools™ comes with our own Archives tool with simpler and less-verbose XML and a handy user interface. The Project Archives plugin consists primarily of the Project Archives view to set up each packaging configuration.

Let's look through all functionality that the Project Archives view provides.

When you open the Project archives view for the first time, it asks you to select the project for which you want to create an archive.


To get started creating a jar, you need right-click inside the view and select New Archive. When creating your new JAR output, you can customize the name, add folders, filesets and inner JARs to it. Shown below is the first page of the New archive wizard.


The page is pretty simple. First it prompts you to set the name of your new archive and a destination.

The destination of an archive can be anywhere on the file system, anywhere in the workspace, inside another archive, or inside a folder declared inside an archive. Select the appropriate checkbox (either workspace or file system) to specify that the destination is related to either the workspace or filesystem. You can browse to workspace or filesystem destinations by clicking on their respective buttons. To select a destination inside some other archive, you'll need to click the Workspace button.


Also in the wizard for creating a new archive you can choose whether an archive to be compressed or exploded into a folder (without compression). You need just select proper checkbox in the Archive type section.

If a build or incremental update fails Project Archives will show an error dialog:


Click the Details button to view detailed information about the cause of the error.

In the Package Explorer you can view the created archive.


If you use the exploded type of archiving, instead of a single file archive the result put into a folder is displayed in the Package Explorer.


Refer to the Ant manual to find more on how to build your applications using Ant.

We also recommend that you watch this movie which demonstrates the powerful archiving functionality in JBoss Tools™.

This chapter provides an overview on how to enable TPTP Profiling for JBoss AS™ adapters in JBoss Tools™.

To get TPTP profiling work on JBoss Application Server™ you should do the following:

  • Download TPTP Runtime and install it, i. e. just add the content of plugins/features folders from downloaded directory to the same folders in your eclipse installation directory or use the HelpInstall New Software command.

  • Install JBoss TPTP Tools which provide TPTP support for JBoss AS servers (find the latest stable version of the JBoss TPTP profile feature at http://www.jboss.org/tools/download/stable).

And now all profile actions should work for you. To start JBoss AS™ in profiling mode use Start the server in profiling mode button or select Profile AsProfile on Server from the context menu of the project.


To enable TPTP features in your workbench use Profiling and Logging Perspective that you can find in the list of proposed perspectives: WindowOpen PerspectiveOther...