Glassfish debug error

Starting Glassfish with --debug option fails, producing an error similar to below;

Waiting for domain1 to start .Error starting domain domain1.
The server exited prematurely with exit code 134.
Before it died, it produced the following output:

FATAL ERROR in native method: JDWP No transports initialized, jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197)
ERROR: transport error 202: connect failed: Connection refused
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [../../../src/share/back/debugInit.c:750]

Command start-domain failed.

The problem was identified to be the jpda settings in the domain.xml file. These were set to server=n,suspend=y instead of server=y,suspend=n. Setting the server directive to "yes" and the suspend directive fixed the problem.

In the end, the java debug options look like this;

<java-config classpath-suffix="" debug-options="-agentlib:jdwp=transport=dt_socket,address=9090,server=y,suspend=n" java-home="/path/to/java/home" system-classpath="">


Configuring Perf4J using Log4J Properties file.

Every application needs to log performance benchmarks in order to identify bottlenecks and show improvements with each deployment iteration. Talking vaguely about where performance is drained are or perceived improvements since a particular deployment surrenders the development effort to subjectivity.

When I decided that my efforts to improve performance in an application I was responsible for cannot be left to the vagaries of uninformed perceptions, I decided to deploy a comprehensive monitoring tool. But I also need something that was fit for purpose and would not impose a heavy burden on existing architecture.

I did some research before hand, and I recommend this article (Java run-time monitoring, Part 1: Run-time performance and availability monitoring for Java systems) from IBM DeveloperWorks for a good fundamental understanding of performance monitoring concepts.

For my implementation, I opted for Perf4J, as it presented me with the least amount of impact on existing software architecture and imposed no additional requirements before deployment. I already had Log4J as my primary logging framework.

The documentation describes how to configure logging Perf4J on Log4J's XML config file, which was not an option for me since I already had an elaborate properties file and I was not willing to migrate to the XML config file. This is where I struggle for a while, but I eventually found the solution on configuring the log4j properties file for Perf4J.

The solution is to configure logging threads on the properties file, one of them being the logger you want assigned to Perf4J (see line 6 of log4j.properties listing). On the Java code, use the Log4JStopWatch instance and provide it with the thread logger defined in the properties file (see line 10 of MyPerformanceMonitor.java listing).

Apache Axis Basic Access Authentication

The Apache Axis2 Web Services is very useful when in need of more control of your web service/client. As I found out sometime ago when I need to access a password protected web service. The standard mechanism for protecting SOAP web service is to required the username/password pair on the SOAPHeader section of the SOAPEnvelope. However, there are cases where the web service is protected at the Transport Layer - in my particular problem this was HTTPs and it needed Basic Access Authentication. Fortunately, Apache Axis is an extensible framework in that it caters for all kinds of eventualities and provides means and ways to address even the most un-anticipated of chalanges. To solve my predicament I only had to had the code below:

org.apache.axis.client.Call _call = ... _call.setProperty(org.apache.axis.client.Call.USERNAME_PROPERTY, "username"); _call.setProperty(org.apache.axis.client.Call.PASSWORD_PROPERTY, "password");

And there is just that simple. I have many more tips and tricks to share on Apache Axis.

The Return...

It has been ages since I last updated this blog - the last post was 3 years ago. I now intend to keep this updated as much as I can, and do I have material to share.

EJB 3 looking good

For a bean developer
The next specification for Enterprise Java Beans is now available, albeit an early draft. Though its objective is to simplify EJB model from a bean developer perspective, it has only managed to be implicit in its intricacies and requirements.

Enterprise business processes are complex by their definition. Software development is a complicated and trying exercise. With this knowledge, I am always suspicious of simplification by abstraction. This always leads to new developers not having a clue why certain things are done they are. This how the EJB developer community got into trouble, by not knowing the underlying principles informing the EJB model. With this new level of abstraction (my bad: simplification), a new crop of developers will enter the market without a clear understanding of objects remote/local and ensuing best practices.

Dependency Injection

I see the movement for dependency injection in the J2EE component architecture is gaining steam. I have read, over the past week, about how Aspect-orientated programming enables this. I have been blown away by ease and ingenious manner in which Java2 1.5 annotations address this problem. It is my believe that component dependency injection and configuration will be done with annotations in the J2EE 1.5 spec.

EJB3, continued...

More nois e about the new EJB3 spec. I still have to read through it and form an opinion about its state. Right now I'm just an observer.

FUD for BEA?

Could BE A be chocking from the pressure exerted by the likes of IBM, Oracle (and of course, the VC funded open-source JBoss) in the J2EE application server space. Recent industry reports seem to suggest they are losing market share.

Call for comment on EJB 3 call backs.

A call for comments on the possible call back mechanism for the new simpler EJB3 spec.
Personally, I have no problem with the current Interface-defined (current 2.x spec) call backs. I always keep a few abstract base classes providing the implementation of the call-back methods. I have empty implementations, event-based implementations with notification capabilities to subscribers (I use this for clean purposes with anonymous classes).
As for my comment: I would like a number of abstract implementations of the call-back interfaces. So, I suggent a combination of option 2 and 3.