The repository provides access to the deployed jar files. It does not store the
jar files in itself, but stores their location as a URL. This allows the jar
files to be stored on a remote server, but requires that a webserver be running
on that server. If the jar file is local, then the location is described using
the file URL and the webserver is not needed. 

There are two different types of the users of the repository: 
1. Containers: EJB and JSP containers will access the repository to get all the
deployed jar files. The containers only need a read-only access to the
repository, and a way to enumerate all available packages. 

2. Tools: The EJB authoring and deployment tools will need to access the
repository in a read/write fashion. 

The responsibility of retrieving appropriate resources from the jar file lies
with the repository user. For example, the "orbd" process, may need to place
the jar file in the classpath of the EJB container process so that the
container can read the contents conveniently. 

Often an application writer will package EJBs, JSPs, HTMLs, and other resources
(like GIFs) in a single jar file. It is the responsibility of the deployment
tool to create the cooked jar file, repackage it and register it with the
repository under an appropriate name. If the EJB and JSP containers are
different processes, then the deployment tool may choose to create two separate
jar files and register them under different names. It is the responsiblity of
the deployment tool to inform the JSP container or the ORBD to load the jar
files when the deployment is completed. 

The repository is implemented as a JNDI name space. 

We are using the following schema: 

server --- apps ---  ejb --- serverJar
       |        |        |
       |        |        +-- clientJar
       |        |
       |        +--- web --- serverJar
       |                 |
       |                 +-- clientJar
       +-- config -- UserDB



Using the repository JNDI namespace: 

the files implementing the JNDI access are present in the com.sun.ejb.repository 
package. Every process that wants to use the repository name space will add all
the classes in its classpath. And hence the repository will be in the same
process. The repository loads the initial bindings through the file
"nametable.properties". 

A container only needs to lookup the repository and will typically use the
following code: 

	Properties env = new Properties();
	env.put("java.naming.factory.initial", 
		"com.sun.ejb.repository.RepositoryInitContextFactory");
	try {
	    Context ctx = new InitialContext(env);
	    System.out.println("app1");
	} catch (Exception e) {
	    e.printStackTrace();
	}

The deployment back end needs to add entries to the repository and will
typically access the repository as :

	// Set up to use factory
	Hashtable env = new Hashtable();
	env.put("java.naming.factory.initial", 
	    "com.sun.ejb.repository.RepositoryInitContextFactory");
	try {
	    Context initctx = new InitialContext(env);
	    initctx.bind("app1", "file:///ejbd/jars/app1.jar");
	    initctx.bind("app2", "file:///ejbd/jars/app2.jar");
	} catch (NamingException e) {
	    e.printStackTrace();
	}


Tasks remaining to be done:

1. Searchable Repository: The containers may need to search the repository to
find different kind of applications that are available. That functionality is
presently not there and need to be written.  
2. For supporting multiple processes better, rather than having in-process
repository classes, we should use a distributed scheme based on LDAP. 
