jdbc

Related posts

Related posts

Related posts

Related posts

BEA released the latest version (v9.0) of their flagship application server, WebLogic in early August. I have been playing with the latest release of WLS to see what's new, what's cool and what are the features that will make me push to upgrade ASAP.

In addition to J2SE 1.5 or Java SE 5.0 support, WLS 9.0 is also fully compliant with the J2EE 1.4 Specification and is fully buzzword compliant. This release includes support for EJB 2.1, Web Services 1.1, JMS 1.1, JMX 1.2, JDBC 3.0, WS-Security, SAML 1.1, Profile 1.0, WS-Policy, WS-Reliable Messaging and WS-Addressing among others. The specification notably missing is EJB 3.0 – WLS 9.0 does not support EJB 3.0 and will support it as a service-pack, when EJB 3.0 JSR finally gets approved. This was kind of disappointing as WebLogic has always been on leading/bleeding edge in terms of specifications. I know I would have used the built-in support for the 3.0 spec, knowing full well that things may change and break with service-packs. The reality is that we won't be pushing apps in production under 9.0 till SP1 is out and we've truly gone through and understood all the changes from 8.1 and their impact to our applications and processes. (More information of all the API alphabet soup is available here here).

One of the newest and biggest additions to WebLogic is the new functionality called 'Production Deployment' or 'side-by-side deployment'. This new feature allows you to redeploy a new, updated version of a production application without affecting existing clients of the application that have valid sessions, and without interrupting the availability of the application to new client requests. So all the old users continue to use the old version of the application and any new users get directed to the new application. As old sessions timeout and/or users log out, the old application is retired. This also works in a clustered environment where you may have many WebLogic instances. The one thing I haven't tested yet is whether in-memory (session) replication still works as before. The scenario I hope to test soon is where Server A and Server B participate in a cluster. User 1 comes in and logs into Server A – in-memory replication will replicate User 1's session over to Server B. While User 1 is still active, I deploy a new version of the application to the cluster. Once the application is deployed, I kill Server A and then have User 1 attempt to use the application. Will the old version of the application still be there on Server B even though it didn't have any users using it?

WLS 9.0 also includes a completely new administration console built on top of the WebLogic Portal framework as a set of JSP's with Struts and Beehive. This allows you to extend the console and add your own custom admin screens. I think this is a pretty useful concept as developers can add custom JMX hooks in their applications and then surface that data via the custom admin console interface. I've always built custom admin-consoles for applications to turn on/off things, resources inside the applications or failover, etc. Being able to add that functionality inside the console gives you the additional authentication and authorization capabilities to your custom admin screen. WLS supports JMX 1.2 and JMX Remote API 1.0 (JSR-160) in this release, which deprecates BEA's proprietary API for remote JMX access, MbeanHome.

One of the nicest new features is the ability to create 1 log file for 1 day. This was always a missing feature that annoyed me to no end as you could rotate logs based by time but it was always elapsed time and so you couldn't create 1 log file for 1 day that automatically rotates to a new log file at midnight. That is now enabled and all I can say is that it's about time.

Another great enhancement is the use of DataSources instead of connection pools by default. Instead of configuring a JDBC connection pool and then configuring a data source to point to the connection pool and binding to the JNDI tree, you configure a data source that encompasses a connection pool. Before JDBC 2.0 and the concept of DataSource, people created a connection-pool and then used the pool driver (JDBC) to get a connection. But now everything is in the context of a DataSource and so you have to create a DataSource to create the underlying connection pool and that will force people to rewrite their legacy code that gets a connection from the pool directly. It's a good thing, as it will make their code more portable.

There are quite a lot of simple enhancements that I find useful. For example, hitting CTRL-C to interrupt a running server that you were running inside a DOS window or UNIX shell used to just kill the server. Now the start script catches the interrupt and calls the WLS shutdown hook. Another minor but useful thing is that the auto-generated start scripts have support for JPDA (Java Platform Debugger Architecture). The command line includes all the parameters needed to fire up the debug listener on port 8453 but it's configurable at each startup script level.

I know I've only scratched the surface with WebLogic 9.0 in the weeks of playing. I'll continue to blog about anything that's interesting or cool or broken.

Links of Interest:

WebLogic, WLS, WebLogic 9, WLS 9.0, BEA, J2EE

Related posts

iBATIS SQL Maps is an open-source JDBC framework that provides a very simple and flexible means of moving data between your Java objects and a relational database. The SQL Maps framework helps reduce the amount of Java/JDBC code that is needed to access a relational database. The framework allows you to map JavaBeans to SQL statements using a very simple XML descriptor that allows you to create complex queries, and inner/outer joins. The beauty of it all is that this is achieved without any special database tables, bytecode manipulation, or code generation.

iBATIS is not meant to replace Object-Relational Mapping (ORM) tools such as Hibernate, OJB, Entity beans or TopLink to name a few. Rather it is a low-level framework that allows you to directly hand-code your SQL statements and map them to Java object. Once you map your persistence layer to your object model, you are all set. You don't need to lookup DataSource, get connections, create prepared statements, parse ResultSet or even cache the results – iBATIS does it all for you. Under the covers, iBATIS creates a PreparedStatement, sets the parameters (if any), executes the statements and builds a Map or JavaBean object from the ResultSet. If the SQL statement was an insert or an update, the numbers of rows affected by the SQL are returned. Here's a little sample to illustrate the features of iBATIS: We'll start with a simple database that ships with the JpetStore application from iBATIS.

First you configure SQL Maps by creating a XML configuration file, which provides configuration details for DataSources, SQL Maps and other options like thread management. Here is a simple example of the SQL Map configuration file:

< ?xml version="1.0" encoding="UTF-8" ?> < !DOCTYPE sqlMapConfig PUBLIC "-//iBATIS.com//DTD SQL Map Config 2.0//EN" "http://www.ibatis.com/dtd/sql-map-config-2.dtd"?>

In my case, I am deploying this code in WebLogic and I have already created a connection pool and a datasource on the WebLogic side. I am just referring to the name of the datasource by using jdbc/jpetstoreDS. You can also create your own datasource via. the SQL Map configuration file:

The SQL Map configuration file includes a reference to another SQL Map file that contains your SQL statements for insert, update, delete as well as results and parameter mapping. Here is a simple example of the file Account.xml:

< ?xml version="1.0" encoding="UTF-8" ?> < !DOCTYPE sqlMap PUBLIC "-//iBATIS.com//DTD SQL Map 2.0//EN" "http://www.ibatis.com/dtd/sql-map-2.dtd">

The Account.xml SQL Map file is pretty self-explanatory — In the file, we are describing a select statement that takes an Integer as it's argument and returns an instance of com.j2eegeek.ibatis.domain.Account. Insert, updates, deletes work the same way along with stored procedures and dynamic queries. The programming API for SQL Maps is really straightforward and provides the developer with the ability to: configure an SQL Map, execute an SQL update (including insert and delete), execute a query for a single object, and execute a query for a list of objects.

SqlMapClient sqlMapClient = null; try { String sqlMapConfigFile = "sql-map-config.xml"; Reader sqlMapConfigReader = Resources.getResourceAsReader(sqlMapConfigFile); sqlMapClient = SqlMapClientBuilder.buildSqlMapClient(sqlMapConfigReader); } catch (IOException e) { log.error(e); } try { Account myAccount = (Account) sqlMapClient.queryForObject("getAccount", new Integer(1234)); log.debug("myAccount.getFirstName() = " + myAccount.getFirstName()); } catch (SQLException e) { e.printStackTrace(); log.error(e.toString()); } }

A pretty simple example but it should illustrate the simplicity of iBATIS SQL Maps and show you the potential of this framework. SQL Maps takes away all of the work required to create Statements, validate and parse inputs, create and parse ResultSets and all of the nitty-gritty details of working with SQL by hand. Instead, you are working at the object level and not really worrying about how your data is stored or retrieved. I've found that this also enables a good separation of work where your 'data-guy' can create up the appropriate SQL statements for you and you just plug them in, assuming you have a 'data-guy'. I've found that SQL Maps really helps me in my development process (In most cases, I am working with existing databases) as I spend time looking at the data-model as part of my overall design process and will typically mock-up the SQL statements I am going to use to manipulate the data at hand. Now I can just take my SQL statements and plug them into the SQL Map XML files and half my app is already built.

iBATIS SQL Maps is really powerful and you can take this one step further by using Spring's DAO framework in conjunction with iBATIS. Using Spring's DAO framework and the iBATIS template classes provided by Spring, you will write even less code that you would have normally written using iBATIS by itself.

Related posts

Expert One-on-One J2EE Development without EJB by Rod Johnson, Juergen Hoeller
Paperback: 576 pages
Publisher: Wrox (June 21, 2004)
ISBN: 0764558315

I've read this book several times since the day it shipped and I have to say that this is an excellent book for anyone working as a developer or architect working in the Enterprise Java arena. I absolutely love this book given my bias – I guess I should start by stating my bias. EJB bashing is a favorite past time of a lot of people. I happen to love EJB's, with the exception of entity beans and think EJB's are a great way to create software solutions are remotable, loosely coupled and powerful. I will agree that EJB's are way too complicated with all the stupid artifacts that you need to create to create and deploy an EJB. Having worked with EJB's since 1999, I guess I am so used to all of nuances of EJB's, I can write up deployment descriptors in my sleep. Having said that, I approached this book with a little apprehension as I hate these EJB-sucks book that don't really offer any intelligent discussion about the shortcomings of EJB nor do they offer a viable alternative. Another assumption I brought to the book was that this was just a Spring book with a little EJB bashing thrown in for good measure.

To my pleasant surprise, Rod Johnson and Juergen Hoeller have written an awesome book. This book does not take cheap shots – Instead there is a intelligent, thought provoking discussion about the pros and cons of EJB. In fact, the first 120 pages (Chapter 1-5) are just a great breakdown of application architecture with a through treatment of EJB. I loved this section and re-read it several times and I found myself agreeing with pretty much everything in this section. I would equate this to a great meaningful discussion you would have with someone who really understood application architecture and development and you could debate the pros and cons of the many alternative approaches that exist today.

Chapter 6 starts the discussion of Lightweight Containers and the idea of Inversion of Control (IoC). This is not a chapter on Spring; rather it is an overview of Inversion of Control and strategies like Dependency Injection in the context of Spring and PicoContainer.

The next chapter offers a quick introduction to the Spring Framework. As everyone already knows, the Spring Framework is a very popular open source application framework created by Rod Johnson. The co-author Juergen Hoeller is another lead developer of Spring. The chapter is Spring is fairly light and people hoping for a in-depth Spring tutorial will be disappointed. Instead this chapter offers a rather high-level overview that will get you some basic understanding of the Spring Framework. I guess it's hard to cover Spring in 43 pages.

After the cursory introduction to Spring, the book moves into Aspect-Orientated programming (AOP) concepts. This section starts with a very introduction to AOP before jumping into AOP implementation strategies. After a brief discussion of AspectJ, AspectWerkz, and JBoss AOP, the authors move into SpringAOP. After AOP, the books moves into Transaction Management where current J2EE approaches are discussed and then contrasted with the Spring approach.

Persistence is the next item tackled in the book and this section includes a really nice discussion of why you need a persistence strategy, when to choose O/R mapping vs. straight JDBC. After a walkthrough of the Java persistence technologies, the book moves into practical items and discusses Persistence in detail. Starting with JDBC, the authors contrast that approach with iBATIS SQL Maps, JDO, and Hibernate. The section on Data Access Object (DAO) pattern discusses the J2EE pattern and discusses some of the common design issues faced by developers. After the discussion, the book moves into discussing how data access works with the Spring framework and discusses Spring's DAO framework and how it works transparently with persistence technologies including iBATIS, Hibernate, JDO and straight JDBC. As an aside, if you haven't looked at Spring or just it's DAO framework, you should explore it as it simplifies the development process and minimizes the amount of code you write. I just rewrote some of my POC applications using Spring's DAO framework that used iBATIS and Hibernate under the covers. By using the template classes provided by Spring, I wrote about 30-40% of the code I would have normally written using iBATIS or Hibernate by themselves. The Spring Framework includes a reworked version of the original JPetStore application that uses Spring's DAO framework along with iBATIS SQL Maps.

After persistence, the book moves to Remoting and the idea of exposing business logic or services to remote client. One of the major benefits of EJB is the ability to remote anything exposed at the bean layer. This chapter starts off by discussing how to access an EJB from a Spring application using the JndiObjectFactoryBean. The setup is so simple and IoC makes lookup, creation of home, etc so easy with the declarative configuration. After EJB, the chapter moves to Web Services and JAX-RPC. Again the authors walk through the steps needed to consume JAX-RPC via. JNDI and demonstrate the elegance and simplicity with which Spring integrates into and consumes existing J2EE services. This chapter also includes discussion of Hessian and Burlap and the concept of lightweight remoting.

The next chapter in the book discusses the other EJB services that the container provides and talks about how to replace them. This section breaks down the do's and don'ts in terms of threading and pooling that is typically provided by an EJB container. There is a brief mention of security in this chapter.

The next section of the book discusses web tier design and dives into the current state of Web Model2 MVC frameworks. The section starts off with a look at Struts before jumping into WebWork. After the intros, the authors describe the Web MVC framework built into Spring. One of the things that I absolutely love about this book is the use of the dark gray boxes to summarize a topic, offer tips and advice or offer a best practice.

The next chapter is one of my favorite chapters in this book and it deals with the idea of unit testing and testability. Anyone that has written a J2EE application will attest to the fact that J2EE apps are really hard to test. There are a lot of testing frameworks in the market now but they require either too much setup or are really cumbersome to use and end up diluting the value they were supposed to offer. This section discusses some of the anti-patterns that are the de-facto standards in J2EE. I love the techniques offered in this section to improve testability. After an overview of testing, the book moves into a discussion of Mock Objects and the how, why and when of using Mock Objects in your development/testing lifecycle. The book then moves into Test-driven development (TDD) and offers a case study of how TDD has helped with the development of the Spring framework itself.

The last section before the sample application is on performance and scalability. This is another great chapter that should be mandatory reading for every developer. In this chapter, the authors discuss the challenges faced in building distributed multi-tier applications. There is a section that breaks down the architectural tiers and some of the common issues faced by every application developer. Very nicely written chapter and I glad the authors included a section on Profiling.

After performance, the book jumps into the sample JPetStore application that ships with the Spring Framework. The authors start off by discussing some of the shortcomings on the JPetStore application and then employ Spring to solve some of those issues. The JPetStore application is a great tutorial application for anyone learning Spring.

The book closes out with the conclusion section where the authors wrap-up and summarize some of their points outlined throughout the book.

Having read this book several times, I have to say that this has to be one of my favorite books of 2004. I love the clear, concise writing style of the authors. This is a great book and a must for every developer's library. While this is not a Spring tutorial book, you will learn enough about Spring to want more, a lot more. I highly recommend this book and encourage you to run to your local bookstore or computer and get this book.

If you are looking for a Spring book from the source, you'll have to wait for Rod's new book entitled Professional Java Development with the Spring Framework co-authored with Juergen Hoeller, Alef Arendsen, Thomas Risberg, Dmitriy Kopylenko or wait for Keith Donald's Spring book.

Related posts