[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...
>
> <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.
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
