Struts installation notes for Resin
In response to the call for platform-specific installation notes, here's a section for the INSTALL document that covers Resin in stand-alone mode. I don't know if the instructions would be different for other modes (IIS, Apache, etc.), since I have only used Resin stand-alone, but perhaps someone else could comment. -- Martin Cooper Tumbleweed Communications RESIN STAND-ALONE - * In the steps below, $RESIN_HOME refers to the directory in which you have installed Resin, and $STRUTS_HOME is the directory in which you unpacked the Struts binary distribution. * Copy the Struts applications (*.war) from $STRUTS_HOME/webapps to your $RESIN_HOME/doc directory. * Modify the file "$RESIN_HOME/conf/resin.conf" to define the Struts applications, by adding a entry for each application inside the section. For example, add the following to define the documentation app: * Restart Resin if it is already running. * You should now be able to access the Struts applications (assuming you are using Resin's default port number of 8080) at, for example: http://localhost:8080/struts-documentation
cvs commit: jakarta-struts .cvsignore
craigmcc01/01/24 14:37:25 Added: ..cvsignore Log: Add ".cvsignore" file so that CVS will now whine about "build" and "dist" directories. Revision ChangesPath 1.1 jakarta-struts/.cvsignore Index: .cvsignore === build dist
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
/src/build
but you are actually moving them to
/build
where before it was
../build/
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 @@
> > >
> > >
> > >
> > > - value="../build/${app.name}"/>
> > > +
> > >
> > >
> > >
> > > -
> > > +
> > >
> > >
> > >
> > >
> > >
> > >
> > > 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 @@
> > >
> > >
> > >This command will create a binary distribution of
> > > Struts, in a
> > > -directory named ../dist/struts (relative
> > > to where you
> > > +directory named dist (relative to where you
> > >are compiling from). This directory contains an exact
> > > replica of the
> > > -files included in a binary distribution of Struts.
> > > +files included in a binary distribution of Struts,
> as described
> > > +in the following 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.
> > > +webapps/struts-template.war -
> > > This web application
> > > +both introduces and demonstrates the Struts
> > > template tags.
> > >webapps/struts-test.war - 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 u
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 @@
> >
> >
> >
> > -
> > +
> >
> >
> >
> > -
> > +
> >
> >
> >
> >
> >
> >
> > 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 @@
> >
> >
> >This command will create a binary distribution of
> > Struts, in a
> > -directory named ../dist/struts (relative
> > to where you
> > +directory named dist (relative to where you
> >are compiling from). This directory contains an exact
> > replica of the
> > -files included in a binary distribution of Struts.
> > +files included in a binary distribution of Struts, as described
> > +in the following 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.
> > +webapps/struts-template.war -
> > This web application
> > +both introduces and demonstrates the Struts
> > template tags.
> >webapps/struts-test.war - 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.
> > -webapps/struts-template.war -
> > This web application
> > -both introduces and demonstrates the Struts
> > template tags.
> >webapps/struts-upload.war - This
> > web application
> >is a quick example of uploading files using the
> > Struts framework.
> >
> >
> >
> >
> >
RE: cvs commit: jakarta-struts/src/doc installation.xml
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)
> -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 @@
>
>
>
> -
> +
>
>
>
> -
> +
>
>
>
>
>
>
> 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 @@
>
>
>This command will create a binary distribution of
> Struts, in a
> -directory named ../dist/struts (relative
> to where you
> +directory named dist (relative to where you
>are compiling from). This directory contains an exact
> replica of the
> -files included in a binary distribution of Struts.
> +files included in a binary distribution of Struts, as described
> +in the following 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.
> +webapps/struts-template.war -
> This web application
> +both introduces and demonstrates the Struts
> template tags.
>webapps/struts-test.war - 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.
> -webapps/struts-template.war -
> This web application
> -both introduces and demonstrates the Struts
> template tags.
>webapps/struts-upload.war - This
> web application
>is a quick example of uploading files using the
> Struts framework.
>
>
>
>
>
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 @@
-
+
-
+
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.xml 2001/01/12 05:24:58 1.7
+++ installation.xml 2001/01/24 21:57:27 1.8
@@ -101,9 +101,10 @@
This command will create a binary distribution of Struts, in a
-directory named ../dist/struts (relative to where you
+directory named dist (relative to where you
are compiling from). This directory contains an exact replica of the
-files included in a binary distribution of Struts.
+files included in a binary distribution of Struts, as described
+in the following 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.
+webapps/struts-template.war - This web application
+both introduces and demonstrates the Struts template tags.
webapps/struts-test.war - 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.
-webapps/struts-template.war - This web application
-both introduces and demonstrates the Struts template tags.
webapps/struts-upload.war - This web application
is a quick example of uploading files using the Struts framework.
Re: cvs commit: jakarta-struts/src/share/org/apache/struts/util MessageResourcesFactory.java
"Deadman, Hal" wrote:
> Thanks, this will make Weblogic users very happy. I am curious why the Class
> variable had to be made transient since it implements Serializable. It would
> be nice to know for future reference. Does it have to do with it storing a
> reference to a Class loaded by a different class loader?
>
That was definitely the motivation.
Consider that many servlet containers support automatic reloading of a webapp
when you change a class. Normally, this is done by throwing away the class
loader that loaded this class, and reloading everything with a new one. In that
manner, any changes to the classes will be picked up.
Now, what would happen if this variable had been left non-transient? The *old*
version of the class would be saved and restored, and any change you made to it
would not be visible! That's not what you want in this scenario.
Proper serialization behavior isn't just a matter of declaring things
Serializable. You also have to ensure that serializing and then deserializing
your object tree does not violate other assumptions you have made -- this is
why, for example, I cannot simply make the pseudo-database in the example app
Serializable -- when it's reloaded, the assumption that there is only one root
of the tree would now be violated.
>
> Thanks, Hal
>
Craig
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 24, 2001 12:26 PM
> To: [EMAIL PROTECTED]
> Subject: 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/MessageResourcesFa
> ctory.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/MessageResourcesFa
> ctory.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/MessageResourcesFa
> ctory.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 MessageResources instances. The general
> usage
> * pattern for this class is:
> @@ -78,10 +81,10 @@
> *
> *
> * @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
> * MessageResourcesFactory instances.
> */
> -protected static Class clazz = null;
> +protected static transient Class clazz = null;
>
>/**
RE: cvs commit: jakarta-struts/src/share/org/apache/struts/util MessageResourcesFactory.java
Thanks, this will make Weblogic users very happy. I am curious why the Class
variable had to be made transient since it implements Serializable. It would
be nice to know for future reference. Does it have to do with it storing a
reference to a Class loaded by a different class loader?
Thanks, Hal
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 24, 2001 12:26 PM
To: [EMAIL PROTECTED]
Subject: 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/MessageResourcesFa
ctory.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/MessageResourcesFa
ctory.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/MessageResourcesFa
ctory.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 MessageResources instances. The general
usage
* pattern for this class is:
@@ -78,10 +81,10 @@
*
*
* @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
* MessageResourcesFactory instances.
*/
-protected static Class clazz = null;
+protected static transient Class clazz = null;
/**
Re: Could Struts manage InitialContext's as well as DataSources?
[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... > Some of the considerations you identify below are why managing the JNDI InitialContext is really the job of the container. All J2EE-compliant containers already do this for you, and many other containers (such as Tomcat 4.0) are adding support for it as well. In all such cases, trying to manage the initial context at the application level (which is where Struts lives) would interfere with the container-provided support, and/or be prevented by security managers employed by the container anyway. If you are running in an app server environment that allows you to identify data sources in the web.xml file, and access them through a JNDI InitialContext (in the standard J2EE manner), I would suggest that you use that approach. Craig > > Consider the following fragment of XML that might be taken from a > struts-config.xml... > > > 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)> > value > value > > ... > > > > 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. In most environments, the context is actually per-webapp. This gets really interesting to implement when there is no a priori association with a particular request thread to a particular app. > > 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. This is one of the main reasons that EJB servers are doing their own integrations with a servlet container (such as the way that EBoss uses Tomcat 3.2). > 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. I would picture the relationship like this: Application <--ServletAPI--> Servlet Container <--JAAS API-->Security Realm In other words, how the servlet container looks up usernames and passwords is totally invisible to the application -- all you do is define what security roles you want to use to protect the various URIs in your application. Many servlet containers today provide a proprietary API in the spot where JAAS is shown in the above picture. For example, in Tomcat 4.0, you can create your own implementation of org.apache.catalina.Realm to interface to any source of usernames and passwords that you want. But it is all "behind the curtain" from the viewpoint of the web application. > > > Thoughts? > > Regards, > James W. > Craig
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 MessageResources instances. The general usage
* pattern for this class is:
@@ -78,10 +81,10 @@
*
*
* @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
* MessageResourcesFactory instances.
*/
-protected static Class clazz = null;
+protected static transient Class clazz = null;
/**
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... > > > 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)> > value > value > > ... > > > > 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. > --
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
