Home | SourceForge.net | OpenSwing | More documentation

Installation Info

In this page will be described how to deploy JAllInOne inside an Application Server, such as Tomcat.

There is also a final section about how to setup a development environment for JAllInOne and how to build it with Ant.

 

Deploy JAllInOne in a web container

Server-side application can be runned using 2 alternative technologies:

  • Java Servlet - it does not require an EJB container, so JAllInOne server side application can be executed inside any Web container, such as Tomcat, Jetty, JBoss, etc. and using any java version starting from release 1.4. This version is ideal when developing application functionalities: development is faster with respect to other technologies and business logic is reusable also with the SOA version, where beans are managed as Spring beans
  • Mule open source ESB - business logic can be executed for instance within Tomcat using java 1.6, by embedding Mule ESB within the JAllInOne web application; this is a SOA solution that open the JAllInOne services (about 200 JAX-WS web services having more than 2000 web methods) to the rest of world, by allowing to customize business logic using SOA capabilities (external BPM, EDM, etc.).

In any case, a simple web container can be used, such as Tomcat.

In case of using the SOA version of JAllInOne, java 1.6.x is required, Tomcat 6.x is recommended and Mule 2.2.1 libraries will be included within the JAllInOne. More detailed instructions are provided below.

There are two JAllInOne distributions, based on the same front-end and the same business logic:

  • a classic version, non SOA enabled, available as a simple .war file, that must be deployed inside the A.S.
  • a SOA enabled version, avaiable as a .war file including Mule 2.2.1 libraries, that must be deployed inside the A.S.; in this case additional libraries are required by Mule ESB: additional jar files are available as a separate endorsed.zip file and must be copied in an "endorsed" named folder inside Tomcat base folder (see Java endorsed standard mechanism for more detail info)

Before executing the A.S., it is also required:

  • the creation of an empty database schema: JAllInOne has been tested on Oracle, SQL Server and MySQL (with JDBC driver 5.x), so you can use any of these databases.
  • the availability of the correct JDBC driver (according to the database you have chosen) inside the A.S. classpath; for instance, in case of Tomcat 4/5: you have to copy jar files related to JDBC driver within commin/lib or server/lib or shared/lib; in case of Tomcat6 you have to copy them within lib subfolder.
    Note that for MS SQLServer there are two different JDBC drivers, an order and a newer (for java 6 and SQLServer 2005/2008) JDBC driver: be sure to select the correct driver in the setup wizard provided by JAllInOne.
After deploying .war file (and including jars in endorsed subfolder in case of SOA version), the application can be accessed in the A.S. using the web context “jAllInOne”.
To start the client-side application a JRE is required in the client machine.
Be careful to always use the same version of java both for client side and A.S.: an error like the following "local class incompatible: stream classdec serialversionUID = -8592787641212272791, local class serialversionUID = 1762110951610984634" means that you are not using the same java version on client and server side.

The application may be accessed through a browser by connecting to

http://host/jAllInOne/launch1xxx.jnlp

when writing this URI within the browser, Java Web Start (included in JRE distribution) will be launched and inside it the JAllInOne client side application. Three distinct launch1xxx files are provided: launch14.jnlp to execute JAIO client with java 1.4, launch15.jnlp to execute JAIO client with java 1.5 and launch16.jnlp to execute JAIO client with java 1.6

Moreover, there are also other jnlp start files: launch14_nolnf.jnlp, launch15_nolnf.jnlp and launch16_nolnf.jnlp that can ne used to start the front-end without the Alluminium Look 'n Feel.


It is strongly recommended to use the jnlp file to start the application: in this way it is possible to esecute the application via the app icon in the PC's desktop, created by Java Web Start after the first execution.
The first time the client-side application has been started, JAllInOne server-side application check if a database connection has already been defined; so the first time a setup wizard is proposed to the user.
By means of this setup, an administrator can define all connection properties used to correctly connect to the database schema already available (and empty). The setup will create all database structures and startup data on them.
After that, the application is ready to use: the login window is showed to authenticate user and access the client-side application.

If you are using SOA version, you have maybe to restart the application server, in order to listen for newer database settings.

 

Upgrade process

If you have installed JAllInOne in the past, having version greater than or equals to 1.0, then you can transparently upgrade the application to a newer one, simply by removing the jallinone.war file from the A.S. and any other temporary directory related to JAllInOne web aplication (e.g. in Tomcat, remove also "webapps\jallinone subfolder"). After that, you have only to deploy again the newer version of jallinone.war file. After the restarting of the A.S., when launching the client side application, a wizard will appears: specify the same settings to the existing database schema and the application will do the rest: it will upgrade the database schema, bringing it to the last version.

If you are using SOA version, you have also to restart the application server, in order to listen for newer database settings.

  
Note that the connection settings defined the first time JAllInOne is launched are used only once to directly connect to the database and to create the database structured and data.
After the first time, there are several ways to connect server-side application to the database:

  • Do anything – in this case an internal connections pooler is used to connect to the database, using the same connection settings define in the setup phase.
  • Define a datasource resource at Application Server level, according to datasource definition settings specific of the A.S. and link this resource to the application by manually changing the web.xml of the JAllInOne:

    <?xml version="1.0" encoding="UTF-8"?>

     

    <!DOCTYPE web-app

    PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN"

    "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">

     

    <web-app>

    <servlet>

    <servlet-name>controller</servlet-name>

    <servlet-class>org.openswing.swing.server.Controller</servlet-class>

    <init-param>

    <param-name>actionClasses</param-name>

    <param-value>org.jallinone.commons.server.ApplicationActionClasses</param-value>

    </init-param>

    <init-param>

    <param-name>connectionSource</param-name>

    <param-value>org.openswing.swing.server.DataSourceConnection</param-value>

    </init-param>

    <init-param>

    <param-name>resourceFactory</param-name>

    <param-value>org.jallinone.commons.server.XMLResources</param-value>

    </init-param>

    <init-param>

    <param-name>sessionIdGenerator</param-name>

    <param-value>org.openswing.swing.server.DefaultSessionIdGenerator</param-value>

    </init-param>

    <init-param>

    <param-name>logger</param-name>

    <param-value>org.openswing.swing.logger.server.ConsoleLogger</param-value>

    </init-param>

    <init-param>

    <param-name>controllerCallbacks</param-name>

    <param-value>org.jallinone.commons.server.ApplicationControllerCallbacks</param-value>

    </init-param>

    <init-param>

    <param-name>dataSourceName</param-name>

    <param-value>xxxxx</param-value>

    </init-param>

     

     

    <load-on-startup>1</load-on-startup>

    </servlet>

    <servlet>

    <servlet-name>JnlpDownloadServlet</servlet-name>

    <servlet-class>com.sun.javaws.servlet.JnlpDownloadServlet</servlet-class>

    </servlet>

     

     

    <servlet-mapping>

    <servlet-name>controller</servlet-name>

    <url-pattern>controller</url-pattern>

    </servlet-mapping>

    <servlet-mapping>

    <servlet-name>JnlpDownloadServlet</servlet-name>

    <url-pattern>/*.jnlp</url-pattern>

    </servlet-mapping>

     

    </web-app>


  • Use another connection mechanism, by defining an implementation of the class org.openswing. swing.server.ConnectionSource

 

Setting up a development environment

JAllInOne is a java three tier client-server application, so to build it you must need a java IDE, such as JBuilder, JDeveloper, NetBeans, Eclipse.

All these environments can be used to compile JAllInOne source code but, if you want to develop new UI forms inside JAllInOne, then you need to use an IDE that supports java beans specifications and provides an UI Swing designer: JBuilder (until 2006 version), JDeveloper 10g, Eclipse (with Jigloo plugin or Window Builder plugin) are all compatible with OpenSwing UI library used to develop JAllInOne GUI.

Already existing UI forms of JAllInOne are developed using the UI designer of JBuilder: if you want to change these UI forms, then you must use JBuilder or Eclipse (with Window Builder plugin) or JDeveloper 10g. You cannot use NetBeans because of its severe constraints on building UI forms, based on .form proprietary files.

 

Classic version vs SOA based version

A SOA based solution is an approach to architecture that effectively eliminates redundancy while simultaneously accelerating the delivery of projects through consolidation and the reuse of services. A "real" SOA solution requires the development of a lot of components (hundreds to thousand of services) and these dimensions can often slow down the development time, due to the start time of the application server (some minutes) each time a restart is required.

For this reason it can be useful to develop business logic using the classic version, having the advantage of a faster A.S. start time and switching to SOA version when a more stable version has been reached or an integration test has to be accomplished.

 

JAllInOne distribution content
As described in README.txt file, JAllInOne distribution is based on a zip file that contains this directory structure:

  • /src - source files of JAllInOne.

  • /srcclassic - additional source files required for classic version; these files must be used in alternative to the ones included in srcmule and cannot be used to start the SOA version of JAllInOne

  • /srcmule - additional source files to use when starting the SOA version of JAllInOne; java 1.5/1.6 is required; these files must be used in alternative to the ones included in srcclassic

  • /docs - documentation files.

  • /classes - resource files, i.e. Resource_xx.xml files for UI transation, jnlp file for starting application, Rule.xml to customize application behavior through the rule engine, web.xml used by build.xml file to build JAllInOne application as a war file

  • /classes/images - client-side image files,deployed inside clientjaio.jar file

  • /classes/reports - server-side report files, i.e. *.jrxml template files created using iReport open source report designer and *.jasper files, compiled by means of iReport and executed on the server-side of JAllInOne through Jasper Report open source report engine to generate reports in PDF format.

  • /pub - contains the "build.xml" Ant file used to build JAllInOne war file; this folder contains the war file too: you can use it to install JAllInOne web applicaiton inside an Application Server (see section "Deploy JAllInOne in a web container" above).

  • /db.xml - database project file, created using DBDesigner 4

  • /pub - contains the "build.xml" Ant file used to build JAllInOne war file; this folder contains the war file too: you can use it to install JAllInOne web applicaiton inside an Application Server (see section "Deploy JAllInOne in a web container" above).

  • /db.xml - database project file, created using DBDesigner 4

  • /libmule - contains jar files required for SOA version: these files must be copied to WEB-INF/lib folder of JAllInOne web application

  • /libendorsed - contains jar files required for SOA version: these files must be copied to endorsed subfolder of the A.S. (in Tomcat6, if not exists this folder, you have to create it as subfolder of Tomcat base dir)

  • /lib - jar files used to compile JAllInOne source code inside an IDE and to execute the application inside the IDE or outside it. The following files are available inside "lib" folder:

    • clientjaio.jar - contains all JallInOne UI; it's downloaded from the server to the client
    • jcalendar.jar - used on client-side to render the calendar widget
    • jnlp.jar - used on client-side to connect JAllInOne to Java Web Start APIs (e.g. to open browser windows and show reports)
    • looks-2.0.1.jar - used on client-side to set open source JGoodies Look 'n Feel
    • netscape.jar - used on client-side to access to web pages
    • clientos.jar - used on client-side, it's the open source OpenSwing library
    • common-beanutils-1.5.jar - used on the server-side for logging management and by Jasper Report
    • common-collections-2.1.jar - used on the server-side for logging management and by Jasper Report
    • common-digester-175.jar - used on the server-side for logging management and by Jasper Report
    • hsqldb.jar - this file is optional and can be used to use JallInOne with Hipersonic DB
    • itext-1.3.1.jar - used on server-side to generate report in PDF format; it is invoked by Jasper Report
    • jasperreports-1.2.7.jar - used on server-side to generate reports starting from .jasper files; it is used on client-side too, to show reports preview inside a Swing based window. You are free to replace this version of Jasper Report with a newer one, if you have the need to upload report files having features available only with newer Jasper Report versions.
    • jnlp-servlet.jar - used on server-side to dinamically generate a jnlp file starting from launch.jnlp template file, having a context path and other info dinamically determined
    • jruleengine.jar - open source rule engine, used on server-side and embedded within JAllInOne to customize business logic
    • jsr94.jar - library used by the rule engine on server-side
    • log4j-1.2.7.jar - used on server-side to log application messages through Log4J open source library
    • mysql-connector-java-5.0.3-bin.jar - this file is optional and can be used to use JallInOne with MySQL 5.x DB
    • poi-2.0-RC2-20040102.jar - used on server-side to export grid content in XLS format
    • pooler.jar - used on server-side to provide a database connection pooling (optional)
    • serverjaio.jar - used on server-side, it contains all JAllInOne business logic
    • serveros.jar - used on server-side, it's the open source OpenSwing library

JAllInOne compilation
To compile JAllInOne application you have to create a project inside the IDE you have chosen (see IDE compatibility list reported above). To create a project inside the IDE follow these steps:

  • unzip JAllInOne distribution onto your file system: after that there will be available some folders: "src","classes" and "lib"
  • create a new project in the IDE
  • set as project build path (i.e. the path where class files will be created) the "classes" folder
  • set as project source paths both "src" and "classes" folders: in this way the IDE compiler does not clear "classes" content each time a new compilation task is being started, otherwise it clears reources files such as .xml and .ini files.
  • set as project libraries all jar files included in "lib" folder, except "hsqldb.jar" and "mysql-connector-java-5.0.1.jar"

Another external library you have to include in the project is a J2EE implementation jar file (or simply a web container implementation) that provides javax.servlet.* package, required by server-side JAllInOne source code. For instance, you could include the servlet.jar (or servlet-api.jar) file stored in "common/lib" or "lib" folder of a Tomcat distribution.

At this point you are ready to compile JAllInOne project inside the IDE.

Run/Debug JAllInOne client-side from the IDE
To develop inside the project it is important to run and debug both server-side and client-side of JAllInOne.
It is possible to run/debug client-side directly inside the IDE: there is available a "main class" named: org.jallinone.commons.client.DebugClientApplication; this class provides a static void main method that can be invoked from the IDE. It assumes that the server-side servlet (deployed in a web container) can be accessed from the local URI: http://localhost:80/jAllInOne/controller. You could create your own client-side starting class instead of DebugClientApplication class.
Note that since the client-side is run through a main method, neither jar files must be built nor any certificate is needed.

 

Debug JAllInOne server-side from the IDE
To run the server-side of JAllInOne you have to provide a web container, such as Tomcat. Many IDEs embed Tomcat on them, so you could configure the project so that it is possible to run/debug JAllInOne server-side directly in the IDE. A "web.xml" file is provided with the distribution and is located in "classes" folder.
In case of deploying JAllInOne server-side in an external web container (i.e. not directly embedded/included with the IDE), such as Tomcat, you have to use the build.xml file provided with the distribution and located in "pub" folder. There are two ways to use it: by including it directly in the project or by invoking it using Ant from command line. In the first case you have to exploit the IDE fatures, in the latter you have first to install Jakarta Ant and then using it to launch JAllInOne build.xml.
This build file contains several targets. To deploy JAllInOne inside the external web container you have to call the "allclasses-nosign" target. This target creates and deploy the whole application but does not sign all client-side jar files, since client-side is directly run within the IDE.
Many variables must be passed to build.xml file to run it. This is a tipical instruction to run build.xml using Ant:

..\lib\ant -buildfile build.xml -DWEBAPPS=... -DLIB_OPENSWING=... -DKEYSTORE=... -DALIAS=... -DSTOREPASS=... <target>

where:

  • WEBAPPS is the absolute path to Tomcat/webapps folder
  • LIB_OPENSWING is the absolute path to "lib" subfolder
  • KEYSTORE is the absolute path to the keystore (i.e.the certificate) to use to sign all client-side jar files. In fact JAllInOne client-side requires a signature to correctly operate, since JVM security policies does not allow to access to local resources as default behaviour: a certificate must be provided to bypass this security policies and this certificate must be used to sign all jars. For this reason you have to create a certificate by using "keytool" command provided with JDK distribution (see KeyTool instructions in JDK documentation)
  • ALIAS is the username to use with the keystore
  • STOREPASS is the password to use with the keystore

Please see Ant installation instructions to correctly setting up it, i.e. you have to set JDK (not JRE) path for Ant and JAVA_HOME environment variable.

Important note: in the top part of the build.xml file are reported a few folders that must be defined on your file system, BEFORE invoking build.xml file:
src - source folder containing most of the source files
srcmule - source folder containing the rest of the source files, to use when you want to run JAIO with Mule (SOA app...)
srcclassic - source folder containing the rest of the source files, to use when you want to run JAIO into a web container (classic web app...)
classes - folder where .class will be created and which contains also the images subfolder
tmp - tmp folder, used during the building
lib - jars files
libmule - jars files used in case you want to run JAIO with Mule (SOA app...)
libendorsed - jars files used in case you want to run JAIO with Mule (SOA app...)
libservlet - jars files used in case you want to run JAIO into a web container

To debug JAllInOne server-side, the web container must be configured to allow the remote debugging from the IDE.
In case of Tomcat, this can be accomplished by editing the "bin/catalina.bat" or "bin/catalina.sh" starting file, by adding
the following lines:

set DEBUG_OPTS=-server -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8001

After that, you have only to configure JAllInOne project in the IDE by activating remote debugging by specifying the same
remote port (8001 in the example above).

Note that you have first to run the web container (e.g. by invoking "catalina run") and then use the IDE Debugger to attach to the web container in remote debugging mode.

Deploying JAllInOne from the development environment
In "pub" folder of JAllInOne distribution is available the build.xml file. This file contains 4 targets:

  • "allclasses" - this target can be used to deploy the whole project in the web container and sign all client-side jar files.
    Use this target when you want to run the client-side of JAllInOne outside the IDE (e.g. by activating JAllInOne from Java Web Start)
  • "allclasses-nosign" - as described above, this target should be used when developing inside the IDE, to debug the server-side and run/debug the client-side directly from the IDE
  • "war" - this target must be invoked only after invoking "all-classes" target: it creates a war file starting from the "jAllInOne" web content stored in the Application Server (through "allclasses" target) and saves it in the "pub" folder
  • "createdistribution" - is used by JAllInOne author to prepare a new distribution of JAllInOne!

Installation of JAllInOne
Installation of JAllInOne requires the availability of an empty database schema in Oracle, MS SqlServer or MySQL 5.x. having grants to create tables, indexes, foreign keys, contraints and alter table operations.
A web container must be provided too, such as Tomcat and JVM 1.4.2 or newer. You have also to provide the JDBC driver needed to connect to the database. This driver tipically is not included with JAllInOne war file: you can store JDBC driver as a shared library inside the Application Server; in Tomcat you could copy it in "common/lib" folder for instance.
To launch a new installation of JAllInOne, the jallinone.war file must be deployed inside the Application Server. In case of Tomcat, it is sufficient to copy the war file in "webapps" folder of Tomcat and start the Application Server.
Note that the war file must NOT include the "WEB-APPS/classes/pooler.ini" file: the availability of this file is checked each time the web application is started and it contains database connection settings; so if this is the first time JAllInOne is started, then no database settings are still defined, so the file does not exist yet. When launching JAllInOne client-side a setup wizard will be showed: through this wizard an administrator can define database connection settings. After confirming all settings, JAllInOne will create "pooler.ini" file inside "WEB-INF/classes" and will use it to connect to the database schema from now. When "pooler.ini" file is being created, also database schema will be filled, by creating all database structures required by JAllInOne.
For detailed information about installation see the chapter at the top this web page.

Developing reports
All report templates have been created using iReport open source report designer. Currently 1.2.7 version of iReport is used and 1.2.7 version of Jasper Report is runned.
Note that you are free to use newer versions of iReport but you have to configure it to compile jasper files using exactly the same version of Jasper Report deployed in JAllInOne project.

Designing the database
JAllInOne database structures have been designed using DBDesigner open source product. This product stores a projects in xml format; JAllInOne database xml file is located in root of the JAllInOne distribution.
By means of DBDesigner it is possible to graphically design the whole structures and generate SQL instructions to include with JAllInOne distribution. This SQL instructions must be manually copied inside the "classes/defsql.ini" file.
During JAllInOne installation process these SQL instructions stored in defsql.ini file are executed: first of all are executed all create instructions, then all alter instructions and finally all other instructions (insert instructions).

 

Deploy JAllInOne Mobile in a web container

JAllInOne Mobile must be installed within a web container, such as Tomcat, after the JAllInOne first execution : you have first to install JAllInOne and start it, after the creation of tables in the database schema and its initialization, the web application JAllInOne Mobile can be deployed in the same web container. This web application uses the same database schema and business logic and requires the same database configuration file: after deploying JAllInOne Mobile, it checks for pooler.ini file within JAllInOne web app and copy it inside it. No manual configuration is required for JAllInOne Mobile.


Deploy JAllInOne eCommerce in a web container

JAllInOne eCommerce must be installed within a web container, such as Tomcat, after the JAllInOne first execution : you have first to install JAllInOne and start it, after the creation of tables in the database schema and its initialization, the web application JAllInOne eCommerce can be deployed in the same web container. This web application uses the same database schema and business logic and requires the same database configuration file: after deploying JAllInOne eCommerce, it checks for pooler.ini file within JAllInOne web app and copy it inside it. No manual configuration is required for JAllInOne eCommerce.
This web application can show products partitioned by company. For this reason, you have first to define a few data in order to use this eCommerce application for a specific company code: within JAllInOne, you have to open "Company Parameters" window and in the "Company level parameters" you have to define two compulsory fields: "eCommerce customer" and "eCommerce warehouse"; optionally, you can also define a defautl charge to apply to every order done inside the eCommerce application.
In this way, the eCommerce application is able to show products, by filtering them for the specific company code, using the prices defined in the pricelist linked to the selected "eCommerce customer" and item availability will be determined using the "eCommerce warehouse" as source of information.
The "eCommerce customer" represents the anonymous customer, not yet identified: when an anonymous customer creates the order through the "check out" button, details data are required in order to create a sale order and a new customer into JAllInOne.
It is also possible for an already defined (in JAllInOne) customer to login into the eCommerce web application, by providing credential previously defined inside JAllInOne. Therefore, JAllInOne users can be (i) employees for the company who usually use the JAllInOne "back-end" application or (ii) customer. In order to allow customers to login into the eCommerce web application, you have to define a user for the customer through the "Users" functionality in JAllInOne and be sure to specify also a customer code for him. It is not needed to specify rules to link to that user, since he has not to login to JAllInOne as well.