Archive for March, 2015


GWT In Practice……

March 30, 2015

GWT In Practice







Recently , just borrowed a book from National Library entitled GWT In Practice written by Robert T. Cooper and Charlie E. Collins . GWT stands for Google Web Toolkit.  GWT is a Java to JavaScript  cross-compiler . That is , it takes Java code and compiles it into JavaScript to be run in a browser.Other aspects that set GWT apart include a harness for debugging Java bytecode directly as it executes in a simulated browser environment, a set of core UI and layout widgets with which to build applications, a Remote Procedure Call (RPC) system for handling communications with a host web server, internationalization support, and testing mechanisms. Another of the reasons GWT is significant and is different from some other RIA offerings is that it provides tooling and testing support. GWT includes a powerful debugging shell that allows you to test and debug your code as it interacts with the native browser on your platform.

The testing support GWT provides is based on JUnit and on a few extensions the toolkit provides. Your GWT code can be tested as Java, from the shell. After you compile your code into JavaScript, the same test can be used again in that form by using further scaffolding provided by GWT. This allows you to test on various browser versions and, if desired, even on different platform and browser combinations.

The GWT Java compiler takes Java code and compiles it into JavaScript—that’s all. It has some advanced rules for doing this, however. By defining GWT compile tasks into modules, the compiler can perform more analysis on the code as it’s processed, and branch into multiple compilation artifacts for different output targets. This means that when compiling a class, you can specify differing implementations based on known parameters. The obvious switch point is the user agent or client browser you’re targeting. This feature drives the core of GWT’s cross-browser compatibility.

Built on top of GWT’s intelligent compilation system is a cross-browser UI layer. The real magic here comes from implementing the UI elements in Java and then using a browser-specific implementation of the core DOM to build out the native browser elements as they’re needed by the higher-level Java layer. Whereas some Ajax libraries have a lot of focus on UI widgets, GWT is intended to provide a core of UI functionality that users and the community can build upon.
The GWT UI layer provides a wide variety of layout-related panels, data representation constructs such as Tree and Grid, a set of user input elements, and more. The 1.4 release of GWT began to expand the UI toolkit to include some new advanced elements, like a rich text editor and a suggest box. This release also started to include some great new optimized UI elements that draw from the power of the plugin-capable compiler, such as the ImageBundle.

The GWT shell allows you to test your application in a browser while executing the native Java bytecode. This gives you the ability to use all your favorite Java tools to inspect your application, including profilers, step-through debugging, and JTI-based monitors. This hosted mode browser, with an embedded Apache Tomcat server, is also what makes it possible to test your compiled JavaScript with JUnit.

First, GWT projects are defined in terms of modules, composed of resources, configuration, and source. The module configuration defines compile-time information about a project and specifies resources needed at runtime. Beyond configuration, modules also make possible a rich inheritance mechanism. Because of this capability, projects can be complete web applications, they can be of a pure library nature, or they can fall anywhere in between. One thing a module defines is the starting point for a project’s code, known as an entry point. Entry point classes are coded in Java and are referenced by a module definition and compiled to JavaScript. Modules themselves, and the entry points they define, are invoked through a <script> reference on an HTML page, known as a host page. Host pages invoke GWT projects and also support a few special <meta> tags that can be used to tweak things. At a high level, these are the three main components of a GWT project: a module configuration file, an entry point class, and an HTML host page.

Lastly , GWT is great in making project websites that uses Javascript. GWT borrows from the approaches that have come before it and takes things in a new direction, expanding the web development frontiers. All the while, GWT maintains the advantages of traditional compiled-language development by starting out from Java; and it adopts the successful component-oriented development approach, applying these concepts to the web tier in a responsive Ajax fashion.

In addition to starting with Java, GWT also embraces the parts of the web that have  worked well and allows developers and users to remain on familiar ground. This is an overlooked yet significant aspect of GWT. GWT doesn’t try to hide the web from you, just to achieve the moniker “rich web application.” Instead, GWT happily integrates with and uses HTML, JavaScript, and CSS.

p/s:- Some of the article is an excerpt taken from the book GWT In Practice written by Robert T. Cooper and Charlie E. Collins , published by Manning. Hope you guys enjoy reading it….








ScreenOS Cookbook…..

March 11, 2015

screenOS cookbook






ScreenOS is one of the operating system that has been used in Juniper Network switch and routers operating system. If you buy a switch or a Juniper’s router , you would like to check ScreenOS installed in it. ScreenOS is used to administer the traffic flow of network design  that uses OSPF , BGP , VPN , NAT , DHCP and so on…Recently , I just borrowed a ScreenOS Cookbook from the National Library (PNM) . It’s quite a good book to read if you’re planning to be a Network Administrator that uses Juniper’s switches and routers product line. Administering ScreenOS is quite easy and challenging , just like you administer the CISCO IOS Software in CISCO’s product line that consist of switch and router. We can use ScreenOS to administer firewall configuration , wireless , route mode and static routing , transparent mode and so on….

DHCP Server Maintenance.

You can use ScreenOS’s get commands to view a feature’s functionality. In the get interface wireless2 dhcp server command , the DHCP server is enabled and on , and is not using the next server option which allows configuration information to be shared among multiple DHCP servers. Also , the DHCP client will update information to the server component.

The get interface <interface name> dhcp server ip allocate command shows the allocated IPs per interface , as well as the Media Access Control (MAC) address and time remaining in the lease. As each interface can have its own DHCP settings , different ranges may be configured on the device. To reset the DHCP leases , use the clear dhcp server <interface name> ip command. You can use this command to clear all leases or just a particular IP address:


FIREWALL-A->clear dhcp erver wireless ip all

FIREWALL-A->get db str


Use get commands:

FIREWALL-A->get interface wireless2 dhcp server

FIREWALL-A->get interface wireless1 dhcp server option.

When the clear dhcp server <interface name> ip all command is issued , the flash:dhcpserv1.txt file is modified. This file is used to store DHCP lease information so that leases can survice a system reboot. When the file is modified, each interface that is not cleared has the lease information for that interface rewritten so as to preserve the information.

The get interface <interface name> dhcp server option command shows all options configured on the DHCP server for that interface , including custom options. When custom options are configured , each option appears in the command output with the name Custom , and the code in parentheses immediately following.

Configure DHCP Relay

FIREWALL-A->set interface ethernet2 dhcp relay service

FIREWALL-A->set interface ethernet2 dhcp relay server-name

FIREWALL-A->set address untrust DHCP_SVR_10.3.1.1

FIREWALL-A->set policy from untrust to trust DHCP_SVR_10.3.1.1 any dhcp-relay permit log

Juniper Network’s firewall system products , which include the NS5000 Series and the ISG Series , do not have DHCP server functionality built-in. As these devices are typically used to protect large-scale environtments , they are frequently sandwiched in between pairs of routers. Furthermore , DHCP servers are often already available and installed elsewhere  in the network. Occasionally , however , hosts requiring DHCP services are directly connected to the firewall.

To accommodate DHCP services for hosts that connect to the firewall as their gateway , you can set up DHCP relay. To configure DHCP relay , simply enable the DHCP relay service on the interface , and configure the server address to forward the DHCP messages.

If you want to send these messages across a tunnel , use the set interface <interface name> dhcp relay vpn command. Additionally , a policy which permits dhcp-relay from the server to the client side-in this case , from untrust to trust-is required.

You can verify that DHCP relay is enabled on the interface by using the get interface command:

FIREWALL-A->get int eth2

For more concise output , use the get interface <interface name> dhcp relay command:

FIREWALL-A->get int eth2 dhcp relay


p/s:- ScreenOS uses CLI like in CISCO IOS Software…We can manage the network connection and network design using ScreenOS. We can also uses multicast traffic through a transparent mode device and create a virtual systems.(Later in the last chapter).. Some of this article are excerpt taken from ScreenOS Cookbook by Stefan Brunner , Vik Davar , David Delcourt , Ken Draper , Joe Kelly & Sunil Wadhwa from O’reilly.