Here we are discussing one of the most sought after feature of deploying our J2EE/JavaEE compliant application in to Pramati Server Using Ant Script. Most IDEs allow configuring a custom build script for the project. Using this feature the deployment activity can be configured as an ANT task in the build script.

IDE Used: MyEclipse 6.0

Target Server: Pramati Server 6.0 SP3

Below mentioned is a step by step procedure on how to configure and Run the Deployment Task Builder In MyEclipse.

1.  Make sure the Pramati Server instance is already up and running on the machine. Open the MyEclipse IDE and create a new Web Application.

2.  Create a file named pramatiDeployer.xml any where on the disc (say D:\pramatiDeployer\ folder) with the following content:

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

<project name="AntShell" default="servertasks">

	<property name="pramati_install_dir" value="D:/Pserver"/>
	<property name="pramati_node_name" value="default"/>

    <taskdef name="pramati" classname="com.pramati.tools.ant.AntTaskHandler" />

	<target name="buildwar">
		<jar jarfile="${build_project}/${project_name}.war" basedir="${build_project}/WebRoot" />
	</target>

    <target name="servertasks" depends="buildwar" >
		<echo message="Project Directory :${build_project}"/>
    	<echo message="Project Name :${project_name}"/>
            <pramati verbose="true"
                     node="${pramati_node_name}"
                     installroot="${pramati_install_dir}/server"
                     ip="localhost"
                     port="9191"
                     realm="system"
                     user="root"
                     password="pramati"
                     fork="false"
                     debug="true"
                     classpath="${pramati_install_dir}/server/lib/pramati/classpath.jar"
                     endorseddirs="${pramati_install_dir}/server/lib/std/endorsed"
                     command="deploy ${build_project}/${project_name}.war"/>
    </target>

    <!--<target name="servertasks" depends="buildwar" >
		<echo message="Project Directory :${build_project}"/>
    	<echo message="Project Name :${project_name}"/>
    	<echo message="Placing the archive in Autodeploy folder"/>
    	<copy file="${build_project}/${project_name}.war"
				todir="${pramati_install_dir}/server/nodes/${pramati_node_name}/archives/autodeploy">
    	</copy>
  	</target>-->

</project>

3.  You can customize the parameters pramati_install_dir, pramati_node_name, port(naming-port), realm, user and password as per the target deployment server and node configuration.

4. Right click on the project and click import. Select General->File System, and click Next.

5. Click ‘Browse’ against ‘From Directory’ box and navigate to the folder containing pramatiDeployer.xml. Click on the check box against pramatiDeployer.xml and click “Finish” to import it into the root directory of the web Application just created

6. Now the file shall be available in the Projects Package Explorer Window file list.

7. Right click  on the file and go to Run As -> Open External Tools Dialog.

8. In the window that follows, double click the “Ant Build” entry on the left panel to add a new Ant Build. The Following screen appears.

9. In case multiple Ant Script build are listed under “Ant Build” entry on the left panel, select the one containing the Project Name you are currently working on.

10. Navigate to “Classpath” tab and Click on “User Entries“. Then click on “Add External JARs” .

11. Navigate to the jar <Pramati_server_install>/server/lib/pramati_client/pramati_ant.jar and click on “Open” to add the same to classpath.

12. Click on “Apply” and “Close” on External Tools Window.

13. Now our script is available as a build script which can be added to the Auto Build sequence. To do so, Right click on the project. Go to Properties->Builders->Import.

14. Select the newly created build script from the listed entries. Take care to choose the one with the current project name, if more than one entries are listed.

15.  Click on “OK“. Now edit the imported builder by clicking on “Edit“. The following window appears.

16. Go to “Targets” tab and Click on “Set Targets” button against the “Auto  Build” Box. On the “Set Targets” dialog that appears, Select the “servertask” entry and click ok.

17. Go to “Main” tab and add the following in the “Arguments” text box.

-Dbuild_project=${build_project} -Dproject_name=${project_name}

18. Click on “OK“. This shall finish the configuration and run the auto build process immediately causing our script to be executed.

19. The following shall appear on the MyEclipse console window in case of successful deployment.

20.  Corresponding out put on the Pramati Server console:

In case of any errors
1. Check correctness of the pramati_install_dir and other configured parameters in pramatiDeployer.xml.
2. Make Sure the server is running
3. Make sure the pramati_ant.jar is placed in classpath and is from the same setup as the target server

Customized deployments can also be done. For example deployments with custom context root, mapping resource (like Datasource) names etc. Steps for the same shall follow in next post.

@ ECHO Generated batch file to setup Environment Variables for Pramati Server 6.0
set install_root=D:\Pserver60_1091_SP3\server
set JAVA_HOME=D:\Java\jdk1.6.0_21
set PATH=%JAVA_HOME%\bin;%PATH%
set CLASSPATH=%JAVA_HOME%\lib\tools.jar;%install_root%\lib\pramati\classpath.jar;
 

Now the nodes can be started using the runserver script file as usual and SSL Session renegotiation shall be disabled by default.

Testing SSL Session renegotiation:
For my test case I have used the instructions at http://blog.ivanristic.com/2009/12/testing-for-ssl-renegotiation.html

The Console output:

C:\OpenSSL098a\bin>openssl s_client -connect localhost:443
Loading 'screen' into random state - done
CONNECTED(00000784)
depth=0 /C=India/ST=AP/L=Hyderabad/O=Pramati/OU=Engineering/CN=test certificate
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=India/ST=AP/L=Hyderabad/O=Pramati/OU=Engineering/CN=test certificate
verify return:1
---

. . .
[SSL-Handshake-Messages]

. . .
---
HEAD / HTTP/1.0
R
RENEGOTIATING
6776:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:.\ssl\s3_pkt.c:534:

closed

C:\OpenSSL098a\bin>
 

Step By Step:
1. Navigate to the OpenSSL bin directory on a Command Prompt
2. Execute command to connect to running web server using command

openssl s_client -connect localhost:443
 

3. If the server IP and Port are correct, connection will be through and a lot of SSL handshake messages shall be printed on console.

Loading 'screen' into random state - done
CONNECTED(00000784)
depth=0 /C=India/ST=AP/L=Hyderabad/O=Pramati/OU=Engineering/CN=test certificate
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=India/ST=AP/L=Hyderabad/O=Pramati/OU=Engineering/CN=test certificate
verify return:1
---
Certificate chain
0 s:/C=India/ST=AP/L=Hyderabad/O=Pramati/OU=Engineering/CN=test certificate
i:/C=India/ST=AP/L=Hyderabad/O=Pramati/OU=Engineering/CN=test certificate
---
Server certificate
-----BEGIN CERTIFICATE-----
MIICXzCCAcigAwIBAgIES6tMbTANBgkqhkiG9w0BAQUFADB0MQ4wDAYDVQQGEwVJ
bmRpYTELMAkGA1UECBMCQVAxEjAQBgNVBAcTCUh5ZGVyYWJhZDEQMA4GA1UEChMH
UHJhbWF0aTEUMBIGA1UECxMLRW5naW5lZXJpbmcxGTAXBgNVBAMTEHRlc3QgY2Vy
dGlmaWNhdGUwHhcNMTAwMzI1MTE0MzQxWhcNMTEwMzI1MTE0MzQxWjB0MQ4wDAYD
VQQGEwVJbmRpYTELMAkGA1UECBMCQVAxEjAQBgNVBAcTCUh5ZGVyYWJhZDEQMA4G
A1UEChMHUHJhbWF0aTEUMBIGA1UECxMLRW5naW5lZXJpbmcxGTAXBgNVBAMTEHRl
c3QgY2VydGlmaWNhdGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALi1cXLT
TxkqxCcHVm/7JcoRn3uJlex3NAnEMYNLTopf2SOzdJDYRjd3MHY3JcT+yEtvfNSR
Vpj7KyDTD0Up2XDZyk0+yJAI6DqLelmfak4/uDbXMW9T7jW7Gu2jbJA5WJD5oyHF
MuiWRAu3xdL049H5uRDJpUN2ckVGBN/eBdOnAgMBAAEwDQYJKoZIhvcNAQEFBQAD
gYEASdTN256auusTcKOReeh2OW8y0PS6kI4eSPjAWCqI+bnixtxc5bhNp/p2kjbL
IqcfpQnRmffbMLXlHJgV03DL4jUTXQCwJu6Jw4fHwiUnU+prcruVDSPT9pNZbEId
ou8CYYE5ISVz+wWSXv6tXRDVhLjj4JZVOl58p9DqzUR+Evc=
-----END CERTIFICATE-----
subject=/C=India/ST=AP/L=Hyderabad/O=Pramati/OU=Engineering/CN=test certificate
issuer=/C=India/ST=AP/L=Hyderabad/O=Pramati/OU=Engineering/CN=test certificate
---
No client certificate CA names sent
---
SSL handshake has read 1152 bytes and written 338 bytes
---
New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol  : TLSv1
Cipher    : EDH-RSA-DES-CBC3-SHA
Session-ID: 4C5027FBD785EA3AAAB4ACBB45A1426E52D5DF829DD13D1B9CDF25C6266D6FC6
Session-ID-ctx:
Master-Key: 291247553A11AF4AC9FB54DE32D677ACE804605675D3EC58B72572D31E831EFB4D2E6C339AB39458E56E8650D2FF8253
Key-Arg   : None
Start Time: 1280321531
Timeout   : 300 (sec)
Verify return code: 18 (self signed certificate)
---
 

4. Now, the connection shall remain active for the socket idle timeout seconds, which is usually 3 seconds for default Pramati Server node.
5. We can send first line of Request header now. Paste the following at command prompt and press enter (before the time out happens of-course).

HEAD / HTTP/1.0
 

6. Now we can initiate a renegotiation by typing R and pressing enter.

R
 

(The time out sure applies here as well. So make sure you key in R and press enter before the time out of 3 seconds starting from the point we pressed enter for the HEAD line above)

7. A renegotiation request is now initiated. Now is the time for results. If JDK does not allow renegotiation, the output on the same window shall be as given below:

RENEGOTIATING
6776:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:.\ssl\s3_pkt.c:534:
 

8. If the JDK allows renegotiation, the output shall be like :

RENEGOTIATING
depth=0 /C=India/ST=AP/L=Hyderabad/O=Pramati/OU=Engineering/CN=test certificate
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=India/ST=AP/L=Hyderabad/O=Pramati/OU=Engineering/CN=test certificate
verify return:1
 

9. We can leave the prompt now as it is, and the connection shall be closed automatically by time-out

closed
 

JDK also provides a system property to re-enable SSL re-negotiation, which can be configured in the server startup script runserver.bat / runserver.sh.

To make the deployment process much simpler, we can now directly deploy the archive using URL spec. Java URLs can be made to work with protocols like http, ftp, etc., with support for introspection of standard headers and authentication mechanisms. For example, you can download an archive uploaded to ftp site as shown below.

  URL url = new URL("ftp://guest:guest@ftp.mysite.com/apps/myapp.war");
  URLConnection conn = url.openConnection();
  InputStream is = conn.getInputStream();
  

You can see that the user & password are also included within the URL, as it requires authentication. Now, all that we need to deploy application is the URL spec., ftp://guest:guest@ftp.mysite.com/apps/myapp.war. This is not just enough, with the growing adoption towards cloud storage services like Amazon S3, there is need to support more protocols. Java allows configuring custom protocol handlers by implementing java.net.URLStreamHandler and placing it in the classpath. The following is a protocol handler for Amazon S3.

  package sun.net.www.protocol.s3;

  public class Handler extends URLStreamHandler {

     protected URLConnection openConnection(URL u) throws IOException {
        InputStream is;
        try {
           RestS3Service s3Service = new RestS3Service(
                    new AWSCredentials(accessKey, secretAccessKey));
           S3Object s3obj = s3Service.getObject(
                    new S3Bucket(u.getHost()), u.getPath().substring(1));
           is = s3obj.getDataInputStream();
        }catch (S3ServiceException e){
           throw new IOException(e);
        }
        final InputStream inputStream = is;
        return new URLConnection(u) {
           public InputStream getInputStream() throws IOException {
              return this.inputStream;
           }
           public void connect() throws IOException {
              // Nothing to do. When we give back this object
           }
        };
     }
  }
  

The package name for the handler class, sun.net.www.protocol.s3 indicates URL mechanism to use this handler for S3 protocol, i.e. for all URLs of the form s3://s3.amazon.com/mybucket/myapp.war, and most importantly the class name should be named as Handler. The package name convention is enforced to make sure the standard protocol handlers are always loaded by the Java boot strap classloaders. However, there is an antidote if you intend to override the default behaviour through system property java.protocol.handler.pkgs, which allows specifying a comma separated list of packages to look for the protocol handlers.

However, the above approach requires protocol handler classes to be placed in system classpath only. There is another approach to control the protocol handling mechanism through the java.net.URLStreamHandlerFactory class, which can be set through a public static method in java.net.URL.

  URL.setURLStreamHandlerFactory(new URLStreamHandlerFactory() {
     public URLStreamHandler createURLStreamHandler(String protocol) {
        ...
        return null;//if you do not intend to create handler for this protocol
     }
  });
  

With the Factory approach we can completely customize the class loading mechanism, package and class name conventions and overriding the default protocol handlers. But the downside is, once the Factory is set, it cannot be reset within the JVM. Especially, if running within a Container or Server environment which has the URLStreamHandlerFactory already set, there is no way of setting our own factory again.

Using the above approaches, we can support deploying applications from one of your favourite storage services through its own protocol.

SQL Server differentiates its data types that support Unicode from the ones that just support ASCII. For example, the character data types that support Unicode are nchar, nvarchar, longnvarchar where as their ASCII counter parts are char, varchar and longvarchar respectively. By default, all Microsoft’s JDBC drivers send the strings in Unicode format to the SQL Server, irrespective of whether the datatype of the corresponding column defined in the SQL Server supports Unicode or not. In the case where the data types of the columns support Unicode, everything is smooth. But, in cases where the data types of the columns do not support Unicode, serious performance issues arise especially during data fetches. SQL Server tries to convert non-unicode datatypes in the table to unicode datatypes before doing the comparison. Moreover, if an index exists on the non-unicode column, it will be ignored. This would ultimately lead to a whole table scan during data fetch, thereby slowing down the search queries drastically.

All the tables created by the JMS Server have non-unicode datatypes and hence will be the indexes on non-unicode datatypes. With this, we fell in the trap of the MS JDBC driver’s default behaviour, facing a performance degradation.

On digging the driver’s configuration, we figured that there is a property called sendStringParametersAsUnicode which helps in getting rid of this unicode conversion. This property defaults to ‘true’ which makes the JDBC driver send every string in Unicode format to the database by default. We switched off this property and achieved two improvements in our use-case:
1) All string parameters of our prepared statements are being sent to the database in ASCII format. This helped us overcome the Unicode conversion overhead.
2) Since Unicode conversion isn’t happening, all our indexes on varchar columns are being used during data fetches instead of whole table scans.

With this, we were able to get our JMS server started in less than 30 sec.

This performance degradation is quite possible with other driver’s for Microsoft SQL Server also as the default behaviour in the well-known drivers for MS SQL Server is to send strings as Unicode by default. However, all these drivers have a similar property to tweak the default behaviour. Here is a list of these of properties by vendor:

How to apply the property in Pramati Server?
Pramati Server maintains all datasources, jdbc connection factories in an xml file called resource-config.xml. The property sendStringParametersAsUnicode has to be added under the ‘properties’ element of the corresponding jdbc connection factory.

Example:
<connection-factory authorized-by=”Container” classname=”com.microsoft.sqlserver.jdbc.SQLServerDriver” description=”" name=”jmsdb-cf” url=”jdbc:sqlserver://localhost\SQLEXPRESS;DatabaseName=TESTDB”>
<login-parameters mask-password=”false” password=”pramati” user=”sa”/>
<properties>
<property name=”sendStringParametersAsUnicode” value=”false”/>
</properties>
</connection-factory>

Alternately, the property can also be added to the connection url string as shown below:

<connection-factory authorized-by=”Container” classname=”com.microsoft.sqlserver.jdbc.SQLServerDriver” description=”" name=”jmsdb-cf”
url=”jdbc:sqlserver://localhost\SQLEXPRESS;DatabaseName=TESTDB;sendStringParametersAsUnicode=false“>
<login-parameters mask-password=”false” password=”pramati” user=”sa”/>
<properties/>
</connection-factory>

If you have installed Pramati Server, then access the Management console through “http://<host_name>:<port_name>/admin” and login with default user name, password as “root” and “pramati” respectively.

where,

1. <host_name> :  Is your host name where server is installed
2. <port_name> :  HTTP listener port value, default is 8181

After logging in, on the left navigation panel, click on “Utilities”. Now you can see “MBean Viewer” link there. MBean Viewer is a utility provided in the Console to allow you to view details about all the MBeans present in and being used by the various Domains. Further expanding the Domain will list all the MBeans related to it. Clicking on a listed MBean will display the following three tabs for the same MBean:

1. attributes
2. operations
3. notifications

You can also avail the Management APIs for particular MBean, by clicking on the link provided under “JavaDoc” section. You can use them as per requirement. Click on the “Help?” icon present on MBean Viewer page to know more about it.

Now, lets see a sample which shows the status of the Datasource configured on the Pramati Server. I assume that you already have a DataSource configured on server. Find more information on configuring DataSources here.  Now coming to our sample with MBean, here is the snippet of code:

import java.util.Properties;
import javax.management.MBeanServer;
import javax.management.ObjectName;
import javax.naming.InitialContext;

import com.pramati.services.admin.base.StatisticsProvider;
import com.pramati.services.admin.stat.Statistic;
import com.pramati.services.admin.stat.StatisticMetadata;
import com.pramati.services.admin.stat.Stats;
import com.pramati.services.admin.util.PoolStatus;
import com.pramati.services.j2ee.spi.admin.J2EEServerMBean;
import com.pramati.services.resource.spi.admin.JDBCResourceMBean;
import com.pramati.services.resource.spi.admin.JDBCSelfManagedDataSourceMBean;

public class MyMBeanLookup
{
    public static void main(String args[])
    {
        try {
//Create Initial Context to the server where we want to lookup the resources
            Properties props = new java.util.Properties();
            props.put("java.naming.factory.initial", "com.pramati.naming.client.PramatiClientContextFactory");
            props.put("java.naming.provider.url", "rmi://127.0.0.1:9191");
            InitialContext ic = new javax.naming.InitialContext(props);
            J2EEServerMBean mBeanServer = (J2EEServerMBean) ic.lookup("root-server-mbean");
//Get Name of Node
            System.out.println("The Server Node Name is :: " + mBeanServer.getServerName());
//Get hold of JDBCResourceMBean
            JDBCResourceMBean myResourceMbean = mBeanServer.getJDBCResourceService();
//Get all Container Managed DataSources
            JDBCSelfManagedDataSourceMBean[] dataSources = myResourceMbean.getJDBCSelfManagedDataSources();
//Iterate the datasources to get the stats
            for (JDBCSelfManagedDataSourceMBean dataSource : dataSources) {
                Stats getMyStats = dataSource.getStats();
                System.out.println("The DS name :: " + dataSource.getJNDIName());
                System.out
                        .println("ConnectionRefreshRate in Minutes :: " + dataSource.getConnectionRefreshRateMinutes());
                System.out
                        .println("ConnectionRequestTimeout in Seconds :: " + dataSource.getConnectionRequestTimeout());
//Get Pool statistics
                PoolStatus poolStat = dataSource.getCurrentPoolStatus();
                System.out.println("Total Pool size :: " + poolStat.getPoolSize());
                System.out.println("Free Pool size :: " + poolStat.getFreePoolSize());
                System.out.println("in Use Pool size :: " + poolStat.getInUsePoolSize());
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

Change the following line of code with appropriate host-name and naming port value for successful lookup on server.

props.put(”java.naming.provider.url”, “rmi://127.0.0.1:9191″);

To compile and execute the class successfully, you need to have following list of jar files in classpath:

1. pramati_client_all.jar :   located at <$pserver_install>\server\lib\pramati_client
2. pramati_client_all_jms.jar :   located at <$pserver_install>\server\lib\pramati_client
3. pramati_jmsconn.jar :   located at <$pserver_install>\server\lib\pramati
4. pramati_serveradmin.jar :   located at <$pserver_install>\server\lib\pramati
5. pramati_util.jar :   located at <$pserver_install>\server\lib\pramati

On successful execution, you should see the status of the configured DataSource. Similarly you can view other services status through

com.pramati.services.j2ee.spi.admin.J2EEServerMBean
or
com.pramati.services.jms.spi.admin.JMSServerMBean

by looking up “root-server-mbean” or “jms-server-mbean” either from the same VM or remotely.

The sample was for viewing the statistics. You can also make any configurational changes through MBean. Changes can not be done through anonymous login. That means in the above example, user is an anonymous user. You must provide administrative credential details to do so. For this, add following three lines to your code:

props.put(”java.naming.security.principal”, “root”);
props.put(”java.naming.security.credentials”, “pramati”);
props.put(”com.pramati.naming.realm”, “system”);

where,

1. root :   default user name
2. pramati :   default password
3. system :   default realm configured on Pramati Server

If you are not using the default values of these properties, then replace them with your customized ones.

Configure/Enable Server for HTTPS Requests :

1. If Pramati Server is already up and running and you want to configure SSL support on the fly with the default (https-port value 443) configuration, execute the following command at Server Shell prompt:

j2eeadmin@default> ssl_accept start

Eg:

Refer the following screen-shot for the details:

2.  If you want to configure SSL support with your own configuration:

* Edit server-config.xml file located at <install_dir>/server/nodes/<node_name>/config/ directory.

* Locate the following under the services tag:

<service name=”WebContainer” enabled=”true” class-name=”com.pramati.web.WebServer”>
<property name=”https-port” value=”443″/>
</service>

* By default, https-port is set as 443. Set this value to the required HTTPS port as you want to modify and save this file.

* Now, edit web-config.xml file located at <install_dir>/server/nodes/<node_name>/config/ directory.

* By default,

<protocol http-enabled="true" ssl-enabled="false"/>.

Set ssl-enabled to true as

<protocol http-enabled="true" ssl-enabled="true"/>.

* Save the changes and restart Server.

* Note that, you will see the following information during the restart of Pramati Server on the server console:

This confirms that SSL support is enabled successfully on Pramati Server.

Manage Security Certificates using Management Console:

1. Start Pramati Server and access the following url:

http://localhost:8181/admin/

2. Provide the required credentials and navigate to “Configure –> Security Certificates” available in the left panel of management console .

3. By default, you see a test certificate called “default” under “Server Certificates” section.  Click on “Add” button:

4. Once you have clicked “Add” button, the following screen will display for the details. Fill the details as per the requirement and click “Save” button:

5. Make sure that the certificate name should be equal to the domain name of the site for which you are trying to configure https. In the above example it is test.pramati.com.  Here, you can ignore the port numbers on which you are going to access the application.

6. The created certificate will appear as shown in the following screen-shot:

The created certificate contains “Alias” name with Issued By and Issued To information. Presently both the entries are equal to the target domain name. This indicates that the certificate is generated for this domain and not yet signed by CA.

7.  The server certificates are loaded during the startup of Pramati Server. By default test certificate is the one which is available, can be picked up. Hence, it is suggested that delete the existing test certificate with alias “default” after creating a new certificate (Eg: samplecert). To delete “default” certificate, check the box available against to alias name “default”  and click “Delete” button. Once you have deleted the existing default certificate, restart Pramati Server to use the newly created certificate.

Note:

It is always recommended that you should have only one certificate under “Server Certificate” section.

8. The certificate that is generated using Server is a self-signed certificate. For getting the certificate signed by a CA, a Certificate Signing Request (CSR) must be sent to the CA. To obtain the CSR,  click on the certificate’s alias name (samplecert) and select “Save CSR”  option in the next screen.

* In case of InternetExplorer, you will get a prompt for saving the file. Click on “Save” and provide the name as “CSRReply.cer“.

* In case of Firefox, CSR details will be displayed directly in right panel of management console. Copy the content and paste in a notepad. Save this file as “CSRReply.cer“.

9.  Once the CSR is generated, the CSR file has to be mailed to the CA. The CA signs the same and sends back the same.

10. Once you have received the mail from CA, extract the CSRReply certificate and save it on the localmachine as “CSRReply.cer“.

11. As most of the CA’s are already listed in Pramati Server under “Certification Authorities trusted by Server” section, you can import the CSRReply on the generated self-signed certificate.

Note:

If the CA is not listed in the trusted certs of Pramati Server, you will get “Exception while importing the CSR reply in the store…” exception. To overcome this problem, refer “General Exceptions with solutions” section which is explained after the completion of the current steps in this post.

12. To import CSRReply, click on alias (samplecert) name and browse for the CSRReply.cer file under “Certificate Signing Request Reply” section and click “Import“.

13. Upon the successful import of certificate, the following information(as shown in the screen-shot) will be displayed against the alias name under “Server Certificates” section:

14. This confirms that the certificate is issued to domain(test.pramati.com) by CA (verisign).

15. Now, access the following URL to confirm the same:

https://test.pramati.com/admin/ (if you have configured https-port as 443 else you have to access this url with port number specified). Make sure that test.pramati.com should points the machine where you have installed the certificate.

General Exceptions with solutions:

1.
File uploaded. Now putting certificate in store…

Exception while importing the CSR reply in the store…:Error while importing the CSR reply. – Could not establish the certificate chain.

Solution:

The above exception clearly indicates that the certificate chain is incomplete.  A certificate chain is a sequence of certificates, where each certificate in the chain is signed by the subsequent certificate. The last certificate in the chain is normally a self-signed certificate-a certificate that signs itself.

Following is the exception while trying with verisign trial certificate:

Exception while importing the CSR reply in the store…:Error while importing the CSR reply. – Could not establish the certificate chain. Missing certificate for issuer ‘CN=VeriSign Trial Secure Server CA – G2, OU=Terms of use at https://www.verisign.com/cps/testca (c)09, OU=”For Test Purposes Only. No assurances.”, O=”VeriSign, Inc.”, C=US’

*To resolve this problem, firstly, double click on “CSRReply.cer” certificate which you have received from CA and saved on the local machine. This certificate contains the information as shown below:

* This certificate is issued by “Verisign Trial Secure Server CA – G2“. So, you need to import root/intermediate certificate for “Verisign Trial Secure Server CA – G2“  into “Certification Authorities trusted by Server” section. You can get these root/intermediate certificates from respective CA. Mostly, all the instructions (download locations) are explained in the CSR reply mail sent by CA.

* Once you have download the root/intermediate certifcate from the respective locations, save this certificate as “inter.cer” and double click this certificate for the details. Details are as follows:

* As this certificate is issued by “Verisign Trial Secure Server Root CA – G2“, you need to import root/intermediate certificates for “Verisign Trial Secure Server Root CA – G2” into “Certification Authorities trusted by Server” section.

* Once you have download the Root CA certificate from repsective location, save this file as “RootCA.cer” and double click this certificate to view the details. Details are as follows:

* This indicates clearly that the “issued by” and “issued to” are same. This conclude that the chain completes if you have the above specified two root/intermediate certificates in the Pramati Server’s trusted store. To import these files, click on “Add” button under “Certification Authorities trusted by Server” section and browse for files and click “import” button to import the intermediate certificates.

* Once you have imported these files under “Certification Authorities trusted by Server” section, import CSRReply, by clicking on alias (samplecert) name and browse for the CSRReply.cer file under “Certificate Signing Request Reply” section and click “Import“.

The certificate creation, signing and import on to server can be done using both the web console and the server command prompt. In this article we discuss on how to carry out the following steps using Pramati server command prompt or a Remoteshell prompt:

• Create the Server certificate

• Generate the Certificate Signing Request (CSR)

• Get the CSR signed by a Trusted Certifying Agency (CA)

• Import the CA reply certificate into Pramati Server

Create the Server certificate:

1. Go to the server command prompt window with j2eeadmin@<node-name> prompt (or remoteshell prompt).

2. Type “secsh” without the quotes and press enter at the j2eeadmin@<node-name> prompt. You shall be presented with the security shell command prompt securityShell@<node-name>.

3. Create a new Server Certificate: Type “generate_cert” without the quotes and press enter. Provide the details asked for one by one. For example

securityShell@default> generate_cert

Please Enter the following values required by the command:
Note: Fields followed by * are mandatory
You can press ‘Enter’ for default values shown in [ ]
Typing ‘q’ and pressing enter at any point will cancel the current command

securityShell@default> – alias * #myalias
securityShell@default> – Common Name * #testsite.com
securityShell@default> – Organization Unit * #SampleOrganisation
securityShell@default> – Organization * #sampleOrg
securityShell@default> – City * #Mumbai
securityShell@default> – State * #Maharastra
Two Letter Code for Country, e.g IN
securityShell@default> – Country * #IN
securityShell@default> – Validity [365] #365
Key Algo can be ‘RSA’ or ‘DSA’
securityShell@default> – Key Algo [RSA] #RSA
Key Size must be a multiple of 64.
securityShell@default> – Key Size [1024] #1024
A few examples of Sign algorithm :
MD5WithRSA
SHA1WithRSA
SHA1WithDSA
securityShell@default> – Sign Algo [MD5WithRSA] #MD5WithRSA
Certificate <myalias> Added to the server keystore.

Please note that the Common Name  attribute should set to a value equal to the site on which the certificate is supposed to be used. Like in the example, the applications on the server can be accessed using https://testsite.com/app1/. In case the site name differs from the Common Name  attribute, client/browser shall raise and SSL handshake error.

You can confirm the addition of the new certificate using the command “list_server_cert” without the quotes.

Generate the Certificate Signing Request (CSR):

1. Type “generate_csr” without the quotes and press enter. Provide the details asked for reg alias and target file name. For example:

securityShell@default> generate_csr

Please Enter the following values required by the command:
Note: Fields followed by * are mandatory
You can press ‘Enter’ for default values shown in [ ]
Typing ‘q’ and pressing enter at any point will cancel the current command

securityShell@default> – alias * #myalias

securityShell@default> – fileName * #mycert.csr
CSR generated for <myalias> and stored in D:\Pserver\server\bin\mycert.csr

Get the CSR signed by a Trusted Certifying Agency (CA):

1. The .csr file should be sent for signing to desired CA. You may type exit in security shell to return back to j2eeadmin prompt.

Import the CA reply certificate into Pramati Server:

1. Take a back up of the existing keystore files from the node (castore,servercerts,trustedcacerts) config directory. (<server-install>/server/nodes/<node-name>/config directory)

2. Go to the server command prompt window with j2eeadmin@<node-name> prompt (or remoteshell prompt).

3. Type “secsh” without the quotes and press enter at the j2eeadmin@<node-name> prompt. You shall be presented with the security shell command prompt securityShell@<node-name>.

4. List the available aliases in the server certificate store by executing the following command at securityShell

list_server_cert

5. Place the reply certificate file from CA in <server-install>/server/bin directory. Say <server-install>/server/bin/signedCert.crt.

6. Execute the following command at at securityShell

import_csr_reply

Provide the inputs prompted for. For example :

securityShell@test> – alias * #myNewCertAlias
securityShell@test> – fileName * #signedCert.crt

7. The ca replyt shall be imported to the server keysotre.

8. You can use “import_cert” command (without the quotes) to import additional CA and intermediate certificates to trusted keystore of the server. Files to be imported have to be placed in <server-install>/server/bin directory. You can use keytool command from jdk, to import such files as well.

The Signed certificate is now imported to server and ready for use on https access.

Prerequisites:

1. Pramati Server 6.0 Installation
2. Active MQ installation
3. Active MQ adapter rar distribution (Bundled with Active MQ distribution in activeMQ\lib\optional directory)

Versions used here:

1. Pramati Server 6.0 SP3 with JDK 1.6
2. Apache Active MQ 5.2.0

Required resources can be located at:

1. http://server.pramati.com/download
2. http://activemq.apache.org/download.html

Deployment Process:
Deployment process is straight forward with deploytool. (For cases where GUI/Deploytool is unavailable, we shall quote a sample descriptor that can be bundled and deployed).
1. Start any node of the server on a console prompt or Connect to any running node through remote shell (The Pramati Server Remote Shell).
2. Execute command “deploytool” without quotes to open the deploytool GUI.
3. In the deploytool GUI, click on the last entry of activemq-rar-5.2.0.rar.
4. Edit Parameters on the right pane general tab as required to point to the active MQ server. If the active MQ server is running on the same machine with default values, no changes are necessary in this section.
5. If active MQ server is running on a different machine, the ServerUrl (Under Configuration Properties Section) should be changed to point to the corresponding ip:port. User name password if changed form default on Active MQ server, should be changed here as well. These properties shall be used by the Resource Adapter to connect to the Active MQ Server from the Pramati Server JVM.
6. The Work Manager Configuration can be left with default values. This Work manager API is supposed to be used internally by the application server to manage threads for the inbound connections to Active MQ.
7. On the Configuration Tab, Click on “Change” button in “Connection Resource Properties” section. On the window that appears, click on ok.
8. Now, Configure a Connection Factory in the “Connection Configuration” section. Provide a jndi name under which the connection factory shall be bound on server. For example “jca/ActiveMQConnection”. Set a pool size that will be maintained by server for connections from this connection factory. For Example : 20. Leave Author option to “container”. Provide the username and password in the corresponding text boxes that will be used to connect to Active MQ server (default values are “defaultUser” and “defaultPassword”). Now click on add to add this connection factory configuration to the (now empty) list on the middle pane.
9. Similarly many other connection factories can be created as per requirement and added to the list in the middle pane.
10. Now click on save button of Deploytool GUI to save the (auto-generated) Deployment descriptor file (pramati-j2ee-server.xml) to the rar archive. This file content can be viewed by clicking on View—>pramati-j2ee-server.xml link.

Now we are ready to deploy the Resource Adapter on to server.

Click on Deploy button to complete the deployment of the archive.

Post deployment, all the JNDI names can be seen bound in the Server JNDI names list. Applications can look up the same and use to connect to Active MQ Server.

Here is a sample pramati-j2ee-server.xml file that can be bundled with the rar and direct deploy command can be used to deploy the archive. No Deploytool or GUI shall be necessary.

1. Edit runserver.bat/runserver.sh file located at <SERVER_INSTALL>\server\bin directory.
2. Add the following properties:

-Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n

Eg:

set TEMP1=%PATH%
set DEBUG_OPTS=-Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n
call E:\Servers\PServer50\SP3_test\server\bin\setup.bat
java -server %DEBUG_OPTS% -Xms128m -Xmx512m -Dinstall.root=%install_root% -verbose:gc -XX:+PrintGCDetails -XX:+PrintHeapAtGC -XX:+PrintGCTimeStamps -Xloggc:verbose_gc.log -Dinstall.root=%install_root% -Djava.security.policy=%install_root%\lib\pramati\pramati.java.policy -Djava.security.auth.policy=%install_root%\lib\pramati\pramati.jaas.policy -Djacorb.home=%install_root%\lib\tp\jacorb -Djava.endorsed.dirs=%install_root%\lib\std\endorsed com.pramati.Server %*
@ set PATH=%TEMP1%

3. Make sure that the address port (used in above configuration) should be free.
4. Start Pramati Server with the above mentioned parameters.
5. Once Pramati Server has started successfully,  start Eclipse.
6. Now, in Eclipse, navigate to Run | Debug option.
7. This will open a dubug window. In this window, right click on Remote Java Application and select New option
8. In the Create configuration  screen you’ll be prompted to enter the following values:

* Name : Name of the Debugger name, can be any name
* Project: Select the Java project that contains the source code you want to debug.
* Connection Type: Leave Connection Type  in default, i.e. Standard (Socket Attach) .
* Host: enter localhost. If you want to debug a remote server, enter it’s hostname or IP address.
* Port: enter 8000 (as defined in your Pramati Server’s startup script).

9. Click Apply
10. In the same screen click Debug (Make sure Pramati Server instance is already running in debug mode with suggested prameters). Eclipse should automatically take you to the Debug  perspective and you should see a stack trace in the Debug  view.
11. If you are not automatically taken to the Debug  perspective, select Window | Open Perspective | Other and then click  Debug option.
12. Now, add the break points and make a request for the application using browser.
13. The application shall be executed till to reach break point. Once break point has reached, Eclipse Debug window should automatically pop-up with the stack pointer on your first breakpoint. This confirms that the whole debug set up is working fine.

1. StackTrace tool developed by adaptj
2. SendSignal program

1. StackTrace is a tool developed by adaptj for inspecting the state of a running JVM without starting it in debug mode and without using any additional startup settings. Visit the following link to download the same:

http://www.adaptj.com/root/main/download

* Now, click on “Launch” button and save the “launch.jnlp” file in the local system.
* Once the launch.jnlp file has been downloaded successfully, double click on the lanuch.jnlp file to execute.  Please note that this jnlp file requires Internet connection during the execution.
* Upon the startup, it opens a new window with the title of “Stack Trace-Untitled”.
* In the opened window, provide “Process ID” (Pramati Server’s java process id located in task manager) in the textbox.
* Now, select “Process” tab and then choose “Thread dump” option.
* Upon the selection, it will generates the thread dumps in that tool itself.

2. SendSignal is a tool which sends ctrl-break signal from command line to JVM to generate thread dumps. Visit the following link to download the same:

http://www.latenighthacking.com/projects/2003/sendSignal/SendSignal.exe

* Once you have downloaded SendSignal.exe program from the above mentioned link, open a command prompt and navigate to the directory where you have downloaded this program.
* Increase the screen buffer(right click on the left top corner of the command window–>Properties–>Layout–>Increase the screen buffer height to 9999) size to capture complete thread dumps.
* Now, Execute the following command:

SendSignal <$PID>

Where PID is the java process id related to Pramati Server. We will get this from task manager.

* This command will generate the thread dumps on the command prompt.