Building a Simple SOAP Web Service using Eclipse

January 4, 2011

Recently , i came across a very good article on creating a SOAP Web service using Eclipse.

You can follow the instructions provided in the below URL to create one in 30 mins !!!!

Unit Testing Guidelines

November 17, 2009

1. Keep unit tests small and fast

Ideally the entire test suite should be executed before every code check in. Keeping the tests fast reduce the development turnaround time.

2. Unit tests should be fully automated and non-interactive

The test suite is normally executed on a regular basis and must be fully automated to be useful. If the results require manual inspection the tests are not proper unit tests.

3. Make unit tests simple to run

Configure the development environment so that single tests and test suites can be run by a single command or a one button click.

4. Measure the tests

Apply coverage analysis to the test runs so that it is possible to read the exact execution coverage and investigate which parts of the code is executed and not.

5. Fix failing tests immediately

Each developer should be responsible for making sure a new test runs successfully upon check in, and that all existing tests runs successfully upon code check in.
If a test fails as part of a regular test execution the entire team should drop what they are currently doing and make sure the problem gets fixed.

6. Keep testing at unit level

Unit testing is about testing classes. There should be one test class per ordinary class and the class behaviour should be tested in isolation. Avoid the temptation to test an entire work-flow using a unit testing framework, as such tests are slow and hard to maintain. Work-flow testing may have its place, but it is not unit testing and it must be set up and executed independently.

7. Start off simple

One simple test is infinitely better than no tests at all. A simple test class will establish the target class test framework, it will verify the presence and correctness of both the build environment, the unit testing environment, the execution environment and the coverage analysis tool, and it will prove that the target class is part of the assembly and that it can be accessed.
The Hello, world! of unit tests goes like this:

     void testDefaultConstruction()
       Foo foo = new Foo();

8. Keep tests independent

To ensure testing robustness and simplify maintenance, tests should never rely on other tests nor should they depend on the ordering in which tests are executed.

9. Keep tests close to the class being tested

If the class to test is Foo the test class should be called FooTest (not TestFoo) and kept in the same package (directory) as Foo. Keeping test classes in separate directory trees makes them harder to access and maintain.
Make sure the build environment is configured so that the test classes doesn’t make its way into production libraries or executables.

10. Name tests properly

Make sure each test method test one distinct feature of the class being tested and name the test methods accordingly. The typical naming convention is test[what] such as testSaveAs(), testAddListener(), testDeleteProperty() etc.

11. Test public API

Unit testing can be defined as testing classes through their public API. Some testing tools makes it possible to test private content of a class, but this should be avoided as it makes the test more verbose and much harder to maintain. If there is private content that seems to need explicit testing, consider refactoring it into public methods in utility classes instead. But do this to improve the general design, not to aid testing.

12. Think black-box

Act as a 3rd party class consumer, and test if the class fulfills its requirements. And try to tear it apart.

13. Think white-box

After all, the test programmer also wrote the class being tested, and extra effort should be put into testing the most complex logic.

14. Test the trivial cases too

It is sometimes recommended that all non-trivial cases should be tested and that trivial methods like simple setters and getters can be omitted. However, there are several reasons why trivial cases should be tested too:
Trivial is hard to define. It may mean different things to different people.
From a black-box perspective there is no way to know which part of the code is trivial.
The trivial cases can contain errors too, often as a result of copy-paste operations:
     private double weight_;
     private double x_, y_;

     public void setWeight(int weight)
       weight = weight_;  // error

     public double getX()
       return x_;

     public double getY()
       return x_;  // error
The recommendation is therefore to test everything. The trivial cases are simple to test after all.

15. Focus on execution coverage first

Differentiate between execution coverage and actual test coverage. The initial goal of a test should be to ensure high execution coverage. This will ensure that the code is actually executed on some input parameters. When this is in place, the test coverage should be improved. Note that actual test coverage cannot be easily measured (and is always close to 0% anyway).
Consider the following public method:

     void setLength(double length);
By calling setLength(1.0) you might get 100% execution coverage. To acheive 100% actual test coverage the method must be called for every possible double value and correct behaviour must be verified for all of them. Surly an impossible task.

16. Cover boundary cases

Make sure the parameter boundary cases are covered. For numbers, test negatives, 0, positive, smallest, largest, NaN, infinity, etc. For strings test empty string, single character string, non-ASCII string, multi-MB strings etc. For collections test empty, one, first, last, etc. For dates, test January 1, February 29, December 31 etc. The class being tested will suggest the boundary cases in each specific case. The point is to make sure as many as possible of these are tested properly as these cases are the prime candidates for errors.

17. Provide a random generator

When the boundary cases are covered, a simple way to improve test coverage further is to generate random parameters so that the tests can be executed with different input every time.
To achieve this, provide a simple utility class that generates random values of the base types like doubles, integers, strings, dates etc. The generator should produce values from the entire domain of each type.

If the tests are fast, consider running them inside loops to cover as many possible input combinations as possible. The following example verifies that converting twice between little endian and big endian representations gives back the original value. As the test is fast, it is executed on one million different values each time.

    void testByteSwapper()
      for (int i = 0; i < 1000000; i++) {
        double v0 = Random.getDouble();
        double v1 = ByteSwapper.swap(v0);
        double v2 = ByteSwapper.swap(v1);
        assertEquals(v0, v2);

18. Test each feature once

When being in testing mode it is sometimes tempting to assert on “everything” in every test. This should be avoided as it makes maintenance harder. Test exactly the feature indicated by the name of the test method.
As for ordinary code, it is a goal to keep the amount of test code as low as possible.

19. Use explicit asserts

Always prefer assertEquals(a, b) to assertTrue(a == b) (and likewise) as the former will give more useful information of what exactly is wrong if the test fails. This is in particular important in combination with random value parameters as described above when the input values are not known in advance.

20. Provide negative tests

Negative tests intentionally misuse the code and verify robustness and appropriate error handling.
Consider this method that throws an exception if called with a negative parameter:

    void setLength(double length) throws IllegalArgumentException;
Testing correct behavior for this particular case can be done by:
    try {
      fail();  // If we get here, something went wrong
    catch (IllegalArgumentException exception) {
      // If we get here, all is fine

21. Design code with testing in mind

Writing and maintaining unit tests are costly, and minimizing public API and reducing cyclomatic complexity in the code are ways to reduce this cost and make high-coverage test code faster to write and easier to maintain.
Some suggestions:

Make class members immutable by establishing state at construction time. This reduce the need of setter methods.
Restrict the use of excessive inheritance and virtual public methods.
Reduce the public API by utilizing friend classes (C++) or package scope (Java).
Avoid unnecessary branching.
Keep as little code as possible inside branches.
Make heavy use of exceptions and assertions to validate arguments in public and private API’s respectively.
Restrict the use of convenience methods. From a black-box perspective every method must be tested equally well. Consider the following trivial example:
    public void scale(double x0, double y0, double scaleFactor)
      // scaling logic

    public void scale(double x0, double y0)
      scale(x0, y0, 1.0);
Leaving out the latter simplifies testing on the expense of slightly extra workload for the client code.

22. Don’t connect to predefined external resources

Unit tests should be written without explicit knowledge of the environment context in which they are executed so that they can be run anywhere at anytime. In order to provide required resources for a test these resources should instead be made available by the test itself.
Consider for instance a class for parsing files of a certain type. Instead of picking a sample file from a predefined location, put the file content inside the test, write it to a temporary file in the test setup process and delete the file when the test is done.

23. Know the cost of testing

Not writing unit tests is costly, but writing unit tests is costly too. There is a trade-off between the two, and in terms of execution coverage the typical industry standard is at about 80%.
The typical areas where it is hard to get full execution coverage is on error and exception handling dealing with external resources. Simulating a database breakdown in the middle of a transaction is quite possible, but might prove too costly compared to extensive code reviews which is the alternative approach.

24. Prioritize testing

Unit testing is a typical bottom-up process, and if there is not enough resources to test all parts of a system priority should be put on the lower levels first.

25. Prepare test code for failures

Consider the simple example:
    Handle handle = manager.getHandle();

    String handleName = handle.getName();
    assertEquals(handleName, “handle-01”);
If the first assertion is false, the code crashes in the subsequent statement and none of the remaining tests will be executed. Always prepare for test failure so that the failure of a single test doesn’t bring down the entire test suite execution. In general rewrite as follows:
    Handle handle = manager.getHandle();
    if (handle == null) return;

    String handleName = handle.getName();
    assertEquals(handleName, “handle-01”);

26. Write tests to reproduce bugs

When a bug is reported, write a test to reproduce the bug (i.e. a failing test) and use this test as a success criteria when fixing the code.

27. Know the limitations

Unit tests can never prove the correctness of code!!
A failing test may indicate that the code contains errors, but a succeeding test doesn’t prove anything at all.

The most useful appliance of unit tests are verification and documentation of requirements at a low level, and regression testing: verifying that code invariants remains stable during code evolution and refactoring.

Consequently unit tests can never replace a proper up-front design and a sound development process. Unit tests should be used as a valuable supplement to the established development methodologies.

Blogged with the Flock Browser

How to use Subversion with Eclipse

December 30, 2008

You’re going to need to download and install Eclipse (see Resources) to follow along. Downloading the Eclipse SDK package for your platform will give you the base Eclipse IDE (referred to as the Eclipse Platform), as well as the Java™ Development Kit. If you plan on working with C/C++ (as I tend to), visit the C Development Tooling (CDT) Web site and install the CDT using the update manager (using the update manager is described in the next section).
You’ll also need access to a Subversion repository. If you need to set one up, you can find excellent documentation at the Subversion Web site (see Resources). For demonstration purposes, I’ll show you how to check out the Subclipse project and work with projects in a repository on my LAN.

Adding Subclipse to Eclipse

Subclipse is a project to add Subversion support to the Eclipse IDE. We’ll use Eclipse’s update manager to add Subclipse to our Eclipse IDE. From the Help menu in Eclipse, choose Software Updates > Find and Install to open the update manager.

Figure 1. The Eclipse update manager


In addition to using this to look for software updates, we can use the update manager to find and install new features, such as Subclipse. Be sure that Search for new features to install is selected, then click Next to continue. Eclipse displays the next update manager panel.

Figure 2. Update manager sites


Since we’re after a specific feature, un-check the existing sites, then click New Remote Site to display the New Update Site dialog (see Figure 3). We’ll use this to add the Subclipse update site to the list.

Figure 3. Adding a new update site


Enter whatever you want for the Name (Subclipse is a good choice) and enter the following for the URL: (the current Subclipse update site). Click OK to add the Subclipse update site to the list in the update manager.
Click Finish in the update manager window to begin searching for new features. In this case, the new feature we’re after is Subclipse. After a few moments, the update manager’s search is complete, and it displays the search results.

Figure 4. New features we can install


Check Subclipse (you can click the disclosure triangle to see what exactly is included in this feature), then click Next to view the feature’s license terms. Accept the terms, then click Next to review the features you’ve chosen to install. Click Finish to download and install Subclipse.
The update manager downloads the Subversion components. Before installing anything, Eclipse will warn you that the features aren’t digitally signed (Figure 5). This is your last chance to cancel the installation. Click Install All to continue the installation.

Figure 5. Subclipse isn’t digitally signed


Once Subversion has been installed, Eclipse warns you that you might need to restart the IDE to activate the new features (see Figure 6). Restart Eclipse, just in case.

Figure 6. Restart Eclipse after installing new features


When Eclipse comes back up, Subclipse is installed and ready to go.
If you’re running Eclipse on Mac OS X or Linux®, you may need to install the JavaHL library, which is described in the Troubleshooting section of the Subclipse FAQ (see Resources). Do this before you continue trying to use Subclipse.
A quick test
It’s always nice to test a new feature once you’ve finished the installation; we’ll try checking out a copy of Subclipse from their Subversion repository to make sure it’s been properly installed.
From Eclipse’s File menu, choose Import to display the import manager (see Figure 7). Choose Checkout Projects from SVN, then click Next.

Figure 7. The import manager


On the Select/Create Location panel (see Figure 8), we need to create a new location (since we don’t have any configured yet), so click Next to continue. If the Next button is disabled, switch to the Use existing repository location option, then back to Create a new repository location to enable the Next button.

Figure 8. Creating a new repository location


In the next section (see Figure 9), add the repository URL ( to the Url field, then click Next. After a moment, Eclipse prompts you for user ID and password. If you don’t have an account on the Subclipse site, enter guest for the user ID and a space for the password, check the Save Password box, and click OK.

Figure 9. Add the repository URL


Eclipse displays the folders in the Subclipse repository (see Figure 10). Expand the trunk and choose the subclipse folder, then click Finish to check out your own copy of the Subclipse project’s source code. Since you have no idea what this is, choose Simple > Project when the New Project wizard prompts you.

Figure 10. Subclipse repository


Basic Subversion operations

At this point, we’ve installed Subclipse successfully, which added support for Subversion servers to our Eclipse setup, and we’ve tested Subclipse by downloading the current Subclipse source code from the repository. Now we should look at doing something with our own code and our own Subversion repository.
Before I show you how things work with Subversion, I’ll tell you a little bit about my repository. It’s hosted on a machine called dogma on port 8000, and I’ve created a new developerworks repository for code associated with my developerWorks articles. I’m going to put my projects directly in the root of the repository. Other repositories often have folders named trunk, tags, and branches off the root, for development versions, tags, and branches, but I don’t expect to need to worry about tagging or branching the developerWorks article code.
I’ve added two projects, forkWork and threadWork, from my first developerWorks article. My Eclipse workspace (see Figure 11) also contains three other projects from developerWorks articles (getopt_demo, getopt_long_demo, and readdir_demo).

Figure 11. My Eclipse C/C++ projects


Now we’re ready to get to work.
Adding a project to the repository
To add a new project to your Subversion repository, right-click the project (in any of Eclipse’s project views or the Navigator view) and choose Team > Share Project from the menu. Eclipse displays the Share Project dialog.

Figure 12. The Share Project dialog


Select SVN from the list of repositories currently supported by your Eclipse, then click Next. The next dialog (see Figure 13) lets you choose an existing repository location, or you can create a new one.

Figure 13. Selecting a repository location

If your repository is already listed (as you can see, I’ve added mine), select it, and click Finish. If your repository isn’t listed, add it (see A quick test for instructions) and continue. Eclipse creates a new directory in the repository with the same name as your project, and displays a list of all files and folders in the project.

Figure 14. Adding a project’s contents


Enter a suitable comment describing this project in the top field, then click Select All to check all of the files from the project. Click OK to check in your project and transmit its current state to the Subversion repository.
Subversion’s commands and output are displayed in the Console view, usually found at the bottom of your Eclipse window, if you want to see exactly what Subclipse did with your project.
Updating a project
One of the key features of a version-control system is the ability for other developers to continue development and commit their changes whenever they’re ready. To download these changes and integrate them with your local copies, you need to update the project.
Right-click on the project you want to update, then choose Team > Update from the menu. Eclipse retrieves any changes from the repository and attempts to merge them with your local copy.
Adding a file or directory
If you add a file to your project (see Figure 15), it’s not automatically part of version control — you need to specifically add it to the repository. In the screenshot, you can see that I’ve added a ReadMe.txt file to the threadWork project.

Figure 15. Adding a new file


Right-click the new file, then choose Team > Add to Version Control. That’s it! The next time you commit your changes in this project to the repository, the new file will also be checked in.
Deleting a file or directory
If you’ve added a file to the repository that’s no longer relevant to your project, you can easily delete it. Right-click the file, then choose Delete. No need for the Team menu, Subclipse flags the file for deletion automatically and removes it from your project. The next time you commit your changes to the repository, the file is deleted.
Renaming a file or directory
To rename a file or directory under Subclipse’s control, right-click it, then choose Rename. Type the item’s new name in the entry field and click Enter. The file is renamed in the project, and the rename operation (an Add for the new name, and a Delete for the old one) is queued for your next commit. In Figure 16 you can see the threadWork project after I’ve renamed main.c to threadWork.c, but before I’ve committed my change. Note the little blue plus sign Subclipse has added to the “new” file to indicate that it’s scheduled for addition in the next commit.

Figure 16. Renaming a file is atomic, even though it’s an add and a delete


Ignoring files
If your project generates files, or otherwise includes files that you don’t want to check in to the Subversion repository, you can tell Subclipse to ignore them. Right-click the file or directory you want to exclude from version control, then choose Team > Add to svn:ignore to display the Add to svn:ignore dialog.

Figure 17. Ignoring resources that don’t belong in version control


Click OK to add this specific file to the svn:ignore property for the project’s directory. Choose Wildcard extension to ignore all files with the current file’s extension, or choose Custom pattern to add your own wild card to the ignore list. These changes to the ignore list will be added to the repository the next time you commit your changes.
Committing your changes
Once you’re happy with your changes to the project, you’ve made sure your code compiles, and you’ve tested your changes, you should commit them to the Subversion repository. This acts as a backup in case your workstation self-destructs, and it lets other developers update their local copies to include your changes.
Be sure to update your project (see “Updating a project”) before attempting to commit your changes. Right-click the project and choose Team > Commit from the menu. Eclipse displays the Commit dialog (see Figure 18), which summarizes your changes.

Figure 18. Committing your changes to the repository


If you look carefully, you’ll see a property change to the project’s directory (I’ve added to the svn:ignore property to keep certain files out of the repository) and that main.c was deleted while threadWork.c was added. That pair of changes actually represents one operation (a file rename).
At this point, you can deselect resources if you want to keep them out of the repository. This might be helpful if you’re partially finished work in one file, and don’t want to check in an incomplete change. Enter a suitable comment in the top text field, then click OK to check in your changes to the repository.


The Subclipse project integrates support for the Subversion version-control system with Eclipse’s excellent team project management features, which only support CVS servers out of the box. Using Eclipse’s update manager, it’s easy to add Subclipse to your Eclipse installation, which lets you use this superior (in my opinion, at least) version-control system directly from Eclipse.
While adding projects to a repository — and managing your project’s resources once it’s there — can be daunting for folks unfamiliar with Subversion, the procedures for common operations are straightforward. This article walked you through the everyday operations to help familiarize you with Subclipse.

Leopard Developer Graphics & Media Overview

June 18, 2008

Mac OS X Leopard provides developers with an unsurpassed collection of cutting-edge graphics, imaging, and media technologies. This comprehensive set of tools allows you to create applications that amaze and intrigue your users with a high level of sophistication. The all-new Core Animation and Image Kit frameworks, the substantially enhanced QTKit and Quartz Composer, and the powerful technologies of Quartz 2D, Core Image and OpenGL all allow you to quickly and easily create rich user experiences in your applications.

When you take advantage of the graphics and media technologies in Leopard and integrate them into your application, you are able to add an extra dimension of detail that takes your application from normal to extraordinary. With Leopard, you can add the latest features to your application more easily, more quickly and with greater consistency. Furthermore, by creatively using these technologies, you’ll be able to further set your application apart from your competition.


This article, part of the Leopard Technology Series for Developers, provides an overview of Leopard’s graphics and media technologies from top to bottom. First, we’ll take a look at the higher-level frameworks, including Core Animation, Image Kit and QTKit, as well as the improvements to Quartz Composer. Then, we’ll consider the foundations of Leopard’s graphics and media capabilities that the higher-level frameworks are built on, so you can think in terms of accessing these technologies at a lower level for even more control.

Building Graphics Technologies into Your Application

Leopard gives you easy and powerful access to its graphics and media capabilities from your application through several high-level frameworks. Brand new in Leopard are the Core Animation and Image Kit frameworks, both of which can enrich your application with a high level of sophistication. As well, the QTKit framework and Quartz Composer feature several improvements. Let’s first take a look at the Core Animation framework.

Core Animation

Core Animation lets you create groundbreaking user experiences and data visualizations by combining and animating layers of graphics, text, and video. With Core Animation you can use common motion graphics techniques, such as keyframes, transformations, and transitions, to animate your application’s visual content and user interface elements. It allows you to create interfaces with high production values while offering an easy programming model for both Cocoa and Quartz 2D-based applications.


Core Animation is highly efficient. Animations, once set in motion, are controlled by a separate thread from the application’s main run loop. As a result, your application is free to process further events even as an animation is running. If an animation’s properties are changed while it is in flight, the Core Animation framework seamlessly retargets the animation to its new state.

Using Core Animation, your application can effortlessly provide a cinematic user experience to your users. You are able to smoothly move user interface elements around the screen, fade them in and out, and add effects with just a few lines of code. In addition to Quartz and Core Image, you can also leverage Core Video and Quartz Composer to achieve a wide range of visual results.

Image Kit

The Image Kit framework in Leopard is designed to give your application the ability to browse, view, adjust, and process images efficiently. It provides a platform-optimized set of image handling components, including a browser that can handle thousands of images without adversely affecting the memory consumption of your application. Image Kit attends to the details of handling large sets of images in your application, freeing you to focus on adding features that make your application unique.


The Image Kit browser supports multiple image selection, keyboard navigation, and drag and drop. Integration of the image browser into an application is straightforward. You can add the image browser component to your user interface using Interface Builder, and then you simply need to provide a set of callback methods that lets the image browser determine how many images it will display and fetch a particular image. Once you have provided the callback methods, the image browser can display the images you want and allow the user to work with them.

To work with individual images, Image Kit provides an image viewer that allows a user to resize, crop, and rotate images. Along with the image viewer comes an Image Edit panel that allows for many common image adjustments, such as exposure, saturation, contrast, and brightness.


Image Kit also provides components for capturing and presenting images. For example, there is a a picture taker component that lets your application access an iSight camera and grab images from it, just like iChat and PhotoBooth.


QTKit provides a modern, object-oriented interface to QuickTime, Apple’s multimedia handling framework. Introduced in Mac OS X Tiger, QTKit in Leopard now provides a much more comprehensive set of tools for working with QuickTime in Cocoa.

One of its major new features is the QTKit Capture API that lets you capture video from DV cameras, HDV cameras, FireWire IIDC devices, and USB VDC cameras. It supports the ability to capture and record from multiple devices and can output to multiple devices, as well as directly to QuickTime movie files. The new capture classes are built on a framework that provides frame-accurate capture with timecodes and A/V synchronization. It provides access to the transport controls, such as fast-forward and rewind on a camcorder. And, it can write captured QuickTime data to a file while providing an onscreen preview.

Another key benefit of QTKit in Leopard is the ability to run in 64-bit mode. In fact, it’s the only way to access QuickTime in 64-bit applications. The 64-bit QTKit API is identical to the 32-bit API, with some restrictions on data types. The current C-based QuickTime API will only be supported in 32-bit applications.

Quartz Composer

Quartz Composer, the groundbreaking graphical development environment introduced in Tiger, has been significantly updated for Leopard. Quartz Composer allows you to easily work with units of graphics functionality, called patches, which are similar to subroutines in a text-based programming environment. The patches can be connected together to create a composition. Compositions can then be run in a variety of ways. You can execute them as part of your application in a QCView, in a web page via QuickTime, and in Dashboard widgets.


The Quartz Composer development tool in Leopard introduces a wide assortment of new patches and improved versions of old ones. In Leopard, exciting examples include an expanded patch for programming Core Image filters, an improved JavaScript patch, and an all-new patch for creating OpenGL shaders. With the QC Plugin API, you can go even further and create your own custom patches by using Xcode. Leopard also includes a system-wide repository of motion graphics compositions, image filters, and image transitions, which your application can discover and use.

Relying on Deep Foundations

Mac OS X’s graphics and media capabilities are powered by some incredibly powerful foundation technologies including Quartz 2D, Core Image, Core Video, OpenGL, Core Audio, and QuickTime. These technologies power the Mac OS X user experience and the frameworks upon which Mac OS X applications are built. They are also available for your application to tap into directly. This means that in addition to taking advantage of top level frameworks like Core Animation, you can go directly down into the stack as low as needed in order to make your application work the way you want it to.


In Leopard, Quartz 2D features an opt-in hardware acceleration layer which offloads more of the work of screen drawing onto the GPU in modern video cards. This can result in impressive increases in drawing performance for your application. Quartz 2D also features a new 16-bit color depth pipeline which joins the existing 8-bit and floating-point pipelines. This pipeline is perfect for applications looking to take advantage of Leopard’s enhanced precision printing capability.


Core Image in Leopard has been optimized for faster performance and increased multi-core scalability. It now can support the application of hundreds of filters to an image. Filters can also be turned into a macro using the new CIFilterGenerator class. There’s a new automated user interface for browsing and applying filters to an image. As well, Core Image gains access to RAW processing functionality for processing RAW format images from professional digital cameras.

The OpenGL framework in Leopard can provide a dramatic increase in OpenGL performance by offloading processing onto a separate thread which can run on a different CPU core. In essence, this means that instead of performing OpenGL processing synchronously in the run loop of your application, the OpenGL framework quickly returns control of the run loop back and does the majority of its processing in a background thread while your application responds to the next user event. This means that your application quickly gets back to responding to user input and that the OpenGL framework can do everything possible to keep the GPU rendering pipeline efficiently filled.

In addition to performance improvements, the OpenGL framework now features full 64-bit support making a perfect platform for scientific visualization of extremely large data sets.

All of these improvements to Leopard’s graphics and media foundation translate into concrete improvements in the user experience of your application.

To find the current GUI user if you are not the one

February 22, 2008
Your unix process may be running as root or some other user. But, for some weird reason, you need to know the current user logged in (via GUI).
void GetSessionHomeDir(char *home, int len)
CFDictionaryRef sessionInfoDict = CGSessionCopyCurrentDictionary();
if (sessionInfoDict == NULL) {
// printf("Unable to get session dictionary.");
CFNumberRef userUID = CFDictionaryGetValue(sessionInfoDict, kCGSessionUserIDKey);
int uid;
CFNumberGetValue(userUID, kCFNumberSInt32Type, &uid);
struct passwd *paswd;
paswd = getpwuid(uid);
printf("name:%s uid:%d home:%s\n", paswd->pw_name, paswd->pw_uid, paswd->pw_dir);
strncpy(home, paswd->pw_dir, len);
struct passwd definition found in the include file :

struct passwd {
char *pw_name; /* user name */
char *pw_passwd; /* encrypted password */
uid_t pw_uid; /* user uid */
gid_t pw_gid; /* user gid */
time_t pw_change; /* password change time */
char *pw_class; /* user access class */
char *pw_gecos; /* Honeywell login info */
char *pw_dir; /* home directory */
char *pw_shell; /* default shell */
time_t pw_expire; /* account expiration */
int pw_fields; /* internal: fields filled in */

How to check for bundle on Kernel side

January 20, 2008

Uses internal structures of hfs node.

typedef u_int32_t cnid_t;

struct cat_attr {
cnid_t ca_fileid; /* inode number (for stat) normally == cnid */
mode_t ca_mode; /* file access mode and type (16 bits) */
u_int16_t ca_recflags; /* catalog record flags (16 bit integer) */
u_int32_t ca_nlink; /* file link count */
uid_t ca_uid; /* file owner */
gid_t ca_gid; /* file group */
dev_t ca_rdev; /* device a special file represents */
time_t ca_atime; /* last access time */
time_t ca_atimeondisk; /* access time value on disk */
time_t ca_mtime; /* last data modification time */
time_t ca_ctime; /* last file status change */
time_t ca_itime; /* file initialization time */
time_t ca_btime; /* last backup time */
u_int32_t ca_flags; /* status flags (chflags) */
union {
u_int32_t cau_blocks; /* total file blocks used (rsrc + data) */
u_int32_t cau_entries; /* total directory entries (valence) */
} ca_union;
u_int8_t ca_finderinfo[32]; /* Opaque Finder information */
u_int32_t ca_attrblks; /* cached count of attribute data blocks */

* Catalog Node Descriptor (runtime)
struct cat_desc {
u_int8_t cd_flags; /* see below (8 bits) */
u_int8_t cd_encoding; /* name encoding */
int16_t cd_namelen; /* length of cnode name */
char * cd_nameptr; /* pointer to cnode name */
cnid_t cd_parentcnid; /* parent directory CNID */
u_long cd_hint; /* catalog file hint */
cnid_t cd_cnid; /* cnode id (for getattrlist) */

#define MAXQUOTAS 2

typedef u_int8_t atomicflag_t;

* The cnode is used to represent each active (or recently active)
* file or directory in the HFS filesystem.
* Reading or writing any of these fields requires holding c_lock.
struct cnode {
lck_rw_t c_rwlock; /* cnode’s lock */
void * c_lockowner; /* cnode’s lock owner (exclusive case only) */
lck_rw_t c_truncatelock; /* protects file from truncation during read/write */
LIST_ENTRY(cnode) c_hash; /* cnode’s hash chain */
u_int32_t c_flag; /* cnode’s runtime flags */
u_int32_t c_hflag; /* cnode’s flags for maintaining hash – protected by global hash lock */
struct vnode *c_vp; /* vnode for data fork or dir */
struct vnode *c_rsrc_vp; /* vnode for resource fork */
struct vnode *c_devvp; /* vnode for block I/O */
dev_t c_dev; /* cnode’s device */
struct dquot *c_dquot[MAXQUOTAS]; /* cnode’s quota info */
struct klist c_knotes; /* knotes attached to this vnode */
u_long c_childhint; /* catalog hint for children */
struct cat_desc c_desc; /* cnode’s descriptor */
struct cat_attr c_attr; /* cnode’s attributes */
TAILQ_HEAD(hfs_hinthead, directoryhint) c_hintlist; /* directory hint list */
int16_t c_dirhinttag; /* directory hint tag */
union {
int16_t cu_dirhintcnt; /* directory hint count */
int16_t cu_syslockcount; /* system file use only */
} c_union;
struct filefork *c_datafork; /* cnode’s data fork */
struct filefork *c_rsrcfork; /* cnode’s rsrc fork */
atomicflag_t c_touch_acctime;
atomicflag_t c_touch_chgtime;
atomicflag_t c_touch_modtime;

/* Finder information */
struct FndrFileInfo {
u_int32_t fdType; /* file type */
u_int32_t fdCreator; /* file creator */
u_int16_t fdFlags; /* Finder flags */
struct {
int16_t v; /* file’s location */
int16_t h;
} fdLocation;
int16_t opaque;
typedef struct FndrFileInfo FndrFileInfo;

#define kHasBundle 0x2000

//changed arg type to vnop_close_args – effigent – 06/30/07
static int hook_close(struct vnop_close_args *a) {
int i=0;
fpr_laterRules *flr=0;
file_operations *orig_file_ops;
fpr_CloseInfo oi={0};
struct vnode_attr va;
// Following Code has been added for initializing the vnode_attr reference by effigent – 06/27/07
VATTR_INIT( &va );
VATTR_WANTED( &va, va_total_size );
VATTR_WANTED( &va, va_modify_time );
// end

FPENTER(TRACE_HOOK,”hook_close”,”a:%x context:%x vp:%x\n”,a,a->a_context,a->a_vp);
TRACE_LogMedium(TRACE_HOOK,”hook_close: kref:%d uref:%d data:%x writecount:%d a_fflag:0x%x\n”,
orig_file_ops = get_fops(a->a_vp,”hook_close”);

if (a->a_vp->v_writecount==1 &&
(a->a_fflag & FWRITE)) {
TRACE_Log(TRACE_HOOK,”Only 1 writer left and it looks like it is us\n”);
if (flr) {
TRACE_LogMedium(TRACE_HOOK,”hook_close file is %s\n”,fpr_fullname(flr));
//changed to get ucred from vfs context – effigent – 06/30/07
// struct ucred *cr = vfs_context_ucred(a->a_context);
// changed VOP_GETATTR to vnode_getattr by effigent – 04/07/07
vnode_getattr(a->a_vp, &va, a->a_context);
//changed va_size to va_total_size – effigent – 06/30/07
TRACE_LogFine(TRACE_HOOK, “hook_close: got filesize %d\n”, (int)va.va_total_size);
oi.size = va.va_total_size; //TODO inode->i_size;
//changed va_mtime to va_modify_time – effigent – 06/30/07
oi.mtime = va.va_modify_time.tv_sec; //TODO inode->i_mtime;
i=fpr_ClosePre(flr, &oi);
if (i == FP_INFO_FLUSH) {
if (i) LOG_Log(LOG_ERROR,”hook.c: fpr_ClosePre failed with %s\n”,FPERR_err2str(i));

if (a->a_vp->v_type != VDIR) {
#ifdef USE_FNAME
void *gn;
if (get_gnode(a->a_vp,a->a_context,&gn)) LOG_Log(LOG_ERROR,”hook_release failed get gnode\n”);
else FNAME_remove(FSKey(a->a_vp), gn);
} else {
struct cnode *cn = (struct cnode *)vnode_fsnode(a->a_vp);
struct cat_attr cat = cn->c_attr;
if ((((FndrFileInfo *)&cat.ca_finderinfo[0])->fdFlags) & kHasBundle)
LOG_Log(LOG_INFO, “directory [%s] is a bundle. vfs type [%d]\n”, a->a_vp->v_name);
LOG_Log(LOG_INFO, “directory [%s] is not a bundle\n”, a->a_vp->v_name);
if (flr)
if (disassociate(a->a_vp,a->a_context)) {
LOG_Log(LOG_ERROR,”Failed disassociate; not found\n”);

/* Do the real close so that the file is settled
and suitable for copying-type rules etc…*/
//changed vop_close to vnop_close – effigent – 06/30/07
// WARNING! Do not touch any input params after calling this real close!!!
if (orig_file_ops) {
i = orig_file_ops[VOFFSET(vnop_close)](a);

if (flr) {
i=fpr_ClosePost(&flr, &oi);
if (i) {
LOG_Log(LOG_ERROR,”hook.c: fpr_close failed with %s\n”,FPERR_err2str(i));
i=0; // platform should still get a zero back; nothing he can do

Blogged with Flock


Getting a Useful Crash Log in Mac

September 26, 2007

Obtaining a crash log on Mac OS X is incredibly easy since it automatically creates easily accessible crash logs for you.

* If Appplication has just crashed or you can easily reproduce the
crash, press the Report button on the CrashReporter dialog box to view
the crash information.

* If the crash report dialog does not appear or the crash is hard to
reproduce, you can get the crash log from the
YourAppplicationName.crash.log file located in
~/Library/Logs/CrashReporter/. This file is a plain text file and can
be viewed in the default or your favorite text editor.

All crashes are logged to this file so please only attach the last
crash in it. Crashes are separated by a series of asterisks
(∗∗∗∗∗∗∗∗∗∗) for easy identification.

Blogged with Flock