| Home >> All >> org >> apache >> [ naming Javadoc ] |
• org.apache.naming: Javadoc index of package org.apache.naming.
Package Samples:
• org.apache.naming.resources.jndi: This package contains the resources directory context implemetation.
• org.apache.naming.resources: This package contains a memory based naming service provider.
• org.apache.naming.ant
• org.apache.naming.core
• org.apache.naming.handler.jndi
• org.apache.naming.modules.cache
• org.apache.naming.modules.fs
• org.apache.naming.modules.id
• org.apache.naming.modules.java
• org.apache.naming.modules.memory
• org.apache.naming.util
• org.apache.naming.factory
• org.apache.naming.java
Classes:
• BeanFactory: Object factory for any Resource conforming to the JavaBean spec. This factory can be configured in a <DefaultContext> or <Context> element in your conf/server.xml configuration file. An example of factory configuration is: <Resource name="jdbc/myDataSource" auth="SERVLET" type="oracle.jdbc.pool.OracleConnectionCacheImpl"/> <ResourceParams name="jdbc/myDataSource"> <parameter> <name>factory</name> <value>org.apache.naming.factory.BeanFactory</value> </parameter> <parameter> <name>driverType</name> <value>thin</value> ...
• SendMailFactory: Factory class that creates a JNDI named javamail MimePartDataSource object which can be used for sending email using SMTP. Can be configured in the DefaultContext or Context scope of your server.xml configuration file. Example: <Resource name="mail/send" auth="CONTAINER" type="javax.mail.internet.MimePartDataSource"/> <ResourceParams name="mail/send"> <parameter><name>factory</name> <value>org.apache.naming.factory.SendMailFactory</value> </parameter> <parameter><name>mail.smtp.host</name> <value>your.smtp.host</value> </parameter> <parameter><name>mail.smtp.user</name> ...
• MailSessionFactory: Factory class that creates a JNDI named JavaMail Session factory, which can be used for managing inbound and outbound electronic mail messages via JavaMail APIs. All messaging environment properties described in the JavaMail Specification may be passed to the Session factory; however the following properties are the most commonly used: mail.smtp.host - Hostname for outbound transport connections. Defaults to localhost if not specified. This factory can be configured in a <DefaultContext> or <Context> element in your conf/server.xml configuration file. An example of factory configuration ...
• BaseDirContextTestCase: Basic unit tests for the javax.naming.directory.DirContext implementations. This class must be subclassed for each individual DirContext implementation. WARNING : These tests make certain assumptions that can generate "false negative" results if they are violated: The pathname of a directory (or WAR file) containing the static resources of the /examples web application shipped with Tomcat is passed to our test class as a system property named doc.base . The entry names that can be found in the top-level DirContext of the static resources are enumerated in the topLevelNames variable. The entry names ...
• BaseNaming: This is the base class for our naming operations, for easy reading. Creating a new context: Create a new class, extending BaseContext or BaseDirContext ( second if you want to support attributes ). Add setters for configuration. The setters will be called autmatically, like in ant, from the initial env settings. Override methods that are defined in BaseNaming. Default behavior is provided for all. If performance is a concern or have special behavior - override Context and DirContext methods. That shouldn't be needed in most cases. This class is designed to minimize the ammount of code that is required ...
• BaseDirContext: Base Directory Context implementation. All j-t-c/naming contexts should extend it. Implements all JNDI methods - if you just extend it you'll get UnsuportedOperation. XXX Should it also act as introspector proxy or should we use a separate context ? The intention is to allow use 'introspection magic' and bean-like DirContexts. IMPORTANT: all contexts should use setters/getters for configuration, instead of the Hashtable. The default constructor will use introspection to configure and may provide ( via a hook ? ) JMX management on all contexts. You must extend and override few methods. Of course, ...
• StringManager: An internationalization / localization helper class which reduces the bother of handling ResourceBundles and takes care of the common cases of message formating which otherwise require the creation of Object arrays and such. The StringManager operates on a package basis. One StringManager per package can be created and accessed via the getManager method call. The StringManager will look for a ResourceBundle named by the package name given plus the suffix of "LocalStrings". In practice, this means that the localized information will be contained in a LocalStrings.properties file located in the package ...
• javaURLContextFactory: Context factory for the "java:" namespace. Important note : This factory MUST be associated with the "java" URL prefix, which can be done by either : Adding a java.naming.factory.url.pkgs=org.apache.catalina.util.naming property to the JNDI properties file Setting an environment variable named Context.URL_PKG_PREFIXES with its value including the org.apache.catalina.util.naming package name. More detail about this can be found in the JNDI documentation : NamingManager.getURLContext(java.lang.String, java.util.Hashtable) > NamingManager.getURLContext(java.lang.String, java.util.Hashtable) 55 .
• IdContext: Store int handles in a DirContext. This replaces the 3.3 notes mechanism ( which were stored in ContextManager ). The context name is the 'namespace' for the notes ( Request, Container, etc ). One subcontext will be created for each note, with the id, description, etc. This is also used for Coyote hooks - to create the int hook id. Example: id:/coyote/hooks/commit -> 1 id:/coyote/hooks/pre_request -> 2 ... id:/t33/hooks/pre_request -> 1 ... id:/t33/ContextManager/myNote1 -> 1 The bound object is an Integer ( for auto-generated ids ). XXX Should it be a complex object ? Should we allow pre-binding ...
• fsURLContextFactory: Context factory for the "file:" namespace. Important note : This factory MUST be associated with the "java" URL prefix, which can be done by either : Adding a java.naming.factory.url.pkgs=org.apache.naming property to the JNDI properties file Setting an environment variable named Context.URL_PKG_PREFIXES with its value including the org.apache.naming package name. More detail about this can be found in the JNDI documentation : NamingManager.getURLContext(java.lang.String, java.util.Hashtable) > NamingManager.getURLContext(java.lang.String, java.util.Hashtable) 55 .
• javaURLContextFactory: Context factory for the "java:" namespace. Important note : This factory MUST be associated with the "java" URL prefix, which can be done by either : Adding a java.naming.factory.url.pkgs=org.apache.naming property to the JNDI properties file Setting an environment variable named Context.URL_PKG_PREFIXES with its value including the org.apache.naming package name. More detail about this can be found in the JNDI documentation : NamingManager.getURLContext(java.lang.String, java.util.Hashtable) > NamingManager.getURLContext(java.lang.String, java.util.Hashtable) 55 .
• BaseContext: Base Context implementation. Use it if the source doesn't support attributes. Implements all JNDI methods with reasonable defaults or UnsuportedOperation. IMPORTANT: all contexts should use setters/getters for configuration, instead of the Hashtable. The default constructor will use introspection to configure and may provide ( via a hook ? ) JMX management on all contexts. All methods use Name variant. They should expect an arbitrary implementation, but it's recommended to check if ServerName is used - and take advantage of the specific features ( MessageBytes, etc ).
• ServerName: Implementation of Name with support for extra information. An extra feature ( not yet implemneted ) is the support for MessageBytes. This allows tomcat to operate lookup operations on the original message, without creating Strings. Another feature is support for extra information that can be cached. This brakes a bit the JNDI requirements, as Contexts can modify the Name and add anotations. The main benefit is that after the first lookup it'll be possible to avoid some expensive operations.
• JndiPermission: Java SecurityManager Permission class for JNDI name based file resources The JndiPermission extends the BasicPermission. The permission name is a full or partial jndi resource name. An * can be used at the end of the name to match all named resources that start with name. There are no actions. Example that grants permission to read all JNDI file based resources: permission org.apache.naming.JndiPermission "*";
• JndiPermission: Java SecurityManager Permission class for JNDI name based file resources The JndiPermission extends the BasicPermission. The permission name is a full or partial jndi resource name. An * can be used at the end of the name to match all named resources that start with name. There are no actions. Example that grants permission to read all JNDI file based resources: permission org.apache.naming.JndiPermission "*";
• DirContextHelper: Utility class providing additional operations on DirContexts. Instead of extending DirContext we use a helper who will work on any context, including 'foreign' ones ( like JNDI, etc ). Typical methods - conversions ( int, boolean), etc. This code should check if the context extend our BaseDirContext and use specific features ( like notes - to cache the conversion results for example ), but fallback for external contexts.
• FileDirContext: DirContext for a filesystem directory. The 'bind' operation will accept an InputStream ( TODO: File, any resource with content ) and create the file. ( TODO: what attributes can we support ? ) The lookup operation will return a FileDirContext or a File. Supported attributes: (TODO: lastModified, size, ...) Note that JNDI allows memory-efficient style, without having one wrapper object for each real resource.
• ServerAttribute: Extended version for Attribute. All our dirContexts should return objects of this type. Methods that take attribute param should use this type of objects for performance. This is an extension of the 'note' in tomcat 3.3. Each attribute will have an 'ID' ( small int ) and an associated namespace. The attributes are recyclable. The attribute is designed for use in server env, where performance is important.
• ServerAttributes: Extended version for Attribute. All our dirContexts should return objects of this type. Methods that take attribute param should use this type of objects for performance. This is an extension of the 'note' in tomcat 3.3. Each attribute will have an 'ID' ( small int ) and an associated namespace. The attributes are recyclable. The attribute is designed for use in server env, where performance is important.
• DirContextURLConnection: Connection to a JNDI directory context. Note: All the object attribute names are the WebDAV names, not the HTTP names, so this class overrides some methods from URLConnection to do the queries using the right names. Content handler is also not used; the content is directly returned.
• DirContextURLConnection: Connection to a JNDI directory context. Note: All the object attribute names are the WebDAV names, not the HTTP names, so this class overrides some methods from URLConnection to do the queries using the right names. Content handler is also not used; the content is directly returned.
• ServerBinding: This is used for both NameClass and Binding. Lazy eval - so the extra methods in Binding don't affect us. For most contexts we'll deal getting the class name is as expensive as getting the object. In addition most operations will only use the name.
• ProxyDirContext: Proxy Directory Context implementation. Will cache directory entries - attributes and content. This can be used to eliminate expensive dir access and to avoid keeping large directories in memory.
• JndiProperties: Dynamic properties from a JNDI context. Use ${jndi:NAME} syntax. You may need to use to set up jndi properties and drivers, and eventually different context-specific tasks.
• ImmutableNameNotFoundException: Immutable exception to avoid useless object creation by the proxy context. This should be used only by the proxy context. Actual contexts should return properly populated exceptions.
| Home | Contact Us | Privacy Policy | Terms of Service |