Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 232352

Summary: Undocumented NamingContext properties
Product: [JBoss] JBoss Enterprise Application Platform 4 Reporter: Brian Stansberry <bstansberry>
Component: doc-Server_Configuration_GuideAssignee: Russell Dickenson <rdickens>
Status: CLOSED WONTFIX QA Contact:
Severity: low Docs Contact:
Priority: medium    
Version: 4.2.0CC: jboss-docs, twells
Target Milestone: ---Keywords: Documentation
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-05-02 04:22:31 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Brian Stansberry 2007-03-14 21:34:23 UTC
The following properties accepted by org.jnp.interfaces.NamingContext are not
covered in the documentation:

jnp.socketFactory -- The javax.net.SocketFactory impl to use for the bootstrap
socket

jnp.localAddress -- The local (client-side) address to bind the connected
bootstrap socket to

jnp.localPort -- The local (client-side) port to bind the connected bootstrap
socket to

jnp.useRelativeName -- A flag indicating the style of names passed to
javax.naming.spi.NamingManager methods. True for api expected relative names, false
for absolute names as used historically by the jboss naming implementation.

jnp.maxRetries -- An integer that controls the number of connection retry
attempts that will be made on the initial connection to the naming server. This
only applies to ConnectException failures. A value <= 1 means that only one
attempt will be made. Default is one.

jnp.discoveryTTL -- The time-to-live for multicast discovery packets

The first five belong in the general discussion of
org.jnp.interfaces.NamingContext (e.g. Section 2.3.2 of The JBoss 4 Application
Server J2EE Reference), while the last belongs in the subsequent clustering
discussion (Section 2.3.3 of the J2EE Reference as well as Section 1.2.2 of The
JBoss 4 Application Server Clustering Guide).

I'll create a separate issue for getting jnp.discoveryTTL in the clustering docs.

Comment 1 Brian Stansberry 2007-03-14 21:41:03 UTC
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232354 is the related
clustering docs issue.

Comment 2 Michael Hideo 2007-06-06 04:49:52 UTC
Adding 'cc ecs-dev-list@redhat.com for team coverage

Comment 4 Joshua Wulf 2007-06-22 08:16:26 UTC
I've updated the clustering documentation and the associated bug. The JBoss 4
Application
Server J2EE Reference doesn't ship with JBEAP 4.2, so this bug may need to be
refiled against a different component / project.



Comment 5 Michael Hideo 2007-10-23 02:48:44 UTC
Removing automation notification

Comment 6 Michael Hideo 2008-01-17 05:49:21 UTC
Mass Re-Assignment to Vinu for vetting. Investigate and migrate to JIRA if
necessary.