You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by bu...@apache.org on 2004/07/31 18:35:05 UTC

DO NOT REPLY [Bug 30424] New: - possible enhancement on bootup (or proving how little I know)...

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=30424>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=30424

possible enhancement on bootup (or proving how little I know)...

           Summary: possible enhancement on bootup (or proving how little I
                    know)...
           Product: Struts
           Version: 1.1 Final
          Platform: All
        OS/Version: Other
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: Controller
        AssignedTo: dev@struts.apache.org
        ReportedBy: nathan@artisticnetwork.com


Sorry, this is going to get a bit long, and is part of your directions to submit
proposed enhancements/patches via Bugzilla.

Preamble:

	I know this violates the letter of the "framework".  However, I submit
	that it does not violate the spirit and provides an extension that
	cleanly solves some issues, especially at boot-time.

Description:

	I am developing a sub-framework for a project that looks like it's
	going to be 95% reusable for another project that's also on my plate.
	It involves creating singleton support objects that all aspects of
	my solution wants to access, often-times for performance reasons (so
	far, my actions, formbeans, and even business logic have accessed these
	application-specific "infrastructure" components).

	It became obvious that I wanted to configure these singleton objects
	from a resource (I got lazy and used .properties - I should have used
	.xml but didn't want to put the thought into organization and dtd
	specification yet.  Yeah, lame excuse).  At this juncture, I ran into
	the problem of initializing my singleton through a static block, and
	I was not in the normal framework of execute().  As a result, I did not
	have access to the initialization parameters through the ServletConfig/
	Servlet/Context.

Proposed Solution:

	Two static methods from the servlet entry point, ActionServlet:
	public static String getAppInitParameter(String key);
	public static Enumeration getAppInitParameterNames();

	Note:  There are no namespace collisions as you will see in the
	javadoc further on down this post.

Patch (all additions to ServletAction.java, from stable release 1.1):

	import java.util.Hashtable;

	protected static Hashtable appInitParameters = new Hashtable();

	/**
	 * ActionServlet.getAppInitParameterNames() returns an Enumeration of
	 * all the application initialization parameters.
	 *
	 * @return java.util.Enumeration
	 */
	public static Enumeration getAppInitParameterNames() {
	    return(appInitParameters.keys());
	}

	/**
	 *	ActionServlet.getAppInitParameter(String key) is designed to allow
	 *	struts-based applications to set and obtain their own initialization
	 *	parameters that they can set in the <init-param> block within the
	 *	<servlet> specification in <i>web.xml</i>.  It works as follows:
	 *
	 *		All application-specific entry names must start with the
	 *		same name as the "application" <init-param> name, followed by a
	 *		slash.  Note:  this "application" name is also the entry that
	 *		specifies the name of your internationalization resource files
	 *		with Struts.  Example:  If if you had the following in your
	 *		<i>web.xml</i> file's servlet specification:
	 *
	 *			<init-param>
	 *				<param-name>application</param-name>
	 *				<param-value>example</param-value>
	 *			</init-param>
	 *
	 *		You could now make the following entry into the web.xml
	 *		servlet configuration block and it would be
	 *		accessible from any part of your application.
	 *
	 *			<init-param>
	 *				<param-name>example/exampleParam</param-name>
	 *				<param-value>example-value</param-value>
	 *			</init-param>
	 *
	 *		Note:  everything is case-sensitive.
	 *
	 *	Note:  The resulting initialization parameter name consists of the
	 *	contents <i>after</i> the separating slash, '/'.  Example:
	 *
	 *		ActionServlet.getAppInitParameter("exampleParam") returns
	 *		"example-value".
	 *
	 *	This is primarily useful in the situations where you are initializing
	 *	helper parts of your application that's outside of the Action and
	 *	Form components of the framework, such as initializing singleton
	 *	support options as part of the initialization of your application's
	 *	base Action class extension.  At this juncture, you were not called
	 *	as part of the normal "execute" path and therefore do not have access to
	 *	the complete normal Struts framework.
	 *
	 *	@param	java.lang.String key
	 *	@return	java.lang.String
	 */
	public static String getAppInitParameter(String key) {
	    return((String) appInitParameters(key));
	}

	// in init()
	String appName = getServletConfig().getInitParameter("application");

	// within "while (names.hasMoreElements()) {
	//     String name = names.nextElement();
            if (appName != null && name.startsWith(appName + "/"))
            {
                appInitParameters.put(name.substring(appName.length() + 1),
                    getServletConfig().getInitParameter(name));
                continue;
            }

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org