J2EEServerAPIProblems

J2EE Server API problems and bugs

Contents


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

There is an enhancement issue http://www.netbeans.org/issues/show_bug.cgi?id=120379. The main trouble is that when new InstanceProperties instance is being created there is no possibility to pass initial set of properties (except the required properties). This leads to two main issues. The first one - when the instance is being created it tries to get disconnected deployment manager but required information are not yet available (almost every serverplugin introduce some ugly solution for this). The second one - when the instance is being created it fires the message notifying about the server addition, leading to node addition and refresh of its state. If the timing is unlucky refresh is invoked before other properties (required for the state check) are set.
Implemented - use it in servers.

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 6: Problem of J2eePlatform:getClasspathEntries for different tools

Follow link for more details.

Issue 7: Missing 'capabilities' API

Excerpt from email from Petr Hejl:

The J2eeModule defines all the basic constants for server tools. But this granularity is not enough even for the current usage. For example the most specific version related method J2eePlatform.getSupportedSpecVersions(module) - if it will return JAVA_EE_5, it is unclear what is actually supported. Can the project use web service ref and ejb ref annotations? Perhaps it can - however we should return nothing for Tomcat as it does not allow such things. On the other hand we want to support Tomcat.

Similar case is the default persistence provider - Tomcat does not have any. This is the reason for ugly hack in isToolSupported method (search for String "defaultPersistenceProviderJavaEE5"). The whole isToolSupported seems to be poor API to me.

The last thing I know about is optional DIGEST_AUTHENTICATION http://www.netbeans.org/issues/show_bug.cgi?id=79943.

The spec version does not seem to be enough - as another example, there was a lengthy discussion on the support of EE5 enterprise application with JBoss 4 (technically it is not EE5 server, but users tend to think so because it supports EJB3).

Proposal for issue 7.


Issue #:...

description of the issue

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo