Ok,
Here it is. There is an attached readme file that explains the whole
thing.
In addition to security, it supports other cool JNDI feature (I would be
careful about using them, though, becuase not all venders support them
and you may have a problem with application server vendor independence.)
Additional Features:
-- Sub Contexts
-- Security on subcontext
(for instance, you can have the following:
inetbasics.system.rootBean1
inetbasics.system.rootBean2
inetbasics.user.userBean1
inetbasics.user.userBean2
and allow different groups access to
different trees for lookup at the system
or user level and everything below is covered
-- EventContext support
-- Pluggable security implementations (though it
should probably be changed to the JAAS stuff)
Let me know if you have any questions.
John
Here is the JNDI implementation.
The "main" of com.inetbasics.server.naming.provider.rmi.RMITreeInstaller
must be run to create the tree. It takes no parameters. I created a
quick main that called it then the JOnAS main so that they could
be in the same VM. It might be worthwhile to add a feature to JOnAS
that reads a configuration and introspects the classes to find the main
then calls it for each (Weblogic style). I can work on fixing it so that
it doesn't need to be in the same VM, but that is not a priority for me
right now.
The JNDI tree installs itself according to the contents of jndi.properties.
This file should be in a directory under <inetbasics_home>/config where
<inetbasics_home> is specified on the command line with a -Dinetbasics.iap.home
The other configuration files should be in this directory too. In this file, you
will find the mechanism for configuring the authentication mechanism. This is a
class that implements the com.inetbasics.server.acl.naming.TreeACL interface.
This is used to accomplish the actual authentication. I included a sample
implementation that reads a properties file.
The tree uses a utility logger called HealthMonitor. It is included under the
util package. The configuration is in logConsumer.xml. In here, you can
specify plugin loggers that service the messages. These are classes that
implements the com.inetbasics.util.log.LogListener interface. I have included
a standard error class to serve this function, but e-mail, database, and others
could be created. Why doesn't the J2EE spec have a standard message logging
system that we can plug vendors into?
Drop me a note if you have any questions: [EMAIL PROTECTED]
enjoy,
John
config.zip
src.zip
