Deployment remains one of the most frustrating and time-consuming aspects of EJB work. This section explores some of the reasons why, and suggests what might be needed to improve the develop/deploy/test cycle.
| 59. |
The WAR/JAR/EAR model is horrible for development and deployment. The deployment spec is opaque, using the Russian Doll metaphor. |
| 60. |
EJB deployment is incredibly fragile. Miss setting a property and the container won't use a sensible default. Of course this depends on the container, but mostly they simply throw a vague error message and refuse to continue. This is just plain unhelpful - "jobsworth", even.
The servlet world has it easy in comparison - e.g. the "invoker" servlet executes anonymous servlet classes that have not been defined in a web.xml file (usually maps to /servlet/*).
In other words, servlet engine writers go to special efforts to make deployment easy. Easiness is what it's all about. EJB containers don't have the equivalent of a default web.xml file that they can inherit default properties from.
|
| 61. |
There is no standard way to deploy an EJB application. The details change with each server, and (worse still) with each revision of each server. |
| 62. |
EJB needs to be more IDE-friendly, particularly when it comes to deployment.
Deployment is not always opened up to tools, e.g. RI 1.2.2/1.3 uses batch files which call Java. Its deploy/package code is not meant to be called by tools. The RI uses the broken concept of current directory, i.e. must be called from a DOS window, not from an IDE VM.
There should be an interface for deployment, which can be picked up and used by IDEs.
|
| 63. |
The EJB spec has too many fictitious roles. In reality there are container/server providers, and application providers who develop, assemble, deploy, and administer the EJB server. The EJB spec should reflect this reality. |
| 64. |
There is no such thing as cross platform EJB. Each platform has its own horrible bugs. Escape one system to fall prey to another. |
| 65. |
Developers have to repeat the same meta-data in the code as SQL, as client properties as server properties, as XML attributes. |
| 66. |
Container managed EJB often requires you to specify a lot of what would be in your code, for example the SQL. |
| 67. |
Administration is different with every server. There is no standard for administering the deployed EJBs. |
| 68. |
XML is all about interpretation. Different vendors interpret the XML differently. For example (on the servlet/JSP side), web.xml's <welcome-file-list>. Some see this as 'look for these files in this order', others as 'these files should be here'.
Of course this sort of misunderstanding just can't be helped sometimes, but is included here as something to be wary of - it's an example of how ambiguity can creep into a seemingly bullet-proof spec and cause standards to fragment.
|
| 69. |
The specifications are continually changing. That's ok, but when new versions cannot run old applications without major changes, then we have a problem. |
| 70. |
The server vendors have graced us with some remarkably vague and misleading deployment tools, e.g verifiers that spout unhelpful error messages, or pass classes that then fail on deployment. |
| 71. |
Loose coupling between the bean and interface. The XML is not strongly typed, i.e. too much room for error. Very little use of reflection to work out class relationships. |
| 72. |
Deployment of code, in order to test it, is a horribly complex, click-laden process. As well as involving many stages, there seems to be no proper way to automate it, especially if you are attempting to target many different EJB servers. |
| 73. |
The basic ejb.xml, web.xml and application.xml descriptors are not sufficient to deploy. The result is that further descriptor information must be written using app-server specific XML.
This means that every ear must be changed to be deployed. It would have been better to have defaults set up so that a minimally defined EJB would deploy and run without modification.
|
| 74. |
The XML descriptors use ambiguous names - for example, displayName isn't just the display name, it's used as the reference name. |
| 75. |
An EJB ear should be able to be deployed on ANY compliant EJB server, with no changes to the ear.
It should expose and advertise the environmental items that can be changed (like war mount point), and those that MUST be changed (like database connections).
However, there should be no requirement on the ear developer to produce X different versions, for all the servers out there. This seems to be the current state, which is madness.
|
| 76. |
The Validator passes descriptors which later fail on deploy. For example (using Catalina/Tomcat in RI 1.3), try creating a war file with multiple entries with the same name. The war is passed on verify, but of course fails to deploy.
A connected problem is that once deployed, there is no way to automatically test that your beans have actually deployed.
These might not be such terrible issues, but they merely add time and frustration to an already slow process.
|
Programming
