Wednesday, March 30, 2011

Glassfish 3.0: Web service result encoding problem ( invalid byte 2 of 2-byte utf-8 sequence) solution

I have developed JEE 6 enterprise application with 2 web modules and EJB3 exposed as web service.

Application deployed successfully on the glassfish v3.0.1 and when viewing the WSDL everything is okay.

But when I invoked the built in web service tester, and invokeing an operation I got the following error:

javax.xml.transform.transformerexception:org.apache.xerces.impl.io.malformedbytesequenceexception:invalid byte 2 of 2-byte utf-8 sequence
So how do I enable the UTF-8 in the "test web service" page? Right now the result is returning UTF-8, but the page is not UTF-8 so it cannot display the result.
The solution as the following:
  1. From left menu choose configuration
  2. Expand server-config
  3. Click on JVM settings.
  4. Click on JVM options tab.
  5. Add -Dfile.encoding=UTF8 to JVM options.
  6. Save changes.
  7. Restart application server.
After restarting try to test again and everything should works fine.

Monday, March 28, 2011

SE: Principles of Quality Software Development

Quality Software Development Principles


So, you have figured out how to build your applications, and they work just like the ones from which you learned. You are getting paid to write these applications, so you are now a professional developer. But how do you know if you are doing a good job?

There are literally thousands upon thousands of articles debating the measures of quality software with each of them offering you their own solution for how you should answer this question.

This body of work can be boiled down to a few questions:

Does the software do what it is supposed to do?
Of course, this is a loaded question. It is entirely possible to say that a piece of software does what it is supposed to do (as defined by a requirements specification), but this is absolutely worthless. In essence, you are talking about a failure of your requirements gathering process, which leads you to build the wrong thing. Your software is being built to serve a particular need, and if it does not satisfy that need (for whatever reason), the software is a failure.

Does the software do things it shouldn’t do?
Developers like to refer to this phenomenon as undocumented features, but your users will refer to them as bugs. Everyone prefers to build bug-free software, but in the real world, this just doesn't happen. All men may be created equal, but all bugs are not. Bugs that do not impact the functioning of the system -or the business process they support -are obviously far less important than those that do.

Did you deliver the software in a timely manner?
Timing is everything, and this is true nowhere more than in software in which the pace of change is incredible. If your software takes so long to deliver that it is no longer appropriate to the business process it supports, then it is worthless. The great untold secret behind the high percentage of software projects that end in failure is that many of them simply could not keep up with the pace of technological innovation and died trying.

Could you do it again if you had to?
Of course, you will have to! This is the job---writing and delivering software that complies with the preceding questions. The key here is that you should not have to learn all of your hard knocks lessons every time you build software. You will invariably be asked to deliver your software again with fixes and enhancements, and you hopefully do not have to fix the same bugs over and over again nor have the same integration challenges repeatedly. “At least we don’t have to deal with this next time” should be a truth that comforts you in your integration and bug fixing, and not a punch line to a development team joke.

These questions may seem like common sense---because they are! But there is an old saying that “common sense is neither,” so it is important not to assume that everyone is on the same sheet of music. Furthermore, the U.S. Army Rangers have a saying, “Never violate any principles, and do not get wrapped up in technique.”

You will find this a helpful maxim in dealing with the maze of processes, products, and techniques involved in software development. These are the core principles of software development, and how you get there is technique. Do not lose sight of the distinction between these two things.

SE: Software Engineering

Software engineering (SE)

is a profession dedicated to designing, implementing, and modifying software so that it is of higher quality, more affordable, maintainable, and faster to build. It is a "systematic approach to the analysis, design, assessment, implementation, test, maintenance and reengineering of software, that is, the application of engineering to software.

The term software engineering first appeared in the 1968 NATO Software Engineering Conference, and was meant to provoke thought regarding the perceived "software crisis" at the time.

The IEEE Computer Society's Software Engineering Body of Knowledge defines "software engineering" as the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software.

It is the application of Engineering to software because it integrates significant mathematics, computer science and practices whose origins are in Engineering.

Software development (SD)

A much used and more generic term, does not necessarily subsume the engineering paradigm. Although it is questionable what impact it has had on actual software development over the last more than 40 years, the field's future looks bright according to Money Magazine and Salary.com, which rated "software engineer" as the best job in the United States in 2006.