In this chapter we will discuss how to install runtimes and servers
The JBoss AS plugin makes use of WTP. This includes starting and stopping servers in run or debug mode. It also includes targeting WTP projects, such as dynamic web projects, to certain server runtimes in order to ensure that the proper jars from a specific server are added to the project's classpath properly.
In order to get started creating, running, and debugging J2EE applications, we must start with creating 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, and it can than be used for two primary purposes:
it provides classpath additions to WTP projects that require them.
For JBoss server at least, it provides information necessary for the starting and stopping of the server, it tells which jars to run and which configuration to use.
You can install runtimes into eclipse from the Window > Preferences... menu, and then select Server > Installed Runtimes from the categories available.
From this preference page you can see what runtimes are declared, and what type they are. In the image shown above, there are two declared runtimes, including a JBoss 4.2 instance.
To create a JBoss runtime, we begin by clicking the Add button. This will open another dialog that allows us to choose what type of runtime we want to create. Most of the runtime options are provided by WTP, but those provided by JBoss Tools are the ones we will focus on.
As seen above, there appear to be two JBoss categories. The first is contributed by WTP, and is a generic adapter that is not upkept very well. For this reason, JBoss Tools provides updated and supported adapters of our own. There is one for each of JBoss 3.2, 4.0, and 4.2. You'll also note a deploy-only runtime type. This type provides no classpath for WTP projects. It is used solely by it's server type for the purpose of setting up a deploy directory for users who don't wish to make use of starting, stopping, or debugging their projects inside eclipse.
As shown above, all you need to do to create the runtime is to name it, browse to it's install directory, select a Java Runtime Environment, and select which configuration you want. As you browse to a valid installation folder, the list of configurations will update allowing you to select the configuration of your choice.
Once the runtime is created, the configuration is an unchanging property of that runtime. This is because many of the jars necessary to provide for classpaths, such as the ejb3 jar locations or the servlet jar locations, are located in deploy directories of each configurations (depending on which version of JBoss is being used). Because of this, to compile against a different configuration's jars, you will need to create a new runtime from that configuration.
Also, because of the open-source nature of JBoss, it is likely that a user may want to modify and repackage some of the configuration-specific jboss jars and create their own configuration using those modified jars. Rather than forcing the user to copy his entire JBoss installation, this structure allows them to create only a new configuration instead.
As a result of having each runtime represent a specific configuration rather than the server installation as a whole, it is very likely you'll create several different runtimes to test each of your configurations. It becomes important to ensure your runtimes, and later your servers, are given descriptive names that help you remember which is which. It will do no good to try to remember if "JBoss-runtime 5" is the 4.0 install with ejb3? Or the 4.2 install's custom configuration you decided to create.
After pressing finish, you'll see that your new runtime has been added to the list and can now be targeted by WTP type projects or servers, both of which we'll get to later.
WTP servers are eclipse-representations of a backing server installation. They are used to start or stop servers, deploy to servers, or debug code that will run on the server. They keep track of what modules (jars, wars, etc) you deploy to the server and also allow you to undeploy those modules.
Servers can be started or stopped with different command-line arguments. They are often backed by a runtime object representing that server's location.
There are many ways to get to the new server wizard. One way is to use the old standard File -> New -> Other... wizard, and type in Server. This should show the screen below, which does not look that different from the initial screen when creating a new runtime.
Because the server object is what keeps track of things like command line arguments when starting or stopping, and runtimes keep track of the location of the installation, each server instance must be backed by an appropriate runtime.
Because there may be many runtimes of each type declared, the wizard allows you to select which runtime you want your server to be backed by. The combo box below the view lets you select which declared runtime to use. For example, if there were already multiple JBoss 4.2 runtimes declared, the combo box would list all of the 4.2 runtimes available.
If none of the runtimes declared are one you want to use, for example if you declared a default and a minimal runtime before but now want your server to be backed by the ALL configuration, then you can click on the Installed Runtimes... button to bring up the preference page shown at the beginning of this chapter.
If the server you want to create doesn't have any installed runtime yet, the combo box and button will disappear, and the next page in the wizard will force you to create the associated runtime first.
Either way, after targeting your server to a runtime, the final screen in this wizard is largely confirmational, giving the user a chance to verify that he's selected the appropriate runtime. It also allows the user to name the server appropriately.
This chapter tells how to manage installed JBoss AS servers via JBoss AS Perspective
The JBoss AS Perspective is similar to the Java perspective, but it contains a few additional views. Two of the additional views are standard views, specifically the Console view and the Properties view. The other two views that are added are the Project archives view and the JBoss Servers View.
This chapter will focus on the the JBoss Server's View. The JBoss Servers View is based on the Webtool's view, Servers View. The top half of the JBoss Servers View essentially embeds the original Servers View directly into it, making slight changes to the context menu. A second half was added to provide additional information about the server selected in the top half. In the image provided, categories in the second half include which modules are currently deployed.
In order to access the view's preferences, you should access Window > Preferences > JBoss Tools > JBoss Servers > View. This preference page allows you to select which view extensions you want on or off, the order they appear in the view, as well as any other extension-specific preferences that may be available.
Extender is meant to provide additional functionality relevant to the server selected in the top half of the view. If a standard server element is selected from above, some of the extensions may still provide the additional information. Others may not. So, let's look at the currently available extensions to the JBoss Server's View.
The Modules section shows what modules are currently deployed to the server, and allows you to remove them from the server, or force a full republish upon them. It only shows which modules have been deployed through Eclipse, not any and all modules that happen to be in the deploy directory.
The Event Log will show relevant information to your server's startup, shutdown, and publish processes. This allows you to keep an eye on what's going on (such as automatic incremental deployment if you have it enabled). The only action available is to clear the event log. However if the properties view is opened, you can receive further information on each event log item (when available).
The XML Configuration category allows you to quickly browse to descriptor files in your server's deploy directory and check or change the values. Its use requires the Properties view. Basically, XML Configuration are XML XPaths where a xpath is a path used to access some specific part of an xml document.
The view itself contains only a list of categories. By right-clicking on XML Configuration, you can create a new category. Ports are provided by default and is filled with many of the most commonly used ports in the JBoss Server.
By right-clicking on Ports, you can create a new XPaths.
After that, the dialog shown below will appear.
As you type, the fields autocomplete to help you locate exactly what xpath you're looking for. The goal here is to get an end result where the xpath matches up with an easily changed property. With that in mind, if the property you want to change is the text of an element, then the final field Attribute Name should be left blank and your xpath should end with port. If, on the other hand, your desired field is the port attribute of <fieldName port="35">, then your xpath will end with fieldName and your Attribute Name will be "port". When finished, you can click Preview to see how many matches you have for that particular xpath, as shown below.
As part of the JBoss Server view there is a JMX Console section which allows you to browse and use the JMX exposed beans on the server.
Also you can see the server's publish status in the JBoss Servers view that allows you to see if changes are awaiting (Republish), are being updated (Publishing...) or are in-sync (Synchronized).
The Server section of the view lists all declared servers and their current states, that is, whether they are started or stopped. By Double-clicking on each server, an editor window will appear allowing you to edit parts of that server. The editor will also link you to modify that server's launch configuration, set command line arguments, and other things that are relevant to launching the server.
A username/password is available in the UI when configuring the server. If you get an SecurityException when trying to launch the server it is most likely because your server is protected and hence you need to fill the username/password fields with appropriate values.
The view's toolbar shown below provides quick access to starting a server (in debug mode, run mode, or profile mode), restarting the server, stopping the server, or publishing to the server.
In order to debug your applications or EJB's that are deployed to the server, you must start the server in debug mode. By starting the server in debug mode, eclipse will allow you to set breakpoints on code in your workspace and step through the code.
The publish icon, on the extreme right, will republish any modules where it has determined the workspace is out of sync with the server. It will attempt to do an incremental publish if it turns out that the module in question is capable of doing one.
Because the JBoss servers have few properties to edit in the editor, a shortcut to the launch configuration has been provided in the context menu when right-clicking on a server. This menu also provides the functionality of starting the server in run or debug mode, stopping it, or synching the publish information between the server and workspace.
Near the bottom you'll also see the Add and Remove Projects... item, which allows you to publish a new project to the server (if its type is supported). The last menu item is the one labeled Twiddle Server.
The Twiddle Server item will open a dialog and allow you to run Twiddle commands against it. Twiddle is a JMX library that comes with JBoss, and you can use it to access any variables that exposed via the JBoss JMX interfaces.
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. JBoss Tools comes with our own archives tool with a bit easier and less-verbose XML and a handy user interface.
The Project Archives plugin consists primarily of a view to set up each packaging configuration. Each project can enable or disable its builder, or depend on the global setting.
The packaging configuration for each project is stored in that project's root folder, and is in a file named .packages, which has a fairly simple XML structure. Modifying the file by hand is neither required nor recommended, and using the UI is the official way of modifying your packaging structure.
Aside from the builder, the other preferences for the plugin are mostly cosmetic, allowing you to show full or truncated paths, show the project at the root, etc. None of these has any effect on the functionality of the packaging plugin.
When creating a new archive, you have some different options at your disposal. If the project has no .packages file, your options will be presented to you all at once for you to choose from (as above). Otherwise you will right-click inside the view and select New Archive to see your archive type options.
JAR is the standard archive type, and does very little configuration, leaving most of the work up to you. You can customize the name, add folders, filesets, and inner jars to it.
The other types, for the most part, simply start off with a default setting, usually the jar with some specific children based on an expected structure of the project. For example, if the project is a dynamic web project, and you create a WAR archive, the archive will be created with a few filesets relevant to the known structure of the project.
Because the first page of all new archive wizards are the same, and it is also the only page in the New Jar Wizard, that page is shown below.
The page is pretty simple. All it asks is for the name of your new archive, a destination, which we'll get to in a moment, and whether the archive is exploded or packaged up.
The destination of an archive can be anywhere on the filesystem, anywhere in the workspace, inside some other archive, or inside a folder declared inside an archive. 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 press the Workspace... button. At the bottom of the list, you'll see archives that have been declared in the workspace.
Creating a folder is much easier. You simply right-click on an archive or folder you want your new folder to be a child under. The only piece of required information is naming the file.
To create a new fileset, you click on an available target location such as an archive, a nested archive, or a folder within an archive, and select New Fileset. The New Fileset Wizard requires a destination (where the files will go), and a root directory (or where the files are coming from). The source can be anywhere in the workspace or from the filesystem at large.
Below that, the fileset requires only an includes pattern and an excludes pattern. As you type in either of these fields, the preview viewer should update itself with which files are matched.
The context menu on the items in the view is extendable, but there are several that come standard. The first is the Build Archive action, enabled only on top-level archives, which initiates a full build on that archive. Editing and deleting nodes are also standard actions, with deletion not needing an explanation. The edit action brings up the wizard associated with that particular node type and allows the details to be changed. The final action contribution here is the ability to publish to a declared server.
The dialog above appears after selecting Publish To Server. To simply publish once, you just select the server(s) that you want, and finish. If you want the Publish to Server action on that particular Archive to always publish to that set of servers, then check the appropriate checkbox. And finally, to enable automatic publishing upon build events, check the last checkbox.
The automatic publishing feature is nice if, for example, your package's destination (where it is built) is a temporary folder and you want the archive published to several servers. If you only really want your archive published to one server, it might be easier to have the archive's destination folder be the deploy folder of the server.
In the context menu of files there is a Deploy To Server option that allows a single file deployment. To deploy these non-WTP files/projects right click on the file (-ds.xml, .ear, .jar etc.) and select Deploy To server and it will be automatically deployed.
The deployed files are listed side-by-side with other modules that are deployed to the server.
This chapter covers how to select installed runtime/server in your web project
WTP provides what are called "faceted" projects. Their most popular of these projects are their J2EE projects, such as their Dynamic Web Project, their EJB Project, or their EAR project. Web projects of JBoss Tools are Stuts, JSF and Seam projects.
The idea behind faceted projects is that each project can accept units of functionality, or facets, which can be added or removed by the user. Some examples of these facets are adding a webdoclet facet to a web project, or an ejbdoclet to an EJB Project.
Most often, these "facets" either add to the project's classpath, enable a builder, or watch the project in some other fashion.
WTP projects have undergone some criticism as being over-engineered or too restrictive in their design. WTP projects are set up in a tree-relationship to each other, where one project can be a child of another. For example, an EAR project may have a Web Project child, an EJB project child, or other types.
The benefit of this is that the structure of your projects is then known, and packaging it up *should* be trivial. However, if your project is non-standard, or you feel too confined by such rigid structural requirements, you can still choose to package your project using the Archives plugin
To create a new Dynamic Web Project select File > New > Other... then Web > Dynamic Web Project
Click Next and you will see Dynamic Web Project page
The first page of most WTP projects allows you to target a specific runtime, representing a server's library location. It will also provide you the ability to add this project to an EAR project, and select a pre-selected default set of facets, called a configuration, rather than manually select each facet you might want.
Selecting the runtime, again, allows the project to install the proper classpaths to the project so it knows what code to compile against.
The second page of the wizard allows you to enable or disable specific facets, as described above. Some facets may require others, and some may conflict with others, but on the whole this page allows you to add any number of facets that don't conflict with each other.
Further pages are specific to either the project type, or the facets selected.
In this chapter it will be described how to deploy modules onto the server.
First of all it is necessary to say that deploying to a server is mostly painless. There are several ways to do it provided by WTP, and some additional methods provided by JBoss Tools. These methods are discribed further in this chapter
The first WTP method is to right-click on a WTP project, such as a dynamic web project, ejb project, or ear project and then select Run As > Run on Server. The resulting dialog allows you to select which supporting server the project can be published to.
Click Next button to see add or remove projects page where you can choose projects to configure them on server.
For the JBoss AS Server Adapters, publishing using this method will force a default, best-guess, packaging configuration for your project. This best-guess does not publish incrementally, but instead repackages your entire project into a .war, .jar, or .ear as appropriate, and then copies that file into the proper deploy directory. For quicker smarter deployment, you will need to create archives using the Project Archives view and customize packaging yourself.
Another method is in either the Servers View, or the JBoss Servers View, to right click on a server and select the Add and Remove Projects menu item. This will bring up a dialog allowing you to either publish projects or modules to a server, or remove them from the server.
If the selected module is a WTP project, it will be published as in the Run on Server option, with a best-guess full package. If, however, the selected element is an archive from the Project Archives View, it will be published according to the rules of that module type.
In the JBoss Server's View, in the bottom section, is a category called Modules which should display all currently-published modules on the server. By right-clicking on the desired module and selecting Full Publish, it will force a full rebuild of the entire module.
In the Project Archives View, you can right-click on any declared archive and select the Publish To Server element, as described in the JBoss AS Perspective chapter.
The only way to ensure an Incremental Build, such as changes to one jsp, html, or .class file, is to enable the builder for that project. This is done by either changing the global preferences for the Archives View, or in enabling project-specific preferences and ensuring the builder is on.