ActionServlet.reload()
If i changed the Struts-config.xml file and i changed the datasources. Then the reload of the ActionServlet doesn't close the current datasources and start them up again. I know this is a bit difficult because what to do when a connection of a datasource is currently in use?? I came across this because i overloaded the init function of the ActionServlet where i create some Application scope objects which are used throughout the complete application. Those objects have some dependencies to each other. And those are set in the init(). But after a reload the DatabaseMessageResources doesn't have the link to the database class anymore because that i do in the init() Can't all the things (including datasources) be closed in the reload() and then just call the init() method from the reload() so that it looks that the servlet get's loaded again? Johan Compagner
Re: Could Struts manage InitialContext's as well as DataSources?
Hi, JNDI properties can be handled quite easily by defining them in a jndi.properties file and any JNDI compliant implementation should load the properties from this file. This is well-documented in the JNDI JavaDocs. IMHO, I don't see a need for Struts to handle JNDI settings. Another issue is security-wise it's a bad idea to store password in clear in the struts-config.xml. Not to mention this is not scalable as the struts-config.xml need to be modified for every new user. [EMAIL PROTECTED] wrote: Hello all, Currently, Struts has the capability to manage javax.sql.DataSources for accessing JDBC connections... I was pondering whether it might also be useful to have it manage InitialContext's... Consider the following fragment of XML that might be taken from a struts-config.xml... naming-contexts naming-context key="myEJBConnection" initialContextFactory="your.factory.class.here" providerUrl="jndi:/some/url/here" securityPrincipal="username" securityCredentials="password" (+ other attributes to support the standard JNDI properties as defined by javax.naming.Context) property name="some.custom.property.name"value/property property name="some.custom.property.name"value/property /naming-context naming-context key="myLDAPConnection" ... /naming-context /naming-contexts Similar to findDataSource(String), ActionServlet would have a javax.naming.Context findNamingContext(String) method. The issues are primarily these: 1. findNamingContext() would probably (???) need to return Contexts on a per user session basis. 2. Whilst forcing all Contexts returned to use the same principal and credentials (as in the above example) is fine for some circumstances (looking up records on an LDAP server) it is definately not for others (such as connecting to an EJB container) where you want to propagate the identity of the user in some fashion. I guess if you chose to omit the securityPrincipal and securityCredentials from the specific naming-context, then depending on which container you are using (as an example, Weblogic which is both a servlet and EJB container) it will probably figure out which user it is and whether they are sufficiently authenticated. If however the servlet and EJB containers are separate products (for example, Tomcat and JBoss), and possibly running different JVMs (for whatever reason), then this is all complicated some what. Is there still some way though, of solving this generically within Struts in a reasonably satisfactory manner? Possibly JAAS comes into play here, but I believe the way in which JAAS integrates with the Servlet model is still a bit unclear. Thoughts? Regards, James W. -- This e-mail is from Cards Etc Pty Ltd (ACN: 069 533 302). It may contain privileged and confidential information. It is intended for the named recipient(s) only. If you are not an intended recipient, please notify us immediately by reply e-mail or by phone on +61 2 9212 7773 delete this e-mail from your system. --
cvs commit: jakarta-struts/src/share/org/apache/struts/util MessageResourcesFactory.java
craigmcc01/01/24 09:25:37
Modified:src/share/org/apache/struts/util
MessageResourcesFactory.java
Log:
Make MessageResourcesFactory (and therefore subclasses of it)
Serializable.
Revision ChangesPath
1.3 +9 -6
jakarta-struts/src/share/org/apache/struts/util/MessageResourcesFactory.java
Index: MessageResourcesFactory.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/util/MessageResourcesFactory.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- MessageResourcesFactory.java 2001/01/16 03:52:57 1.2
+++ MessageResourcesFactory.java 2001/01/24 17:25:36 1.3
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-struts/src/share/org/apache/struts/util/MessageResourcesFactory.java,v
1.2 2001/01/16 03:52:57 craigmcc Exp $
- * $Revision: 1.2 $
- * $Date: 2001/01/16 03:52:57 $
+ * $Header:
/home/cvs/jakarta-struts/src/share/org/apache/struts/util/MessageResourcesFactory.java,v
1.3 2001/01/24 17:25:36 craigmcc Exp $
+ * $Revision: 1.3 $
+ * $Date: 2001/01/24 17:25:36 $
*
*
*
@@ -63,6 +63,9 @@
package org.apache.struts.util;
+import java.io.Serializable;
+
+
/**
* Factory for codeMessageResources/code instances. The general usage
* pattern for this class is:
@@ -78,10 +81,10 @@
* /ul
*
* @author Craig R. McClanahan
- * @version $Revision: 1.2 $ $Date: 2001/01/16 03:52:57 $
+ * @version $Revision: 1.3 $ $Date: 2001/01/24 17:25:36 $
*/
-public abstract class MessageResourcesFactory {
+public abstract class MessageResourcesFactory implements Serializable {
// Instance Properties
@@ -121,7 +124,7 @@
* The Java class to be used for
* codeMessageResourcesFactory/code instances.
*/
-protected static Class clazz = null;
+protected static transient Class clazz = null;
/**
Re: cvs commit: jakarta-struts/src/doc installation.xml
Colin Sampaleanu wrote:
care to clarify the rationale for this? (I'm just curious, I've always set
up my projects so anything under /src lives in source control)
Yes .. you're likely to see similar changes on other Jakarta subprojects as
well. (Modifying files outside your source directory is highly offensive to
some developers, and I'm starting to see the light about why :-).
Consider the fact that we're about to release Struts 1.0, and happily start
working on Struts 1.1 (in a branch of the jakarta-struts repository). Now, it
is quite likely that any post-release bug found in 1.0 will also affect 1.1, so
I'm going to want to keep both versions checked out. No problem, I can do that,
by renaming my source directories "jakarta-struts-1.0" and "jakarta-struts-1.1".
But now, when I go do a build, the output from one version steps on the
"../build/struts" and "../dist/struts" directories of the other version :-(.
This could be fixed by maintaining version numbers in the build directory names
(by changing the "build.home" value to "../build/struts-1.1" for example), but
it just seems cleaner to keep everything localized. The "build" and "dist"
directories will automatically be version-specific, with no chance for
corrupting each other.
NOTE: Even though the "build" and "dist" directories will be wtihin the source
directory, they will *not* be checked in to CVS. As soon as the server lets me
back in, I've got a ".cvsignore" file to add that will keep CVS from whining
about unregistered directories.
Craig
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: January 24, 2001 4:57 PM
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-struts/src/doc installation.xml
craigmcc01/01/24 13:57:27
Modified:.build.xml
src/doc installation.xml
Log:
Change the Struts build process to place the "build" and "dist"
directories *inside* the source directory, rather than up and over
("../build/struts" and "../dist/struts") as they are now. Tweak the
installation documentation to reflect this.
Revision ChangesPath
1.33 +2 -2 jakarta-struts/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-struts/build.xml,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -r1.32 -r1.33
--- build.xml 2001/01/20 00:32:43 1.32
+++ build.xml 2001/01/24 21:57:26 1.33
@@ -2,11 +2,11 @@
!-- Initialization properties --
property name="app.name" value="struts"/
- property name="build.home" value="../build/${app.name}"/
+ property name="build.home" value="build"/
property name="catalina.home" value="../build/tomcat-4.0"/
property name="debug" value="true"/
property name="deprecation"value="false"/
- property name="dist.home" value="../dist/${app.name}"/
+ property name="dist.home" value="dist"/
property name="optimize" value="true"/
property name="project.name" value="jakarta-struts"/
property name="project.version" value="1.0-dev"/
1.8 +5 -4 jakarta-struts/src/doc/installation.xml
Index: installation.xml
===
RCS file: /home/cvs/jakarta-struts/src/doc/installation.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- installation.xml2001/01/12 05:24:58 1.7
+++ installation.xml2001/01/24 21:57:27 1.8
@@ -101,9 +101,10 @@
/pre
pThis command will create a binary distribution of
Struts, in a
-directory named code../dist/struts/code (relative
to where you
+directory named codedist/code (relative to where you
are compiling from). This directory contains an exact
replica of the
-files included in a binary distribution of Struts./p
+files included in a binary distribution of Struts, as described
+in the following section./p
/section
@@ -138,13 +139,13 @@
You can install this web application on any
servlet container
compatible with the Servlet 2.2 (or later) and JSP
1.1 (or later)
specifications./li
+listrongwebapps/struts-template.war/strong -
This web application
+both introduces and demonstrates the Struts
template tags./li
listrongwebapps/struts-test.war/strong - This
web application
contains test pages for the various custom tags
supported by Struts.
It is primarily of use to developers who are
enhancing the Struts
custom tag libraries, but may also be useful as
simple examples of
the usage of various Struts tags./li
-
RE: cvs commit: jakarta-struts/src/doc installation.xml
-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: January 24, 2001 5:21 PM
To: [EMAIL PROTECTED]
Subject: Re: cvs commit: jakarta-struts/src/doc installation.xml
Colin Sampaleanu wrote:
care to clarify the rationale for this? (I'm just curious,
I've always set
up my projects so anything under /src lives in source control)
Yes .. you're likely to see similar changes on other Jakarta
subprojects as
well. (Modifying files outside your source directory is
highly offensive to
some developers, and I'm starting to see the light about why :-).
Consider the fact that we're about to release Struts 1.0, and
happily start
working on Struts 1.1 (in a branch of the jakarta-struts
repository). Now, it
is quite likely that any post-release bug found in 1.0 will
also affect 1.1, so
I'm going to want to keep both versions checked out. No
problem, I can do that,
by renaming my source directories "jakarta-struts-1.0" and
"jakarta-struts-1.1".
But now, when I go do a build, the output from one version
steps on the
"../build/struts" and "../dist/struts" directories of the
other version :-(.
This could be fixed by maintaining version numbers in the
build directory names
(by changing the "build.home" value to "../build/struts-1.1"
for example), but
it just seems cleaner to keep everything localized. The
"build" and "dist"
directories will automatically be version-specific, with no chance for
corrupting each other.
Actually I think I just didn't understand the change. I though you were
moving builds to
project-root/src/build
but you are actually moving them to
project-root/build
where before it was
project-root../build/appname
If this is the case, then that is exactly what I do already, and it makes
sense for the reasons you describe...
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: January 24, 2001 4:57 PM
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-struts/src/doc installation.xml
craigmcc01/01/24 13:57:27
Modified:.build.xml
src/doc installation.xml
Log:
Change the Struts build process to place the "build" and "dist"
directories *inside* the source directory, rather than
up and over
("../build/struts" and "../dist/struts") as they are
now. Tweak the
installation documentation to reflect this.
Revision ChangesPath
1.33 +2 -2 jakarta-struts/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-struts/build.xml,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -r1.32 -r1.33
--- build.xml 2001/01/20 00:32:43 1.32
+++ build.xml 2001/01/24 21:57:26 1.33
@@ -2,11 +2,11 @@
!-- Initialization properties --
property name="app.name" value="struts"/
- property name="build.home"
value="../build/${app.name}"/
+ property name="build.home" value="build"/
property name="catalina.home" value="../build/tomcat-4.0"/
property name="debug" value="true"/
property name="deprecation"value="false"/
- property name="dist.home" value="../dist/${app.name}"/
+ property name="dist.home" value="dist"/
property name="optimize" value="true"/
property name="project.name" value="jakarta-struts"/
property name="project.version" value="1.0-dev"/
1.8 +5 -4 jakarta-struts/src/doc/installation.xml
Index: installation.xml
===
RCS file: /home/cvs/jakarta-struts/src/doc/installation.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- installation.xml2001/01/12 05:24:58 1.7
+++ installation.xml2001/01/24 21:57:27 1.8
@@ -101,9 +101,10 @@
/pre
pThis command will create a binary distribution of
Struts, in a
-directory named code../dist/struts/code (relative
to where you
+directory named codedist/code (relative to where you
are compiling from). This directory contains an exact
replica of the
-files included in a binary distribution of Struts./p
+files included in a binary distribution of Struts,
as described
+in the following section./p
/section
@@ -138,13 +139,13 @@
You can install this web application on any
servlet container
compatible with the Servlet 2.2 (or later) and JSP
1.1 (or later)
specifications./li
+listrongwebapps/struts-template.war/strong -
This web application
+both introduces and demonstrates the Struts
template tags./li
