ÛÛÛÛ                                                                     ÛÛÛÛÛ     
                                                   °°ÛÛÛ                                                                    °°ÛÛÛ      
 ÛÛÛÛÛ ÛÛÛ ÛÛÛÛÛ ÛÛÛÛÛ ÛÛÛ ÛÛÛÛÛ ÛÛÛÛÛ ÛÛÛ ÛÛÛÛÛ    °ÛÛÛ   ÛÛÛÛÛÛ  ÛÛÛÛÛÛÛÛ  ÛÛÛÛÛÛÛÛÛÛÛÛÛ    ÛÛÛÛÛÛ   ÛÛÛÛÛÛÛÛ       ÛÛÛÛÛ  °ÛÛÛ ÛÛÛÛÛ
°°ÛÛÛ °ÛÛÛ°°ÛÛÛ °°ÛÛÛ °ÛÛÛ°°ÛÛÛ °°ÛÛÛ °ÛÛÛ°°ÛÛÛ     °ÛÛÛ  ÛÛÛ°°ÛÛÛ°°ÛÛÛ°°ÛÛÛ°°ÛÛÛ°°ÛÛÛ°°ÛÛÛ  °°°°°ÛÛÛ °°ÛÛÛ°°ÛÛÛ     ÛÛÛ°°   °ÛÛÛ°°ÛÛÛ 
 °ÛÛÛ °ÛÛÛ °ÛÛÛ  °ÛÛÛ °ÛÛÛ °ÛÛÛ  °ÛÛÛ °ÛÛÛ °ÛÛÛ     °ÛÛÛ °ÛÛÛ °ÛÛÛ °ÛÛÛ °°°  °ÛÛÛ °ÛÛÛ °ÛÛÛ   ÛÛÛÛÛÛÛ  °ÛÛÛ °ÛÛÛ    °°ÛÛÛÛÛ  °ÛÛÛÛÛÛ°  
 °°ÛÛÛÛÛÛÛÛÛÛÛ   °°ÛÛÛÛÛÛÛÛÛÛÛ   °°ÛÛÛÛÛÛÛÛÛÛÛ      °ÛÛÛ °ÛÛÛ °ÛÛÛ °ÛÛÛ      °ÛÛÛ °ÛÛÛ °ÛÛÛ  ÛÛÛ°°ÛÛÛ  °ÛÛÛ °ÛÛÛ     °°°°ÛÛÛ °ÛÛÛ°°ÛÛÛ 
  °°ÛÛÛÛ°ÛÛÛÛ     °°ÛÛÛÛ°ÛÛÛÛ     °°ÛÛÛÛ°ÛÛÛÛ    ÛÛ ÛÛÛÛÛ°°ÛÛÛÛÛÛ  ÛÛÛÛÛ     ÛÛÛÛÛ°ÛÛÛ ÛÛÛÛÛ°°ÛÛÛÛÛÛÛÛ ÛÛÛÛ ÛÛÛÛÛ ÛÛ ÛÛÛÛÛÛ  ÛÛÛÛ ÛÛÛÛÛ
   °°°° °°°°       °°°° °°°°       °°°° °°°°    °° °°°°°  °°°°°°  °°°°°     °°°°° °°° °°°°°  °°°°°°°° °°°° °°°°° °° °°°°°°  °°°° °°°°° 
java ubuntu foto muzic rodokmen

obsah

Aktualne CV, 232.63 KB
EJB3(entity + session) + Visual JSF (05/2009), 2.54 MB
ako nasadit bussines components + fussion web na tomcat (04/2009), 2.2 MB
prednaska spring framework - zaklady (03/2008)
vyborny j2ee tutorial pdf (09/2007), 9.66 MB

pripravujem

ako nasadit ADF na free servery

spring framework - zaklady

Spring Hello World
example project : SpringHelloWorld, 2.58 MB

To understand principles of Spring Framework, we need to change the way we think from J2SE.
If we write hello world application, we want to print on the screen greeting. for this reason we had defined interface GreetingServiceInterface,which make sure, that all classes which will implement this interface will sayGreeting() - return String with greeting. 
So, let's create our 'functional' class GreetingServiceImplemetace which hold property greeting, has setter for this property and this property can be set by overloaded constructor. for each class used in Spring Framework and gained through bean container we need to define default constructor.
Finally, we create XML file, which is the heart of Spring Framework, file, which define and wire beans together, springBeanConfig. After closer look, we see, that we define beans, using identificator for container (id), defining connected class (class). We can inject values by node property or by node constructor. for closer look for bean wiring, see next (or next next) chapter.
So, we have everything pulled together, now is the time to create application, which will retrieve bean from container and use it – Aplikace . To get instance of our bean we use XmlBeanFactory, then we get our bean (default as singleton) by calling it's identificator.
Seems to be, after we run Aplikace, we should see on standard output something as 'hello world'.
Well done, you have just wrote your first spring application.

Understanding Inversion Of Control (IOC)
example project : InversionOfControl, 1.32 MB

In any more complex application than Hello World cooperates two or more classes.
let's define class Auto and class Volant. Normally, if Auto wants Volant, it needs to initialize one. If this actions is defaultly set for example in contructor of class, then we get into big trouble. For example, if we want to unit test class Auto – without volant. This approach complicate situation with persistence. For this reason comes on the white horse inversion of control - IOC is opposite, we inject Volant dependency to Auto, see  springBeanConfig.  It might sound strange, but it's not Auto, who is responsible – in the worst case might thrown an exception – i don't have volant - that has Volant, but mechanic, which put Volant on right place called familiary IOC container.
As result, our vehicle will be proud to say, that has volant.
Now, let's make short stop to see, how IOC container could be provided. In previous examples we used BeanFactory to gain access to our beans. There is another bean manager, ApplicationContext. ApplicationContext is almost the same as BeanFactory – both loads bean definitions, wire beans together and dispense bean upon request – but applixationContext offers more - 
provide resolving od text messages (internalization (I18N))
provide generic way to load file resources, such as images
provide bean registration to events, that beans are registered as listeners
there are 3 implementations of applicationContext 
ClassPathApplicationContext (XML is located on class path)
FileSystemXmlApplicationContext (XML is located on file system)
XmlWebApplicatiobContext (XML within a web application)

Bean Wiring
example project : Wiring, 1.33 MB

Piecing together beans within the Spring container is known as wiring. When wiring beans, we tell to container what beans are needed and how the container should use dependency injection to tie them together. As was said before, as default all beans are singletons, we can change this by setting bean property singleton = „false“. As well we said before, when we use ApplicationContext, we can use events – for initialization and destruction we can set bean properties init-method =“a“ and destroy-method = „b“, where a and b are names of methods called in bean when event occure. We saw in previous examples, that we can inject value of property via setter or contructor, as well refer to another bean. What will happened when our property is a List of values ? Spring support those collections as bean properties : list, set, map, props. For example, for list into property node we put node  and all his child's,  present values in list.

DAO Support
example project : HibernatePersistence, 16.04 MB

Dao pattern presents way, how do we handle entities agains database. Each entity class will have own Dao class supporting it's db operations. For specific tasks we will can use HQL language. Good thing about HQL is that, we work more or less with concrete properties of a class, code is very easy to maintain. For closer look, how to handle classes properties, have a look at AutoEntityDao ant it's method getAllWithVolant().
In out example we create entity class Auto and Volant, tied together by xml application context. however, we are interested only in cars, Volant will be persisted together with car (if any) with 1:1 cascade dependency, which means, if we remove from DB auto, of course, if it has volant, will be removed as well.
To test functionality, we have prepared set of unit tests.
Of course, it will be not comfortable to write for each class full-size-dao. for this reason we find in example AbstractDao, from which we inherite all daos. However, we would like to use differently named property for id's (extending interface Serializable, which means Long or String), we need to declare with concrete Dao definition not class, which will manage, but as well type of id. if we decide, that our application will use only long id's call in each class with the same name, this feature can be removed. 
and, that's all folks
obsah

pocet navstevnikov od 06/2008 :