Doug Gschwind

Actually, the singleton model does NOT expose a public constructor. An example is the following:
public class Singleton
{
private static Singleton instance;
private Singleton()
{
super();
}
public static synchronized Singleton getInstance()
{
if (instance == null)
{
instance = new Singleton();
}
return instance;
}
// other stuff below
}
The call to super() from the private constructor exposes nothing additional to Singleton's consumers. The code above also limits construction to just one instance. Consumers of this class only obtain access to the one instance via the getInstance() class method.

If you are making changes in your VA environment to Java classes, you need only export those changes from VA. So, if you export class X, VA creates X.java, then you need only go to your Forte environment and pick up that change. In Forte, either refresh the package that X resides within, or navigate to the class itself and open it. Forte will ask you if you want the updated version (if Forte was already running when you exported X.java from VA). Once Forte has picked up the change, the additionally available methods should appear for code completion.
Hope that helps.

Craig Larman gave a presentation to the Boulder Java User's Group a couple of weeks ago and stated that Jikes is the fastest Java compiler available at the moment.
He also stated that IBM's JVM implementation is one that should be considered in any HotSpot genre evaluation due to its speed as well.

Actually, a good place for you to start further thinking would
be the State pattern in the GoF book.

Some thoughts for you to consider, in response to your specific points.
1. Not necessarily true regarding what CORBA requires you to code. True, the intent of the EJB spec, and therefore an implementation of the spec (an EJB container), is to provide infrastructure on behalf of the bean developer so that the bean developer doesn't have to "reinvent the wheel" so to speak regarding infrastructural (multithreading, persistence, transactions, etc.) software. There has been a movement within the OMG to embrace the ideas presented by the EJB specification. The intent of that movement was to provide infrastructure components in the CORBA world similar to what is provided in the EJB world. I haven't checked on the progress of that OMG effort in at least 12 months though.
2. EJB can be thought of as being language independent as well, when you consider that the EJB spec was written to provide access to EJB deployed JavaBeans through EITHER RMI or CORBA, with RMI being of course the default mechanism.
3. CORBA may be slightly more mature than EJB in that CORBA has been around longer. Probably a bit of a stretch to state that EJB is less reliable than CORBA though.
4. May be tough to prove this, especially in light of the OMG's movement to embrace the ideas of the EJB specification. Check into where the OMG is on their EJB like component model, and how the ORB vendors are choosing to implement it, if at all.
5. Seems like an apples (CORBA - MT) to oranges (EJB - persistence) comparison on this point. The EJB spec calls for full MT support as well, as I recall.
There is one other point to me that is paramount here. The efforts of the OMG revolve around the reduction of proprietary interfaces, which the EJB spec cannot itself address. The OMG has a process in place for adopting and implementing "standard" technology, which goes beyond the simple plumbing and such provided by an ORB vendor. This process also embraces standards within vertical domains (e.g. Telco, Finance, etc.) as well.
The idea here being that if you as a consumer of software components, purchase a software component that lives up to an OMG standard, your cost of ownership is reduced, since you should be able to dismiss that product in favor of another product which implements to the same IDL interface. This point does not appear to be addressed at all by the EJB community, as I have seen it thus far. Not to discredit the efforts by the EJB community, as I certainly believe in their efforts, but I personally would like to see efforts taken so that we all can purchase software off the shelf with this notion of reduced cost of ownership. I don't like being held at bay by the likes of the Microsoft's of the world.
I went off on a bit of a rant there. Hope this helps nonetheless.

You are correct and your colleague is incorrect.
A private method (class or instance) cannot be overriden, per the JLS. Only a non-final method that has public, package, or protected visibility can be overriden.

Yes, that does help, and makes good sense. I was wondering if that approach was possible.
Thanks for the help.

There is some good step by step instructions on what goes into the .jar file (e.g. ejb-jar.xml) for a bean in the "Bean Deployment" or "Deploying Beans" section of the WebLogic documentation. That documentation should be present in your installation. Just start with the top level .html file present in your weblogic install and you should be able to navigate to the specific information you are looking for.
The section for developers in that documentation explains some things pretty well as well.

There is some good step by step instructions on what goes into the .jar file (e.g. ejb-jar.xml) for a bean in the "Bean Deployment" or "Deploying Beans" section of the WebLogic documentation. That documentation should be present in your installation. Just start with the top level .html file present in your weblogic install and you should be able to navigate to the specific information you are looking for.
The section for developers in that documentation explains some things pretty well as well.

I certainly understand and agree with placing all the presentation specifics in a JSP, leaving the fill in the blank info as the responsibility of the Servlet/backend.
Suppose you have the situation where the result of an end user's actions is a variable length (in terms of number of rows) HTML table. How can the JSP/Servlet be designed so that the Servlet (or elsewhere in the non-presentation logic) doesn't generate HTML? Seems like in this case the Servlet needs to render the table row, table data, and end table row constructs for each row.

Check out the JavaWorld article referenced in :
http://www.javaranch.com/ubb/Forum7/HTML/000605.html

Together/J does this very well. As you make design changes, you see the forward engineered .java file change to reflect the design change. Similarly, if you edit the .java file directly (and say add a new method to the class), Together/J detects the change and updates the class diagram to reflect the updated class definition.

Barbara, I had the same problem with Acrobat 3.0. I simply upgraded to Acrobat 4.0 and then the pages are rendered as intended without that invalid color space error.

I forgot about my post on this forum some time ago. Look at:
http://www.javaranch.com/ubb/Forum9/HTML/000001.html

I assessed both products (Together/J 3.0 and Rose 98i actually) in detail about a year ago now. They are both UML based OOA/D
CASE tools. They do compare fairly closely, but depending on your work environment, one may stand out better than the other. Here are some high level pros/cons of both products, circa Q4 1999:
Together/J
Pros:
1. Excellent support for class and sequence diagrams. I also
liked the support for methods or variables being able to
be defined as having class or instance scope.
2. Forward/reverse engineering to Java source was very
nearly a foolproof endeavor. Forward engineering happens
as class design takes place, so a no brainer there. You
need only point to a directory and the tool can reverse
engineer a pre-existing source code baseline. Changes to
code (created during class design) that happen outside of
Together/J are reflected when the tool comes back on line.
Also, when a pre-existing source code baseline is reverse
engineered, the classes in a package are properly laid out
to minimize confusion when rendering relationships between
the classes (minimized line crossing).
3. I really liked that fact that any documentation that was
provided for a given class, method, variable/field,
parameter, exception, or return value, was forward
engineered into the java source code within a javadoc
compliant comment block.
Cons:
4. It does support team development, but because of its file
structure for housing diagram details, makes it a bit
cumbersome to use in a team environment. Instead of just
checking out a package to work on, the designer would need
to check out the package and the class level files desired
to be modified. Not a big deal, but not convenient.
Rose 98i
Pros:
1. Very convenient to use in a team environment. To checkout
a UML package to work on, you simply create a "unit"
comprising the package of interest, and everything in that
package is available for modification.
Cons:
2. Support for class and sequence diagrams could be better. No
way to specify that a given method has class scope, other
than to preface the method name with "static".
3. Forward and reverse engineering made your day fairly
frustrating and unpleasant.
For general UML understanding, Martin Fowler's book, "UML Distilled" is very good and concise. The second edition of the book came out in August of 1999 I believe, so there may be a newer edition available now.
Only info I know of regarding TogetherSoft is their website, www.togethersoft.com.