Child pages
  • WAR Deployment
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

Servoy Developer (6.1 and later) offers the option to export the Servoy Application Server to a so-called WAR file . This WAR file can then be deployed on any J2EE standards compliant application server, like GlassfishIBM WebSphereJetty or Apache Tomcat for example.

Terminology

In this chapter the term "application server" is used to refer to two different things:

  • Servoy Application Server: this refers to the specific libraries & software components created by Servoy that provide the Servoy specific functionality, like the Servoy Admin page, the hosting of Solutions that can be launched in the different types of Servoy Clients etc.
  • (J2EE standards compliant) application server: this refers to any Java application server that follows the J2EE server specification and under which the Servoy Application Server can run

Benefits

The benefits of the WAR export option are:

  • Provides the ability to create a custom Servoy Application Server "package", containing specific plugins, beans, drivers and LAFs plus specific settings that can be deployed to an application server in one go
  • Provides the ability to run a Servoy Application Server on any J2EE standards compliant application server. 
    Contrary to the Servoy installation that results from running the All-In-One installer, the WAR export does NOT contain the Apache Tomcat application server. A WAR file is an archive file that follows containing an entire application
  • Run multiple Servoy Application Servers on the same application server

Differences with a standard Servoy Application Server installation through the All-In-One installer

  • Doesn't contain Apache Tomcat as application server
  • Doesn't contain the database engine or database files
  • Doesn't support WEBDAV for Web Client template editing
  • Doesn't support uploading (new versions) of plugins, beans, drivers of LAFs through the Servoy Admin page
  • Doesn't support command-line upgrading

Similarities with a standard Servoy Application Server installation through the All-In-One installer

  • Still requires a servoy_repository database connection to operate
  • Can run all the different types of Servoy Client
  • Has the full Servoy Admin page, except for the Library Upload functionality
  • Solutions can be imported through the Servoy Admin page

 

Database connections and .war deployment

The needed database connections (including the repository server DB connection) have to be operational (so already started) before deploying the .war file. This is not much different from a normal application server where you would also need the repository connection operational before starting the server.

If for some reason the .war deployment failed and you cannot access your solution/admin page as expected please check the J2EE server's log files as well as any relevant log files in (user_home_dir)/.servoy/... For example a repository version in the repository DB that is incompatible with the version of Servoy the .war was built on could generate this problem.

Creating a WAR export

The WAR export functionality is exposed in Servoy Developer through the Export menu (File > Export > Servoy > Export War File). This launches a wizard containing the following steps:

  1. Specify name and location for the export file
    The name user for the export file automatically becomes the so-called "context" for the Servoy Application Server when installed on a application server, see About "context" for more info
    NOTE: If you check "Include active solution and modules", table changes and i18n when selected will be synced or imported into the application server when the WAR is first deployed. If the active solution has pre/post import hooks, those will be called during the import process. 
    This solution (and its modules) won't be imported into the repository but are serialized as a binary file that is read in from the file system every time the application/war is started. If that solution is also in the repository then that one will be deleted and will not be used. The repository is still needed for user and sequence management 
  2. Specify plugins to include
  3. Specify beans to include
  4. Specify LAFs to include
  5. Specify Drivers to include
    If the required drivers are already available on the application server on which the WAR will be deployed, htye don't have to be included in the WAR export
  6. Select ng web components to include
  7. Select ng web services to include
  8. Specify servoy.properties file to include
    If specified, steps 7 & 8 will be skipped, see About the servoy.properties file for more info
  9. Specify database server names to include
  10. Specify details for each database server included in the previous step
  11. Finish
About "context"

A application server can host many applications, where a Servoy Application Server is just one of the applications. In order to be able to access each individual application and prevent name clashes, each individual application runs in it's own namespace or "context". If the application server runs on http://localhost:8080 and the context of an application is "xyz", the assets of the application are exposed through http://localhost:8080/xyz/.....

In case of a Servoy Application Server that is deployed as a WAR file with the name "myCustomServoyServer" on a application server on http://localhost:8080, the typical url's of the assets a Servoy Application Server exposes are:

About the servoy.properties file

The WAR export wizard in Servoy Developer allows the specification of a specific .properties file to be included in the WAR file. The settings in the .properties file that is specified will be included in the WAR export and when the WAR is deployed on an application server, the settings are applied. When the .properties file is not specified, the default settings for a Servoy Application Server will be included.

When updating an existing WAR deployment (see Updating a WAR deployment below for more info), only new default settings will be applied to the existing deployment, as to not override configuration changes made after the initial deployment.

On the application server, the settings are stored in the following location: {user.home}/.servoy/server/{context}/servoy_server.properties. 

If {user.home} is a read-only folder, then a SERVOY_USER_HOME system variable must be defined to point to a writable folder.

NOTE: when using an existing servoy.properties file, check if the property "SocketFactory.tunnelConnectionMode" is set to one of the following values: "Http&Socket", "Http" or "Socket". The "2waysocket" option is not fully supported when deploying using a WAR: deploying multiple Servoy WAR's on the same server or a hot redeploy does not work when using "2waysocket". When not using an existing servoy.properties file the "SocketFactory.tunnelConnectionMode" is set to "Http&Socket".

About Web Client templates

A Servoy Application Server deployed as a WAR file does not support WEBDAV, thus it is not possible to edit Web Client Templates. Any templates that require editing need to be edited in Servoy Developer. The WAR Export functionality in Servoy Developer will automatically export all modified templates.

Deploying a WAR file

Deploying a WAR file depends on the application server used. Some application servers host a admin webpage to manage WAR deployments. On other application servers the deployment can be as simple as placing the WAR file in a special 'webapps' folder of the web server, after which the WAR automatically gets deployed by the application server. For details see the documentation of the application server used.

Some application servers automatically expand the WAR file, which means that the content of the WAR file is automatically unzipped into separate files/directories in the appropriate directory of the application server.

When running multiple Servoy Application Servers through WAR deployment on the same application server it is vital to make sure each Servoy Application Server is configured to use a different RMI port and use a different set of databases

 

Port conflicts

If you keep your developer open while testing war deployment on the same machine, please take care of possible port conflicts. For example if your J2EE server is Tomcat it will probably try to use 8080 which is already being used by Servoy Developer. So you will not be able to access it from the browser on that port. Just close developer before deploying or change the ports (see your J2EE server's documentation or this topic if it is not Tomcat) on one of the servers.

Updating an existing WAR deployment

A deployed WAR file can't be modified. Therefor the ability of a Servoy Application Server to upload new (versions of) plugins, beans, drivers and LAF's is disabled. 

If updates are required to plugins, beans, drivers, LAFs, Web Client templates or Servoy Application Server version updates, a new WAR export needs to be made from Servoy Developer. The generated WAR file can then be deployed using the WAR deployment mechanism that most application server have to upload WAR files and (re)deploy them. 

When upgrading an existing WAR deployment, make sure to use the exact same context, otherwise when the WAR file gets deployed, it doesn't update the existing deployment, but instead deploys the WAR as a new application under the new context.

Application server support

The Servoy Application Server can be deployed as a WAR file on any J2EE standards compliant application server. These include for example JBoss, IBM WebSphere, Apache Tomcat and Glassfish.

The WAR deployment of the Servoy Application Server is actively tested by Servoy on:

  • Apache Tomcat
  • IBM WebSphere
  • GlassFish
  • Jetty

NGClient needs the support of websockets and then the java implementation that is based on: JSR-356. For example Tomcat supports this from 7.0.43 and higher and Jetty from 9.1

NOTE: You should not use the Servoy application server (the tomcat we ship) as your target for your WAR. This can result in errors and weird behavior because then 2 application servers are running at the same time in the same space that is not separated from each other. Two war deployements on the same server should be fine (they are separated by tomcat) you only have to make sure that the rmi ports are then different if you enabled rmi/smartclients.

 

Trouble Shooting

Admin page not accessible

  • Is database running?
  • Using 2waysocket?
  • No labels