J2EE Design Questions

Question

Please forgive me, I am just getting into J2EE and, despite having a mountain of manuals on my desk, I'm having a little trouble figuring out how everything fits together...
Question 1.
Is there any standard application entry point for an EJB container... kind of like main() in a plain old java application, or the contextInitialized() method for a ServletContextListener in a web container?
Question 2.
Is there any kind of an analog to web.xml for EJB containers? If not, is there some kind of standard way to set initialization parameters for EJBs?
Question 3.
Is there any kind of JNDI service provider created for me by my EJB container? For example, the (rather old) article here:
http://java.sun.com/products/jndi/tutorial/getStarted/examples/naming.html
suggests the following code:
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
    "com.sun.jndi.fscontext.RefFSContextFactory");
Context ctx = new InitialContext(env);specifically 'Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.fscontext.RefFSContextFactory"' looks like a bunch of voodoo to me, and also mentions something about the file system... I don't want my JNDI to have anything to do with my filesystem. Do I need to install some kind of JNDI server or LDAP server or something? Sorry... I'm really confused.
Question 4.
In my test application, I'm trying to centralize logging. I have a stateless EJB that implements logging capability. When instantiated, (in theory) it should register it's logging element to JNDI, so that further instantiations of the logging EJB should all direct their calls to the same element.
I fully realize that this would imply (at best), in a distributed environment, the rather strange behavior of logging calls bouncing around to the first machine that happend to instantiate a logging bean...
regardless, I have the following broken code:
import javax.ejb.Stateless;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
@Stateless
public class LogEJB implements VCMarkWeb.log.LogEJBRemote {
    private transient Context context;
    private transient Log     log;
    private transient boolean logMaster = false;
    private int logLevel;
    public
    LogEJB() {               
        try {
            context = new InitialContext();
            Log     globLog = (Log) context.lookup("log");           
            if (log != null){
                this.log = globLog;
                return;
            log = new LogWindow(800, 600, "LogBean", 5);
            log.out("Logging born.");
            context.bind("log", log);
            this.logMaster = true;           
        catch (Exception exception) {
            System.out.println("LogEJB: Exception while instantiating.");
            System.out.println(exception.getMessage());
    public void
    finalize() {
        if (!logMaster)
            return;
        try {
            context.unbind("log");
        catch (Exception exception) {
            System.out.println("LogEJB.finalize(): Exception unbinding log.");
            System.out.println(exception.getMessage());
} Obviously, this code is broken, because my EJB has overridden finalize(), which is apparently not allowed. In this case (since I'm going to have to delete that finalize() method), how could I assure that my reference to a logging element will be unbound once the owner of that logging element is garbage-collected?
..or.. if I'm asking Question #5 in too convoluted of a way...
Question 5'. Say, when my EJB container is kicked off, I want to create a single class containing a swing window, which will exist for the lifetime of the container, to which I can pass a handle to, such that any EJB's can invoke its methods? How would I do that, and how would I pass to my EJBs a handle to said class the 'right way'(tm)?
Thanks so much for your assistance, J2EE design gurus :)

Answer 1

singletons are counter to the very concept of distributed computing, which EJB is of course liable to do.
So while you may have a class that behaves like a singleton inside its own enterprise application context, there is no guarantee it will behave like a singleton when seen from the perspective of a client.
In fact, when the enterprise application is run in a distributed environment it's guaranteed to not be a singleton anymore as each JVM instance will have its own instance of the class loaded.
It can get even worse depending on application server architecture, and you may end up having several instances of your "singleton" running inside the same server (possibly the same application) though that is more rare.
So the best thing to do with singletons is forget all about them.