Making JDev just that little faster on WLS

During the ODTUG conference this year Lucas Jellema and myself discovered a little WebLogic Server feature (thanks to a presentation by Chris Bucchere) known as "fast-swap" that may have significant benefits in making the code-deploy-run cycle much shorter with JDeveloper. As usual Lucas is the quickest to the blog punch, and has blogged it here.

Take time to check it out.

If anybody finds any limitations beyond those mentioned in Lucas's post, in particular those relating to JDev and ADF *please*let*us*know* as it will assist the entire JDev community.

Stress & load testing web applications (even ADF & Apex) using Apache JMeter

A couple of years ago I presented Take a load off! Load testing your Oracle Apex or JDeveloper web applications at OOW and AUSOUG. I can't recommend enough the importance of stress testing your web applications, it's saved my bacon a number of times. Frequently as developers, we develop under a single user (developer) model where concurrency issues are easily avoided. When our programs hit production, with just 1 more user, suddenly our programs grind to a halt or fall over in bizarre places. Result, pie on developers' faces, users' faith in new technologies destroyed, and general gnashing of teeth all round. Some simple stress and load tests can head off problems way before they hit production.

(For the remainder of this post I'll infer "stress testing" and "load testing" as the same thing, though strictly speaking one tests for your application falling over, and the other how fast it responds under load)

So how to go about stress testing a web application?

There are numerous tools available to stress test web applications, paid and free. This post will look at the setup and use of Apache's JMeter, my tool of choice, mainly because it is free! ... to undertake a very simple stress test. Apache JMeter is available here, version 2.3.3 at time of writing.

On starting JMeter (<jmeter-home>/bin/jmeter.bat on Windows) you'll see the following:


Creating a Thread Group

From here what we want to do is set up a Thread Group that simulates a number of users (concurrent sessions), done by right clicking the Test Plan node -> Thread Group option. This results in:


As you can see the Thread Group allows us to set a number of threads to simulate concurrent users/sessions, loop through tests and more.

Creating HTTP Requests

From here we can create a number of HTTP requests (Test Plan node right click -> Add -> Sampler -> HTTP Requests) to simulate each HTTP request operation (Get, Post etc), HTTP headers, payloads and more. However in a standard user session between server and browser there can be a huge array of these requests and configuring these HTTP requests within JMeter would be a major pain.

Configuring the HTTP Proxy Server

However there's an easier way. Apache JMeter can work as a proxy between your browser and server and record a user's HTTP session, namely the individual HTTP requests, that can be re-played in a JMeter Thread Group later.

To set this up instead right click the Workbench node, Add -> Non-Test Elements -> HTTP Proxy Server:


To configure the HTTP Proxy Server do the following:

* Port – set to a number that wont clash with an existing HTTP server on your PC (say 8085)
* Target Controller – set to "Test Plan > Thread Group". When the proxy server records the HTTP session between your browser and server, this setting implies the HTTP requests will be recorded against the Thread Group you created earlier, so we can reuse them later
* URL Patterns to include – a regular expression based string that tells the proxy server which URLs to record, and those to ignore. To capture everything set it to .* (dot star). Be warned that during recording however, if you use your browser for anything else but accessing the server you wish to stress test, JMeter will also capture that traffic. This includes periodic refreshes by web applications such as Gmail or Google Docs that you don't even initiate; I'm pretty sure when replaying your stress test, Google would prefer you not to stress test their infrastructure for them; stick to your own for now ;-)

The end HTTP Proxy Server setting will look something like this:


You'll note the HTTP Proxy Server has a Start button. We can't use this just yet.

Configuring your Browser

In order for the JMeter HTTP Proxy Server to capture the traffic between your server and browser, you need to make some changes to your browser's configuration. I'm assuming you're using Firefox 3 in the following example, but same approximate steps are needed for Internet Explorer.

Under Firefox open the Tools -> Options menu, then Advanced icon, Network tab, Settings button which will open the Connection Settings dialog.

In the Connection Settings dialog set the following:

* Select the Manual proxy configuration radio button
* HTTP Proxy – localhost
* Port – 8085 as per the JMeter HTTP Proxy Server option we set earlier
* No Proxy for – ensure that localhost and 127.0.0.1 aren't in the exclusion list


The above setup makes an assumption that the server you want to access is accessibly without a further external proxy required.

Recording your HTTP session

Once the browser's proxy is setup, to record a session between the browser and server do the following:

1) In Apache JMeter hit the Start button on the HTTP Proxy Server page
2) In your browser enter the URL of the first page in the application you want to stress test

Thereafter as you navigate your web application, enter data and so on, JMeter will faithfully record each HTTP request between the browser in server against your Thread Group. This may not be immediately obvious, but expand the Thread Group and you'll see each HTTP request made from the browser to server:


As can be seen, even visiting 1 web page can generate a huge amount of traffic. Ensure to stop recording the HTTP session by selecting the Stop button in the JMeter HTTP Proxy Server page.

Configuring the Thread Group for replay

Once you've recorded the session in the Thread Group there are a couple of extra things we need to achieve.

For web application's that use Cookies and session IDs (JDeveloper's ADF uses a JSessionID for tracking sessions) to track each unique user session, we cannot replay the exact HTTP request sequence with the server through JMeter, as the session ID is pegged to the recorded session, not the upcoming stress test sessions.

To solve this in JMeter right click the Thread Group -> Add -> Config Element -> HTTP Cookie Manager. This will be added as the last element to the Thread Group. I usually move it to the top of the tree:


Next we need to configure the Thread Group to show us the results of the stress test. There are a number of different ways to do this, from graphing the responses, to showing the raw HTTP responses. In this post we'll take the later option.

Right click the Thread Group -> Add -> Listener -> View Results in Tree, which will add a View Results in Tree node to the end of the Thread Group:


Finally save the Thread Group by selecting it in the node tree, then File -> Save.

Running the Thread Group

To commence your first stress test run, it's best to leave the number of spawned sessions to 1, just to see the overall test will work in it's most basic form. The default Thread Group number of threads is set to 1, so there is no need to make a change to do this.

To run the test, simply select the Run menu -> Start. On running the Thread Group, you'll see the top right of JMeter has a little box that tells if it's still running, and the number of tests to go vs total number of tests:


Once the tests are complete, this indicator will grey out.

We can now visit the View Results Tree:


This shows the HTTP requests that were sent out and on selecting an individual request, you see the raw HTTP request and the actual response. You'll note the small green triangles showing a successful HTTP 200 result. If different HTTP errors occur the triangles show different colours. Also remember that sometimes application errors don't perculate up to the HTTP layer in your web application, so you should check your application's logs too (in the case of a JEE application, this will be your container's internal logs).

Running a Stress Test

The obvious step from here is to change the Thread Group number of threads to a higher number.

From here take time out to explore the other features in JMeter. It includes a wide range of features that in particular make it useful for regression testing.

Caveats

Firstly remember when doing this you're not only stress testing your application, your stress testing a server, potentially stress testing databases, stress testing your networks and so on. Therefore you can have an affect on anybody sharing those resources. "Hard core" stress tests should be on separate infrastructure, after hours, aiming for as little impact on those around you!

Also keep in mind, besides seeing your application fall over at 2 users, 10 users, 100 users, which is an important test, try to be realistic about your stress tests. Stress testing you're brand-new-application to a 1 million concurrent users is probably not being realistic. How many concurrent user requests do you really expect and what response times do you need? Normally when I ask managers this question they'll answer with, "oh we have 1000 concurrent users, the application must support that many at any one time". However what they really mean is the application has 1000 users, potentially all logged into the application (ie. sessions) at the same time, but not necessarily hitting the server with HTTP requests at any onetime.

(Later note: for readers interested in specifically testing JDeveloper's ADF, see this more recent post).

WLS 10.3 WSDL external policy attachment error

We recently encountered an issue with deploying JAX-WS web services to Oracle WebLogic Server 10.3 where the web service WSDL included a <wsp:policyReference> external policy attachment.

The error:

javax.xml.ws.WebServiceException: weblogic.wsee.ws.init.WsDeploymentException: Unable to to retrieve policy from URI 'externalpolicy.xml'
 at weblogic.wsee.jaxws.framework.jaxrpc.TubelineDeploymentListener.createServer(TubelineDeploymentListener.java:85)
 at weblogic.wsee.jaxws.WLSTubelineAssemblerFactory$TubelineAssemblerImpl.createServer(WLSTubelineAssemblerFactory.java:74)
 at com.sun.xml.ws.server.WSEndpointImpl.(WSEndpointImpl.java:152)
 at com.sun.xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.java:217)
 at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:467)
 Truncated. see log file for complete stacktrace 

Note the name of the policy file in the error: externalpolicy.xml

Our WSDL included the following binding options referring to the external policy file:

Note the use of the <wsp:PolicyReference> tag with the URI attribute referring to the externalpolicy.xml file located in the same src directory as the WSDL.

The externalpolicy.xml included an MTOM policy, ultimately nothing special:

          xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
          xmlns:wsoma="http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization"
          xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512">
 
  
 
 

The deployment problem is caused because by default WLS isn't configured to search for external policy files on the CLASSPATH of the application.

The fix is however simple (and somewhat obscurely documented here)

Locate your WLS %domain_home%/bin/startWebLogic.cmd file and replace the following line:

set JAVA_OPTIONS=%SAVE_JAVA_OPTIONS%

..to..

set JAVA_OPTIONS=-Dweblogic.wsee.policy.LoadFromClassPathEnabled=true %SAVE_JAVA_OPTIONS%

ADF Faces RC: turning off the browser's autocomplete functionality

(Post edit - customers should note that for JDev/ADF 11.1.2.X controls such as af:inputText now include an autoComplete property that determines "whether previous values of text fields in the form should be remembered and offered for auto completion.")

Modern browsers include an autocomplete function, effectively a poplist that shows the user's most recent entries for a set field in a list, for the user to choose from.

There are times when this functionality isn't desirable, such as credit card numbers, password fields and similar.

As detailed in the following Mozilla Developer Center page, both IE and FF support an autocomplete="off" attribute on form and input controls to suppress the browser's autocomplete functionality. Unfortunately this feature is not part of the HTML standards, and in turn is not a property of the equivalent tags in ADF Faces RC for JDeveloper 11g build 5188 (ER with Oracle Support pending).

There is a JavaScript solution that readers may be interested to see, and I thought this a good post because it shows the mechanism for calling JavaScript through the ADF Faces RC tags, something that I seem to be doing more and more.

The following example shows how to turn the autocomplete off at the form level:

  
  
  
  ...so on...

Points to note:

* The use of the "load" clientListener at document level to call the disableAutoComplete. This is the equivalent of the HTML body tags onLoad attribute.

* The use of the clientComponent="true" attribute in the form tag. This forces ADF Faces RC to generate a HTML form component with the same id in the resulting HTML page to be rendered. This is essential as the disableAutoComplete method requires the form id in the DOM in order to find the form via it's call to getElementById and turn off the autocomplete function.

Q&A With Grant Ronald

(This is a reprint of an article published in the UKOUG's Select magazine early this year)

When talking about Oracle Forms and JDeveloper, one Oracle personality stands out among others - long time blogger Grant Ronald from Oracle Corporation UK. Grant has for a long time “pimped” Oracle Forms and its big brother JDeveloper at Oracle events and user groups events around the world. His popularity is shown by his blog receiving on average 2000 hits per day. Lately, to reassure Oracle customers that Oracle intends to keep on supporting Oracle Forms and show that Forms has a future inline with JDeveloper, Grant has been responsible for the Oracle’s Forms Modernization message.

Chris Muir from SAGE Computing Services Australia conducted the following Q&A session with Grant to get the low down and latest on Forms and JDeveloper, as well as a little about Grant himself.

CM: What role do you currently play at Oracle and what does your day job entail?

Grant Ronald: Well, my title says “Group Product Manager” and the products I cover are Oracle Forms and Oracle JDeveloper. As a Product Manager you are responsible for the success of the products in your area. That encompasses everything from working with developers on features, the marketing department on campaigns or delivering presentations at events like Oracle World. In the morning you can be rolling your sleeves up and getting into code with a developer, and in the afternoon you can be meeting with the CTO. It’s that varied.

CM: How did you get into this Oracle gig anyhow? What’s your background at Oracle and computing in general?

Grant Ronald: Back in the early ’80s, home computing was slowly starting to take off with computers like the Sinclair Spectrum, Vic20 and BBC home computers, and it seemed like a new an innovative field to get involved in when I left school. So I got my degree in Computing Science then joined a small IT outfit in the UK that eventually got consumed by EDS. It was a pretty typical development role for about seven years, mainly focused on military applications, and my last job was designing, developing and leading the team for the development of the user interface for a military email system.

This took me up to 1996 when I fancied a change, and Oracle was looking for people with development experience on Unix and Motif in their support organization. So I joined Oracle Support where I eventually headed up the group who supported the local EMEA (Europe, Middle East, Africa) teams in Forms, Reports and Discoverer. Given that I was working closely with the Oracle Product Management team in this role, I was eventually persuaded to make the jump into Oracle Development!

CM: Ok, now for some tough questions worthy of any Q&A: You’re currently known via your blog for discussions on Oracle development including Forms and SOA, and presentations in Oracle Developer Days around the world. Previously you were also known for you work on JDeveloper. Why the change? Has Oracle internally panicked about the impression (my emphasis) customers are getting that Oracle has killed Forms, and now the need for Forms advocates?

Grant Ronald: There has not really been a change. The thing is, we’ve never stopped talking about Forms. I’ve got the air miles and passport stamps to show that we were still presenting Forms at Oracle World, ODTUG (Oracle Development Tools User Group), UKOUG (UK Oracle User Group), DOAG (German Oracle User Group) and dozens of other events covering EMEA, APAC and the Americas.

The Forms OTN page is still a hive of activity: news, events, whitepapers and how-to’s. Maybe people thought we had stopped talking about Forms because we were also talking about other technologies as well. Ten years ago if you developed on an Oracle database then you pretty much used Forms, simple as that. But the world has changed and there are other things to talk about now. Which makes sense, if you think about it; there is more need and more demand to be talking about the “new” stuff, especially when it is evolving at such a rate.

CM: On discussing Forms and considering that some Oracle customers are confused on the future of Forms, can you outline Oracle’s commitment to Forms in terms of existing versions and Oracle Support?

Grant Ronald: I think the strongest statement we have is the fact that we published a statement of direction five years ago and that statement remains true today. We’ve always said that we are committed to Forms and that there have been no plans to desupport it. That line has never changed. Regarding support, we’ve recently just extended the support date for 10.1.2 (the latest release of Oracle Forms) and Forms 11g is in development, having already had positive reviews from our beta testers. So we are lengthening the support dates, we are working on the next release and we are also discussing enhancements and features for post 11g. I think that’s all good news.

CM: Could the problem with Oracle Forms just be an image problem? It’s never been known for sexy development (a’la grey screens of boredom), and especially now that the web world, web rich clients, AJAX etc have taken off.

Grant Ronald: The sweet spot for Oracle Forms has always been the ability to rapidly develop rich, transactional business applications. So you see Oracle Forms applications in your government offices, airlines and bank back-offices etc. The need for visual “bells and whistles” is less at the fore than, for example, an online shopping application where a user makes a snap decision, often based on visual aesthetics, as to whether they will use the site.

But there is nothing to stop you pushing the boundaries of the visual aspects of Oracle Forms. We have customers who are using some of the features of Oracle Forms, like PJCs and Java beans, to really push the boundaries of the Forms UI. Like this story. So there is nothing to stop you modernizing your Forms application, starting with an update of the user interface.

CM: So what plans do Oracle have in addressing Forms customers?

Grant Ronald: We are continuing to present at all the major events and user groups. In addition, we’ve launched a focus page. This includes recorded webcasts on Forms strategy, calling web services from Forms and Forms new features. There are also white papers and customer stories as well. This is also being backed up by a roadshow which to date has hit nearly 20 countries.

For those Forms customers who are taking a step into the Java world, we have a dedicated site on OTN as well as dedicated developers guides, books and Oracle University courses.

CM: Consider an Oracle shop with a large legacy Oracle Forms application that is running well but in a desupported version of Forms. Should they have any intentions of upgrading their Forms installs and what are the risks if they don’t?

Grant Ronald: Our roadmap for Forms customers is “upgrade and integrate”. So the first point to consider is upgrade. There are, of course, benefits of upgrading but you also have to consider the risk of not upgrading: running your business applications on desupported software that is neither security nor bug patched, or being certified on newer OS or database versions. Are you managing the risk that some piece of this stack may change and destabilise your applications (e.g. a forced O/S upgrade), or are you just hoping that this software tower will hold up with no means of support. It’s your call.

Which takes us to the next point: integration. By web deploying your Forms on the application server, you are positioning yourself on a platform on which you can integrate both your legacy applications, and new services and applications.

By following the “upgrade and integrate” roadmap, you can limit the risk to your business applications while still positioning yourself for your long-term strategic goals.

CM: Consider an Oracle shop with a large amount of SQL and PL/SQL programmers who are cognisant in Forms. Which Oracle development technology should they pick for maintenance and extension of the existing system: Forms, Apex or JDeveloper/ADF?

Grant Ronald: The simplest answer is really to pick the technology/tool that suits you best. If you are extending your existing Forms application it may be that you build new business logic in the database that could be shared between Forms, Java and Apex applications. Or you might decide that you really want to exploit the power of Java and so JDeveloper and ADF would be a natural choice. Many customers are closely aligned with Oracle’s business applications and so the Oracle Fusion technology stack may drive the choice of development tool. I try to discourage customers to think in binary terms when choosing tools. The reality is that you will probably have a mix.

CM: You mention that JDeveloper and ADF would be the natural choice for an Oracle developer. Why?

Grant Ronald: As I mentioned earlier, I look after Oracle Forms and Oracle JDeveloper. One reason for this split in roles is to bring my 4GL Forms experiences into JDeveloper and Oracle ADF. When I first joined the JDeveloper team I was amazed how developers were willing to write lines of code for common actions that I set with the click of a checkbox in Forms. Part of my job is to ensure that the kind of rich features a Forms developer takes for granted are implemented in JDeveloper and Oracle ADF.

JDeveloper and Oracle ADF is also a natural choice because it’s the route our own Applications Division is taking. Our next generation Fusion applications are being built using JDeveloper and ADF. So, as the technology choice for Oracle’s own Fusion Applications, the technology is built with the Forms/Database and PL/SQL developers in mind. No other tool or framework can make this claim.

CM: What skills do you see a Forms developer needing in moving to ADF, and what approach do you suggest to a development team in minimising this learning curve?

Grant Ronald: There is a learning curve in moving to any new technology but with JDeveloper and ADF we are really smoothing out that learning curve and lowering the barrier at which you can start to become productive.

Of course, the bottom line is that you will need some Java knowledge, but how much depends on how far you want to get below the covers and customize the behaviour of the framework.

With an overview of ADF and some basic Java language skills, you can go a long way: building business services, validation, page flow, rich UI interaction, LOVs, graphs – stuff that you couldn’t even consider if you weren’t using ADF.

But if you have made a strategic choice to develop on the Java platform, I’d expect you to still have some members of your team who have a more advanced knowledge of the platform so they can make architectural decisions and set up best practices. We are also working on giving you the learning aids to get up to speed. We have developed a number of Oracle University courses specifically targeted at the Forms audience moving to Java. There are a number of books already published and more in the pipeline that are aimed at opening up the platform. And of course, we have a dedicated focus page on OTN and the essential ADF developer guides for 4GL developers.

CM: Recently you’ve been focusing on SOA technology integration with Forms. Why advantages do you see this combination providing? What challenges do Forms programmers face with integration?

Grant Ronald: The benefits of a service based approach are already well documented: loosely coupled, reusable implementations of business processes gives a more flexible, agile architecture that is better aligned to the business.

Much of the work we are doing with Oracle Forms now is to allow your existing Forms application to hook into the SOA world. The ability to call out to web services and for those services to call back asynchronously is one example.

CM: Grabbing your crystal ball, given your long-term experience in development, where do you see Oracle development in 10 years time?

Grant Ronald: I think the clearest view of the future can be seen in Oracle’s own business applications. Oracle’s Applications Division have upgraded to the most recent version of Forms, while looking to exploit the benefits of a services oriented architecture and a standards based platform. Using JDeveloper and Oracle ADF, they are taking developers from a background including Forms, PL/SQL and Peopletools, and making them productive on the Java platform.

I think this gives the clearest indication of where Oracle development is heading and I think there is a great comfort in knowing that the technology choices you are making are the ones Oracle is betting its business applications on as well.

CM: Finally, moving out of the Oracle arena, what keeps you kicking out of work? I know you play in a band.

Grant Ronald: I play a bit of keys in a band, and that mixed with a few weekends out biking helps balance out all the fun I have at Oracle!

Book review - Processing XML Documents with JDeveloper 11g

I was recently asked to write a book review on Processing XML Documents with JDeveloper 11g by Deepak Vohra, among several other bloggers here, here, here and here.

The thing about book reviews, like movie reviews, is the interpretation by the reviewer is subjective. The trick is for you the review reader to work out does the reviewer have the same tastes and likes as you. If yes that should mean that the book review will be relevant to you potentially giving a recommendation that suits your needs. If no you might miss a really good book or waste a couple of those hard earned squid.

So where do I come from to help you assess if I'm "your" type of reviewer? I'm a both a consultant *and* a trainer. I'm interested in how the story is told as much as what is told. I'm looking for clear examples, a logical A-B-C progression path, and like everyone else something to keep me interested, especially important in the often dreary world of computing. In addition I use XML and JDeveloper in my day to day job, so I should be a prime candidate for this book.

In considering the book's title and what I'd expect to find between the book's covers, I'd want to see a discussion around the XML facilities in JDev 11g vs earlier versions, a comparison of JDev's XML facilities against the other IDEs, then a road-show through the XML features vs the common XML tasks in Java of creating/parsing XML, XML schemas & validation etc. Let's see how the book fairs.

Firstly the Who-is-this-book-for section somewhat incorrectly states readers need to know just XML basics: "what an XML document is, what XSLT is, what XPath is, and what an XML schema is." In the very first chapter it introduces the DOM and SAX parsing methods without any explanation of how they work or the differences, so it actually assumes more knowledge than stated. Anybody with a limited knowledge of XML should definitely look at a book tailor fitted to explaining XML alone before reaching for this book.

The book does receive bonus points for including the latest version of JDeveloper 11g. On average, computing books have short half-lives because the technology they're based on is updated or replaced regularly. As a book purchaser you want your investment to last long as possible without becoming instantly redundant. The fact this book is written against the latest JDev 11g release should help extend that investment, until Oracle does another rewrite of the IDE.

Yet on considering my expectations for the book, it doesn't take the opportunity to discuss JDeveloper in general, nor its XML feature support. This is a shame as it doesn't help to "sell" JDeveloper and its benefits in any direct manner.

But in addressing my expectations again the book takes you through typical stuff you want to do with XML via Java, such as creating and parsing XML, working with XML schemas, XML validation, XPath and so on very much in a cookbook like fashion – here's a recipe now you follow it. I somewhat don't understand the inclusion of chapters on XML to PDF, XML to Excel, and XML Publisher, as the book's title is about processing XML in JDeveloper, those chapters relate to specific XML use cases not a generalised XML requirement. Their exclusion could have made this a concise JDev-XML guide.

If I consider the writing style used, personally from reading around a zillion technical books I tend to lump technical books into 3 styles:

a) the "Head First" series which takes an extreme narrative style
b) the other end which is just reams of code and specifications which isn't a book but rather a printed manual, it typically gives no narrative, just cold hard "this is how you do it" facts
c) and the books that lie in between

For me a good book is one that lies in that nice gray area "c". I want the writer to keep me interested with a narrative style while reading the boring technical bits, information about the pros and cons, some background information, but not bury me in opinions and jokes (and crosswords and word puzzles for that matter).

For me this book falls closer to "b", you can tell it's written by a programmer by its dry clinical dry style. For instance chapter 1 introduces the fact that Oracle XDK 11g provides an API that extends JAXP, but then doesn't discuss what the Oracle XDK 11g is, why Oracle chose to override JAXP, and what benefits you'll get over using the non-standard libraries. So you get a "this is how you do it" style rather than any discussion on the "why", which I think is important for learning. Some readers might be smart enough (I know I'm not ;-) to conclude the "why" without any explicit description, so this book might suit you directly.

If we take the fact the book includes a large amount of code, in particular XML, care by the author and the publisher needs to be taken to present code in a concise way, well laid out code that is documented clearly, because code is central to the book's value. There are numerous examples in the book where code stretches across several pages without explanation, code layout is messy in areas, and given the quantity of code at times it's hard to work out which bit I should be focusing on (a problem that is often magnified by the "over-wordiness" of XML). I've no doubt given the amount of code in the book achieving this consistency is a very hard task, but again it detracts from the quality of the book.

Finally I mentioned that it's important for technical books to present a logical A-B-C progression path in assisting the reader to learn. Given this book's clinical style, where in each chapter it discusses the JDev environment setup, then a bullet point section walk through of the code, and how to run and see the results in the end, it does achieve this goal. Again the "why" is often missing in this book, but you do see the A-B-C progression path which is important.

In summary would I recommend this book? If you're simply looking for a cookbook like style technical book the answer is yes, but (and there is always a but).... for myself I miss the "why" in this book, the part that helps me learn the peripheral issues, so the answer is no.