Java Related Knowledge: 2012

Monday, December 10, 2012

noscript and comments JQuery

The <noscript> tag is used to provide an alternate content for users that have disabled scripts in their browser or have a browser that doesnâ��t support client-side scripting.

The <noscript> element can contain all the elements that you can find inside the <body> element of a normal HTML page.

The content inside the <noscript> element will only be displayed if scripts are not supported, or are disabled in the userâ��s browser.

Tips and Notes

Tip: It is also a good practice to use the comment tag to "hide" scripts from browsers without support for client-side scripts (so they don't show them as plain text):

<script>
<!--
function displayMsg()
{
alert("Hello World!")
}
//-->
</script>

CSS JQuery buttons

<style>

button {
  margin-top: 60px; }
button.punch {
  background: #4162a8;
  border-top: 1px solid #38538c;
  border-right: 1px solid #1f2d4d;
  border-bottom: 1px solid #151e33;
  border-left: 1px solid #1f2d4d;
  border-radius: 4px;
  -webkit-box-shadow: inset 0 1px 10px 1px #5c8bee, 0px 1px 0 #1d2c4d, 0 6px 0px #1f3053, 0 8px 4px 1px #111111;
  box-shadow: inset 0 1px 10px 1px #5c8bee, 0px 1px 0 #1d2c4d, 0 6px 0px #1f3053, 0 8px 4px 1px #111111;
  color: #fff;
  font: bold 20px/1 "helvetica neue", helvetica, arial, sans-serif;
  margin-bottom: 10px;
  padding: 10px 0 12px 0;
  text-align: center;
  text-shadow: 0px -1px 1px #1e2d4d;
  width: 150px;
  -webkit-background-clip: padding-box; }
  button.punch:hover {
    -webkit-box-shadow: inset 0 0px 20px 1px #87adff, 0px 1px 0 #1d2c4d, 0 6px 0px #1f3053, 0 8px 4px 1px #111111;
    box-shadow: inset 0 0px 20px 1px #87adff, 0px 1px 0 #1d2c4d, 0 6px 0px #1f3053, 0 8px 4px 1px #111111;
    cursor: pointer; }
  button.punch:active {
    -webkit-box-shadow: inset 0 1px 10px 1px #5c8bee, 0 1px 0 #1d2c4d, 0 2px 0 #1f3053, 0 4px 3px 0 #111111;
    box-shadow: inset 0 1px 10px 1px #5c8bee, 0 1px 0 #1d2c4d, 0 2px 0 #1f3053, 0 4px 3px 0 #111111;
    margin-top: 58px; }
 
 </style>
    <br>
    
    <button class="punch">Send</button>
<button class="punch">Preview</button>
    <button class="punch">Cancel</button>

Saturday, December 08, 2012

Tiles Advantages over JSP:include

Large websites often need a common Look and Feel (L&F). If the L&F is hard coded in all pages, changing it becomes a nightmare: you would have to modify nearly all pages. When you are using JSP include, you create the layout of the website within the page and then place the actual view component (JSP). Hence you need to repeat the same layout logic to every page causing repetition in the web page. This also discourages you to change the view of the website at a later time as you may have a lot of pages to modify.

“Tiles” is the solution for this problem. Tile is an area or region on web page. Tiles is the technology which is used to create view of a website. Using Tiles you can define the layout as a template, can create complicated layouts and use them through out the application for consistent layout. The purpose of layout is to assemble a group of tiles to specify the format of page. As it is a layout, you insert placeholders (using Tiles insert tag) instead of actual view components (JSPs). The values for the placeholders are defined by an XML. If you want to change the view of the application you can do so by changing the layout only and can save a lot of time.
With Tiles you can do things such as:
o Screen definitions that include inheritance
o Templating: you can create templates and can use them again and again o Layouts for common pages, menus, and portals
o Dynamic page building
o Reuse tiles

o I18N support for locale-specific loading

9. Tiles vs. JSP Include
9.1. Advantage of Tiles over JSP include

Code Repetition is reduced
Use of Tiles reduce the code repetition to a great extent. Code repetition is bad but repetition of layout logic could be worst. Tiles also handle this issue. As you have layout templates based on which all the pages are combined, you don't need to repeat the code for layout. Other view components are also reusable and can be used in the same application at other places reducing the code repetition.
Low coupling between pages
Coupling is the degree of interactivity between two entities. It is always suggested to minimize coupling between unrelated classes, packages, and so on. Same principle is applied to view components. Tiles reduce the coupling between unrelated view components.
High layout control
Tiles provide great layout control by providing layout templates.
I18N support for locale-specific loading
Dynamic Page building
Pages are built dynamically in tiles. You can control the page view by configuring it through xml.
Elimination of duplicate and redundant information
Tiles eliminate the duplicate and redundant information in the configuration file by providing Tiles inheritance.
Central location for view components
Tiles save definition of all the components at one place (in tilesDef.xml) and hence can be modified easily when required.

9.2. Disadvantages of Tiles

Increases the number of pages
Increases complexity
Tiles increase complexity by introducing another layout page. Understanding and implementing templating can also be difficult at initial stages.
Big API
Tiles have a bigger API set which may be difficult to understand for getting full benefit of tiles.
You have to specify a name to any component you create.

I am a big believer in the Tiles framework. It's main advantage, in my
viewpoint, is its ability to increase reuse across the presentation
tier of an application

.

With Tiles a developer can set up a few Tile definitions (templates)
that represent the different page layouts across a web app

. Each Tile
definition can have both concrete JSPs as well as empty Tiles. Then,
through Tile inheritence, each template can be extended n times to
create any number of pages. Say that a web app

has a common header and
footer across 10 pages. Tiles allows the developer

to create one JSP
for the header, one JSP for the footer, one Tile definition, and 10
JSPs for the body of each page. If the header JSP changes the change
ripples through all pages without any need to change the Tiles XML.

Sure, you could use jsp:include and get a similar result but you would
lose the flexibility of the XML configuration and the inheritence that
Tiles provides you. In the near term it will save development time
with each new page that you create that fits into one of the templates
you have defined. In the long run it will make the application much
easier to maintain.

To add to that point, Tiles helps you code views in a way that allows
you to minimize the number of objects placed in the session scope.
Many times you see a developer using a traditional MVC where a servlet
can only dispatch to only 1 jsp.

The jsp is normally called main.jsp but it calls numerouse includes.
Main.jsp accepts the request attributes, but included jsp, that may
also include other jsp for presentation purpose may not, but should
have access to the object added to the request. So many developers

would capture it in main.jsp and then add it to the session. This is
not scalable. So with tiles you dont have to do that the inheritence
allows you to access the request scope attributes at any level.

Monday, December 03, 2012

Jenkins

java -jar jenkins.war --ajp13Port=8010 --httpPort=8084

Jenkins as a service

Git Commands

git --bare init

git clone --bare -l non_bare_repo new_bare_repo

git remote add origin S:\Wasif\Depot\lanyon_documents.git

git branch -a

git remote update

git show-branch -a

git ls-remote origin

git rev-parse HEAD

git remote show origin

git difftool -y

git mergetool -y

git reset --hard ORIG_HEAD.

Sunday, December 02, 2012

10.6: Re-enable Java 1.4.2 and Java 1.5 apps in Snow Leopard

Many applications that relied on Java 1.4.2 and Java 1.5 stopped working in Snow Leopard, because Apple removed these Java versions from the system. Upgrading to the lastest versions of many applications usually will solve the problem. However, your favorite application may not have a Snow Leopard compatible upgrade. For these applications, re-installing Java 1.4.2 and/or Java 1.5 is necessary. Sometimes, even this is not enough. As an example, Apple also removed the Cocoa-Java bridge from Snow Leopard, which some Java applications such as PDFLab depended on. Reinstalling the Cocoa-Java bridge along with the proper version of Java is necessary to re-enable these applications on Snow Leopard. For example, getting PDFLab working again in Snow Leopard requires reinstalling Java 1.4.2 and the Cocoa-Java bridge. Read on for a how-to...

Installing Java 1.4.2 and/or Java 1.5 on snow Leopard:

The following is based on two blog posts: Using Java 1.5 and Java 1.4 on Snow Leopard and Installing Java 1.5 on Snow Leopard:

Download the official Java package from Apple: Java for Mac OS X 10.5 Update 4, dated June 15, 2009.
Use the excellent shareware utility Pacifist to open the downloaded JavaForMacOSX10.5Update4.pkg file.
First use Finder to go to System » Library » Frameworks » JavaVM.framework » Versions and delete the two aliases (symlinks) 1.5 and 1.5.0. Don’t skip this step, because otherwise the extraction will follow the symlinks and overwrite the contents of the 1.6.0 folder, oops!
In Pacifist, drill down into Contents » System » Library » Frameworks » JavaVM.framework » Versions.
In Pacifist, select 1.5 and 1.5.0, Control-click on the selection, and chose Install to Default Location from the pop-up menu.
In the instructions above, the same applies for version 1.4.2.

Installing the Cocoa-Java Bridge:

This is based on Getting back the Cocoa-Java bridge in Snow Leopard:

Copy from a working Leopard (10.5) installation the following folders:

the com directory in /System/Library/Java
the eight files ending with .dylib in /usr/lib/java (four of these are regular files, the other four are symlinks; if you prefer, you can copy just the files and recreate the symlinks by hand).

Thursday, November 29, 2012

Git repo commands

Making git repository bare...

git config --bool core.bare true

Tuesday, November 20, 2012

Checkstyle Vs. PMD Vs. FindBugs

There is often some misunderstanding when people talk about coding rules engines. Everyone tries to take position in favor of his preferred tool and does his best to explain what are the weaknesses of the other ones. For instance, a PMD supporter could say :

“Checkstyle is a stupid tool consuming time to search for tab characters when PMD is a smart one that can do the job alone as a good soldier, Findbugs is very good for resource consumption and Macker is … uh, what is Macker ? “

Time to breathe ! There is in fact no need to take such position since those tools are not competing but are complementary and should be used simultaneously as it is the case in Sonar. Each of them is mainly targeting a certain type of coding rules : conventions (Checkstyle), bad practices (PMD) and potential bugs (FindBugs).

Thursday, November 15, 2012

GPL based JavaScript

When a user accesses a website with GPL'd JavaScript code, technically the "source code" (in this case a JS file) is "distributed" to the end-user. Does that mean your entire website needs to be GPL'd? There's anentire debate about that, too.

GPL license

It's called the GNU GPL.

And you should clarify which version. There are minor differences in the GNU GPLv2 and GNU GPLv3 in regards to how it applies to uncompiled scripting languages.

That being said, both are distribution licenses only, not EULAs (albeit GPLv3 borders on that). You can use the code without obligations if you do not redistribute it in any way. No paying, no attribution, no publishing required on your part.

The GNU GPL, as it is actually called, does allow usage without accepting the license (clause 5 in GPLv2.1). This usage permission applies to said friend. However, he may not distribute the combined work.

Using it internally (applies to webserver case): yes.

Distributing this mixed code as software package: no.

Actually, there is a modified version(AGPL) that is specifically designed to force web apps to release the code. If the binaries are running on the server, you don't have any obligation under vanilla GPLv2.

What is a commercial website

Any site that Buys, Sells, or provides a service for a fee.

Mutable Vs. Immutable

Well, there are a couple aspects to this. Number one, mutable objects without reference-identity can cause bugs at odd times. For example, consider a Person bean with an value-based equals method:

Map map = ...
Person p = new Person();
map.put(p, "Hey, there!");

p.setName("Daniel");
map.get(p);       // => null

The Person instance gets "lost" in the map when used as a key because it's hashCode and equality were based upon mutable values. Those values changed outside the map and all of the hashing became obsolete. Theorists like to harp on this point, but in practice I haven't found it to be too much of an issue.

Another aspect is the logical "reasonability" of your code. This is a hard term to define, encompassing everything from readability to flow. Generically, you should be able to look at a piece of code and easily understand what it does. But more important than that, you should be able to convince yourself that it does what it does correctly. When objects can change independently across different code "domains", it sometimes becomes difficult to keep track of what is where and why ("spooky action at a distance"). This is a more difficult concept to exemplify, but it's something that is often faced in larger, more complex architectures.

Finally, mutable objects are killer in concurrent situations. Whenever you access a mutable object from separate threads, you have to deal with locking. This reduces throughput and makes your codedramatically more difficult to maintain. A sufficiently complicated system blows this problem so far out of proportion that it becomes nearly impossible to maintain (even for concurrency experts).

Immutable objects (and more particularly, immutable collections) avoid all of these problems. Once you get your mind around how they work, your code will develop into something which is easier to read, easier to maintain and less likely to fail in odd and unpredictable ways. Immutable objects are even easier to test, due not only to their easy mockability, but also the code patterns they tend to enforce. In short, they're good practice all around!

With that said, I'm hardly a zealot in this matter. Some problems just don't model nicely when everything is immutable. But I do think that you should try to push as much of your code in that direction as possible, assuming of course that you're using a language which makes this a tenable opinion (C/C++ makes this very difficult, as does Java). In short: the advantages depend somewhat on your problem, but I would tend to prefer immutability.

Tuesday, November 13, 2012

kill JBoss on Mac

kill -9 $(ps -e|grep jboss|awk '{ print $1 }')

Thursday, November 08, 2012

Types of DAO

Table DAO Code

Table DAO code is the most widely used Data Access Object. Each Table DAO represents a single table and contains methods to insert, update, and delete single rows using the following signatures (using an example Customer table):

public void insert(Customer customer) throws CustomerDaoException

public void update(CustomerPk pk, Customer customer) throws CustomerDaoException

public void delete(CustomerPk pk) throws CustomerDaoException

In addition to this, there are also numerous 'finder' methods generated. FireStorm/DAO creates default finders when you first import a schema but these are fully customizable. Some examples of finder methods:

public Customer findByPrimaryKey(CustomerPk pk) throws CustomerDaoException;

public Customer[] findWhereLastNameEquals(String lastName) throws CustomerDaoException;

public Customer[] findByCountry(int countryId) throws CustomerDaoException;

View DAO Code

The View DAO is generated for each view in the database. This DAO code offers the same finder methods as the Table DAO code but obviously does not provide the insert, update, and delete operations because views are read-only.

Custom DAO Code

Custom DAO code is used when you have a complex SQL query that goes beyond the simple CRUD (create, update, delete) operations on a single table. Examples would be SQL queries that perform a join between several tables, queries that performs aggregration using the GROUP BY operator, and bulk update or delete queries.

Example queries that the Custom DAO code feature in FireStorm/dAO can support:

SELECT a.*, b.* FROM a, b WHERE a.id = b.id AND b.install_date between ? and ?

DELETE customer WHERE status = ? AND create_date = ?

SELECT product, count(*) FROM product WHERE download_date > ? GROUP BY product

Example of declarative transaction implementation

Consider the following interface, and its attendant implementation. This example uses Foo and Bar classes as placeholders so that you can concentrate on the transaction usage without focusing on a particular domain model. For the purposes of this example, the fact that the DefaultFooService class throws UnsupportedOperationException instances in the body of each implemented method is good; it allows you to see transactions created and then rolled back in response to the UnsupportedOperationException instance.

// the service interface that we want to make transactional

package x.y.service;

public interface FooService {

  Foo getFoo(String fooName);

  Foo getFoo(String fooName, String barName);

  void insertFoo(Foo foo);

  void updateFoo(Foo foo);

}

// an implementation of the above interface

package x.y.service;

public class DefaultFooService implements FooService {

  public Foo getFoo(String fooName) {
    throw new UnsupportedOperationException();
  }

  public Foo getFoo(String fooName, String barName) {
    throw new UnsupportedOperationException();
  }

  public void insertFoo(Foo foo) {
    throw new UnsupportedOperationException();
  }

  public void updateFoo(Foo foo) {
    throw new UnsupportedOperationException();
  }

}

Assume that the first two methods of the FooService interface, getFoo(String) and getFoo(String, String), must execute in the context of a transaction with read-only semantics, and that the other methods,insertFoo(Foo) and updateFoo(Foo), must execute in the context of a transaction with read-write semantics. The following configuration is explained in detail in the next few paragraphs.

<!-- from the file 'context.xml' -->
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns:aop="http://www.springframework.org/schema/aop"
     xmlns:tx="http://www.springframework.org/schema/tx"
     xsi:schemaLocation="
     http://www.springframework.org/schema/beans 
     http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
     http://www.springframework.org/schema/tx
     http://www.springframework.org/schema/tx/spring-tx-3.0.xsd
     http://www.springframework.org/schema/aop 
     http://www.springframework.org/schema/aop/spring-aop-3.0.xsd">
  
  <!-- this is the service object that we want to make transactional -->
  <bean id="fooService" class="x.y.service.DefaultFooService"/>

  <!-- the transactional advice (what 'happens'; see the  bean below) -->
  <tx:advice id="txAdvice" transaction-manager="txManager">
  <!-- the transactional semantics... -->
  <tx:attributes>
    <!-- all methods starting with 'get' are read-only -->
    <tx:method name="get*" read-only="true"/>
    <!-- other methods use the default transaction settings (see below) -->
    <tx:method name="*"/>
  </tx:attributes>
  </tx:advice>
  
  <!-- ensure that the above transactional advice runs for any execution
    of an operation defined by the FooService interface -->
  <aop:config>
  <aop:pointcut id="fooServiceOperation" expression="execution(* x.y.service.FooService.*(..))"/>
  <aop:advisor advice-ref="txAdvice" pointcut-ref="fooServiceOperation"/>
  </aop:config>
  
  <!-- don't forget the DataSource -->
  <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
  <property name="driverClassName" value="oracle.jdbc.driver.OracleDriver"/>
  <property name="url" value="jdbc:oracle:thin:@rj-t42:1521:elvis"/>
  <property name="username" value="scott"/>
  <property name="password" value="tiger"/>
  </bean>

  <!-- similarly, don't forget the PlatformTransactionManager -->
  <bean id="txManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
  <property name="dataSource" ref="dataSource"/>
  </bean>
  
  <!-- other  definitions here -->

</beans>

Examine the preceding configuration. You want to make a service object, the fooService bean, transactional. The transaction semantics to apply are encapsulated in the definition. The definition reads as “... all methods on starting with 'get' are to execute in the context of a read-only transaction, and all other methods are to execute with the default transaction semantics”. The transaction-managerattribute of the tag is set to the name of the PlatformTransactionManager bean that is going to drive the transactions, in this case, the txManager bean.

Declarative transaction management

	Note
	Most Spring Framework users choose declarative transaction management. This option has the least impact on application code, and hence is most consistent with the ideals of a non-invasivelightweight container.

The Spring Framework's declarative transaction management is made possible with Spring aspect-oriented programming (AOP), although, as the transactional aspects code comes with the Spring Framework distribution and may be used in a boilerplate fashion, AOP concepts do not generally have to be understood to make effective use of this code.
The Spring Framework's declarative transaction management is similar to EJB CMT in that you can specify transaction behavior (or lack of it) down to individual method level. It is possible to make a setRollbackOnly() call within a transaction context if necessary. The differences between the two types of transaction management are:

Unlike EJB CMT, which is tied to JTA, the Spring Framework's declarative transaction management works in any environment. It can work with JTA transactions or local transactions using JDBC, JPA, Hibernate or JDO by simply adjusting the configuration files.
You can apply the Spring Framework declarative transaction management to any class, not merely special classes such as EJBs.
The Spring Framework offers declarative rollback rules, a feature with no EJB equivalent. Both programmatic and declarative support for rollback rules is provided.
The Spring Framework enables you to customize transactional behavior, by using AOP. For example, you can insert custom behavior in the case of transaction rollback. You can also add arbitrary advice, along with the transactional advice. With EJB CMT, you cannot influence the container's transaction management except with setRollbackOnly().
The Spring Framework does not support propagation of transaction contexts across remote calls, as do high-end application servers. If you need this feature, we recommend that you use EJB. However, consider carefully before using such a feature, because normally, one does not want transactions to span remote calls.

The concept of rollback rules is important: they enable you to specify which exceptions (and throwables) should cause automatic rollback. You specify this declaratively, in configuration, not in Java code. So, although you can still call setRollbackOnly()on theTransactionStatus object to roll back the current transaction back, most often you can specify a rule that MyApplicationException must always result in rollback. The significant advantage to this option is that business objects do not depend on the transaction infrastructure. For example, they typically do not need to import Spring transaction APIs or other Spring APIs.

Although EJB container default behavior automatically rolls back the transaction on a system exception (usually a runtime exception), EJB CMT does not roll back the transaction automatically on an application exception (that is, a checked exception other thanjava.rmi.RemoteException). While the Spring default behavior for declarative transaction management follows EJB convention (roll back is automatic only on unchecked exceptions), it is often useful to customize this behavior.

Reference:(http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/transaction.html#transaction-declarative)

Java Related Knowledge

Monday, December 10, 2012

noscript and comments JQuery

CSS JQuery buttons

Saturday, December 08, 2012

Tiles Advantages over JSP:include

Monday, December 03, 2012

Jenkins

Git Commands

Sunday, December 02, 2012

10.6: Re-enable Java 1.4.2 and Java 1.5 apps in Snow Leopard

Thursday, November 29, 2012

Git repo commands

Tuesday, November 20, 2012

Checkstyle Vs. PMD Vs. FindBugs

Thursday, November 15, 2012

GPL based JavaScript

GPL license

What is a commercial website

Mutable Vs. Immutable

Tuesday, November 13, 2012

kill JBoss on Mac

Thursday, November 08, 2012

Types of DAO

Table DAO Code

Custom DAO Code

Example of declarative transaction implementation

Example of declarative transaction implementation

Declarative transaction management

Declarative transaction management

C3P0 connection pool configuration

Blog Archive