J2EE Server API problems and bugs

Overview

This document lists all known problems and bugs of the J2EE Server API. It will serve as a starting point for the future API fixes and possible redesigns.

Issue 1: J2eeModuleProvider should serve only as J2eeModule provider

J2eeModuleProvider does much more than what it should. The original purpose of J2eeModuleProvider is to provide J2eeModules. At the moment it provides also configuration support, verifier support, etc. This class became kind of messy and therefore we should try to clean it up.

One big issue is that J2eeModuleProvider makes the InstanceProperties public. I don't think this should be ever be public. As a side effect any code can modify the server properties and broke the server registry. Another issue is that code using the InstanceProperties usually depends on specific properties (acessed by name) that are not guaranteed to exist for the serverplugin.

TODO: elaborate it a bit more

Issue 2: J2eeModuleProvider must be implemented by the project.

It would be nice if this were de-coupled from the project such that a standalone deploy task could be developed. (Please refer to the attachment to issue 62228 for an example). A standalone deploy has the following advantages:

• It's more powerful in that it gives the ant script full control over what gets deployed. Consider the use case of more than one war per project. This may sound theoretical, but it's not, in fact it is something that we are doing today. To give you some background we have an ant project with a build script setup such that it builds from a single source a war for different target environments - dev, test, and production. This project is geared towards professional services deployments of an enterprise software product. In a typical deployment, there will be a dev/test environment with a different set of resources than in production. The wars produced differ in some configuration and the database repository to which they refer. The ant build has a "current-target" property which controls the war which is produced when the project is built and the war which is deployed to Netbeans appserver when the project is run.

• A second use case is that of launching multiple WARS simultaneously. I've worked at two places where their product was decomposed into several wars. (Admittedly I don't know how wise of a decision this was, but the architects felt that it would be a good way to make the product more modular.) Nevertheless, if I wanted to build an ant script that could launch the whole product, I could have several calls to standaloneDeploy, passing in the war location.

• It's more re-usable since it can be used in any project, not just a project which implements J2eeModuleProvider. This is nice for people who are implementing their own project types (it's one less thing that needs to be implemented).

That said, even with this change, there's no reason the nbdeploy task couldn't behave as it does today. That is, the nbdeploy task could still fetch the J2eeModuleProvider from the project and pass it to Deploy. The difference would be that from Deploy on down, it would use the J2eeModuleProvider instance passed to it rather than fetching it from the project.

Issue 3: ServerInstance, ServerRegistry, ServerString, and ProgressUI are non public.

I can probably think of more use-cases for these to be public, but the particular problem I had to solve was that of automatically undeploying and shutting down the server. Whenever the user does a "Clean Project" the war needs to be undeployed or they get a bunch of "Unable to delete..." error messages. In addition, when performing a deploy/redeploy you will eventually run out of memory and need to restart the server. It is simply too easy for a class loaded in a parent class loader to hold onto a reference to a class in your war and so memory leaks on redeploy are nearly unavoidable.

I've solved both these problems by writing a ShutdownServer ant task that undeploys all wars on the given server and shuts down the server. This is called at the start of every build. Shutting down and restarting Tomcat takes no more than a second and is definitely worth it from the standpoint of the user.

In order to implement ShutdownServer, I had to hack the thread-local class loader and use reflection to invoke the APIs I needed. It would be nice if these were public.

Issue 4: InstanceProperties should provide factory method with initial properties parameter

Issue 5: There should be API for tailing the server process streams and logs

Every serverplugin must solve ui presentation of server logs. Even without the ui process streams has to be consumed otherwise deadlock threatens. Almost every serverplugin solves it either custom way or by code copy pasting. Experience shows that almost every such implementation contains a bug or deadlock possibility. The new support api should solve this in unified way.

Issue #:...

description of the issue