Just Blog

Friday, August 23, 2013

JVM -D option

JVM ეშვება სისტემ properties ებთან ერთად. ჩვენ კი შეგვიძლია ისინი დავაკონფიგურიროთ -D პარამეტრით. მაგალითად, აპლიკაციის გასაშვება თუ გვინდა პროქსის გავლით, შეგვიძლია მარტივად დავწეროთ:

 -Dhttp.proxyHost=XXX.XXX.XXX.X -Dhttp.proxyPort=TTTT -Dhttps.proxyHost=XXX.XXX.XXX.X -Dhttps.proxyPort=YYYY -Dhttp.proxySet=true

view raw gistfile1.txt hosted with ❤ by GitHub

ან მაგალითად JNLP ვუშვებთ ჯივიემის პარამეტერებით:

	<resources>
	<j2se version="1.6+" href="http://java.sun.com/products/autodl/j2se" max-heap-size="512m" />
	<jar href="visible-signer-package-2.0.jar" main="true" />
	<property name="-DdevelopmentMode" value="false"/>
	<extension name="BouncyCastle cryptography library" href="bcprov-jdk16.jnlp"/>
	</resources>

view raw gistfile1.txt hosted with ❤ by GitHub

ჩვენი კოდიდან კი თუ გვინდა მნიშვნელობის ამოღება:
System.getProperty("developmentMode");

Friday, July 12, 2013

EJB Timer Service API

Timer Service API.

Timer Service ის გამოსაყენებლად იმპლემენტაცია უნდა გავუკეთოთ javax.ejb.TimedObject ინტერფეისს, რომელშიც აღწერილია ქოლბექ მეთოდი ejbTimeout( ):

	public interface TimedObject {
	public void ejbTimeout(Timer timer) ;
	}

view raw gistfile1.java hosted with ❤ by GitHub

EJB ში შეგვიძლია @javax.ejb.Timeout ანოტაციაც დავადოთ მეთოდს, რომელიც voidს აბრუნებს, და ექნება javax.ejb.Timer პარამეტრი.
აქვე ორივეს ვნახავთ

	@Stateless
	public class Example1 implements javax.ejb.TimedObject {
	public void ejbTimeout(javax.ejb.Timer timer) {
	// ბიზნეს ლოგიკა
	}
	}

view raw gistfile1.java hosted with ❤ by GitHub

ალტერნატივა არი @javax.ejb.Timeout ანოტაცია:

	@Stateless
	public class Example2{

	@Timeout
	public void maintenance(javax.ejb.Timer timer) {
	// ბიზნეს ლოგიკა აქ
	}
	}

view raw gistfile1.java hosted with ❤ by GitHub

}

იმისათვის რომ დავარეგისტრიროთ ბინი დროის პერიოდში TimerService –ს ვიყენებთ. TimerService შეგვიძლია inject გავუკეთოთ @javax.annotation.Resource ით ან EJBContext იდან წამოვიღოთ.

ანუ ეს ორი ვარიანტი გვაქვს:
@Resourceprivate SessionContext ctx; ctx.getTimerService();
@Resource javax.ejb.TimerService timerService;

მაგალითად დარეგისტრირებისთვის შევქმნათ CalendarTimer, ან შეგვილია პირდაპირ IntervalTimer, ანაც SingleActionTimer იც აქვს. დეტალურად API ში შეგიძლიათ ნახოთ, რა რას აკეთებს, აქ რო არ დავწყო მე პოემების წერა. აგერ ლინკიც: http://docs.oracle.com/javaee/6/api/javax/ejb/TimerService.html - Just Google :-)

ტაიმერის წაშლაც ადვილადაა შესაძლებელი, პირდაპირ cancell() მეთოდი აქვს.

აგერ ერთი მაგალითიც CalendarTimer–ის.

	@Resource
	private TimerService timerService;
	private ScheduleExpression expression;
	private TimerConfig timerConfig;

	@Override
	public void setUpTimer() {

	LOG.info("cleans all timer settings");
	if (timerService.getTimers() != null) {
	for (Timer timer : timerService.getTimers()) {
	timer.cancel();
	}
	}

	String nextTime=TimerConfUtils.getTimerInterval();
	expression = new ScheduleExpression().dayOfWeek("").hour("").minute("*").second(nextTime);
	timerConfig = new TimerConfig();
	timerConfig.setPersistent(true);
	timerConfig.setInfo(TIMER_NAME);
	timerService.createCalendarTimer(expression, timerConfig);

	}

view raw gistfile1.java hosted with ❤ by GitHub

მოლკედ მთავარი მუღამი ისაა, რომ თუ სერვერი დარესტარტდება ან რამე მაგდაგვარი, ტაიმერრი თავის დროს მაინც გააგრძელებს მუშაობას. ანუ რომ შეხვიდეთ Jboss ის ფოლდერში, მაგალითად : /usr/jboss/standalone/data/timer-service-data ფოლდერში
მანდ ნახავთ თქვენს ობიექტებს ტაიმერისას.

რაც შეეხება EJB 3.1 აქ უკვე არის @Schedule ანოტაცია. ძალიან მარტიავად

	@Singleton
	public class TimerService {

	@EJB
	private CryptoDaoLocal cryptoDao;

	@Schedule(second="/1", minute="",hour="*", persistent=false)
	public void doWork(){
	LOG.log(CryptoDaoLocal.generateKeys());
	}
	}

view raw gistfile1.java hosted with ❤ by GitHub

აგერ XML ითაც შეგვიძლია გავაკეთოთ იგივე @Schedule რომ არ ვწეროთ:


	<?xml version="1.0" encoding="UTF-8"?>
	<ejb-jar xmlns="http://java.sun.com/xml/ns/javaee" version="3.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd">
	<enterprise-beans>
	<session>
	<ejb-name>ClealTemporaryFile</ejb-name>
	<ejb-class>ge.embedded.signer.schedule.ClealTemporaryFile</ejb-class>
	<session-type>Stateless</session-type>
	<timer>
	<schedule>
	<minute>*/30</minute>
	<hour>*</hour>
	<month>*</month>
	<year>*</year>
	</schedule>
	<timeout-method>
	<method-name>ServiceTask</method-name>
	</timeout-method>
	</timer>
	</session>
	</enterprise-beans>
	</ejb-jar>

view raw gistfile1.xml hosted with ❤ by GitHub

ეს XML კი META-INF ში ჩავაგდოდ – Deployს მერე jar ის META_INF ში ჩახტება;

Thursday, May 23, 2013

Inversion of Control

შეიელბა ასე გავმარტოთ. Inversion of Control (IoC) და Dependency Injection (DI) პატერნები არიან ყველანი იმისათვის რომ დეფენდენსები არ გქონდეთ თქვენს კოდზე და არხდებოდეს კოდის განმეორებები. კოდის ოპტიმიზაცი ყოველთვის პრიორიტირებულია ჩვენთვის. ოპტიმიზაციის მთარავი მიზანიც ის არის რომ კოდი ლამაზად და გასაგებად ეწეროს, და ყველაზე მთავარი რაცაა არ ხდებოდის კოდის ხშირი გამეორებები, როდესაც მცირე რამეა შესაცვლელი.

ერთერთი მაგალითი ასეთი შეიძლება მოვიყვანოთ.

გვაქვს List რაღაც A ტიპის ობიექტებით სავსე და მინდა მისი გადაყვანა Map ში. შემდეგ ვაკეთებ ისევ სიას, ოღონდ B ტიპის ობიექტებით სავსეს და მინდა მისი გადაყვანა კვლავ Map ში. ამ შემთხვევაში შეგვიძლია მხოლოდ ერთი მეთოდი გვქონდეს გადაყვანის, არ ვაკეთოთ ტიპებით overload ები. თუ ასეთი 10 ტიპის ობიექტი მექნება, 10 overload არ გავაკეთებ.

მაგალითად, გვაქვს კლასი წიგნებისა.

	/**
	* For My Book Library
	* @author v.koroghlishvili
	*
	*/
	private static class Book {
	private final Long id;
	private final String name;

	public Book(Long id, String name) {
	this.id = id;
	this.name = name;
	}

	public Long getId() {
	return id;
	}

	public String getName() {
	return name;
	}
	}

view raw gistfile1.java hosted with ❤ by GitHub

შევავსოთ იგი:

	List<Book> list = new ArrayList<Book>();
	list.add(new Book(1L, "Just Spring"));
	list.add(new Book(2L, "EJB 3.1"));
	list.add(new Book(3L, "Node.JS"));

view raw gistfile1.java hosted with ❤ by GitHub

ახლა დაგვჭირდება ერთი ინტერფეისი, რომელშიც მეთოდის პროტოტიპს ჩავწერთ – მეფითა keyს ამოღებისა. მთავარი პრობლემა ჩვენ ის გვაქვს რომ არ ვიცით ობიექტის key რა იყოს (ზოგ შემთხვევაში რა არის, ზოგში რა). ამიტომ თითოეული ობიექტისათვის გავაკეთოთ კლასი, რომელიც იმპლემენტაციას გაუკეთებს KeyFinder–ს.

მაგალითად ინტერფეისი:

	public static interface KeyFinder<K, E> {
	K getKey(E e);
	}

view raw gistfile1.java hosted with ❤ by GitHub

და ჩვენი წიგნებისთვის გვექნება იმპლემენტაცია შემდეგნაირი, თუ Id გვინდა იყოს მეფსი key.

	private static class BookKeyFinder implements KeyFinder<Long, Book> {
	@Override
	public Long getKey(Book e) {
	return e.getId();
	}
	}

view raw gistfile1.java hosted with ❤ by GitHub

და გვექნება მხოლოდ ერთი მეთოდი, ზოგადი. რომელსაც გადაეცემა სია ნებსმიერი ტიპისა. და ინტერფეისი რომ გავაკეთეთ KeyFinder, აქაც განზოგადებული ტიპებით. მოხდება Mapის შექმნა. შემდეგ გადავუვლით ყველა ელემენტს სიაში, და
სათითაოდ ამოვიღებთ გასაღებს,

	public static <K, E> Map<K, E> listToMap(List<E> list, KeyFinder<K, E> finder) {
	Map<K, E> mp = new HashMap<K, E>();
	for (E e : list) {
	K key = finder.getKey(e);
	mp.put(key, e);
	}
	return mp;
	}

view raw gistfile1.java hosted with ❤ by GitHub

კოდს თუ დააკვირდებით , KeyFinder finder გვაქვს, სადაც KeyFinder ინტერფეისი არის. resolver აქვს რეფერენსი რომელიმე კლასის ობიექტთან , რომელსიც აკეთებს ინტერფეისი იმპლემენტაციას ––> მას აქვს Overriden მეთოდი გასაღების ამოღებისა ––> მისი დახმარებით , სწორედ ამ ტიპის კლასის ობიექტიდან როგორ ამოვიღოთ გასაღები ვიცით.

თუ დავამატებთ მაგალითად მანქანების კლას. დაგვჭირდება უბრალოდ CarKeyFinder -ის დაწერა რომელიც იმპლემენტაციას გაუკეთებს KeyFinder-ს. ან მეორე ვარიანტი ისაა რომ პირადპირ მანქანის კლასმა გაუკეთოს იმპლემენტაცია KeyFinder–ს და ცალკე არ გავიტანოთ - ნუ, გემოვნების ამბებია.

MVN Manifest Entries

თუ აღმოჩნდა რომ manifest ფაილის კონფოგურაციისათვის Maven–ის სტანდარტული პარამეტრები არ გყოფნით, იმისათვის რომ manifest თგვენს გემოზე ააწყოთ (თქვენი საკუთარი ველები დაუმატოთ), ამისთვის მავენს აქვს <manifestEntries> ტეგი. გამოყენება მარტივია:

<manifestEntries>
      <YOURTAG> value </YOURTAG>
</manifestEntries>

იხილეთ მაგალითაი:

	<build>
	<finalName>${artifactId}-${version}</finalName>
	<plugins>
	<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-jar-plugin</artifactId>
	<configuration>
	<archive>
	<manifest>
	<addClasspath>false</addClasspath>
	<classpathPrefix>dependency/</classpathPrefix>
	</manifest>
	<manifestEntries>
	<Trusted-Library>true</Trusted-Library>
	<URL>${project.url}</URL>
	</manifestEntries>
	</archive>
	</configuration>
	</plugin>
	<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-jarsigner-plugin</artifactId>
	</plugin>
	</plugins>
	</build>

view raw gistfile1.xml hosted with ❤ by GitHub

შედეგი კი გვენქება დაახლოებით ასეთი.

	Manifest-Version: 1.0
	Trusted-Library: true
	URL: vakhokor.blogspot.com
	Build-Jdk: 1.7.0_21
	Built-By: v.koroghlishvili
	Created-By: Apache Maven
	Archiver-Version: Plexus Archiver

view raw gistfile1.txt hosted with ❤ by GitHub

Monday, May 20, 2013

Strategy Pattern

Stragegy patern. ასევე ლიტერატურაში შეიძლება შეგხვდეს მისი სახელწოდეა როგორც Policy pattern. მისი საშვალებით ალგორითმის ქცევის არჩევა ძალზედ მარტივად ხდება. იმას, თუ რომელი ალგორითმი იქნება გამოყენებული, კლიენტი განსაზღვრავს.

დამავწყდა მეთქვა, რომ, ეს დიზაინ პატერნი Creational pattern ოჯხს განეკუთნება.

ამ დიზაინ პატერნის სტრუქტურა ასეთია:

როგორც სურათზე ხედავთ, გვაქვს სტრატეგიის ინტერფეისი, რომელთა მრავალი იმპლემენტაცია შეილება გვქონდეს– მაგალითად გვინდა Payment ის შესრულება. იგი შეიძლება შესრულდეს Visa ელექტრონით, შეიძლება MasterCard -ით.

ალგორითმი უსმენს კლიენტს და იმ იმპლემენტაციას უშვებს რომელიც მოთხოვნას შეესაბამება. მოსმენას და შესაბამის სტრატეგის ალგორითმის გამოძახებას Context ემსახურება.

დავიწყოთ მაგალითის წერა, და თან განვმარტოთ. თავდაპირველად, გადახდისთვის გავაკეთოთ enum, რომლებითაც იქნება შესაძლებელი გადახდა.

	/**
	* @author v.koroghlishvili
	* Enum for Payment methods
	*/
	public enum PaymentType {
	VISA_ELECTRON, MASTERCARD
	}

view raw gistfile1.java hosted with ❤ by GitHub

შემდეგ ამ ენამიდან რომელიმეს Context–ს გადავცემთ. თუ სხვა ჯერზე ფეიმენთის გაკეთება გადახდის სხვა ტიპით მომინდება, უბრალოდ კონტექტს ვეტყვი ამ ყოველივეს.

	/**
	*
	* @author v.koroghlishvili
	*
	*/
	public class PaymentContext {

	private PaymentRule paymentRule;

	public PaymentContext(PaymentType setting) {
	this.paymentRule = createRule(setting);
	}

	/**
	* This method chooses payment method,
	* using payment type
	* @param setting
	* @return
	*/
	private PaymentRule createRule(PaymentType setting) {
	switch (setting) {
	case MASTERCARD:
	return new VisaElectronRule();
	case VISA_ELECTRON:
	return new MaserCardRule();
	default:
	return null;
	}
	}

	public void cheeckOut(String number) {
	paymentRule.makePayment(number);
	}

	public PaymentRule getValidationRule() {
	return paymentRule;
	}
	}

view raw gistfile1.java hosted with ❤ by GitHub

PaymentContext, რომელიც განსაზღვრავს რომელი implement გაუშვას. აქ მარტივადაა ყველაფერი, switch ით ვნსაზღვრავ საჭიროს. როდესაც კონტესტის ობიექტს შევქმნი, კონსტრუქტორშივე ვახდენ შესაბამისი მეთოდის მინიჭებას.

PaymentRule ინტეფეისი ,რომლის შვილებიც იქნებიან კონკრეტული იმპლემენტაციები. ჩვენს შემთვევაში ერთი მასტერქარდთან მომუშავე, მეორე ვიზა ელექტრონთან. სწორედ კონტექსტში PaymentRule შვილის რომელიმე ობიექტს ვქმნი (switch ებში), და ვანიჭებ paymentRuleს, რომელიც არის PaymentRule ტიპისა.

ახლა დავწეროთ კონკრეტული სტრატეგიის იმპლემენტაციები.

ეს VisaElectron იმპლემენტაცია. ეს კი უკვე MasterCard–ის:

საბოლოოდ კი ყველაფერი ძალიან მარტივი გვაქ.

Tuesday, February 19, 2013

Dash panel

ახალი გრაფიკული გარემო და პრობლემები.
Gnu/linux -ში, კერძოდ ახალ დისტრო UBUNTU ში, სადაც დიდიხანია ახალი გრაფიკული გარემო გვაქვს, იქმნება პრობლემები Dash panel–ზე იკონკების დაგდებისა. მაგალითად თუ პროგრამას დააინსტალირებთ სინაპტიკიდან პრობლემა არ შეგექმნებათ, მაგრამ როდესაც ხელით აინსტალირებთ... შექმენი *.desktop ფაილი /usr/share/applications/ ში. gksudo gedit /usr/share/applications/სახელი.desktop ბ) შიგნით კი რაიმე ამის მზგავსი უნდ აგააკეთოთ:



[Desktop Entry]
Type=Application
Terminal=false
Icon=/path/to/icon/icon.svg
Name=give-name-here
Exec=/path/to/file/executable Name=unmount-mount

ჩემ შემთხვევაში არის ეს:




    [Desktop Entry]
    Type=Application
    Terminal=false
    Icon=/home/vakhoq/EclipseEE/e2.png
    Name=Eclipse EE
    Exec=/home/vakhoq/EclipseEE/eclipse Name=Eclipse EE

მერე Dash Home ში შედით და იქიდან გადმოგაგდეთ თქვენი პროგრამა. სულ ესაა :–)

Cross-domain communication problems

Cross-domain communication 


პრობლემა რიმლისათვისაც ბევრი framework არის დაწერილი, როგორებიცაა მგალითად easyxdm, YUI. მაგრამ საქმე გაცილებით გამარტივდა როდესაც HTML 5 თან გვაქვს უკვე საქმე. 


მაგალითად ავიღოთ 2 დომეინი A.net და B.net. გვინდა მათ შორის გვქონდეს კომუნიკაცია.

XmlHttpRequest ობიექტს ადევს   security  ბრაუზერებისაგან, რომელიც კრძალავს  მიწვდეს მონაცემებს სხვა სერვერზე. ეს კი  Ajax developer ებისთვის სერიოზული ლიმიტია.

წარმოვიდგინოთ გვინდა ასეთი სტრუქტორა. ჩვენ ფეიჯ  A.net ზე გვაქვს iframe რომელშიც არის B.net ის გვერდი. ახლა კი გვინდა კომუნიკაციები მათ შორის. მაგალითად , უმარტივესი, თუ დავაკლიკეთ iframe–ს შიგნით რაიმე ღილაკს, გვინდა A.net ის ფეიჯზე დაფიქსირდეეს და მათ შორის Request -Response კომუნიკაციები გავმართოთ.

ასეთი სტრუქტურები მრავლად არის პრაქტიკაში. მაგალითად Chrome Extension–ს რომ ვწერდი Gmail–ისთვის, მეილის გვერდზე როდესაც ვაწვებოდი Signe Document კნოპკას,  უნდა გამოსულიყო Iframe ჩემი სერვერის. აქ უნდა მქონოდა Listener ები გვერდებზე და Request-responze კომუნიკაციები ჩემ სერვლეტსა და extension -ს შორის.

HTML5-ს შემოთავაზებული გზა ასეთია , ვიძახებთ window.postMessage()-ს რომელსა ორი პარამეტრი გადაეცემა. 1 სტრუქტურა რაც გვინდა გადავცეთ და 2–ე არის მიმღები (ან * ყველასთვის);



stuct=new Object();
stuct.owner="admin";
stuct.status="cancell";
parent.postMessage(struct, "https://mail.google.com"



და მიმღები უსმენს მას:



window.addEventListener("message", function( event ) {
if ( event.data.status === "cancell" ) {
console.log(event.origin)
}
}, false );




მაგალითად iframe ში რაღაცას რო დავაწვები, სერვერზე რო წამოვიდეს პასუხი:

 <!DOCTYPE HTML>
<html>
<head>
<script>
var send= function(){  
   // Post message
   // from Iframe Page to domain A
    parent.postMessage("FROM IFRAME ","http://a.net");
}
</script>
</head>
<body>
INSODE
 <button onclick="send()">Inside The iframe</button>
 
 <script>
  // Listen from Domain A
  window.addEventListener('message', function(event) {
   console.log(event.data+' : '+event.origin) ;
   }, false);
 
</script>
</body>
</html>
 
 
<!DOCTYPE HTML>
    <html>
    <head>	
    <script>
    function sendCommand() {
	//  post massage to domain B
	var  receiver = 
         document.getElementById('frameId').contentWindow;
	receiver.postMessage("MSG", 'http://b.net');
    } 
 
  function load (){ 
	// Leasten messages from Domain B
	window.addEventListener('message', function(event) {
	console.log(event.data+' : '+event.origin) ;					
	return;
	}, false);
   } 
	</script>
  </head>
  <body onload="load()">
  <iframe id="frameId" src="http://b.net/2.html"  onload="sendCommand();">  No Frame!</iframe> 
  <button onclick="sendCommand()">OutSide The Frame</button>
  </body>
</html>

რაც შეეხება Request-Response–ბს. ჰედერში მოგიწევთ Access-Control-Allow-Origin ის ჩამატება.

მაგალითად სერვლეტებში


protected void doPost(HttpServletRequest request, HttpServletResponse response) {
     response.addHeader("Access-Control-Allow-Origin","UR");
...
}

 Ajax–ში თუ გვინდა ჰედერში ასე ჩავამატებთ.

var xhr = new XMLHttpRequest();
xhr.open("GET", url, true);
xhr.responseType = "arraybuffer";
xhr.setRequestHeader('Access-Control-Allow-Origin', 'URL');

XDomainRequest object  არის, რომელიც IE სთვის. CORS–ს გვთავაზობს Firefox. რომელიც ყველა ბრაუზერში კარგადაა.


function createCORSRequest(method, url){
    var xhr = new XMLHttpRequest();
    if ("withCredentials" in xhr){
        xhr.open(method, url, true);
    } else if (typeof XDomainRequest != "undefined"){
        xhr = new XDomainRequest();
        xhr.open(method, url);
    } else {
        xhr = null;
    }
    return xhr;
}



თორემ გამოვარდება ბრაუზერისგან შეცდომა:
XMLHttpRequest cannot load http://b.net/.../. Origin https://a.net is not allowed by Access-Control-Allow-Origin.