Guide to Deployment on Apache Tomcat, JSP Web Language

smuthhomelyΔιακομιστές

17 Νοε 2013 (πριν από 3 χρόνια και 1 μήνα)

134 εμφανίσεις

Guide to Deployment on Apache Tomcat, JSP Web
Language

Revised: September 18, 2007
Created: September 18, 2007

Author: Sylvie CHABE





Guide to Deployment on Apache Tomcat, JSP Web
Language

page 2/24





C
ONTENTS


Contents.............................................................................................................2

Installing Apache Tomcat and JSP......................................................................4

Installing Apache Tomcat...................................................................................4

Installing the Jawin component...........................................................................7

Installing Eclipse...............................................................................................7

Note................................................................................................................8

Installation of MEGA WEB Access and MEGA on the server.................................9

MEGA WEB Access and MEGA on the Web server or on a server accessible from the Web
server.............................................................................................................9

Installing components on the Web server..........................................................9

Calling MEGA WEB Access on JSP.....................................................................9

MEGA WEB Access and MEGA on a server other than the Web server in Web service mode 18

Creating MEGA WEB Access..............................................................................19

Installing resources and generation context....................................................21

Installing JSP sources......................................................................................21

Root directory.............................................................................................22

User directory.............................................................................................22

Installing generation context............................................................................22

Conclusion........................................................................................................24




Summary
The aim of this document is to provide an example of MEGA WEB Access deployment on the
Apache Tomcat server using JSP language.
Tests have been carried out only in a Windows environment and are validated only from this
environment.

We distinguish several stages in the installation of MEGA WEB Access on a Tomcat server:
¾ Installation of Apache Tomcat and integration of servlets (JSP).
¾ Check that the server is operating correctly.
¾ Installation of MEGA WEB Access and MEGA. There are two types of installation:
Guide to Deployment on Apache Tomcat, JSP Web
Language

page 3/24





o MEGA WEB Access and MEGA are on the Web server or on a server accessible
from the Web server: in this case, JSP calls MEGA WEB Access directly via COM
protocol.
o MEGA WEB Access and MEGA are on another server not accessible by the Web
server: in this case, JSP calls MEGA via a Web service.
¾ Configuration of MEGA WEB Access adapted to JSP language.
¾ Installing resources and generation context


I
NSTALLING
A
PACHE
T
OMCAT AND
JSP

Installing Apache Tomcat

The first stage consists of installing Java JDK. We choose the following version: j2sdk-
1_4_2_13-windows-i586-p.exe.
When JDK has been installed, we can start Tomcat installation. The version chosen is: apache-
tomcat-4.1.34.exe.
The different versions should be validated since certain versions of JDK are incompatible with
certain versions of Apache Tomcat.
For more information, you should consult Web site:
http://tomcat.apache.org/
.

When installation starts, normal default installation should be selected and correct installation
of JSP extensions verified:




Then select:
• The port on which your Web server should analyze requests
• Administrator name and password. Temporarily, we can select mwa, mwa


Guide to Deployment on Apache Tomcat, JSP Web
Language

page 4/24







The default port is 80. If this port is already in use, you can use 8080. Your http address will
then be:
http://localhost:8080/
instead of
http://localhost/
.
Do not forget to configure the path of the environment of your machine so that it takes into
account the path of JDK:

Guide to Deployment on Apache Tomcat, JSP Web
Language

page 5/24







The Tomcat server should now be tested by running the start service in the bin directory:
bin\startup.bat.
When the service has started, you can test operation of your Web server by testing URL:
http://localhost:8080/
.
The following page should appear:

Guide to Deployment on Apache Tomcat, JSP Web
Language

page 6/24







You will note that this address redirects automatically to a jsp page. Servlet access is therefore
also validated.


Installing the Jawin component
This component enables use of the COM protocol required to access MEGA WEB ACCESS.
It is available at address:
http://jawinproject.sourceforge.net/
.
To install jawin, we must:
- extract the library, for example into your Web work environment
- copy the 2 jar points which are in the lib directory of jawin under:
TOMCAT4.1.24>/common/lib
- copy jawin.dll which is in the bin directory of jawin under: <TOMCAT4.1.24>/bin
Stop the server and restart. The component will normally have been taken into account.
Machine reboot is sometimes necessary.
Installing Eclipse
If you wish to carry out development in JSP, it is best to install Eclipse software as well as the
Tomcat plug-in which enables debugging in JSP.
Eclipse is development software which particularly enables development in JSP.
It can be downloaded from address:
http://www.eclipse.org/downloads/index.php
.
Guide to Deployment on Apache Tomcat, JSP Web
Language

page 7/24





Guide to Deployment on Apache Tomcat, JSP Web
Language

page 8/24





When the file has been downloaded, unzip it in directory "C:\Program Files" of your machine.
The Eclipse executable is available in directory: c:\Program Files\eclipse\eclipse.exe.
When Eclipse has been installed, we must install the Tomcat plug-in available for Eclipse. This
plug-in is available at address:
http://www.eclipsetotale.com/tomcatPlugin.html
. At this
address you will find the latest version of the plug-in and the installation instructions.
When the plug-in has been installed, it must be configured with particular attention paid to the
version of Apache Tomcat that you use.

Note
Note that Tomcat is case-sensitive with respect to files and folders. Take care therefore to
respect case when typing a URL in a navigator.

I
NSTALLATION OF
MEGA WEB A
CCESS AND
MEGA
ON THE
SERVER


MEGA WEB Access and MEGA on the Web server or on a
server accessible from the Web server
This is the preferred deployment mode. We access MEGA WEB Access directly. Communication
protocols are therefore much faster than with Web services. In addition, the fact that MEGA
WEB Access is on the Web server avoids possible network dataflow problems.
It should be noted that the client can refuse installation of components on his Web server. If
his server is common to several Web applications, use of MEGA WEB Access could be costly in
terms of memory. In this case it is better to deploy MEGA WEB Access on another machine,
still installing it from the Web server. In this case, only the cost of a call on the network is
involved, unlike the Web service which encapsulates the communication in a series of
SOAP messages: this significantly slows data regeneration.
Installing components on the Web server
A first stage consists of saving components on the server. To do this, the MEGA version must
be installed from the server on which MEGA WEB Access will be installed so that MEGA will be
accessible by MEGA WEB Access via COM.
When MEGA has been installed, the MEGA WEB Access component must be installed from the
server so that the Web application can communicate with MEGA WEB Access via COM protocol.

Calling MEGA WEB Access on JSP
We use the jawin library. This library is obtainable free of charge on the Web at address
http://jawinproject.sourceforge.net/
. For more information on installation of this component,
see the section above.
This library enables call on a COM object and the associated methods. However, it needs to
know how MEGA WEB Access methods have been declared. To access this information:
¾ Run the oleview.exe utility available at address:
http://www.microsoft.com/downloads/details.aspx?familyid=5233b70d-d9b2-4cb5-
aeb6-45664be858b6&displaylang=en
.
¾ Click button
and select file mgwmwas.exe

We then obtain the following window:

Guide to Deployment on Apache Tomcat, JSP Web
Language

page 9/24







This specifies that "OpenSession" is a get type method and that all the other methods are
invoke type.

The Jawin library proposes 3 method types for calling COM methods:
¾ getN(…) which should be called for all methods declared as get type. This is the case for
OpenSession.
¾ putN(…) which should be called for all methods declared as put type. MEGA WEB
ACCESS does not use this method type.
¾ invokeN(…) which should be called for all methods declared as "standard". This is the
case for CloseSession, Generate, Discard and SetExecutionMode.


Stages in generating a page are:

Creating MEGA WEB Access:

The first stage consists of referencing in the JSP file the jawin packages we shall use:

We must therefore reference:
<%@ page import="org.jawin.DispatchPtr" %>
<%@ page import="org.jawin.constants.VarTypes" %>
<%@ page import="org.jawin.win32.Ole32" %>
<%@ page import="org.jawin.Variant" %>
<%@ page import="org.jawin.UnknownPtr" %>

We must then create our MEGA WEB ACCESS component using the APIs supplied by the
library:

DispatchPtr oMWA = null ;
//----
Guide to Deployment on Apache Tomcat, JSP Web
Language

page 10/24





Guide to Deployment on Apache Tomcat, JSP Web
Language

page 11/24





oMWA = (DispatchPtr) new DispatchPtr("MegaWebAccess.Application");


The object is created. It is a Dispatch object. The object will be created in each page.
Successive creations of MEGA WEB ACCESS always point to the same, unique component
mgwmwas.exe.

Opening a session to MEGA WEB Access:

Opening a session to MEGA WEB ACCESS is by call to the OpenSession method. As we have
previously seen, the OpenSession method is a get type method. The Jawin API to be used to
produce OpenSession is therefore getN(…)


String sSessionId = null ;
//----
if( session.getAttribute("SessionId") == null )
{
String sPwd = "" ;
String sEnvironment = "C:\\Program Files\\MEGA\\MEGA
Code Name 710\\Standard";
String sDatabase = "Adventure" ;
String sLanguage = "english" ;
String sUserWebName = "dupont";
String sUserWebData = "";
Variant vError = new Variant();
vError.bstrVal = "" ;
vError.vt = VarTypes.VT_BSTR ;
Variant.ByrefHolder vRefError = new
Variant.ByrefHolder(vError);
Variant vOldSession = new Variant();
vOldSession.bstrVal = "" ;
vOldSession.vt = VarTypes.VT_BSTR ;
Variant.ByrefHolder vRefOldSession = new
Variant.ByrefHolder(vOldSession);

Object[] sSessionArgs = {sUserWebName, sUserWebData ,
sUser ,sPwd,sEnvironment,sDatabase, sLanguage , (Object) vRefError , (Object)
vRefOldSession};
//----
sSessionId = (String) oMWA.getN("OpenSession" ,
sSessionArgs);
session.setAttribute("SessionId" , sSessionId ) ;
}
else
{
sSessionId = (String) session.getAttribute("SessionId")
;
}

Session opening is necessary only at call to the first page. The session identifier returned is
then valid for as long as the session does not fall into timeout (ie. 20 minutes machine
inactivity. If you carry out several OpenSessions with the same Web user, call to the
Guide to Deployment on Apache Tomcat, JSP Web
Language

page 12/24





OpenSession method will return an error and you will be not be able to generate your page. To
solve this problem, your session identifier should be stored in a session variable to avoid
untimely reconnections which are unnecessary and could invalidate your Web application.

It should be noted that values specified by reference (ie. values that can be modified on the
MEGA WEB Access side) must be declared as Variant and specified as Variant.ByRefHolder.
There are typically two variables here: vError/vRefError et vOldSessionId/vRefOldSession.
Note that these Variants are preinitialized with value VT_BSTR since the expected return
results are strings.


Regenerating content with MEGA WEB Access:

Regeneration of a content by MEGA WEB ACCESS is by call to the Generate method. As we
have previously seen, the Generate method is an invoke type method. The Jawin API to be
used to produce Generate is therefore invokeN(…)


//Step 6 : Retrieve Generation Data
String sGenerationData =
(String)request.getParameter("data");
if( sGenerationData == null )
{
sGenerationData = "generationType-
standard|generator-E5C6E63A46A9007F|object-9E2A9E2B44BB0000";
}
String sUserData = "";
Variant vType = new Variant();
vType.bstrVal = "" ;
vType.vt = VarTypes.VT_BSTR ;
Variant.ByrefHolder vRefType = new
Variant.ByrefHolder(vType);
Object[] oGenerationData = {sSessionId
,sGenerationContext,sGenerationData,sUserData, (Object) vRefType};
//---
//Step 6 : Generate current data
String sResult = (String)oMWA.invokeN("Generate",
oGenerationData);

String sResultType = (String) vRefType.getRef() ;
System.out.println("Return Type = "+
sResultType);

ServletOutputStream outPage =
response.getOutputStream();
//---
//Step 7 : if the data contains text, its content
is returned as it is
if( sResultType.indexOf("text") >= 0 )
{
outPage.print(sResult);
}
//Step 8 : f the data contains binary data, MEGA
returns the hexadecimal content of the data.
Guide to Deployment on Apache Tomcat, JSP Web
Language

page 13/24





// this content must be turned into binary
content.
else
{
response.setContentType(sResultType);
String src=sResult;
byte[] res=new
byte[src.length()/2];
int a,b;
for(int i=0;i<src.length()/2;i++)
{

a=Integer.valueOf(src.substring(i*2,i*2+1),16).intValue();

b=Integer.valueOf(src.substring(i*2+1,i*2+2),16).intValue();
a= (b*16+a);
if(a>0x7f)
{
res[i]=(byte)(a-0xff-
0x1);
}
else
{
res[i]=(byte)a;
}
}
outPage.write(res);
}
outPage.flush();

Regeneration of a Web content must be analyzed before display at navigator level. Data
returned is in either text or binary format. Variable vType/vRefType allows us to identify the
MIME return type to be regenerated. Processing to send the content to the navigator is
therefore specific depending on the returned format. Typically in the case of the code above,
we test for recovery of binary or not binary data. If binary data must be displayed, we use a
small conversion utility, which converts the string returned by MEGA WEB ACCESS (which is in
hexadecimal) to binary. For more information on this subject, see technical article "Binary data
management".

It should be noted that values specified by reference (ie. values that can be modified on the
MEGA WEB Access side) must be declared as Variant and specified as Variant.ByRefHolder.
There is typically one variable here: vType/vRefType.
Note that this Variant is preinitialized with value VT_BSTR since the expected return result is a
string.



Example of complete code:

<%@ page language="java"%>
<%
response.setHeader("Cache-Control","no-cache");
response.setDateHeader ("Expires", 0); //prevents caching at the proxy server
Guide to Deployment on Apache Tomcat, JSP Web
Language

page 14/24





%>
<%@ page import="java.rmi.RemoteException"%>
<%@ page import="java.sql.SQLException"%>
<%@ page import= "java.io.BufferedReader" %>
<%@ page import= "java.io.FileNotFoundException" %>
<%@ page import= "java.io.FileReader" %>
<%@ page import= "java.io.IOException" %>
<%@ page import= "java.io.PrintWriter" %>
<%@ page import="org.jawin.DispatchPtr" %>
<%@ page import="org.jawin.constants.VarTypes" %>
<%@ page import="org.jawin.win32.Ole32" %>
<%@ page import="org.jawin.Variant" %>
<%@ page import="org.jawin.UnknownPtr" %>

<%


//Creation of MWA component
try
{
//Step 1 : intialize COM context
Ole32.CoInitialize() ;

try
{
//Step 2 : create MEGA WEB Access object
DispatchPtr oMWA = null ;
//----
oMWA = (DispatchPtr) new DispatchPtr("MegaWebAccess.Application");
try
{
//Step 3 : Retrieve current user
String sUser = (String)request.getParameter("user");
String sUserWebName = null;
if( sUser == null )
{
sUser = "riskAccess" ;
sUserWebName = "dupont";
}
else
{
sUserWebName = "durand";
}
//Step 4 : Retrieve Session Id for the current user
String sSessionId = null ;
//----
if( session.getAttribute("SessionId") == null )
{
Guide to Deployment on Apache Tomcat, JSP Web
Language

page 15/24





String sPwd = "" ;
String sEnvironment = "C:\\Program Files\\MEGA\\MEGA
Code Name 710\\Standard";
String sDatabase = "Adventure" ;
String sLanguage = "english" ;
String sUserWebName = "dupont";
String sUserWebData = "";
Variant vError = new Variant();
vError.bstrVal = "" ;
vError.vt = VarTypes.VT_BSTR ;
Variant.ByrefHolder vRefError = new
Variant.ByrefHolder(vError);
Variant vOldSession = new Variant();
vOldSession.bstrVal = "" ;
vOldSession.vt = VarTypes.VT_BSTR ;
Variant.ByrefHolder vRefOldSession = new
Variant.ByrefHolder(vOldSession);

Object[] sSessionArgs = {sUserWebName, sUserWebData ,
sUser ,sPwd,sEnvironment,sDatabase, sLanguage , (Object) vRefError , (Object)
vRefOldSession};
//----
sSessionId = (String) oMWA.getN("OpenSession" ,
sSessionArgs);
session.setAttribute("SessionId" , sSessionId ) ;
}
else
{
sSessionId = (String) session.getAttribute("SessionId")
;
}
System.out.println("sSessionId ind= "+ sSessionId);

try
{
//Step 5 : Retrieve Generation context
String sGenerationContext = null;
//----
FileReader fr= new FileReader("C:\\Program Files\\Apache
Software Foundation\\Tomcat 4.1\\webapps\\ROOT\\jsp\\GenCtx.xml");
BufferedReader br=new BufferedReader(fr);
sGenerationContext = br.readLine();
while (br.ready())
{
// Print file line to screen
sGenerationContext=sGenerationContext+br.readLine();
//System.out.println("sGenerationContext ind= "+
sGenerationContext);
}
sGenerationContext = sGenerationContext.replaceAll("%user%" , sUser )
;

Guide to Deployment on Apache Tomcat, JSP Web
Language

page 16/24





try
{
//Step 6 : Retrieve Generation Data
String sGenerationData =
(String)request.getParameter("data");
String sFilename =
(String)request.getParameter("filename");
if( sGenerationData == null )
{
sGenerationData = "generationType-
standard|generator-F8B0F995461C0029|object-9E2A9E2B44BB0000";
}
String sUserData = "";
Variant vType = new Variant();
vType.bstrVal = "" ;
vType.vt = VarTypes.VT_BSTR ;
Variant.ByrefHolder vRefType = new
Variant.ByrefHolder(vType);
Object[] oGenerationData = {sSessionId
,sGenerationContext,sGenerationData,sUserData, (Object) vRefType};
//---
//Step 7 : Retrieve page content
String sResult = (String)oMWA.invokeN("Generate",
oGenerationData);

String sResultType = (String) vRefType.getRef() ;
System.out.println("Return Type = "+
sResultType);

ServletOutputStream outPage =
response.getOutputStream();
//---
//Step 8 : Add HTTP Header data to download
external reference on the browser side
if( sFilename != null )
{
String sHeader = "attachment;filename=\""
;
sHeader = sHeader.concat(sFilename) ;
sHeader = sHeader.concat("\"");
response.setHeader("Content-Disposition" ,
sHeader );
}

//Step 9 : if the external reference contains
text, its content is returned as it is
if( sResultType.indexOf("text") >= 0 )
{
outPage.print(sResult);
}
//Step 10 : if the external reference contains
binary data, MEGA returns the hexadecimal content of the external reference.
Guide to Deployment on Apache Tomcat, JSP Web
Language

page 17/24





// this content must be turned into binary
content.
else
{
response.setContentType(sResultType);
String src=sResult;
byte[] res=new byte[src.length()/2];
int a,b;
for(int i=0;i<src.length()/2;i++)
{

a=Integer.valueOf(src.substring(i*2,i*2+1),16).intValue();

b=Integer.valueOf(src.substring(i*2+1,i*2+2),16).intValue();
a= (b*16+a);
if(a>0x7f)
{
res[i]=(byte)(a-0xff-0x1);
}
else
{
res[i]=(byte)a;
}
}
outPage.write(res);
}
outPage.flush();
}
catch(RemoteException errorGenerate)
{
System.out.println("Error calling Generate : \n"+
errorGenerate.toString());
}
}
catch (FileNotFoundException e)
{
e.printStackTrace();
}
}
catch(RemoteException errorOpenSession)
{
System.out.println("Error Opening Session : \n"+
errorOpenSession.toString());
}
}
catch(RemoteException errorMWACreation)
{
System.out.println("MWA Creation Error : " +
errorMWACreation.toString());
}
Guide to Deployment on Apache Tomcat, JSP Web
Language

page 18/24





//Step 11 : Uninitialize COM context
Ole32.CoUninitialize() ;
}
catch(RemoteException errorCOM)
{
System.out.println("OLEInitialize Error : " + errorCOM.toString());
}
%>

MEGA WEB Access and MEGA on a server other than the
Web server in Web service mode
A choice of deployment type must be made:
¾ if the client refuses installation of components on his Web server, and if the server on
which components must be installed is not accessible from the Web server. If his server
is common to several Web applications, use of MEGA WEB Access could be costly in
terms of memory. In this case, it is better to deploy MEGA WEB Access on another
machine.
¾ if the Web server is installed on an operating system other than Windows. MEGA WEB
Access and MEGA currently operate only under Windows. The only solution to call your
component is to pass via a Web service which is itself deployed on a Windows server.

A technical article on Web services technology will be delivered in a future service pack.


C
REATING
MEGA WEB A
CCESS

MEGA WEB Access setup proposes a default configuration:



Use of this configuration is strongly recommended. However, if you wish to modify it, you can
restart setup for updates by installing the component in the same location or by editing the
registry.
If you use the registry, parameters are located in:
HKEY_LOCAL_MACHINE\SOFTWARE\MEGA\WEB ACCESS SERVER\7.1
You can therefore add or modify the following registry keys:
¾ LogFileName: this is the complete path in which component traces will be stored.
The default value is MWASLOG.TXT in the temporary directory of the machine.
¾ CacheFileRootPath: this is the directory in which the cache is stored. The default
value is the MWAS directory in the temporary directory.
¾ MaxMegaSessionCount: this is the maximum number of MEGA processes
(mgwspro.exe) that can be run by the server on which MEGA is installed. The value
of this parameter will depend on machine power. The default value is 4.
¾ LogRequest: defines if queries that have been run must be logged in the MWAS
logfile. The default value is 1.
¾ LogInvoke: defines if parameters used in the API of MEGA WEB Access must be
logged or not. The default value is 0.
¾ Console: defines if the Windows console must appear as soon as MEGA WEB Access
is used on the server. The default value is 0.
¾ DirectSubProcess: defines if sub-processes started for sessions must be started as
mgwmapp.exe or mgwspro.exe. The default value is 0, which corresponds to
starting mgwspro.exe.
Guide to Deployment on Apache Tomcat, JSP Web
Language

page 19/24





Guide to Deployment on Apache Tomcat, JSP Web
Language

page 20/24





¾ CacheSerialize: defines if the cache must be serialized or not. The default value is
1. In this case the cache is serialized.
¾ CheckState: defines if MEGA WEB Access must verify if the cache of the current
session is consistent with the repository involved. Typically, if dispatch occurs, the
cache is invalidated during reconnection to the session. The default value is 1.

If other registry keys are present, it is recommended that these be left unchanged or the
component may not function correctly. JSP imposes specificities on use of COM components in
its pages.

Guide to Deployment on Apache Tomcat, JSP Web
Language

page 21/24





I
NSTALLING RESOURCES AND GENERATION CONTEXT


MEGA delivers standard examples. These examples must be adapted by the user so that they
can operate with the user environment. You must:
¾ Adapt JSP sources
¾ Adapt generation context to user requirements

Installing JSP sources
Examples of sources are delivered as standard. These sources are made available as examples
only, and cannot operate directly on a Web server on which we deploy MEGA and MEGA WEB
Access.
Typically, the pages delivered specifically manage:
¾ The connecting Web user (variable sUserWebName): the user must therefore integrate
management of its own Web users.
¾ The connecting MEGA user (variable sUser and sPwd): the user must therefore integrate
the MEGA user associated with the connecting Web user. MEGA supplies a tool enabling
creation of mapping between Web user and MEGA user. A technical article on this tool is
available.
¾ The address of the target environment (variable sEnvironment): the user must define
here the environment to be consulted.
¾ The target database (variable sDatabase): the user must define here the database to be
consulted.
¾ The language used (variable sLanguage): the user must define here the language in
which his site will be consulted.
¾ The address of the generation context used. This is referenced as hard data in the JSP
code and should take account of the address of new file GenCtx.xml.
¾ The _HexaIdAbs property of the generator used: here we replace the identifier in red by
the hexaidabs of the user's Web site: $generationData = "data.generationType-
standard|data.generator-1E0C1E2A46150019|data.object-9E2A9E2B44BB0000"
¾ The _HexaIdAbs property of the object for which we wish to display the page: here we
replace the identifier in red by the hexaidabs of the object for which we want a page:
$generationData = "data.generationType-standard|data.generator-
1E0C1E2A46150019|data.object-9E2A9E2B44BB0000"


If the user decides to use these sources to carry out initial tests, the sources must be modified
and adapted, replacing the specificities listed above by data relating to the user's own
environment. Sources provided as examples do not in any event manage:
¾ Session duration
¾ Connection of different Web users
¾ Mapping of Web users with MEGA users.
¾ In-depth error management

These points are the responsibility of the customer, since they can be be highly-specific to the
company, but they must in any event be implemented.

When files have been adapted to the client context, their content must be tested by making
them accessible by the Web server, in this case Apache Tomcat.
There are two possibilities:
Guide to Deployment on Apache Tomcat, JSP Web
Language

page 22/24





¾ Files are positioned at the root of documents that can be read as standard by Apache
Tomcat
¾ Files are deployed in another directory on a machine on which Apache Tomcat is
instaleld.

Root directory
The directory in which documents directly accessible by Apache Tomcat are located is
webapps\ROOT. You can therefore copy your files directly to this location, or create a
"MyFolder" sub-directory in which you copy your files.
In the first case, to access pages of your site, just type address:
http://localhost:8080/index.jsp
in your navigator (if the file you want to access is index.jsp).
In the second case, to access pages of your site, just type address:
http://localhost:8080/MyFolder/index.jsp
in your navigator (if the file you want to access is
index.jsp).
The second solution is preferable since it enables better organization of architectures of the
different Web applications present on an Apache Tomcat server.


User directory
As a security measure, we may wish to define a directory other than the webapps\ROOT
directory as the Web site directory. This prevents hackers directly accessing JSP files and
therefore avoids possible security problems.
In this case, we must edit file server.xml which is located in the conf directory of the Tomcat
installation, positioning on the part that processes directories (<context> tag which is a sub-
tag of <Host>):


Here we map the virtual directory of the Web site with the real physical directory, which is the
directory in which the JSP files are located.
For example:

<Context path="/ MyWebPath " reloadable="true" docBase="c:\MySpecificFolder\" />


Where:
MyWebPath will be the name of the directory called in the Web address:
http://localhost:8080/MyWebPath/index.jsp

and
c:\MySpecificFolder\ is the directory in which JSP sources are located.

The Web site will therefore be available at address:
http://localhost:8080/MyWebPath/index.php
This type of deployment is recommended since it offers better Web application file access
security.


Installing generation context

Generation context delivered as standard is in form:
Guide to Deployment on Apache Tomcat, JSP Web
Language

page 23/24






<
GenerationContext
>
<
cssFiles
>
<
cssFile
>
<
name
>
eanew.css
</
name
>

<
url
>
BinaryImage.php?data=%GenerationData%&user=%user%
</
url
>



</
cssFile
>
</
cssFiles
>

<
generatorFormat
>
complete
</
generatorFormat
>


<
layout
>
standard
</
layout
>


<
binaryResultType
>
hexa
</
binaryResultType
>

<
pages
>
<
diagram
>
<
diagramLayout
>
PNG
</
diagramLayout
>

<
url
>
BinaryImage.php?data=%GenerationData%&user=%user%
</
url
>

</
diagram
>
<
resource
>
<
url
>
BinaryImage.php?data=%GenerationData%&user=%user%
</
url
>



</
resource
>

<
object
>
<
url
>
index.php?data=%GenerationData%&user=%user%
</
url
>

</
object
>
<
externalReference
>
<
url
>
extRef.php?data=%GenerationData%&filename=%FileName%&user=%use
r%
</
url
>



</
externalReference
>
</
pages
>
<
target
>
_self
</
target
>

</
GenerationContext
>



This generation context is but one example among others, and must be totally adapted to the
Web site concerned.
It must take into account the case of files since Tomcat is case-sensitive, and must invalidate
the file call if case is not respected.

Points to be covered are the following:
¾ Style sheet: does file eanew.css correspond to the style sheet of your Web site? If this
is not the case, you must process and reference the correct style sheet in the <name>
tag of <cssFile>, or delete these tags.
¾ Is page generation format "Standard", "frame" or "table"? Depending on definition of
your Web site, you must adapt content of the <layout> tag.
¾ Is _self the target window of all URL addresses referenced in the Web site? If this is not
the case, this parameter must be modified.

Finally, the most important point here concerns binary data regeneration characterized by the
<binaryResultType> tag. The value is and must always be "hexa". The API COM provided by
JSP cannot recover strings with binary format content. We must therefore impose regeneration
in hexadecimal format, and convert the result obtained in the JSP file to binary format so as to
return content that is correct and usable by the navigator.

Guide to Deployment on Apache Tomcat, JSP Web
Language

page 24/24





C
ONCLUSION

Installing a JSP Web application regenerating MEGA data on an Apache Tomcat server
therefore requires installation in different stages.

The first stage consists of installing the different components required for operation of our
application:
¾ Web server: this is Apache Tomcat. It handles analysis and regeneration of transiting
http queries
¾ JSP interpreter: this interprets code in the JSP files and regenerates HTTP content to be
transferred to the navigator Il est intégré dans Tomcat.
¾ MEGA application: this handles generation of content in Web pages
¾ MEGA WEB ACCESS application: this manages user connections and regenerates http
contents to the Web application.

The second stage consists of installing configuration in MEGA and MEGA WEB ACCESS. MEGA
configuration consists of confirming that the target Web site and its entry point do in fact exist.
Configuration of MEGA WEB ACCESS should ba as in chapter "MEGA WEB Access
configuration".

The third stage consists of taking account of code examples provided in this document to
create a Web application that will enable access to MEGA WEB ACCESS. The user can be guided
by JSP code examples delivered with MEGA.

Finally, when the Web application has been installed, its deployment on the server must be
managed so that it is accessible from any navigator.