|
|
||||||
Masoud Kalali's BlogJ2SE ArchivesHibernate dynamic mapping and Dom4J enabled sessionsPosted by kalali on February 11, 2007 at 03:53 PM | Permalink | Comments (3) Hibernate from version 3.0? provide a very useful feature for people who develop application frameworks. Indeed this feature allows you to work directly with XML documents and elements which represent entities.
Imagine that you have an application or an SDK which help users to manipulate data from different RDBMSs. Hibernate provide rich configuration facilities which help you configure Hibernate dynamically in term of adding mapping data or other configuration artifacts that usually stores in hibernate.cfg.xml or equal properties files. As we are planning to use Hibernate dynamic mapping and Dom4J entity mode i am going to blog about it during my evaluation. OK, Hibernate provide 3 kinds of entity mode
<property name="default_entity_mode">dom4j</property>To hibernate.cfg.xml . but for our sample we will create a session with dom4j entity mode. you can find a complete sample for this blog entry here . Make sure that you read readme file in project folder before you go toward executing it. For this sample I used Netbeans 6.0 M6 (which really rules) and Hibernate 3.2.1 . I wont tell steps to create project, XML file or ... but just actions and core required for hibernate side. you can see project structure in the following image. As you can see it is a basic ant based project. Let me give you content of each file and explain about it as much as i could. First of all lets see what we have in hibernate.cfg.xml <?xml version='1.0' encoding='utf-8'?> <!DOCTYPE hibernate-configurationThe configuration file is a simple and traditional hibernate configuration file with pooling enabled and dialect sets to MySQL ones. We have one mapping file which is named student.hbm.xml so we include it into the configuration file. If you do not have MySQL around then use Derby which is included into NetBeans ;-) . Log4J configuration is another traditional one, as you see We used a file appender which send formatted log entry into a file named messages_dynamic.log in project root directory. next file which we are going to take a look is Student.hbm.xml it is our mapping file, where we define the student as a dynamic entity. <?xml version="1.0"?>As you can see there is just one change in mapping file, we have entity-name attribute instead of class attribute. You should know that can have both class and entity-name attribute so an entity could be dynamic or mapped to a concrete class. Next step is looking at our HibernateUtil which is known to the community for Hibernate booting and hibernate instance management. here is its code:
Noting extra here. lets look at last part in which we try to use dom4j session to manipulate our data. package dynamic; In the begging we create a session with dom4j entity mode. so it will return Dom4J elements as our entities. in next two blocks i have create two students one is Alice Cooper and the other is John connor (what does this name remind you? ;-) . we simply ask our session to save them as we do for usual POJO mode. Session know what to do with dom4j elements as it is configured as a DOM4J session. In Second block we query our table and retrieve all entities into a list, but this list is not a list of Student POJOs instead it is a list of DOM4J elements. so we need to do some XML processing when we want to extract our entity properties. you can learn more about DOM4J at Here . Next step we retrieve a single row, edit and save it into our database, Its all simple DOM4J operation which you should use over some elements to manipulate your data. Build file that i used contains two target that we will use during this project. first one is hbm2ddl which will create our database structure and the second one is run target which will execute our main class. it is not required to include build file here you can download the sample and check it yourself. make sure you look at readme file before digging into execution of application. In next few days I will try to do a simple benchmark for some simple CRUD operation to have a basic clue about DOM4J entity mode in our environment.
Step by Step toward a jms sample in NetBeans and yes GlassFish. part 2 : Remote ClientPosted by kalali on May 10, 2006 at 06:01 AM | Permalink | Comments (0)In previous part you saw that how easy is to make an MDB to consume messages and a jsp/Servlet Front End to send message to a queue. in this part i will show you how you can send message to a queue from a remote j2se client. you should know that in jms sending and reciving mesages has similar steps , some small changes require to consume message from a j2se client instead of sending messages. to make it more clear , the main purpose of an MDB is to consume messages as they arrive , The MDB onMessage(..) is called whenever a message become available in destination that MDB is binded to it. sure we can do what ever we want after message recieved. for example you can send the message that you recive from a queue to several topics , you can process it to do some database operation.... usually we use JMS for executing Asynchronous operations ,bringing more decoupling of a system components.... but lets come to our own steps to create a simple remote client that will sends some messages to tQueue that we made in first part of this series. then we will see that our messages are reciveing by TMDB. As you know we used a context object to locate the Queue and ConnectionFactory . the servlet code was like: ... Context ctx = new InitialContext(); ...By default a JNDI client assume that it is in a correctly configured environment , so when we do not pass a HatshTable to IinitialContext , the InitialContextFactory will return a context configured with that environment .In server environment we do not need to explicity pass parameters to InitialContext unless we need to initiate a context for another environment. But, what are this parameters and how we can use them to initiate a context for none default environemtn or in places that there is no default environemt pre-configured , situation like standalone remote clients? in a such situation we should configure the InitialContext using a HashTable that contain some parameters, There are several parameter that can be used to configure the initialContext but Two most important ones are :
I should tell that we can also make this parameter to be the jvm default parameter and allows the Initialcontext to return a context without need to pass any arguments. in this way we need to pass parameters to java command when we want to start it. for example you can use : java -Djava.naming.provider.url="iiop://127.0.0.1:3700" -Djava.naming.factory.initial="com.sun.appserv.naming.S1ASCtxFactory" to start our application. this way you allows the Initialcontext to return a context without need to configure it by a HashTable. For our Sample we will use a hashtable to configure the InitialContext , but you can try to pass parameters to java instead and observ the execution of your application. To create a j2se remote client we need to add some jar files to our project , NetBeans provide its own way to manage jar files that may be used in more than one project. it is Libraries.... Run NetBeans, From Tools menu select Library Manager , create a new library and name it jms . Now you can add as much jar files to this library as you need , then it will be reuseable for your other projects. add following jar files to this library , I use glassfish_home as installation directory of glassfish.
Create a j2se project using , File > new project > general > java application. name the application jmsClient and allow the IDE to create a Main class for you. You shoud add that library that you create to this project. to do this , expand the project node , right click on the libraries and select add library Now from the library list select jms . Up to now you have done 30% of creating an stand alone remote client to interact with your jms resources like connectionFactories and destinations. Now we need to code the main method of main class . expand the jmsClient node , expand the source packages and finally open the main class of your project. The overall look of your code shoul be like the following :
public class JmsClient {
Context ctx;
public JmsClient() {
Hashtable properties = new Hashtable(2);
properties.put(Context.PROVIDER_URL,"iiop://127.0.0.1:3700");
properties.put(Context.INITIAL_CONTEXT_FACTORY,"com.sun.appserv.naming.S1ASCtxFactory");
try {
ctx = new InitialContext(properties);
} catch (NamingException ex) {
ex.printStackTrace();
}
}
public Object lookup(String name){
try {
return ctx.lookup(name);
} catch (NamingException ex) {
ex.printStackTrace();
}
return null;
}
public static void main(String[] args) {
JmsClient client = new JmsClient();
try{
ConnectionFactory connectionFactory = (ConnectionFactory)client.lookup("jms/tConnectionFactory");
Queue queue = (Queue)client.lookup("jms/tQueue");
javax.jms.Connection connection = connectionFactory.createConnection();
javax.jms.Session session = connection.createSession(false,Session.AUTO_ACKNOWLEDGE);
MessageProducer messageProducer = session.createProducer(queue);
for(int i=0;i<5;i++) {
TextMessage message = session.createTextMessage("It is a message from main class "+ ": "+ i);
System.out.println( "It come from main class:"+ message.getText());
messageProducer.send(message);
}
} catch(Exception ex){
ex.printStackTrace();
}
}
}
Now lets see what the above code means , i will not go indepth because JMS APIs are discussed too much :-) . In constructor we configured a context object named ctx we encapsulate the lookpu task in a method named lookup(...) we usually use a service locator or cached service locator to locate our objects in JNDI because JNDI lokups are time consumer In main method:
Now lets run the program and see the result , to run the application you nedd to complete the first part of this series , then you should run the application server , and if you like to have a demonestration like what i will show you , you should deploy the application that we made in first part. i assume you have completed first part and you have the application server running , Now run the client that we made and what you will see in output window should be like : and if you take a look at application server log file (in runtime tab , expand the servers node and rigt click on the glassfish instance , now select view server log..) what you should see in the server log should be something like : messages that we send via standalone client will reach the queue that the MDB is listening on it , as soon as we send a message MDB will pick it up and start processing it. you can download the standalone client project from here | ||||||
|
|