It seems that Oracle attitude towards some communities is starting to have some unwanted consequences. After dumping the OpenSolaris community with an obstinate silence and continuing to leave the Java Community Process in an embarrassing limbo, the OpenOffice community has decided to take action and announced the creation of The Document Foundation to take control of the OpenOffice productivity suite.
Meanwhile, Oracle has been requested to join the "new" community by applying to the Foundation. Other companies worried by Oracle latest moves, such as Google and Novell and Red Hat, are already supporting the Foundation.
I wonder what Oracle will do and hope that Larry, at least once, does something so that Oracle be not the bad guy. This news makes me miss the Good Old Sun Microsystems.
Wednesday, 29 September 2010
The Death of OpenSolaris: Choosing an OS for a Java Developer
A Bit of History: The Struggles of OpenSolaris
This is no news: you probably know all about it.As a long time Solaris user, the recent years have been full of good news for me.
I remember starting with GNU/Linux at home to have "something similar" to the Solaris workstations I used at work. It was the time when software would most likely compile on Solaris rather than on Linux.
Years later I bought my first Sun Workstation: it was the time when trying to compile on Solaris packages that would supposedly compile on a POSIX system was a pain. Still, I continued to regard Solaris as a stable platform to keep on using it for my work duties, such as Java programming.
Then came Solaris 10 and all of its wonderful technologies such as ZFS, Zones and DTrace, just to cite a few. With it, there came the Solaris Express distributions which, at last, filled a long standing gap between Solaris and other operating systems, providing us a pretty modern desktop environment.
In late 2008 came the first OpenSolaris distribution. I installed it, played with it, but kept on using SXCE for my workstations. The main reason was compatibility with many Sun packages, such as the Java Enterprise System or the Sun Ray Server Software, that had more than one glitch on OpenSolaris.
When SXCE was discontinued, I waited for the 2010.xx OpenSolaris release to upgrade my systems. Unfortunately, that release will never see the light.
The Oracle Leaked Memo (the dignifying uppercase is a must given Oracle prolonged silence over the subject) shed a light over Oracle plans for Solaris proper and OpenSolaris. Part of the "good news" is that the Solaris Express program has been resurrected and the first binary distribution is expected later this year.
The bad news is that the code, at least the parts of it that will be released with an open source license, will be released after the releases of the full Solaris Operating Systems. Basically, our privileged observation point over the development of the operating system has been shut down.
Lots of ink has been been spilled since the Leaked Memo and plenty of information, discussions and wars are going on in the blogosphere. I'm not an authoritative source to speak about the subject and it's not even clear to me what I'm going to do, now.
Benefits of Solaris for a Java Developer
Solaris has been my operating system of choice since before I started working in the IT industry. As a student, I grew up with Solaris at the data center of my University and the Slackware I used at home seemed like a kid toy, compared to it. After graduating, I started working as a design engineer for a leading microprocessors producer. Needless to say, Solaris was the platform we ran our design software upon. Then, I moved to a consulting firm and started my career as a Java architect.Solaris was and is the platform of choice for most of the clients I've been working for. Even today, the application servers, the cluster software, the database, and most of the infrastructure used by my clients run on Solaris. It always seemed a sound choice to me, then, developing software on the same platform that will run it in production.
IDEs, Tools and Runtimes
As a Java developer, I can run all of my tools I need on a supported platform. My favorite IDEs (NetBeans and JDeveloper), the application servers my clients use (WebLogic and WebSphere, mostly), the databases used by my applications (MySQL, Oracle RDBMS, PostgreSQL): all of them run and are supported on Solaris. Some of them are even bundled with it or readily available by Sun sponsored package repositories. The Eclipse platform, to cite a widely use IDE for Java, is available in the OpenSolaris IPS repository, too.Solaris Technologies
Solaris 10 also integrates DTrace, a powerful, unobtrusive framework that allows you to observe and troubleshoot application and OS problem in real time, even in production systems with an almost null overhead. DTrace has allowed us to diagnose strange production quirks with no downtime: once you've tried DTrace and the D language, there's no going back to "just" a debugger, even in the development stages of your project.Other kinds of problems does not show up in your debugger or are extremely hard to catch. It might be the case of network or file systems problems. That's where DTrace comes in handy: it lets you observe with an incredibly high detail what's going on in your application and in the kernel of the operating systems, if it's necessary to dig so deep.
Solaris Virtualization Technologies
Solaris is also an ideal host virtualization platform. Solaris can "virtualize itself" with Containers, Zones and Logical Domains: you can start a Zone in no time (and almost no space overhead), assign a resource cap to it and also build a virtualized network in a box to simulate a complex network environment.One of the problems that I encountered during the development of big enterprise system is that the development environment, and sometimes even the integration environment, is very different than the production one. It surely is a methodology problem: nevertheless, developers have few weapons to counteract. For example, applications that appear to run fine on a single node may not run correctly on a server cluster, or scale badly.
The more you wait to catch a bug, the more impact will have a patch for it. That's why in my development team, for example, we use Solaris Zones to simulate a network cluster of IBM WebSphere Application Servers and a DB cluster. All of them run in completely isolated Zones in one physical machine and communicate on a virtual network with virtual etherstubs (sort of a network switch), VLANs and routing rules. This environment lets us simulate exactly how the software will behave in the production system. Without a flexible and lightweight virtualization technology it would have been much more difficult and expensive to prepare a similar environment.
And if you (still) need to run other platforms, you can use Xen or VirtualBox to run, for example, your favorite Linux distro, Windows, or *BSD.
Summarizing
Enumerating the advantages of Solaris is difficult in such a reduced space, however I'll try:- It's a commercially supported operating system: that's an option, since Solaris is free for development purpose. Nonetheless, it's an important point to take into account.
- Is (very) well documented: there's plenty of official and unofficial documentation.
- It's easy to administer: Solaris is pretty easy to administer, even if you're not a seasoned system administrator.
- It's an UNIX system: with all of its bells and whistles.
- It is a great virtualization platform.
- It has some unique technologies that add much value to its offering, such as ZFS and DTrace.
If you're a Java developer and haven't given Solaris I try, I strongly suggest you do it. Maybe you'll start to benefit from other Solaris 10 technologies such as Zones and ZFS, even for running your home file or media server.
Complaints
I often hear complaints about Solaris coming from different sources and with the most imaginative arguments: proprietary, closed, old, difficult to use. I usually answer inviting users to try it and see for themselves before judging it (if that's the case). Most of the times I'm not surprised to discover that the complaining guy had minimal or null exposure to Solaris.Also, I'd like to point out that no OS I tried is a swiss army knife. Solaris is a server-oriented OS with a good desktop but it's not comparable with other operating systems for such an use. So: no comparison with Linux, please. It would be so unjust as comparing Linux and Mac OS X for the average home user. ;)
Alternatives
Since Java "runs anywhere", there's plenty of choice for a Java developer.Since I own a laptop with Mac OS X, I've built a small development environment with all of the tools I need. Mac OS X is a great operating systems that comes with many fancy features out of the box and, although it has some idiosyncrasy with Java (read: you have to use the JVM shipped by Apple), it's a good OS for a Java developer. Since the Mac OS X hype has begun, there's plenty of packages for it and a big ecosystem which is still growing. Still, many software packages run in the enterprise aren't supported on Mac OS X. Since I prefer to have an environment as close as possible as the production one, I think that OS X is not the best choice for the average Java EE architect.
I've also been an hardcore Slackware and Debian user for a long time. An enterprise Java developer would miss nothing in a modern GNU/Linux distribution, nowadays, and most of the software packages you'll find in the enterprise will run on your GNU/Linux distribution.
No need to talk about Windows, either.
So, why Solaris? Every OS has its own advantages and disadvantages. The point is to just recognize them. Mac OS X, in my opinion, is the best OS for a home user. I would change it for no Windows and no Linux. But as far as it concerns my developers' duties, every other OS just lacks the features and the stability that make Solaris great. ZFS, DTrace and Zones, for my use cases, are killer features.
What's Next?
You've decided to give Solaris a try, so: which is Your distribution? I don't know.Solaris Express/Oracle Solaris
I strongly suspect that my wait will be prolonged and I will finally upgrade my machines as soon as Solaris Express has been released. Upgrading to Solaris 10 09/10 is not possible since I'm using some ZFS pools whose version is not yet supported by Solaris proper but it is a sound choice for a starter.The advantage I see in using one of these versions is the availability of optional support and the good level of integration with the most commonly used software packages that Oracle is likely to guarantee.
OpenIndiana
You should also know that OpenSolaris sources have been (sort-of) forked and two new projects are born: Illumos and OpenIndiana. The project were started by Nexenta employees and volunteers of the OpenSolaris community. The first projects aims at maintaining the OpenSolaris code and the parts of the code that are closed or code that upstream might choose not to maintain. The OpenIndiana project aims at producing binary distribution of the operating system built upon the Illumos source code. OpenIndiana will provide a really open source, binary compatible alternative to Solaris and Solaris Express.Sounds good and I'll willingly support it. In the meantime I've installed OpenIndiana in a couple of virtual machines and the first impressions are very good. I suppose it hasn't passed enough time yet for diverging changes to have emerged.
If you prefer a more modern desktop with a recent Gnome interface, drop Solaris 10 and go for OpenIndiana, if you don't feel like waiting for Solaris Express. In any case, switching between the two shouldn't pose any problems. What's clear to me is that I won't consider using both operating systems: I'll have to make a choice.
Support Availability
As an enterprise user and a Java developer, I've always been more concerned about OS support and support for the packages I use, rather than about eye candy. Even at the cost of running a proprietary platform.In conclusion: I'll wait for Solaris Express to be released and only then will decide which one I'll use for my purposes between Oracle Solaris Express and OpenIndiana. My heart is betting for OpenIndiana. My brain is betting for Oracle Solaris Express and Solaris proper. Only time will tell which one is right (for me.)
Follow-Up
A follow-up of this blog post is avaible at this address. In this post I'll try to summarize some use cases in which the technology we introduced in this post are effective and add real value to your development duties.I hope you enjoy it.
Tuesday, 28 September 2010
Encoding an Unicode Character to UTF-8
Introduction
I'm living in an UTF-8 world. Everthing, from the operating systems I use (Solaris, Linux and Mac OS X) to my terminals. Even the file systems I use must be able to support the UTF-8 names I give to my files.UTF-8 is a flexible and well supported encoding for Unicode and it's supported, out of the box, on all the operating systems I use. UTF-8 allows me not to worry (ever) about the characters I use in file names or in the files I write. Being a native Italian living in Spain, it's essential for me to have an encoding that supports all of the languages I use in my daily file.
UTF-8 is the perfect solution: it's ASCII backwards compatible, so I need no conversion when writing ASCII files, and can encode every characters in the Unicode character set. No need to worry if one day I had to write some Japanese file name. The only "drawback" it may have it's a little space overhead compared to some other encodings (such as UTF-16) but in this particular case, UTF-8 beats them all.
In such an UTF-8 world, there's no need to worry: just use the tools you have and everything will be fine.
Well, almost. Sometimes, as described in that post, I need to know exactly how UTF-8 encodes a specific Unicode code point. Some other times, since I'm a sed and grep addict, it's really handy knowing what to look for. Some days ago, for example, I had look for file names that contained specific code points to correct an idiosyncrasy between Subversion and Mac OS X (I still cannot believe it...). In such a cases, an UNIX terminal and its utilities are really your best friends. Since the encoding process is very easy, I'm quickly describing it to you in the case you need it.
The UTF-8 Encoding
The UTF-8 encoding is a variable width encoding in which each Unicode code point can be encoded as a sequence of 1 to 4 octects. Each octect is composed by a heading byte and trailing bytes. Since the encoding is a variable width one, you need a way to tell where a sequence starts and where it ends. That information is stored in the head byte.Heading Byte
The head byte can take one of these forms:- 0xxxxxxx: Single byte.
- 110xxxxx: Head of a sequence of two bytes.
- 1110xxxx: Head of a sequence of three bytes.
- 11110xxx: Head of a sequence of four bytes.
You may have noticed that the number of 1s in a heading byte tells how long the sequence is. If the heading byte starts with 0, the sequence is single byte.
The 0xxxxxxx format guarantees that ASCII characters in the [0, 127] range are encoded by the identical function thus guaranteeing the backwards compatibility with ASCII.
Trailing Bytes
Trailing bytes in a multibyte UTF-8 sequence always have the following form:- 10xxxxxx
Encoding
The 0s and 1s in the heading and trailing bytes format described in the previous sections are called control bits. In the UTF-8 encoding, the concatenation of the non control bits is the scalar value of the encoded Unicode code point. Because of the structure of the aforementioned forms, the number of required bytes to encode a specific Unicode code point with UTF-8 depends on the Unicode range where it falls (the ranges are given both hexadecimal and binary forms:- [U+000, U+007F] [00000000, 01111111]: one byte.
- [U+0080, U+07FF] [10000000, 111 11111111]: two bytes.
- [U+0800, U+FFFF] [1000 00000000, 11111111 11111111]: three bytes.
- [U+10000, U+10FFFF] [1 00000000 00000000, 10000 00000000 00000000]: four bytes.
One Byte Range
In the one byte range, meaningful bits of the Unicode code points are in then [0, 6] range. Since the single byte form has a 1 bit overhead (the leading 0), a single byte is sufficient:[0xxxxxxx 0xxxxxxxx]
[00000000, 011111111]
Two Bytes Range
In the two bytes range, meaningful bits of the Unicode code points are in the [0, 10] range. Since the head of a sequence of two bytes has a 3 bits overhead and the form of a trailing byte has a 2 bits overhead, there's room for exactly 11 bits.[ fff ffssssss, fff ffssssss]
[00000000 10000000, 00000111 11111111]
(* f are bits from the first byte of the encoded sequence)
(** s are bits from the second byte of encoded the sequence)
The encoded sequence is:
[110fffff 10ssssss]
Three Bytes Range
In the three bytes range, meaningful bits of the Unicode code points are in the [0, 15] range. Since the head of a sequence of three bytes has a 4 bits overhead and the form of a trailing byte has a 2 bits overhead, there's room for exactly 16 bits.[ffffssss sstttttt, ffffssss sstttttt]
[00001000 00000000, 11111111 11111111]
(* f are bits from the first byte of the sequence)
(** s are bits from the second byte of the sequence)
(*** t are bits from the third byte of the sequence)
The encoded sequence is:
[1110ffff 10ssssss 10tttttt]
Four Bytes Range
In the four bytes range, meaningful bits of the Unicode code points are in the [0, 20] range. Since the head of a sequence of four bytes has a 5 bits overhead and the form of a trailing byte has a 2 bits overhead, there's room for exactly 21 bits.[ fffss sssstttt tthhhhhh, fffss sssstttt tthhhhhh]
[00000001 00000000 00000000, 00010000 11111111 11111111]
(* f are bits from the first byte of the sequence)
(** s are bits from the second byte of the sequence)
(*** t are bits from the third byte of the sequence)
(**** h are bits from the third byte of the sequence)
The encoded sequence is:
[11110fff 10ssssss 10tttttt 10hhhhhh]
Conclusion
You know see how easy is to convert an Unicode code point to its representation in the UTF-8 encoding. The UTF-8 encoding of the Byte Order Mark (BOM) character, for example, whose code point is U+FEFF, can be easily be computed as explained above.The U+FEFF code point falls in the three byte range and its binary representation is:
[F E F F ]
[1111 1110 1111 1111]
According the the aforementioned rule, the conversion gives:
[E F B B B F ]
[11101111 10111011 10111111]
that corresponds to the \xEF\xBB\xBF expression used with sed in our previous example.
LibreOffice - A Free Productivity Suite Makes Its Debut
LibreOffice a Free office suite makes its debut. LibreOffice is a fork of OpenOffice.org and is sponsored by Google and Novell. The office suite is essentially OpenOffice.org and even contains the very same icons and graphics of OpenOffice.org.
Read more »
Read more »
EJB 3.1 Global JNDI Access
Table of Contents
As outlined in the previous parts of this series, the major drawback of the EJB v. 3.0 Specification was the lack of portable global JNDI names. This implies that there's no portable way to link EJB references to a bean outside your application.
The EJB v. 3.1 Specification fills this gap defining, in its own words:
"a standardized global JNDI namespace and a series of related namespaces that map to the various scopes of a Java EE application."
"a standardized global JNDI namespace and a series of related namespaces that map to the various scopes of a Java EE application."
This blog post will give you an overview of the Global JNDI Access as defined by the EJB v. 3.1 Specification.
Namespaces and Scopes
The EJB v. 3.1 Specification defines three distinct namespaces with its own scopes:
- Global.
- Application.
- Module.
The specification requires compliant containers to register all of the session beans with the required JNDI names. Such standardized names are portable and your application components will be able to establish a reference to an EJB using a name that is portable across application servers.
Global
Names in the global namespace will be accessible to code in any application and conform to the following syntax:
java:global[/<app-name>]/<module-name>/<bean-name>[!<interface-FQN>]
<app-name> is the name of the Java EE application as specified in its standard deployment descriptor (application.xml) or, by default, the base name of the deployed EAR archive. This path fragment is used only if the session EJB is deployed within a Java EE application EAR file.
If the session EJB is deployed in an EAR file, its <module-name> is the path name of the Java EE module that contains the bean (without extension) inside the EAR file. If the session bean is deployed as a standalone Java EE component in a JAR file or as part of a Java EE web module in a WAR file (which is now allowed by the Java EE 6 Specification), the <module-name> is the name of the archive (without extension). The <module-name> value can be overridden by the <module-name/> element of the component's standard deployment descriptor (ejb-jar.xml or web.xml).
The <bean-name> is the EJB name as specified by the mechanisms described in the previous parts of this blog post.
The <interface-FQN> part is the fully qualified name of the EJB business interface.
The container has to register one JNDI global entry for every local and remote business interface implemented by the EJB and its no-interface view.
Session EJB With One Business Interface or a No-Interface View
If an EJB implements only one business interface or only has a no-interface view, the container is also required to register such a view with the following JNDI name:java:global[/<app-name>]/<module-name>/<bean-name>
Application
Names in the application namespace will be accessible only to code within the same application and conform to the following syntax:
java:app/<module-name>/<bean-name>[!<interface-FQN>]
Each path fragment retains the same meaning described for the global namespace JNDI names syntax in the previous section.
The same publishing rules for a compliant container described in the previous section apply.
java:app/<module-name>/<bean-name>[!<interface-FQN>]
Each path fragment retains the same meaning described for the global namespace JNDI names syntax in the previous section.
The same publishing rules for a compliant container described in the previous section apply.
Module
Names in the module namespace will be accessible only to code within the same module and conform to the following syntax:java:module/<bean-name>[!<interface-FQN>]
Once more, each path fragment retains the same meaning described for the global namespace JNDI names.
The same publishing rules for a compliant container described in the global namespace section.
Local Clients
It may be important to notice that, although global JNDI names for local interfaces (and no-interface views) are published, this does not imply that such an interface will be accessible to components running in another JVM.Conclusions
The EJB v. 3.1 Specification, and other specifications in the Java EE 6 Platform, brings simplicity and adds many new features and tools to the developers' toolboxes. "Global JNDI names" is an outstanding, although simple, feature because it finally fills a long-standing portability limitation of the previous revisions of this specification and, hence, of the entire Java EE platform.EJB 3.0 and EJB 3.1 provide a powerful, portable, yet simple component model to build enterprise applications. The "EJB sucks" day are gone but only time will tell if this technology will regain the trust of Us, The Developers.
As far as it concerns myself, I feel pretty comfortable with Java EE 6, EJBs, CDI beans, the good support I have from IDEs such as NetBeans or JDeveloper (although the latter does not support EJB 3.1 yet), and all the specifications that build up this venerable platform.
A Shell Script to Find and Remove the BOM Marker
Introduction
Have you ever seen this characters while dumping the contents of some of your text files, haven't you?
If you have, you found a BOM marker! The BOM marker is a Unicode character with code point U+FEFF that specifies the endianness of an Unicode text stream.
Since Unicode characters can be encoded as a multibyte sequence with a specific endianness, and since different architectures may adopt distinct endianness types, it's fundamental to signal the receiver about the endianness of the data stream being sent. Dealing with the BOM, then, it's part of the game.
If you want to know more about when to use the BOM you can start by reading this official Unicode FAQ.
UTF-8
UTF-8 is one of the most widely used Unicode characters encoding on software and protocols that have to deal with textual data stream. UTF-8 represents each Unicode character with a sequence of 1 to 4 octects. Each octect contains control bits that are used to identify the beginning and the length of an octect sequence. The Unicode code point is simply the concatenation of the non control bits in the sequence. One of the advantages of UTF-8 is that it retains backwards compatibility with ASCII in the ASCII [0-127] range since such characters are represented with the same octect in both encodings.If you feel curious about how the UTF-8 encoding works, I've written an introductory post about it.
Common Problems
Because of its design, the UTF-8 encoding is not endianness-sensible and using the BOM with this encoding is discouraged by the Unicode standard. Unfortunately some common utilities, notably Microsoft Notepad, keep on adding a BOM in your UTF-8 files thus breaking those application that aren't prepared to deal with it.Some programs could, for example, display the following characters at the beginning of your file:

A more serious problem is that a BOM will break a UNIX shell script interfering with the shebang (#!).
A Shell Scripts to Check for BOMs and Remove Them
The Byte Order Mark (BOM) is a Unicode character with code point U+FEFF. Its UTF-8 representation is the following sequence of 3 octects:1110 1111 1011 1011 1011 1111
E F B B B F
The quickest way I know of to process a text file and perform this operation is sed. The following syntax will instruct sed to remove the BOM from the first line of its input file:
sed '1 s/\xEF\xBB\xBF//' < input > output
A Warning for Solaris Users
I haven't found a way (yet) to correctly use a sed implementation bundled with Solaris 10 to perform this operation, neither using /usr/bin/sed nor /usr/xpg4/bin/sed. If you're a Solaris user, please consider installing GNU sed to use the following script.The quickest way to install sed and a lot of fancy Solaris packages is using Blastwave or OpenCSW. I've also written a post about loopback-mounting Blastwave/OpenCSW installation directory in Solaris Zones to simplify Blastwave/OpenCSW software administration.
A Suggestion for Windows Users
If you want to execute this script in a Windows environment, you can install CygWin. The base install with bash and the core utilities will be sufficient for this script to work on your CygWin environment.Source
This is the source code of a skeleton implementation of a bash shell script that will remove the BOM from its input files. The script support recursive scanning of directories to "clean" an entire file system tree and a flag (-x) to avoid descending in a filesystem mounted elsewhere. The script uses temporary files while doing the conversion and the original file will be overwritten only if the -d option is not specified.#!/bin/bash
set -o nounset
set -o errexit
DELETE_ORIG=true
DELETE_FLAG=""
RECURSIVE=false
PROCESSING_FILES=false
SED_EXEC=sed
TMP_CMD="mktemp"
TMP_OPTS="--tmpdir="
XDEV=""
if [ $(uname) == "SunOS" ] ; then
TMP_OPTS="-p "
if [ -x /usr/gnu/bin/sed ] ; then
echo "Using GNU sed..."
SED_EXEC=/usr/gnu/bin/sed
fi
fi
function usage() {
echo "bom-remove [-dr] [-s sed-name] files..."
echo ""
echo " -d Do not overwrite original files and do not remove temp files."
echo " -r Scan subdirectories."
echo " -s Specify an alternate sed implementation."
echo " -x Don't descend directories in other file systems."
}
function checkExecutable() {
if ( ! which "$1" > /dev/null 2>&1 ); then
echo "Cannot find executable:" $1
exit 4
fi
}
function parseArgs() {
while getopts "dfrs:x" flag
do
case $flag in
r) RECURSIVE=true ;;
f) PROCESSING_FILES=true ;;
s) SED_EXEC=$OPTARG ;;
d) DELETE_ORIG=false ; DELETE_FLAG="-d" ;;
x) XDEV="-xdev" ;;
*) echo "Unknown parameter." ; usage ; exit 2 ;;
esac
done
shift $(($OPTIND - 1))
FILES="$@"
if [ ! -n "$FILES" ] ; then
echo "No files specified. Exiting."
exit 2
fi
if [ $RECURSIVE == true ] && [ $PROCESSING_FILES == true ] ; then
echo "Cannot use -r and -f at the same time."
usage
exit 1
fi
checkExecutable $SED_EXEC
checkExecutable $TMP_CMD
}
function processFile() {
TEMPFILENAME=$($TMP_CMD $TMP_OPTS$(dirname "$1"))
echo "Processing $1 using temp file $TEMPFILENAME"
cat "$1" | $SED_EXEC '1 s/\xEF\xBB\xBF//' > "$TEMPFILENAME"
if [ $DELETE_ORIG == true ] ; then
if [ ! -w "$1" ] ; then
echo "$1 is not writable. Leaving tempfile."
else
echo "Removing temp file..."
mv "$TEMPFILENAME" "$1"
fi
fi
}
function doJob() {
# Check if the script has been called from the outside.
if [ $PROCESSING_FILES == true ] ; then
for i in $FILES ; do
processFile "$i"
done
else
# processing every file
for i in $FILES ; do
# checking if file or directory exist
if [ ! -e "$i" ] ; then echo "File not found: $i. Skipping..." ; continue ; fi
# if a parameter is a directory, process it recursively if RECURSIVE is set
if [ -d "$i" ] ; then
if [ $RECURSIVE == true ] ; then
find "$i" $XDEV -type f -exec "$0" $DELETE_FLAG -f "{}" +
else
echo "$i is a directory. Skipping..."
fi
else
processFile "$i"
fi
done
fi
}
parseArgs $@
doJob
$ bom-remove file-to-clean ...
If you want to clean the files in an entire directory, you can use the following syntax:
$ bom-remove -r dir-to-clean
If your sed installation is not in your $PATH or you have to use an alternate version, you can invoke the script with the following syntax:
$ bom-remove -s path/to/sed file-to-clean
If you want to clean a directory in which other file systems might be mounted, you can use the -x option so that the script does not descend them:
$ bom-remove -xr dir-to-clean
However, should your file system be affected by the BOM-desease, I hope this script will be a good starting point to build a BOM-cleaning solution for your site.
Enjoy!
if [ $RECURSIVE == true ] && [ $PROCESSING_FILES == true ] ; then
echo "Cannot use -r and -f at the same time."
usage
exit 1
fi
checkExecutable $SED_EXEC
checkExecutable $TMP_CMD
}
function processFile() {
TEMPFILENAME=$($TMP_CMD $TMP_OPTS$(dirname "$1"))
echo "Processing $1 using temp file $TEMPFILENAME"
cat "$1" | $SED_EXEC '1 s/\xEF\xBB\xBF//' > "$TEMPFILENAME"
if [ $DELETE_ORIG == true ] ; then
if [ ! -w "$1" ] ; then
echo "$1 is not writable. Leaving tempfile."
else
echo "Removing temp file..."
mv "$TEMPFILENAME" "$1"
fi
fi
}
function doJob() {
# Check if the script has been called from the outside.
if [ $PROCESSING_FILES == true ] ; then
for i in $FILES ; do
processFile "$i"
done
else
# processing every file
for i in $FILES ; do
# checking if file or directory exist
if [ ! -e "$i" ] ; then echo "File not found: $i. Skipping..." ; continue ; fi
# if a parameter is a directory, process it recursively if RECURSIVE is set
if [ -d "$i" ] ; then
if [ $RECURSIVE == true ] ; then
find "$i" $XDEV -type f -exec "$0" $DELETE_FLAG -f "{}" +
else
echo "$i is a directory. Skipping..."
fi
else
processFile "$i"
fi
done
fi
}
parseArgs $@
doJob
Examples
Assuming the script is in your $PATH and it's called bom-remove, you can "clean" a bunch of files invoking it this way:$ bom-remove file-to-clean ...
If you want to clean the files in an entire directory, you can use the following syntax:
$ bom-remove -r dir-to-clean
If your sed installation is not in your $PATH or you have to use an alternate version, you can invoke the script with the following syntax:
$ bom-remove -s path/to/sed file-to-clean
If you want to clean a directory in which other file systems might be mounted, you can use the -x option so that the script does not descend them:
$ bom-remove -xr dir-to-clean
Next Steps
The most effective way to fight the BOM is avoiding spreading it. Microsoft Notepad, if there's anybody out there using it, isn't the best tool to edit your UTF-8 files so, please, avoid it.However, should your file system be affected by the BOM-desease, I hope this script will be a good starting point to build a BOM-cleaning solution for your site.
Enjoy!
Sunday, 26 September 2010
References to EJBs Outside Your Application With Oracle WebLogic
Table of Contents
In the previous posts we made an overview of the EJB v. 3.0 and of the portable mechanisms it provides you to build your Java EE application. Since Java EE specifications are all about portability, at the risk of repeating ourselves we've often stressed the most important portability limit still present on the EJB v. 3.0 specifications: there is no portable way to declare and link a reference to an EJB outside your application.
Although there exist other standards (such as Web Services) that let you loosely couple components of your applications, remote EJBs are still an ideal mean to accomplish this task because of their simplicity, their standardization, the good development support of many IDEs and the good performance they provide.
In this blog post we'll make an overview of the mechanisms provided by one of the leading Java EE application servers, Oracle WebLogic, to give support to references to EJBs outside the scope of your application.
mappedName in Oracle WebLogic
Java EE compliant application servers provide additional non-portable API, tools and mechanisms used to enhance the standard Java EE features they implement. One of the features we've mentioned in the first part of this series was the mappedName @EJB element.
Although the EJB v. 3.0 Specification is willingly unclear about this element (that was sort of replaced by the lookup element introduced by the EJB v. 3.1 Specification), many application server vendors have implemented it with the intuitive behavior suggested by its own name: mapping an EJB to a global JNDI name.
If you want to trade portability for simplicity, many application servers (such as Oracle WebLogic or GlassFish) will let you define a bean's global JNDI name with the value of the mappedName element (or its corresponding deployment descriptor element.) As already stated, beware that Oracle WebLogic will assign global JNDI names to remote business interfaces only. This isn't really a limitation since local business interfaces can always be referenced using the APIs described in the previous parts of this series.
Oracle WebLogic Naming Conventions for EJB Remote Business Interfaces
With such a mechanism in place, linking a reference to a bean outside your application is straightforward. JDeveloper's EJB wizard, indeed, will put a default mappedName for you with an intuitive naming scheme that resembles somehow the new portable global JNDI names introduced by the EJB v. 3.1 specification, as shown in the following screenshot:
The naming scheme suggested by JDeveloper is the following:
mappedName = [application-name]-[module-name]-[bean-name]
If adopted, this naming scheme provides an easy way to assign every bean an unique name throughout your applications. I recognize that such names are a bit awkward but, being non-portable, is a naming scheme as good as any other.
Global JNDI Names for Remote EJB Interfaces in Oracle WebLogic
The global JNDI names of the remote business interfaces of an EJB with a mappedName in Oracle WebLogic Application Server will be:
mappedName#[interface-FQN]
Using this naming scheme will allow you to build loosely coupled Java EE application that reuse each other EJBs. If you want to inspect your server JNDI tree and check the actual names of your deployed EJB, you can use WebLogic's JNDI Tree inspector, which can be launched opening the WebLogic console, navigating to the Environment/Servers/[your-server] page and using the View JNDI Tree link. In the following screenshot you can examine the global JNDI entry for a bean defined as follows:
package es.reacts;
import ...;
@Stateless(name = "EJBByMappedName", mappedName = "Application1-EjbTest0-EJBByMappedName")
@Remote
public class EJBByMappedNameBean implements RemoteByMappedName {
[...]
}
In the screenshot you can appreciate the entry corresponding to the es.reacts.RemoteByMappedName business interface.
Customizing the JNDI Name of an EJB Remote Interface
Oracle WebLogic provides you the necessary tools to customize and override its default naming conventions for EJB remote interfaces. To assign or override the global JNDI name of an EJB remote interface you can use the WebLogic specific deployment descriptors. In the case of an EJB module, for example, you can use JDeveloper to quickly add a default weblogic-ejb-jar.xml or, if using another IDE such as NetBeans, you can create a new XML file named weblogic-ejb-jar.xml in the META-INF directory of your module. An empty weblogic-ejb-jar.xml file looks like this (as of Oracle WebLogic 10.3):
<?xml version = '1.0' encoding = 'UTF-8'?>
<weblogic-ejb-jar xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-ejb-jar http://www.bea.com/ns/weblogic/weblogic-ejb-jar/1.0/weblogic-ejb-jar.xsd"
xmlns="http://www.bea.com/ns/weblogic/weblogic-ejb-jar">
</weblogic-ejb-jar>
To assign or override a global JNDI name for a given EJB remote interface you can use the following elements:
<?xml version = '1.0' encoding = 'UTF-8'?>
<weblogic-ejb-jar xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-ejb-jar http://www.bea.com/ns/weblogic/weblogic-ejb-jar/1.0/weblogic-ejb-jar.xsd"
xmlns="http://www.bea.com/ns/weblogic/weblogic-ejb-jar">
<weblogic-enterprise-bean>
<ejb-name>SessionTest0</ejb-name>
<stateless-session-descriptor>
<business-interface-jndi-name-map>
<business-remote>es.reacts.SessionTest0</business-remote>
<jndi-name>global-jndi-name</jndi-name>
</business-interface-jndi-name-map>
</stateless-session-descriptor>
</weblogic-enterprise-bean>
</weblogic-ejb-jar>
If you're using JDeveloper, it provides you an easy GUI to edit the weblogic-ejb-jar.xml file:
The JDeveloper GUI will let you easily customize the WebLogic deployment descriptor and configure other non-portable features of the WebLogic Application Server such as EJB clustering.
Linking an EJB Reference to a Global JNDI Name
In the previous section we made an overview of the tools that Oracle WebLogic Application Server provides to customize the execution environment and establish a global JNDI name for a remote interface of an EJB. In the same way, Oracle WebLogic provides you other tools to link an EJB reference to a specific target EJB using a global JNDI name.
In the examples seen so far, we've always linked an EJB reference to a target using the portable mechanisms provided by the EJB v. 3.0 Specification. If you need to establish a target to a remote EJB outside the scope of your application, you can use the WebLogic-specific deployment descriptor of the module that acts as the EJB client. In the case of the Java EE module we've used so far, you can use JDeveloper to add the WebLogic-specific deployment descriptor called weblogic.xml. If you're using other IDEs, the skeleton of this file is the following (as of Oracle WebLogic 10.3):
<?xml version = '1.0' encoding = 'UTF-8'?>
<weblogic-web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-web-app http://www.bea.com/ns/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd"
xmlns="http://www.bea.com/ns/weblogic/weblogic-web-app">
<ejb-reference-description>
<ejb-ref-name>ejb/myGlobalRef</ejb-ref-name>
<jndi-name>global-jndi-name</jndi-name>
</ejb-reference-description>
</weblogic-web-app>
This weblogic.xml deployment descriptor links the EJB reference ejb/myGlobalRef with the object stored with the global JNDI name global-jndi-name, that is the name we've specified in the weblogic-ejb-jar.xml file described in the previous section. This reference will be declared as usual with a @EJB annotation or in the standard deployment descriptor (in this case, the web.xml file).
If you're using JDeveloper, a GUI will help you build the WebLogic-specific deployment descriptor. The GUI is well done and is also able to scan you module's EJB references and let them choose from a list when customizing them.
Next Steps
In this part we've learnt how to use WebLogic-specific tools in the case we had to link an EJB reference to an EJB that lives outsides our application using a global JNDI name. In the following part (coming soon) we'll see how the EJB v. 3.1 Specification has (finally) filled this gap defining portable JNDI names. With EJB v. 3.1 you'll be able to build modular Java EE application that reuse components of one another without the need to rely on non-portable mechanisms any longer.
Subscribe to:
Posts (Atom)