In previous installments of this series I've concentrated on the -javaagent parameter for agent access. In this installment I'll introduce another way to access the inner workings of a JVM via an undercover agent; the -agentpath and -agentlib parameters.

As prevously presented, agent access was obtained via a Java class that was loaded early in the JVM startup sequence. This class had access to many areas of the JVM, but not all. By using an 'undercover' agent, access to much more fine-grained behavior can be obtained - but at a price.

In part 1 of this series, I gave an overview of Java agents and bytecode manipulation and provided a simple agent that adds a System.out.println() message to a method. In part 2, I provided an agent that eliminates calls to log4j log methods in designated packages and log levels. In part 3, I'll show how to augment code to help analyze stack traces by introducing an agent that keeps track of how many instrumented methods are called by each thread.

In my previous blog entry Not-So-Secret Java Agents, Part 1, I gave an introduction to the concepts behind Java agents and provided a simple example that dynamically added a System.out.println() message to a method. In this installment I'll amp up the complexity by implementing an agent that dynamically and selectively eliminates log4j calls.

A little-known option to recent Java VMs holds a fair amount of mystery and quite a lot of power. That option is 'javaagent', and it holds the key to monitoring and profiling JVMs and being able to dynamically modify Java classes as they're being loaded.

Many of you might find this to be a funny question but almost daily I am asked, “what would you suggest as a platform for the development of XYZ Application --- .Net or Java?” or better yet “which one is better, .Net or Java?” Quite honestly, this is a loaded question and cannot be answered without significant analysis into both technical factors and a comprehensive review of the overall organization structure, existing investment, and review of why and what business problems XYZ application is being built to solve.   

Preface:

One of the traits of a well-designed application is the efficient handling of crosscutting concerns.  By efficient I mean the application architecture/framework to handle bulk of the crosscutting concerns (such as security, transaction management, logging etc.) and let the individual services concentrate on the business logic. In this blog entry, I discuss one such cross cutting concern and a way to handle it at the framework level.

Most Java developers have never needed to interact with the DNS directly; the most well-known job of DNS, that of resolving hostnames to IP addresses, is performed automatically every time a network operation involving a hostname is performed. Similarly, finding a server that is willing to accept email for a particular email address is performed transparently using DNS. How would a Java developer get access to such arcane, low-level information to do something as simple as validate that a particular email address has a server somewhere in the world willing to accept email for it? It all comes down to hierarchy.

It is very common to put a WebLogic Portal cluster behind a web server or load balancer.  Most implementations I have seen to date either use an F5, Apache Web Server, or a combination of the two to serve up the portal content.  If you are also trying to access the Portal Admin Console through the web server you most likely experienced some sort of session affinity issue.  I realize most IT shops will just access the Portal Admin Console through a specific combination of managed host and port.  However, if you have any desire to access the Portal Admin Console through a web server or load balancer (especially for CMS functions or just a friendly url), here is why the session affinity issue is presenting itself.

The Portal Admin Console was developed to use a non standard Cookie Name.  By default, weblogic applications will use the JSESSIONID Cookie Name to maintain the user session.  However, the WebLogic Portal Admin Console uses a differe

Most people are familiar with authentication, the process of proving who you are (usually with a username and password). Access control sounds very similar, but there is a subtle difference: access control refers to the permissions assigned to an authenticated person or entity. In other words, access control first requires successful authentication, and then it can use the identity of the logged-in user to determine to which resources he has access.

While unstaffed the last few weeks, a manager tapped me to help put together a BlackBerry proof of concep for one of our clients.  I have had experience working on a BlackBerry project from a previous employer's project, however I did not have hands on experience programming the device myself.  I was looking forward to this as I had been wanting to do some dabbling with mobile devices, I just had not had the time.