DirectoryDeploymentOfEnterpriseApplications

Directory Deployment of Enterprise Application to GlassFish

Contents



Description of Problem

Building any complex application in NetBeans is easy, if you know how to structure your developement environment to leverage the keybindings which make it simple. The most critical of these bindings is F6 (Run Main Project). This single keystroke does so much work for a developer, that using any other is almost always counter productive.

The use of F6 while doing development of enterprise applications triggers a lot of work packaging and unpackaging of the application and its subprojects to do the deployment. The j2eeserver module has had directory deployment support for all module types that would allow these steps to be optimized out of the development process. The bugs that are in the code haven't been worked out, since the SJSAS/GF plugin has never "said" that it was capable of supporting directory deployment for EAR projects. So, I decided to investigate the process end-to-end and integrate changes that would allow module owners to make changes that would improve the developer experience.

Some design decisions have been made since the initial implementation of the directory deployment support in j2eeserver that have complicated this end-to-end testing. Other issues surfaced while triggering code paths that have not been exercised since their initial implementation. In both cases I have elected to implement the smallest changes that allow the current infrastructure to be enabled for all J2EE/Java EE module types including EAR projects.

The user view

There really isn't a user view for this feature. The user doesn't change what they currently need to do to develop and test J2EE/Java EE applications in NetBeans.

Users create enterprise applications that incorporate J2EE/Java EE submodules/sub-projects. As the user makes changes to their application's code, they run the enterprise application and verify that their changes are having the desired effect. The user doesn't need to explicitly "manage" building the subprojects, assembling the projects or deploying the assembled application today and that will not change when this feature is implemented. The user will develop their app and the IDE will manage those details. Once this feature is implemented, the deployment mechanism will change, but the result from a user's perspective will remain the same as it is today.


So, why do this change at all?

These changes do not create a better user experience, by themselves, but they enable improvements to be based on this functionality. Many simple changes to the build processing can significantly improve the development experience for J2EE/Java EE developers. Those changes are dependent on this feature being enabled.

here is a quick list of changes that can be treated as bugs that will improve the development experience for J2EE/Java EE developers:

  1. remove unnecessary packaging from Run Project/Deploy Project/Debug Project/Profile Project.
  2. remove unnecessary unpacking of the complete apps for a single file change
  3. remove unnecessary packaging of web app subprojects when they are part of an ear.
  4. eliminate bugs in the current implementations of j2eeserver api's that may not have surfaced

What about the complex cases?

These changes do not resolve some of the many sticky issues that will need to be resolved to make NetBeans really deliver stunning experience enhancements for our user base. They aren't meant to. The coordination for such sweeping changes need to come from all the J2EE/Java EE module owners. Since none of the owners have the resources to resolve this larger problem, it is clear that those changes will need to wait.

These changes will allow the various module owners to be able to make progress on experience improvements individually and collectively, as their schedules permit.


The changes

Per J2EE/Java EE Project Module

The decision to have two build directories has proven to be unnecessary. We can unify the two build directories back to a single directory. The most effective way to make this change safely is to limit the number of changes to the project modules. The smallest change necessary is to to replace the value of the "build directory for inclusion in an ear" property with the value of the "build directory fro stand-alone deployment" property.

Property Name old value new value
AppClientProjectProperties.BUILD_EAR_CLASSES_DIR "${"+AppClientProjectProperties.BUILD_DIR+"}/ear-module' "${"+AppClientProjectProperties.BUILD_DIR+"}/jar"
EjbJarProjectProperties.BUILD_EAR_CLASSES_DIR "${"+EjbJarProjectProperties.BUILD_DIR+"}/ear-module" "${"+EjbJarProjectProperties.BUILD_DIR+"}/jar"
WebProjectProperties.BUILD_EAR_WEB_DIR "${"+WebProjectProperties.BUILD_DIR+"}/ear-module" "${"+WebProjectProperties.BUILD_DIR+"}/web"


This unification should be migrated into existing apps also. The easiest way to make this happen safely, is to add code to the 'open hook' of the three J2EE/Java EE module projects that will force the two properties to have the same value if they are different.

More extensive changes are possible, but have considerably more risk, which the module project owners should really assume and schedule.

In j2eeserver

The changes here are mostly bug fixes, too.

The first change resolves a bug in the ConfigSupportImpl.java. The null return value for getModuleUri(null), when the j2eeModule object is a J2eeApplication was preventing any attempt to deploy an enterprise application. See TargetServer.java (v 1.50, line 465).

The second change in InitialServerDistributor.java prevent incremental deployment from deleting a projects source directories. A pretty typical off-by-one error combined with delete() does terrible things to projects...

The last changes are in ServerFileDistributor.java. This file has a dereferencing errors. On line 122 of rev 1.24, the

 childModule[I] 
is the TargetModuleID that needs to be dereferenced here not the targetModule.

The next necessary change weakens an assumption in the code. The code currently assumes that the TargetModuleIDs that are associated with an ear have a one-to-one correspondence with the J2EeeModule objects that are associated with a J2eeApplication. This isn't a valid assumption for SJSAS/GF which may return additional TMID's for the generated web apps that support Java Web Start of application clients. Since this has been shown to be an invalid assumption for one server, it seems likely that it will also prove to be invalid for others, so weakening this assumption in the j2eeserver module is the best coding choice. {line 127 of rev 1.24}

The last change to this file replace a delete/copy file pair with a "rewrite content" operation. This is helps prevent deployment errors caused by Windows file locking. It is safe to do this rewrite operation, since the ear project will be the only type of project that goes through this change and the application will be redeployed and eliminate the chance that an executing application will try to work with code that has been overwritten.

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