[GUMP] Build Failure - jakarta-tomcat-jk-ant

[Craig McClanahan]

This email is autogenerated from the output from:



Buildfile: build.xml does not exist!
Build failed

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

getServerPort

[Doug Davis]

Just wondering if anyone knows about the status of:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13172
I'm using Tomcat 4.1.18 and getServerPort seems to still only return 80
even though its running on port 8080.
thanks,
-Dug


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 16449] - Race condition when compiling jsp pages

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16449

Race condition when compiling jsp pages

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |



--- Additional Comments From [EMAIL PROTECTED]  2003-01-28 15:24 ---

Because other people seem to want this patch as well as me, I would like to 
reopen the bug, or atleast get a vote from some of the other commiters.

Remy -- if you want to close it again that is fine, I will not reopen it, I 
just want more people to take a look at it and see if the preformance decrease 
is realy there and weight that with a code base that works %100 of the time vs. 
one that works in "most" cases.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[5.0] Exception at startup...

[Jeanfrancois Arcand]

Hi,

is somebody seeing that error when starting Tomcat  with the latest 
workspace:

org.apache.webapp.admin.ApplicationServlet
java.lang.ClassNotFoundException: org.apache.webapp.admin.ApplicationServlet
   at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:
1307)
   at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:
1154)
   at 
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:888)

   at 
org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:825)
   at 
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:36
55)
   at 
org.apache.catalina.core.StandardContext.start(StandardContext.java:3900)
   at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:822
)
   at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:808)
   at 
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632)
   at 
org.apache.catalina.core.StandardHostDeployer.addChild(StandardHostDeployer.ja

Seems classes are not created under 
server/webapps/admin/WEB-INF/classes/org/apache/webapp/admin.

Thanks,

-- Jeanfrancois


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-catalina/webapps/admin build.xml

[jfarcand]

jfarcand2003/01/28 08:37:20

  Modified:webapps/admin build.xml
  Log:
  Fix a bug introduced by the addition of common modeler. Now the Admin tool will 
compile properly when you use a fresh workspace ;-)
  
  Revision  ChangesPath
  1.6   +2 -2  jakarta-tomcat-catalina/webapps/admin/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/admin/build.xml,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- build.xml 5 Dec 2002 15:59:03 -   1.5
  +++ build.xml 28 Jan 2003 16:37:20 -  1.6
  @@ -59,7 +59,7 @@
classpath="${jmx.jar}" />
   
  + classpath="${commons-modeler.jar}:${jmx.jar}"/>
   
  @@ -190,7 +190,7 @@
   
 
 
  -
  +  
   mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: 

Re: JspC compile JSP with JSTL

[Henri Gomez]

Jeanfrancois Arcand wrote:

Replace the xercesImpl.jar with Xerces 2.1.0. There is a bug in Xerces 
that cause that strage error.,

Or use the Xerces 2.3.0 which should fix such error ;)



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: JspC compile JSP with JSTL

[Jack Lauman]

Kelly:

The "--" is a known bug in a previous version of xerces.  xerces 2.3.0
was released in the last 24 hrs. ad is supposed to cure the problem.
Let me know if it works.

Regards,

Jack Lauman
nwcascades.com

Kelly Chen wrote:
> 
> I just wonder if anyone have done this before. I am using JspC to
> compile JSP from the command line.  It was working OK until I tried to
> use JSTL. As soon as I add the following lines to the to be compiled JSP
> <%@ taglib prefix="c" uri="http://java.sun.com/jstl/core"; %>
> 
> JspC starts to run into error. I debug a bit more into Jasper, the root
> problem is caused by a SAX exception
> 
>   [jasper2] [TldLocationsCache] tldConfigJar(/WEB-INF/lib/standard.jar): Process
> ing entry 'META-INF/c.tld'
>   [jasper2] Parsing /WEB-INF/lib/standard.jar
>   [jasper2] The string "--" is not permitted within comments.+ line307
>   [jasper2] org.xml.sax.SAXParseException: The string "--" is not permitted with
> in comments.
>  [jasper2] at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
>  [jasper2] at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Sour
> e)
>  [jasper2] at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:
> 6)
>  [jasper2] at org.apache.jasper.xmlparser.ParserUtils.parseXMLDocument(Pars
> rUtils.java:171)
>  [jasper2] at org.apache.jasper.compiler.TldLocationsCache.parseTldForUri(T
> dLocationsCache.java:288)
>  [jasper2] at org.apache.jasper.compiler.TldLocationsCache.tldConfigJar(Tld
> ocationsCache.java:254)
>  [jasper2] at org.apache.jasper.compiler.TldLocationsCache.processJars(TldL
> cationsCache.java:218)
> .
> 
> I couldn't really make much sense out of the error message. the standard.jar is 
>jakarta-taglibs, standard-1.0.2. I have been trying to use different version of 
>dom/sax parser, different version of Jasper library. The result is all the same. Do I 
>miss anything obvious?
> 
> I know Jasper supports 1.2 JSTL and it must have been worked from Tomcat, because I 
>have seen UI page shows JSP with the core taglib without issue. I just couldn't 
>figure why JspC couldn't do the same.
> 
> --
> Kelly Chen   Tumbleweed Communication Corp.
> T:650-216-2043   700 Saginaw Drive
> F:650-216-2565   Redwood City, CA 94063
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[5.0] Splitting authentication and authorization.

[Jeanfrancois Arcand]

Hi,

since the last time I've  proposed to split 
Authentication/Authorization, we have moved to JMX Listerner as hooks 
and standardize on JMX, I would like to re-open the discussion on 
splitting the behaviour. Mainly, I would like to move three Realm 
methods into an Authorizer interface and use the current Valve mechanism 
as the first implementation.. The Authorizer will define:

public boolean 
hasResourcePermission(HttpRequest,HttpResponse,SecurityConstraint);
public boolean 
hasUserDataPermission(HttpRequest,HttpResponse,SecurityConstraint);
public boolean hasRolePermission(HttpRequest, 
HttpResponse,SecurityConstraint, String role);

I would like to see a clear distinction between Authorization and 
Authentication. That will also allow third party  implementation of JSR 
115 (and the upcoming JSP on Authentication) to be more easily 
implemented in Tomcat.

The first implementation will be a re-factoring of the current code. 
Once completed, we should talk about having an JSR 115 implementation 
(requires by default the Security Manager) or something customized for 
Tomcat using JAAS.

The other solution is to move the Authenticator and Realm concept  into 
coyote as JMX listener and add the Autorizer logic there(will require a 
CoyoteChain or something simliar to StandardPipeline). It is a major 
refactoring and I cannot sign on a major task like that (but I can help 
if we decide its the best decision). But I would favor a Valve for now 
(the logic will be re-usable if we decide to move it into coyote). 
That's what we call the two phases commit :-)

Throughts?

-- Jeanfrancois






--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper - New directory

[remm]

remm2003/01/28 10:13:41

  jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper - New 
directory

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper Mapper.java MappingData.java

[remm]

remm2003/01/28 10:14:51

  Added:   util/java/org/apache/tomcat/util/http/mapper Mapper.java
MappingData.java
  Log:
  - Add new mapper. This has a dependency on JNDI (is that ok ?).
  
  Revision  ChangesPath
  1.1  
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper/Mapper.java
  
  Index: Mapper.java
  ===
  /*
   * 
   *
   * The Apache Software License, Version 1.1
   *
   * Copyright (c) 1999 The Apache Software Foundation.  All rights 
   * reserved.
   *
   * Redistribution and use in source and binary forms, with or without
   * modification, are permitted provided that the following conditions
   * are met:
   *
   * 1. Redistributions of source code must retain the above copyright
   *notice, this list of conditions and the following disclaimer. 
   *
   * 2. Redistributions in binary form must reproduce the above copyright
   *notice, this list of conditions and the following disclaimer in
   *the documentation and/or other materials provided with the
   *distribution.
   *
   * 3. The end-user documentation included with the redistribution, if
   *any, must include the following acknowlegement:  
   *   "This product includes software developed by the 
   *Apache Software Foundation (http://www.apache.org/)."
   *Alternately, this acknowlegement may appear in the software itself,
   *if and wherever such third-party acknowlegements normally appear.
   *
   * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
   *Foundation" must not be used to endorse or promote products derived
   *from this software without prior written permission. For written 
   *permission, please contact [EMAIL PROTECTED]
   *
   * 5. Products derived from this software may not be called "Apache"
   *nor may "Apache" appear in their names without prior written
   *permission of the Apache Group.
   *
   * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
   * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
   * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
   * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
   * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
   * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
   * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
   * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
   * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
   * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
   * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
   * SUCH DAMAGE.
   * 
   *
   * This software consists of voluntary contributions made by many
   * individuals on behalf of the Apache Software Foundation.  For more
   * information on the Apache Software Foundation, please see
   * .
   *
   * [Additional notices, if required by prior licensing conditions]
   *
   */ 
  package org.apache.tomcat.util.http.mapper;
  
  import org.apache.tomcat.util.buf.CharChunk;
  import org.apache.tomcat.util.buf.MessageBytes;
  
  /**
   * Mapper, which implements the servlet API mapping rules (which are derived
   * from the HTTP rules).
   *
   * @author Remy Maucherat
   */
  public final class Mapper {
  
  
  // - Instance Variables
  
  
  /**
   * Array containing the virtual hosts definitions.
   */
  protected Host[] hosts = new Host[0];
  
  
  /**
   * Default host name.
   */
  protected String defaultHostName = null;
  
  
  /**
   * Flag indicating if physical welcome files are to be processed by this
   * mapper. Some default servlets may not want this, so this may be disabled
   * here.
   */
  protected boolean processWelcomeResources = true;
  
  
  // - Public Methods
  
  
  /**
   * Get default host.
   * 
   * @return Default host name
   */
  public String getDefaultHostName() {
  return defaultHostName;
  }
  
  
  /**
   * Set default host.
   * 
   * @param name Default host name
   */
  public void setDefaultHostName(String defaultHostName) {
  this.defaultHostName = defaultHostName;
  }
  
  
  /**
   * Get flag value indicating whether or not welcome files are processed by 
   * the mapper.
   * 
   * @return Value of the processWelcomeResources flag
   */
  public boolean getProcessWelcomeResources() {
  return processWelcomeResources;
  }
  
  
 

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet JspServlet.java

[remm]

remm2003/01/28 10:15:49

  Modified:jasper2/src/share/org/apache/jasper/servlet JspServlet.java
  Log:
  - IMO, this should be debug information (not info).
  
  Revision  ChangesPath
  1.19  +13 -13
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspServlet.java
  
  Index: JspServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspServlet.java,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- JspServlet.java   22 Jan 2003 20:39:29 -  1.18
  +++ JspServlet.java   28 Jan 2003 18:15:49 -  1.19
  @@ -221,19 +221,19 @@
   
   boolean precompile = preCompile(request);
   
  - if (log.isInfoEnabled()) {  
  - log.info("JspEngine --> " + jspUri);
  - log.info("\t ServletPath: " + request.getServletPath());
  - log.info("\tPathInfo: " + request.getPathInfo());
  - log.info("\tRealPath: " + context.getRealPath(jspUri));
  - log.info("\t  RequestURI: " + request.getRequestURI());
  - log.info("\t QueryString: " + request.getQueryString());
  - log.info("\t  Request Params: ");
  + if (log.isDebugEnabled()) { 
  + log.debug("JspEngine --> " + jspUri);
  + log.debug("\t ServletPath: " + request.getServletPath());
  + log.debug("\tPathInfo: " + request.getPathInfo());
  + log.debug("\tRealPath: " + context.getRealPath(jspUri));
  + log.debug("\t  RequestURI: " + request.getRequestURI());
  + log.debug("\t QueryString: " + request.getQueryString());
  + log.debug("\t  Request Params: ");
Enumeration e = request.getParameterNames();
while (e.hasMoreElements()) {
String name = (String) e.nextElement();
  - log.info("\t\t " + name + " = " +
  -  request.getParameter(name));
  + log.debug("\t\t " + name + " = " +
  +  request.getParameter(name));
}
}
   serviceJspFile(request, response, jspUri, null, precompile);
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] New mapper

[Remy Maucherat]

Costin Manolache wrote:

Remy Maucherat wrote:

If the question is about using JMX1.2 - it was alredy proposed, and it
seems nobody objected ( but nobody did it either ). If you want to do
that - all you need is update the mbean descriptors, and change all the
arrays to use the JNI names ( [Ljava.lang.String; instead of
java.lang.String[] ). And of course - fix download to get jmxri instead
of mx4j. 

When MX4J implements 1.2, we'll switch back.
I'm using JMXRI1.2 - and so far it works very nice. 

Regarding the registration listener: there are 2 issues you need to 
be carefull. First, it would be good if the code is independent of
the load order - i.e. listen for notifications but also do a query for
the existing objects. You can do that using JMX query, or by
using the attributes. After you take care of the existing mappings, 
you can start listening for registration - you can do both with plain
JMX1.1.

Speaking of which, I'm missing a registration for the hosts (I don't 
know if it's defined in JSR 77).
Could we add some custom attributes on the object name for wrapper 
(giving the mapping), as well as the host registration, and still comply 
with the spec (I'd say yes, but ...) ?

Thanks,
Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] New mapper

[Remy Maucherat]

Costin Manolache wrote:

Remy Maucherat wrote:


If the question is about using JMX1.2 - it was alredy proposed, and it
seems nobody objected ( but nobody did it either ). If you want to do
that - all you need is update the mbean descriptors, and change all the
arrays to use the JNI names ( [Ljava.lang.String; instead of
java.lang.String[] ). And of course - fix download to get jmxri instead
of mx4j. 

When MX4J implements 1.2, we'll switch back.
I'm using JMXRI1.2 - and so far it works very nice. 

Ok.

The new mapper works with my simple test cases and uses some proven (but 
basic) sorting algorithms. It appears to be fast, although the algorithm 
cost is greater than using a hashtable or a tree. Anyway, it should be a 
lot faster than the old mapper (aahhh, zero garbage mapping :-D ), but I 
have to wait until I've integrated it with Catalina to know how much.

The mapper has a currently unused dependency on JNDI, and I plan to put 
it in the org.apache.tomcat.util.http.mapper package.

I'll use the new fields it introduces to optimize whatever in the 
pipeline was not good:
- Checks for /WEB-INF and /META-INF
- B2C conversion for the URI; the encoding will be configurable with an 
attribute on the connector (people have been asking for it for some 
reason, instead of using UTF-8 :-( ), and will feature a Nasty Cast (TM) 
mode for "ISO-8859-1"
- (later) Request dispatcher mapping; I think request dispatching speed 
is very important as it is (ab)used by popular frameworks like Struts

Regarding the registration listener: there are 2 issues you need to 
be carefull. First, it would be good if the code is independent of
the load order - i.e. listen for notifications but also do a query for
the existing objects. You can do that using JMX query, or by
using the attributes. After you take care of the existing mappings, 
you can start listening for registration - you can do both with plain
JMX1.1.

How can I listen to registrations with JMX 1.1 ? In 1.2, this is quite 
obvious, but I think I missed it in 1.1. The static queries are of 
course similar.

I don't know if all the components are registered - we do have the Context
and Servlet, but you'll need to make sure the Context mbean is exposing the
mappings. Unfortunately JSR77 ( or other standards I know ) do not define
any standard attribute that a "WebModule" mbean would use to expose
supported mappings - so the code will remain dependent of catalina, but
with less cupling.


That's a problem. Too bad ...


BTW, I am now able to create Context mbeans and have them registered 
automatically - and I'll try to get the same working for Valves, Connectors
and JkHandlers. If this is used with an mbean server that supports
reloading ( like jboss.mx ) - we'll be able to replace modules without
restarting the VM ( which is pretty cool ).

That's good.

Remy



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardContext.java

[jfarcand]

jfarcand2003/01/28 10:18:39

  Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java
  Log:
  Fix bugtraq 4782776 The is-xml element of a jsp-property-group doesn't work as 
specified in JSP 2.0
  
  Revision  ChangesPath
  1.15  +10 -4 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java
  
  Index: StandardContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- StandardContext.java  27 Jan 2003 23:27:26 -  1.14
  +++ StandardContext.java  28 Jan 2003 18:18:39 -  1.15
  @@ -1605,6 +1605,12 @@
   if (servletName == null) {
   servletName = "jsp";
   }
  +
  +// Properly handle file that are considered to be a jsp.
  +if (pattern.indexOf("*.") > 0){
  +pattern = pattern.substring(pattern.lastIndexOf("*"));
  +servletName = "jsp";
  +}   
   addServletMapping(pattern, servletName);
   }
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5 CoyoteAdapter.java CoyoteConnector.java CoyoteRequest.java

[remm]

remm2003/01/28 10:19:39

  Modified:coyote/src/java/org/apache/coyote/tomcat5 CoyoteAdapter.java
CoyoteConnector.java CoyoteRequest.java
  Log:
  - "Use" the new mapper.
  - Since the mapper is not populated, it doesn't do anything.
  
  Revision  ChangesPath
  1.8   +14 -6 
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteAdapter.java
  
  Index: CoyoteAdapter.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteAdapter.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- CoyoteAdapter.java16 Jan 2003 21:58:14 -  1.7
  +++ CoyoteAdapter.java28 Jan 2003 18:19:38 -  1.8
  @@ -77,8 +77,10 @@
   import org.apache.coyote.Request;
   import org.apache.coyote.Response;
   
  +import org.apache.catalina.Context;
   import org.apache.catalina.Globals;
   import org.apache.catalina.Logger;
  +import org.apache.catalina.Wrapper;
   import org.apache.catalina.util.StringManager;
   
   
  @@ -214,7 +216,7 @@
*/
   protected void postParseRequest(Request req, CoyoteRequest request,
   Response res, CoyoteResponse response)
  -throws IOException {
  +throws Exception {
   // XXX the processor needs to set a correct scheme and port prior to this 
point, 
   // in ajp13 protocols dont make sense to get the port from the connector..
   request.setSecure(req.scheme().equals("https"));
  @@ -249,7 +251,7 @@
   
   // Parse cookies
   parseCookies(req, request);
  - 
  +
   // Set the SSL properties
if( request.isSecure() ) {
res.action(ActionCode.ACTION_REQ_SSL_ATTRIBUTE,
  @@ -265,6 +267,12 @@
   if (principal != null) {
   request.setUserPrincipal(new CoyotePrincipal(principal));
   }
  +
  +// Request mapping
  +connector.getMapper().map(req.serverName(), req.decodedURI(), 
  +  request.getMappingData());
  +request.setContext((Context) request.getMappingData().context);
  +request.setWrapper((Wrapper) request.getMappingData().wrapper);
   
   }
   
  
  
  
  1.10  +26 -8 
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteConnector.java
  
  Index: CoyoteConnector.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteConnector.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- CoyoteConnector.java  16 Jan 2003 21:58:14 -  1.9
  +++ CoyoteConnector.java  28 Jan 2003 18:19:38 -  1.10
  @@ -60,9 +60,17 @@
   
   package org.apache.coyote.tomcat5;
   
  -
   import java.util.Vector;
   
  +import javax.management.ObjectName;
  +import javax.management.MBeanServer;
  +import javax.management.MBeanRegistration;
  +
  +import org.apache.commons.modeler.Registry;
  +import org.apache.commons.logging.Log;
  +import org.apache.commons.logging.LogFactory;
  +
  +import org.apache.tomcat.util.http.mapper.Mapper;
   import org.apache.tomcat.util.IntrospectionUtils;
   
   import org.apache.coyote.Adapter;
  @@ -81,12 +89,6 @@
   import org.apache.catalina.net.ServerSocketFactory;
   import org.apache.catalina.util.LifecycleSupport;
   import org.apache.catalina.util.StringManager;
  -import org.apache.commons.modeler.Registry;
  -import org.apache.commons.logging.Log;
  -import org.apache.commons.logging.LogFactory;
  -import javax.management.ObjectName;
  -import javax.management.MBeanServer;
  -import javax.management.MBeanRegistration;
   
   
   /**
  @@ -321,6 +323,12 @@
   private Adapter adapter = null;
   
   
  + /**
  +  * Mapper.
  +  */
  + private Mapper mapper = new Mapper();
  +
  +
   // - Properties
   
   
  @@ -580,6 +588,16 @@
   return (info);
   
   }
  +
  +
  + /**
  +  * Return the mapper.
  +  */
  + public Mapper getMapper() {
  +
  + return (mapper);
  +
  + }
   
   
   /**
  
  
  
  1.15  +46 -6 
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteRequest.java
  
  Index: CoyoteRequest.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteRequest.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- CoyoteRequest.java5 Jan 2003 11:24:22 -   1.14
  +++ CoyoteRequest.java28 Jan 2003 18:19:38 -  1.15
  @@ -109,6 +109,7 @@
   import org.apache.catalina.Connector;
   import org.ap

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina Request.java

[remm]

remm2003/01/28 10:20:05

  Modified:catalina/src/share/org/apache/catalina Request.java
  Log:
  - "Use" the new mapper.
  - Since the mapper is not populated, it doesn't do anything.
  
  Revision  ChangesPath
  1.3   +20 -4 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Request.java
  
  Index: Request.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Request.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- Request.java  25 Nov 2002 21:02:21 -  1.2
  +++ Request.java  28 Jan 2003 18:20:05 -  1.3
  @@ -150,6 +150,22 @@
   
   
   /**
  + * Return the Host within which this Request is being processed.
  + */
  +public Host getHost();
  +
  +
  +/**
  + * Set the Host within which this Request is being processed.  This
  + * must be called as soon as the appropriate Host is identified, and
  + * before the Request is passed to a context.
  + *
  + * @param host The newly associated Host
  + */
  +public void setHost(Host host);
  +
  +
  +/**
* Return descriptive information about this Request implementation and
* the corresponding version number, in the format
* /.
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardEngineMapper.java

[remm]

remm2003/01/28 10:20:48

  Modified:catalina/src/share/org/apache/catalina/core
StandardEngineMapper.java
  Log:
  - "Use" the new mapper.
  - Since the mapper is not populated, it doesn't do anything.
  
  Revision  ChangesPath
  1.2   +8 -4  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardEngineMapper.java
  
  Index: StandardEngineMapper.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardEngineMapper.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- StandardEngineMapper.java 18 Jul 2002 16:48:12 -  1.1
  +++ StandardEngineMapper.java 28 Jan 2003 18:20:48 -  1.2
  @@ -177,6 +177,10 @@
*/
   public Container map(Request request, boolean update) {
   
  +// Has this request already been mapped?
  +if (update && (request.getHost() != null))
  +return (request.getHost());
  +
   int debug = engine.getDebug();
   
   // Extract the requested server name
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardEngineValve.java

[remm]

remm2003/01/28 10:21:16

  Modified:catalina/src/share/org/apache/catalina/core
StandardEngineValve.java
  Log:
  - Remove useless code (the protocol layer will take care of that check).
  
  Revision  ChangesPath
  1.2   +4 -15 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardEngineValve.java
  
  Index: StandardEngineValve.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardEngineValve.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- StandardEngineValve.java  18 Jul 2002 16:48:13 -  1.1
  +++ StandardEngineValve.java  28 Jan 2003 18:21:16 -  1.2
  @@ -148,17 +148,6 @@
   return; // NOTE - Not much else we can do generically
   }
   
  -// Validate that any HTTP/1.1 request included a host header
  -HttpServletRequest hrequest = (HttpServletRequest) request;
  -if ("HTTP/1.1".equals(hrequest.getProtocol()) &&
  -(hrequest.getServerName() == null)) {
  -((HttpServletResponse) response.getResponse()).sendError
  -(HttpServletResponse.SC_BAD_REQUEST,
  - sm.getString("standardEngine.noHostHeader",
  -  request.getRequest().getServerName()));
  -return;
  -}
  -
   // Select the Host to be used for this Request
   StandardEngine engine = (StandardEngine) getContainer();
   Host host = (Host) engine.map(request, true);
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] Splitting authentication and authorization.

[Costin Manolache]

Wouldn't be better to just standardize on JAAS for authentication
and stop using our own private interfaces ? 
AFAIK JAAS is included in JDK1.3+ - and available to older VMs. 

The only problem is getUserRoles(), which is not supported very well
by JAAS. 

I'm fine with implementing them as valves - I'm not sure the interface
you're proposing is the best choice. 

+1 on spliting between Authorization and Authentication _and_ user
management ( the user database ).  

I would preffer doing the "right" thing - and using existing standards
APIs where it is possible - JAAS for authentication is pretty clear.

I would be +1 on using the Policy for authorization - my understanding is 
that it _does_not_ require the security manager to be enabled. All the code
I've seen is checking for a security manager - because the contract is that
without a secuirty manager you shouldn't enforce the policy. However the
Policy object ( or some implementation ) should just work without the SM.

Regarding use of JMX - well, JMX should be used to enable management of
whatever authenticator/authorizer module we use ( attributes, runtime info,
etc ). We should use JMX notification for callbacks - but only when a
standard API doesn't exists ( or if the standard is too bad or unusable ).

Costin

Jeanfrancois Arcand wrote:

> Hi,
> 
> since the last time I've  proposed to split
> Authentication/Authorization, we have moved to JMX Listerner as hooks
> and standardize on JMX, I would like to re-open the discussion on
> splitting the behaviour. Mainly, I would like to move three Realm
> methods into an Authorizer interface and use the current Valve mechanism
> as the first implementation.. The Authorizer will define:
> 
> public boolean
> hasResourcePermission(HttpRequest,HttpResponse,SecurityConstraint);
> public boolean
> hasUserDataPermission(HttpRequest,HttpResponse,SecurityConstraint);
> public boolean hasRolePermission(HttpRequest,
> HttpResponse,SecurityConstraint, String role);
> 
> I would like to see a clear distinction between Authorization and
> Authentication. That will also allow third party  implementation of JSR
> 115 (and the upcoming JSP on Authentication) to be more easily
> implemented in Tomcat.
> 
> The first implementation will be a re-factoring of the current code.
> Once completed, we should talk about having an JSR 115 implementation
> (requires by default the Security Manager) or something customized for
> Tomcat using JAAS.
> 
> The other solution is to move the Authenticator and Realm concept  into
> coyote as JMX listener and add the Autorizer logic there(will require a
> CoyoteChain or something simliar to StandardPipeline). It is a major
> refactoring and I cannot sign on a major task like that (but I can help
> if we decide its the best decision). But I would favor a Valve for now
> (the logic will be re-usable if we decide to move it into coyote).
> That's what we call the two phases commit :-)
> 
> Throughts?
> 
> -- Jeanfrancois



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-catalina/webapps/docs/config coyote.xml jk2.xml

[remm]

remm2003/01/28 10:24:43

  Modified:webapps/docs/config coyote.xml jk2.xml
  Log:
  - Small docs fixes.
  
  Revision  ChangesPath
  1.4   +1 -1  jakarta-tomcat-catalina/webapps/docs/config/coyote.xml
  
  Index: coyote.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/config/coyote.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- coyote.xml27 Jan 2003 18:32:08 -  1.3
  +++ coyote.xml28 Jan 2003 18:24:42 -  1.4
  @@ -137,7 +137,7 @@
 specifies the minimum amount of data before the output is compressed). If
 the content-length is not known and compression is set to "on" or more
 aggressive, the output will also be compressed. If not specified, this
  -  attribute is set to "false".
  +  attribute is set to "off".
   
   
   
  
  
  
  1.5   +1 -1  jakarta-tomcat-catalina/webapps/docs/config/jk2.xml
  
  Index: jk2.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/config/jk2.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- jk2.xml   15 Jan 2003 03:40:44 -  1.4
  +++ jk2.xml   28 Jan 2003 18:24:42 -  1.5
  @@ -148,7 +148,7 @@
   
   
   
  -  Please refer to the Coyote JK 2 documentation 
  +  Please refer to the Coyote JK 2 
documentation 
for HOWTOs and complete configuration information.
   
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [5.0] Splitting authentication and authorization.

[Filip Hanik]

In JBoss they have the following problem with JAAS.
You protect /myapp/secure, the user logs on. When the user is in another subcontext, 
for example,
/myapp/nonsecure/ JAAS doesn't return a user principal at all, because that subcontext 
was not marked for being secure.

just an fyi
Filip

-Original Message-
From: Costin Manolache [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 28, 2003 10:18 AM
To: [EMAIL PROTECTED]
Subject: Re: [5.0] Splitting authentication and authorization.


Wouldn't be better to just standardize on JAAS for authentication
and stop using our own private interfaces ? 
AFAIK JAAS is included in JDK1.3+ - and available to older VMs. 

The only problem is getUserRoles(), which is not supported very well
by JAAS. 

I'm fine with implementing them as valves - I'm not sure the interface
you're proposing is the best choice. 

+1 on spliting between Authorization and Authentication _and_ user
management ( the user database ).  

I would preffer doing the "right" thing - and using existing standards
APIs where it is possible - JAAS for authentication is pretty clear.

I would be +1 on using the Policy for authorization - my understanding is 
that it _does_not_ require the security manager to be enabled. All the code
I've seen is checking for a security manager - because the contract is that
without a secuirty manager you shouldn't enforce the policy. However the
Policy object ( or some implementation ) should just work without the SM.

Regarding use of JMX - well, JMX should be used to enable management of
whatever authenticator/authorizer module we use ( attributes, runtime info,
etc ). We should use JMX notification for callbacks - but only when a
standard API doesn't exists ( or if the standard is too bad or unusable ).

Costin

Jeanfrancois Arcand wrote:

> Hi,
> 
> since the last time I've  proposed to split
> Authentication/Authorization, we have moved to JMX Listerner as hooks
> and standardize on JMX, I would like to re-open the discussion on
> splitting the behaviour. Mainly, I would like to move three Realm
> methods into an Authorizer interface and use the current Valve mechanism
> as the first implementation.. The Authorizer will define:
> 
> public boolean
> hasResourcePermission(HttpRequest,HttpResponse,SecurityConstraint);
> public boolean
> hasUserDataPermission(HttpRequest,HttpResponse,SecurityConstraint);
> public boolean hasRolePermission(HttpRequest,
> HttpResponse,SecurityConstraint, String role);
> 
> I would like to see a clear distinction between Authorization and
> Authentication. That will also allow third party  implementation of JSR
> 115 (and the upcoming JSP on Authentication) to be more easily
> implemented in Tomcat.
> 
> The first implementation will be a re-factoring of the current code.
> Once completed, we should talk about having an JSR 115 implementation
> (requires by default the Security Manager) or something customized for
> Tomcat using JAAS.
> 
> The other solution is to move the Authenticator and Realm concept  into
> coyote as JMX listener and add the Autorizer logic there(will require a
> CoyoteChain or something simliar to StandardPipeline). It is a major
> refactoring and I cannot sign on a major task like that (but I can help
> if we decide its the best decision). But I would favor a Valve for now
> (the logic will be re-usable if we decide to move it into coyote).
> That's what we call the two phases commit :-)
> 
> Throughts?
> 
> -- Jeanfrancois



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

JVM Error

[Alexander Leyke]

I've seen similar problems - java is very sensitive to each thread
beeing 'registered'. My understanding is that attaching the
thread will set all the TLDs that are needed, and jk2 is calling the 
attach method - so I don't know what is wrong here.
My bet would be on thread creation - I would add some printf with the
TID serving the request ( before attaching the thread ). One thing that
may happen in 10 minutes is the thread management code adding or removing
threads. 

Costin
 

Right, something like that. The deepest I can debug is jk2_vm_attach 
function in jk_vm_default.c module. The function makes a call to JNI's 
GetEnv method, and if result indicates the thread is not attached, calls 
AttachCurrentThread. Well, I see Web server create a brand new thread, 
and GetEnv returns an environment pointer for it... This is obviously 
wrong and causes a problem later when JK2 attempts to call a static 
method in Tomcat.
I thought GetEnv may be broken somehow and altered the code so Attach 
always happens. No luck either - this time access violation happens in 
AttachCurrentThread and stack backtrace looks like this:

jk2_vm_attach(env = 0x1cc220, jkvm = 0x224fc0)
jni_AttachCurrentThread(0xfe0a0338, 0x580f00, 0x0, 0xfe092000, 
0xee171668, 0x0)
Thread::initialize_thread_local_storage(0x580f00, 0x6, 0x580f00, 0x0, 
0x0, 0x0)
ThreadLocalStorage::set_thread(0xfe092000, 0x580f00, 0x580f00, 
0xee17156c, 0x0, 0x0)
report_fatal(0x42, 0xfe092000, 0xfe0482a8, 0xee171, 0xfe092000, 0xee1714ac)
report_error(0xd4, 0xee170b7c, 0x42, 0xfe028208, 0xfe0ffddc, 0xfe092000)
Thread::print(0x580f00, 0xfe092000, 0x1e8, 0xee170, 0xfe092000, 0xee1702ec)
os::get_priority(0x580f00, 0xee1702ec, 0xfe092000, 0xee17033c, 
0x7fff, 0xfe092000)
os::get_native_priority(0x580f00, 0xee170284, 0x0, 0xee170b50, 0x79, 
0xee170357)

The offending thread doesn't seem to differ in any way (e.g., stack 
size, priority attributes) from previous Web server request thread which 
successfully attached itself to JVM. Am I missing some step here?

Thanks,
Alex


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] Splitting authentication and authorization.

[Jeanfrancois Arcand]

Costin Manolache wrote:


Wouldn't be better to just standardize on JAAS for authentication
and stop using our own private interfaces ? 
AFAIK JAAS is included in JDK1.3+ - and available to older VMs. 

I agree on JAAS too for Authentication if it is available for the 
majority of open source VM  I will first refactor the interface, commit 
them and then start working on JAAS if everybody agree.


The only problem is getUserRoles(), which is not supported very well
by JAAS. 

I'm fine with implementing them as valves - I'm not sure the interface
you're proposing is the best choice. 

Why? To be able to authorize properly, we need at least the Principal 
and the resource (+ the SecurityConstraint from the web.xml).


+1 on spliting between Authorization and Authentication _and_ user
management ( the user database ).  

I would preffer doing the "right" thing - and using existing standards
APIs where it is possible - JAAS for authentication is pretty clear.

I would be +1 on using the Policy for authorization - my understanding is 
that it _does_not_ require the security manager to be enabled.

I'm not sure about that. My understanding was that when you call 
AccessController.checkPermission (that require the Security Manager to 
be turned on), the class will delegate the call to Policy.implies 
implementation. If we don't have the security manager enabled, that 
means we use Policy.implies only. Where did you get the information?

All the code
I've seen is checking for a security manager - because the contract is that
without a secuirty manager you shouldn't enforce the policy. However the
Policy object ( or some implementation ) should just work without the SM.


I'm fine with the idea if we can come up with something that has the 
same behaviour with a SecurityManager. When running under the security 
manager, we should be 115 compliant.


Regarding use of JMX - well, JMX should be used to enable management of
whatever authenticator/authorizer module we use ( attributes, runtime info,
etc ). We should use JMX notification for callbacks - but only when a
standard API doesn't exists ( or if the standard is too bad or unusable ).



-- Jeanfrancois



Costin

Jeanfrancois Arcand wrote:

 

Hi,

since the last time I've  proposed to split
Authentication/Authorization, we have moved to JMX Listerner as hooks
and standardize on JMX, I would like to re-open the discussion on
splitting the behaviour. Mainly, I would like to move three Realm
methods into an Authorizer interface and use the current Valve mechanism
as the first implementation.. The Authorizer will define:

public boolean
hasResourcePermission(HttpRequest,HttpResponse,SecurityConstraint);
public boolean
hasUserDataPermission(HttpRequest,HttpResponse,SecurityConstraint);
public boolean hasRolePermission(HttpRequest,
HttpResponse,SecurityConstraint, String role);

I would like to see a clear distinction between Authorization and
Authentication. That will also allow third party  implementation of JSR
115 (and the upcoming JSP on Authentication) to be more easily
implemented in Tomcat.

The first implementation will be a re-factoring of the current code.
Once completed, we should talk about having an JSR 115 implementation
(requires by default the Security Manager) or something customized for
Tomcat using JAAS.

The other solution is to move the Authenticator and Realm concept  into
coyote as JMX listener and add the Autorizer logic there(will require a
CoyoteChain or something simliar to StandardPipeline). It is a major
refactoring and I cannot sign on a major task like that (but I can help
if we decide its the best decision). But I would favor a Valve for now
(the logic will be re-usable if we decide to move it into coyote).
That's what we call the two phases commit :-)

Throughts?

-- Jeanfrancois
   




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 


 

Re: [5.0] Splitting authentication and authorization.

[Jeanfrancois Arcand]

Filip Hanik wrote:


In JBoss they have the following problem with JAAS.
You protect /myapp/secure, the user logs on. When the user is in another subcontext, for example,
/myapp/nonsecure/ JAAS doesn't return a user principal at all, because that subcontext was not marked for being secure.


Any idea how they manage this scenario (I can look at the code but I 
would prefer some feedback from you first :-) ). Seems we can "patch" 
the problem internaly (if a jaas only solution isn't available).

-- Jeanfrancois




just an fyi
Filip

-Original Message-
From: Costin Manolache [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 28, 2003 10:18 AM
To: [EMAIL PROTECTED]
Subject: Re: [5.0] Splitting authentication and authorization.


Wouldn't be better to just standardize on JAAS for authentication
and stop using our own private interfaces ? 
AFAIK JAAS is included in JDK1.3+ - and available to older VMs. 

The only problem is getUserRoles(), which is not supported very well
by JAAS. 

I'm fine with implementing them as valves - I'm not sure the interface
you're proposing is the best choice. 

+1 on spliting between Authorization and Authentication _and_ user
management ( the user database ).  

I would preffer doing the "right" thing - and using existing standards
APIs where it is possible - JAAS for authentication is pretty clear.

I would be +1 on using the Policy for authorization - my understanding is 
that it _does_not_ require the security manager to be enabled. All the code
I've seen is checking for a security manager - because the contract is that
without a secuirty manager you shouldn't enforce the policy. However the
Policy object ( or some implementation ) should just work without the SM.

Regarding use of JMX - well, JMX should be used to enable management of
whatever authenticator/authorizer module we use ( attributes, runtime info,
etc ). We should use JMX notification for callbacks - but only when a
standard API doesn't exists ( or if the standard is too bad or unusable ).

Costin

Jeanfrancois Arcand wrote:

 

Hi,

since the last time I've  proposed to split
Authentication/Authorization, we have moved to JMX Listerner as hooks
and standardize on JMX, I would like to re-open the discussion on
splitting the behaviour. Mainly, I would like to move three Realm
methods into an Authorizer interface and use the current Valve mechanism
as the first implementation.. The Authorizer will define:

public boolean
hasResourcePermission(HttpRequest,HttpResponse,SecurityConstraint);
public boolean
hasUserDataPermission(HttpRequest,HttpResponse,SecurityConstraint);
public boolean hasRolePermission(HttpRequest,
HttpResponse,SecurityConstraint, String role);

I would like to see a clear distinction between Authorization and
Authentication. That will also allow third party  implementation of JSR
115 (and the upcoming JSP on Authentication) to be more easily
implemented in Tomcat.

The first implementation will be a re-factoring of the current code.
Once completed, we should talk about having an JSR 115 implementation
(requires by default the Security Manager) or something customized for
Tomcat using JAAS.

The other solution is to move the Authenticator and Realm concept  into
coyote as JMX listener and add the Autorizer logic there(will require a
CoyoteChain or something simliar to StandardPipeline). It is a major
refactoring and I cannot sign on a major task like that (but I can help
if we decide its the best decision). But I would favor a Valve for now
(the logic will be re-usable if we decide to move it into coyote).
That's what we call the two phases commit :-)

Throughts?

-- Jeanfrancois
   




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 


 

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core DummyRequest.java

[remm]

remm2003/01/28 11:07:30

  Modified:catalina/src/share/org/apache/catalina/core
DummyRequest.java
  Log:
  - Ooops, missing update.
  
  Revision  ChangesPath
  1.3   +6 -4  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/DummyRequest.java
  
  Index: DummyRequest.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/DummyRequest.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- DummyRequest.java 25 Nov 2002 21:03:50 -  1.2
  +++ DummyRequest.java 28 Jan 2003 19:07:30 -  1.3
  @@ -220,6 +220,8 @@
   public void setConnector(Connector connector) {}
   public Context getContext() { return null; }
   public void setContext(Context context) {}
  +public Host getHost() { return null; }
  +public void setHost(Host host) {}
   public String getInfo() { return null; }
   public Response getResponse() { return null; }
   public void setResponse(Response response) {}
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 16507] New: - Remote Host Filter does not allow wild-card

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16507

Remote Host Filter does not allow wild-card

   Summary: Remote Host Filter does not allow wild-card
   Product: Tomcat 4
   Version: 4.1.18
  Platform: Sun
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


According to the documentation the following is permitted:

  

However, in practice Tomcat will not startup properly when you specify a wild 
card characeter in this regular expression. You can however just 
put "mycompany.com" in the allow field to allow only connections with the 
domain "mycompany.com". Therefore, I'm not sure whether or not Tomcat is 
supposed to support the wild card character.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [5.0] Splitting authentication and authorization.

[Filip Hanik]

http://www.jboss.org/forums/thread.jsp?forum=49&thread=26355&message=3758564&q=userrole#3758564

don't think they had a solution

Filip

-Original Message-
From: Jeanfrancois Arcand [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 28, 2003 10:54 AM
To: Tomcat Developers List
Subject: Re: [5.0] Splitting authentication and authorization.




Filip Hanik wrote:

>In JBoss they have the following problem with JAAS.
>You protect /myapp/secure, the user logs on. When the user is in another subcontext, 
>for example,
>/myapp/nonsecure/ JAAS doesn't return a user principal at all, because that 
>subcontext was not marked for being secure.
>
Any idea how they manage this scenario (I can look at the code but I 
would prefer some feedback from you first :-) ). Seems we can "patch" 
the problem internaly (if a jaas only solution isn't available).

-- Jeanfrancois



>
>just an fyi
>Filip
>
>-Original Message-
>From: Costin Manolache [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, January 28, 2003 10:18 AM
>To: [EMAIL PROTECTED]
>Subject: Re: [5.0] Splitting authentication and authorization.
>
>
>Wouldn't be better to just standardize on JAAS for authentication
>and stop using our own private interfaces ? 
>AFAIK JAAS is included in JDK1.3+ - and available to older VMs. 
>
>The only problem is getUserRoles(), which is not supported very well
>by JAAS. 
>
>I'm fine with implementing them as valves - I'm not sure the interface
>you're proposing is the best choice. 
>
>+1 on spliting between Authorization and Authentication _and_ user
>management ( the user database ).  
>
>I would preffer doing the "right" thing - and using existing standards
>APIs where it is possible - JAAS for authentication is pretty clear.
>
>I would be +1 on using the Policy for authorization - my understanding is 
>that it _does_not_ require the security manager to be enabled. All the code
>I've seen is checking for a security manager - because the contract is that
>without a secuirty manager you shouldn't enforce the policy. However the
>Policy object ( or some implementation ) should just work without the SM.
>
>Regarding use of JMX - well, JMX should be used to enable management of
>whatever authenticator/authorizer module we use ( attributes, runtime info,
>etc ). We should use JMX notification for callbacks - but only when a
>standard API doesn't exists ( or if the standard is too bad or unusable ).
>
>Costin
>
>Jeanfrancois Arcand wrote:
>
>  
>
>>Hi,
>>
>>since the last time I've  proposed to split
>>Authentication/Authorization, we have moved to JMX Listerner as hooks
>>and standardize on JMX, I would like to re-open the discussion on
>>splitting the behaviour. Mainly, I would like to move three Realm
>>methods into an Authorizer interface and use the current Valve mechanism
>>as the first implementation.. The Authorizer will define:
>>
>>public boolean
>>hasResourcePermission(HttpRequest,HttpResponse,SecurityConstraint);
>>public boolean
>>hasUserDataPermission(HttpRequest,HttpResponse,SecurityConstraint);
>>public boolean hasRolePermission(HttpRequest,
>>HttpResponse,SecurityConstraint, String role);
>>
>>I would like to see a clear distinction between Authorization and
>>Authentication. That will also allow third party  implementation of JSR
>>115 (and the upcoming JSP on Authentication) to be more easily
>>implemented in Tomcat.
>>
>>The first implementation will be a re-factoring of the current code.
>>Once completed, we should talk about having an JSR 115 implementation
>>(requires by default the Security Manager) or something customized for
>>Tomcat using JAAS.
>>
>>The other solution is to move the Authenticator and Realm concept  into
>>coyote as JMX listener and add the Autorizer logic there(will require a
>>CoyoteChain or something simliar to StandardPipeline). It is a major
>>refactoring and I cannot sign on a major task like that (but I can help
>>if we decide its the best decision). But I would favor a Valve for now
>>(the logic will be re-usable if we decide to move it into coyote).
>>That's what we call the two phases commit :-)
>>
>>Throughts?
>>
>>-- Jeanfrancois
>>
>>
>
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>
>  
>

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] Splitting authentication and authorization.

[Costin Manolache]

Jeanfrancois Arcand wrote:

> Costin Manolache wrote:
> 
>>Wouldn't be better to just standardize on JAAS for authentication
>>and stop using our own private interfaces ?
>>AFAIK JAAS is included in JDK1.3+ - and available to older VMs.
>>
> I agree on JAAS too for Authentication if it is available for the
> majority of open source VM  I will first refactor the interface, commit
> them and then start working on JAAS if everybody agree.

AFAIK it is available- haven't checked it. Even if it isn't - I hope there
is still a standalone download that can be used with any VM ( like JDK1.2 ).


>>The only problem is getUserRoles(), which is not supported very well
>>by JAAS.
>>
>>I'm fine with implementing them as valves - I'm not sure the interface
>>you're proposing is the best choice.
>>
> Why? To be able to authorize properly, we need at least the Principal
> and the resource (+ the SecurityConstraint from the web.xml).

We already have _far_ too many interfaces ( and base classes, abstract
classes, and so on ). 
Do you expect people to implement this new interface ( instead of JAAS ) ?
As long as a clear standard interface exists ( JAAS ) and we know that it 
can be used ( there is a JAAS plugin for tomcat ) - I see no reason to 
create yet another interface.

Are you going to port LDAP, JAAS, database plugins as well as UserDatabase
to the new interface ? 
Just refactoring the interface and increasing the mess with 33% is not good.
( 33% - because we already have 2 interfaces for this, Realm and
UserDatabase )



>>I would be +1 on using the Policy for authorization - my understanding is
>>that it _does_not_ require the security manager to be enabled.
>>
> I'm not sure about that. My understanding was that when you call
> AccessController.checkPermission (that require the Security Manager to
> be turned on), the class will delegate the call to Policy.implies
> implementation. If we don't have the security manager enabled, that
> means we use Policy.implies only. Where did you get the information?

Why would we call AccessController.checkPermission 

The information about the access control is stored in a PolicyObject. 
If the base implementation requires the security manager ( and I doubt )- we 
can use our own implementation of Policy. We'll have to use our own anyway
for performance optimizations.

At least from the javadoc of Policy and my understanding of java security - 
I can't see any good reason why Policy would require a security manager
( except the fact that this is how most people use it today ).


Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 16508] New: - Response is not being committed after RequestDispatcher forward

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16508

Response is not being committed after RequestDispatcher forward

   Summary: Response is not being committed after RequestDispatcher
forward
   Product: Tomcat 4
   Version: 4.1.18
  Platform: PC
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I upgraged from Tomcat 4.1.12 to 4.1.18 and discovered new behavior with the 
RequestDispatcher.  After the forward method, the response is no longer being 
committed.

I believe this is a bug.  Acording to the Servlet 2.3 spec, section 8.4.  It 
says, "Before the forward method of the RequestDispatcher interface returns, the
response content must be sent and committed, and closed by the servlet 
container."

With tomcat 4.1.18 this is not true.  After the forward method, if you call 
response.isCommitted() it returns false.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 16507] - Remote Host Filter does not allow wild-card

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16507

Remote Host Filter does not allow wild-card





--- Additional Comments From [EMAIL PROTECTED]  2003-01-28 19:56 ---
This may be a problem with the documentation.  The RemoteHost valve
uses the jakarta-regexp API, you can look at the docs for it to find
out what regexp's can be used.

For example a '.' in a regexp means match any single character.
To match a period in a string the '.' has to be escaped as '\.'.
Also '*' means match 0 to N number of times on the previous
character or expression.  So '.*' would match any character,
any number of times.  In your case, a leading '*' caused the
regexp to fail because there was no previous character.

Hope this helps.

Patches to the documentation are welcome. :-)

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

bugzilla 9526

[Amy Roh]

Can anyone point me to the thread of discussion where the bug was 
decided invalid?  I'm trying to close the corresponding bugtraq bug with 
a reason.

Thanks,
Amy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] Splitting authentication and authorization.

[Jeanfrancois Arcand]

Costin Manolache wrote:


Jeanfrancois Arcand wrote:

 

Costin Manolache wrote:

   

Wouldn't be better to just standardize on JAAS for authentication
and stop using our own private interfaces ?
AFAIK JAAS is included in JDK1.3+ - and available to older VMs.

 

I agree on JAAS too for Authentication if it is available for the
majority of open source VM  I will first refactor the interface, commit
them and then start working on JAAS if everybody agree.
   


AFAIK it is available- haven't checked it. Even if it isn't - I hope there
is still a standalone download that can be used with any VM ( like JDK1.2 ).


 

The only problem is getUserRoles(), which is not supported very well
by JAAS.

I'm fine with implementing them as valves - I'm not sure the interface
you're proposing is the best choice.

 

Why? To be able to authorize properly, we need at least the Principal
and the resource (+ the SecurityConstraint from the web.xml).
   


We already have _far_ too many interfaces ( and base classes, abstract
classes, and so on ). 

Not sure I agree. We cannot have 1 interface for everything (Yes we can, 
but we will have to rebuild a lot of things). And having Base classes 
and Interface let the design very open. But that's not the goal of the 
discussion :-)

Do you expect people to implement this new interface ( instead of JAAS ) ?


Yes. JAAS should be used by default, but if someone doesn't want to use 
it, he can switch to the current implementation. The servlet spec 
doesn't requires JAAS for enforcing the web.xml security element..

As long as a clear standard interface exists ( JAAS ) and we know that it 
can be used ( there is a JAAS plugin for tomcat ) - I see no reason to 
create yet another interface.

Remember that JAAS is *not enough* for authorization (that's why JSR 115 
was defined). 115 is one layer on top of JAAS (uses JAAS) We should not 
re-invent something (even with JAAS) but use a known api. In order to do 
that, we need to be able, at authorization time, to call the Policy. 
Right now, this will happen:

AuthenticatorBase -> RealmBase.hasResourcePermission()

instead,as a first step, I recommend

AuthenticatorBase -> AuthorizerBase.hasResourcePermission()

If I follow you properly, you want:

AuthenticatorBase -> TomcatPolicy 
The problem is some pre-processing code will have to reside inside 
Autheticator if we do that like this. That's the reason the logic should 
be delegated to Authorizer (who will call the TomcatPolicy).

Again. I do not want to remove the Valve behaviour for now. And do not 
push JSR 115 also (we should vote on JAAS/115). The current 
implementation is fast and doesn't requires the Security Manager. 
115/JAAS implementation will be slower, for sure (download J2EE 1.4 RI 
beta and do a test with the same web app. You will visually see my point 
:-) ). 115 PFD2 has been modified and I'm sure the performance hit will 
be improved.


Are you going to port LDAP, JAAS, database plugins as well as UserDatabase
to the new interface ? 

That will be easy because authorization methods (hasResourcePermissions, 
hasUserDataPermission and hasRole) were private before Tomcat 5. I've 
moved them to RealmBase in late august (if I remember correctly). Those 
components were not affected. The logic for those methods are guided by 
the Servlet specs, so I don't see why we should implement it using LDAP 
or JAAS. 115 could be a viable solution if people agree.

Just refactoring the interface and increasing the mess with 33% is not good.
( 33% - because we already have 2 interfaces for this, Realm and
UserDatabase )


Realy, you think it is a mess? Be positive, nothing perfect :-)





 

I would be +1 on using the Policy for authorization - my understanding is
that it _does_not_ require the security manager to be enabled.

 

I'm not sure about that. My understanding was that when you call
AccessController.checkPermission (that require the Security Manager to
be turned on), the class will delegate the call to Policy.implies
implementation. If we don't have the security manager enabled, that
means we use Policy.implies only. Where did you get the information?
   


Why would we call AccessController.checkPermission 


Just to be consistent with JAAS. I never see a case where JAAS was used 
without the Security Manager. IMBW.


The information about the access control is stored in a PolicyObject. 
If the base implementation requires the security manager ( and I doubt )- we 
can use our own implementation of Policy. We'll have to use our own anyway
for performance optimizations.

At least from the javadoc of Policy and my understanding of java security - 
I can't see any good reason why Policy would require a security manager
( except the fact that this is how most people use it today ).

Will see. I don't like implementing part of an api, but I understand 
your point.

-- Jeanfrancois



Costin


--
To unsubscribe, e-mail:   
For additiona

RE: bugzilla 9526

[Shapira, Yoav]

Howdy,
This will get you on the thread:
http://marc.theaimsgroup.com/?l=tomcat-dev&m=102971833127528&w=2

Yoav Shapira
Millennium ChemInformatics


>-Original Message-
>From: Amy Roh [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, January 28, 2003 3:32 PM
>To: Tomcat Developers List
>Subject: bugzilla 9526
>
>Can anyone point me to the thread of discussion where the bug was
>decided invalid?  I'm trying to close the corresponding bugtraq bug
with
>a reason.
>
>Thanks,
>Amy
>
>
>--
>To unsubscribe, e-mail:   [EMAIL PROTECTED]>
>For additional commands, e-mail: [EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

mod_jk2 jni connector: segfault in CreateJavaVM with Sun VM; IBM VM works fine

[Adam Megacz]

Hey, I'm using mod_jk2 with Apache2 (prefork) on Linux, and the Sun
JVM (1.4 and 1.3) segfaults somewhere deep within libjvm.so's
CreateJavaVM call, yet IBM's JVM (1.4) works fine.

Has anybody else experienced this?  Any idea what causes it?

If this isn't enough info, I'll make a much more detailed post later
on.  I'm just hoping that somebody's seen this before.

Also, has anybody gotten the JNI connector to work with an MPM other
than prefork?  Or is that currently not supported?

Thanks!!

  - a



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] Splitting authentication and authorization.

[Costin Manolache]

It seems I missread your post, I tought you would add another
authentication interface too ...

But I still don't like the interface :-)

I need to think about it.

I'm pretty sure we can use Policy, Permission, etc without a security
manager, and it would be better to go directly to use those.

One problem is in parameter passing ( since HttpServletRequest and
all other info must be available when making the policy decission ). 

The authentication layer should be able to return a Principal
that is associated with the request. And the authorization layer shouldn't
care about the request - only about the Principal and the required
permission.

In other words - all security constraints can be converted to Permissions
( no need for 3 methods in the interface - just one method that checks
a particular Permission ). 

The problem mentioned about JBoss is due to the fact that the authorization
layer calls the authentication ( this seems to be the case in your proposal
as well ). A request that doesn't have a security constraint will not try
to set the Principal. 

Costin
 

> since the last time I've  proposed to split
> Authentication/Authorization, we have moved to JMX Listerner as hooks
> and standardize on JMX, I would like to re-open the discussion on
> splitting the behaviour. Mainly, I would like to move three Realm
> methods into an Authorizer interface and use the current Valve mechanism
> as the first implementation.. The Authorizer will define:
> 
> public boolean
> hasResourcePermission(HttpRequest,HttpResponse,SecurityConstraint);
> public boolean
> hasUserDataPermission(HttpRequest,HttpResponse,SecurityConstraint);
> public boolean hasRolePermission(HttpRequest,
> HttpResponse,SecurityConstraint, String role);
> 
> I would like to see a clear distinction between Authorization and
> Authentication. That will also allow third party  implementation of JSR
> 115 (and the upcoming JSP on Authentication) to be more easily
> implemented in Tomcat.
> 
> The first implementation will be a re-factoring of the current code.
> Once completed, we should talk about having an JSR 115 implementation
> (requires by default the Security Manager) or something customized for
> Tomcat using JAAS.
> 
> The other solution is to move the Authenticator and Realm concept  into
> coyote as JMX listener and add the Autorizer logic there(will require a
> CoyoteChain or something simliar to StandardPipeline). It is a major
> refactoring and I cannot sign on a major task like that (but I can help
> if we decide its the best decision). But I would favor a Valve for now
> (the logic will be re-usable if we decide to move it into coyote).
> That's what we call the two phases commit :-)
> 
> Throughts?
> 
> -- Jeanfrancois



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime JspContextWrapper.java

[kinman]

kinman  2003/01/28 14:06:28

  Modified:jasper2/src/share/org/apache/jasper/compiler Collector.java
Generator.java
   jasper2/src/share/org/apache/jasper/runtime
JspContextWrapper.java
  Log:
  - Encapsulate scope variable synchromizations in JspContextWrapper.
  - Aliases should not generate scripting variables.
  
  Revision  ChangesPath
  1.8   +5 -4  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Collector.java
  
  Index: Collector.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Collector.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- Collector.java30 Oct 2002 17:41:22 -  1.7
  +++ Collector.java28 Jan 2003 22:06:27 -  1.8
  @@ -188,8 +188,9 @@
   
   if( (n instanceof Node.CustomTag) && !hasScriptingVars) {
   Node.CustomTag ct = (Node.CustomTag)n;
  - hasScriptingVars = ct.getVariableInfos().length > 0
  - || ct.getTagVariableInfos().length > 0;
  + hasScriptingVars = ct.getTagFileInfo() != null &&
  + (ct.getVariableInfos().length > 0 ||
  +  ct.getTagVariableInfos().length > 0);
}
   
// Record if the tag element and its body contains any scriptlet.
  
  
  
  1.156 +32 -18
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
  
  Index: Generator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
  retrieving revision 1.155
  retrieving revision 1.156
  diff -u -r1.155 -r1.156
  --- Generator.java28 Jan 2003 01:42:57 -  1.155
  +++ Generator.java28 Jan 2003 22:06:27 -  1.156
  @@ -291,6 +291,10 @@
varName = n.getTagData().getAttributeString(
tagVarInfos[i].getNameFromAttribute());
}
  + else if (tagVarInfos[i].getNameFromAttribute() != null) {
  + // alias
  + continue;
  + }
String tmpVarName = "_jspx_" + varName + "_"
+ n.getCustomNestingLevel();
if (!vars.contains(tmpVarName)) {
  @@ -1793,8 +1797,7 @@
   
// Copy virtual page scope of tag file to page scope of invoking
// page
  - out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
this.jspContext).copyTagToPageScope(javax.servlet.jsp.tagext.VariableInfo.NESTED);");
  - out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
this.jspContext).copyTagToPageScope(javax.servlet.jsp.tagext.VariableInfo.AT_BEGIN);");
  + out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
this.jspContext).syncBeforeInvoke();");
   
// Invoke fragment
String varReaderAttr = n.getTextAttribute("varReader");
  @@ -1813,8 +1816,7 @@
out.pushIndent();
// Copy page scope of invoking page back to virtual page scope of
// tag file
  - out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
this.jspContext).copyPageToTagScope(javax.servlet.jsp.tagext.VariableInfo.NESTED);");
  - out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
this.jspContext).copyPageToTagScope(javax.servlet.jsp.tagext.VariableInfo.AT_BEGIN);");
  + out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
this.jspContext).syncAfterInvoke();");
out.popIndent();
out.printil("}");
   
  @@ -1841,8 +1843,7 @@
   
// Copy virtual page scope of tag file to page scope of invoking
// page
  - out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
this.jspContext).copyTagToPageScope(javax.servlet.jsp.tagext.VariableInfo.NESTED);");
  - out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
this.jspContext).copyTagToPageScope(javax.servlet.jsp.tagext.VariableInfo.AT_BEGIN);");
  + out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
this.jspContext).syncBeforeInvoke();");
   
// Invoke body
String varReaderAttr = n.getTextAttribute("varReader");
  @@ -1863,8 +1864,7 @@
out.pushIndent();
// Copy page scope of invoking page back to virtual page scope of
// tag file
  - out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
this.jspContext).copyPageToTagScope(javax.servlet.jsp.tagext.VariableInfo.NESTED);");
  - out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
this.jspContext).copyPa

cvs commit: jakarta-servletapi-5/jsr152/examples/WEB-INF web.xml

[jfarcand]

jfarcand2003/01/28 16:54:22

  Modified:jsr152/examples/WEB-INF web.xml
  Log:
  Fix XML Schema error.
  
  Revision  ChangesPath
  1.7   +2 -1  jakarta-servletapi-5/jsr152/examples/WEB-INF/web.xml
  
  Index: web.xml
  ===
  RCS file: /home/cvs/jakarta-servletapi-5/jsr152/examples/WEB-INF/web.xml,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- web.xml   17 Dec 2002 22:23:23 -  1.6
  +++ web.xml   29 Jan 2003 00:54:22 -  1.7
  @@ -5,10 +5,11 @@
   xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee web-app_2_4.xsd"
   version="2.4">
   
  -JSP 2.0 Examples
   
 JSP 2.0 Examples.
   
  +JSP 2.0 Examples
  +
   
   
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationDispatcher.java

[jfarcand]

jfarcand2003/01/28 17:42:38

  Modified:catalina/src/share/org/apache/catalina/core
ApplicationDispatcher.java
  Log:
  Fix Bug 16078 Request parameter aggregation when using  is no longer 
working. mergeParameters was called twice.
  
  Revision  ChangesPath
  1.8   +4 -5  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java
  
  Index: ApplicationDispatcher.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- ApplicationDispatcher.java17 Dec 2002 20:06:20 -  1.7
  +++ ApplicationDispatcher.java29 Jan 2003 01:42:38 -  1.8
  @@ -466,7 +466,6 @@
   if (queryString != null) {
   wrequest.setAttribute(Globals.FORWARD_QUERY_STRING_ATTR,
 queryString);
  -wrequest.mergeParameters(queryString);
   }
   
   if (queryString != null) {
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 16078] - Request parameter aggregation when using is no longer working as expected.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16078

Request parameter aggregation when using  is no longer working as expected.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
Summary|Request parameter   |Request parameter
   |aggregation when using  |aggregation when using
   | is no longer| is no longer
   |working as expected.|working as expected.



--- Additional Comments From [EMAIL PROTECTED]  2003-01-29 01:44 ---
Fixed. mergeParameters was called twice.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [5.0] Splitting authentication and authorization.

[Costin Manolache]

What about this:

instead of 3 methods, have a single method:

interface Authorization {
  boolean hasPermission( HttpServletRequest, Permission perm )
} 

I'm still trying to figure out the hack in JSR155 ( with the 
permission per request ) - but if you understand it we can even
use 

  boolean implies( Permission currentRequestPermission, 
   Permission targetPermission ) 

Where currentRequestPermission will hold info about the request.

When we decide to support JSR155 - we can either make our Permission
implement the JSR155 classes, or change the code to support both 
kinds of Permissions.
Even if we support 155 - we'll still need our own implementation - 
for optimizations, recycle, etc. 

It seems Authorization interface is needed - at least from reading 
155. BTW, in the draft I'm reading there is also the option of using
Policy ( which would not require the security manager ).

Costin


Costin Manolache wrote:

> It seems I missread your post, I tought you would add another
> authentication interface too ...
> 
> But I still don't like the interface :-)
> 
> I need to think about it.
> 
> I'm pretty sure we can use Policy, Permission, etc without a security
> manager, and it would be better to go directly to use those.
> 
> One problem is in parameter passing ( since HttpServletRequest and
> all other info must be available when making the policy decission ).
> 
> The authentication layer should be able to return a Principal
> that is associated with the request. And the authorization layer shouldn't
> care about the request - only about the Principal and the required
> permission.
> 
> In other words - all security constraints can be converted to Permissions
> ( no need for 3 methods in the interface - just one method that checks
> a particular Permission ).
> 
> The problem mentioned about JBoss is due to the fact that the
> authorization layer calls the authentication ( this seems to be the case
> in your proposal as well ). A request that doesn't have a security
> constraint will not try to set the Principal.
> 
> Costin
>  
> 
>> since the last time I've  proposed to split
>> Authentication/Authorization, we have moved to JMX Listerner as hooks
>> and standardize on JMX, I would like to re-open the discussion on
>> splitting the behaviour. Mainly, I would like to move three Realm
>> methods into an Authorizer interface and use the current Valve mechanism
>> as the first implementation.. The Authorizer will define:
>> 
>> public boolean
>> hasResourcePermission(HttpRequest,HttpResponse,SecurityConstraint);
>> public boolean
>> hasUserDataPermission(HttpRequest,HttpResponse,SecurityConstraint);
>> public boolean hasRolePermission(HttpRequest,
>> HttpResponse,SecurityConstraint, String role);
>> 
>> I would like to see a clear distinction between Authorization and
>> Authentication. That will also allow third party  implementation of JSR
>> 115 (and the upcoming JSP on Authentication) to be more easily
>> implemented in Tomcat.
>> 
>> The first implementation will be a re-factoring of the current code.
>> Once completed, we should talk about having an JSR 115 implementation
>> (requires by default the Security Manager) or something customized for
>> Tomcat using JAAS.
>> 
>> The other solution is to move the Authenticator and Realm concept  into
>> coyote as JMX listener and add the Autorizer logic there(will require a
>> CoyoteChain or something simliar to StandardPipeline). It is a major
>> refactoring and I cannot sign on a major task like that (but I can help
>> if we decide its the best decision). But I would favor a Valve for now
>> (the logic will be re-usable if we decide to move it into coyote).
>> That's what we call the two phases commit :-)
>> 
>> Throughts?
>> 
>> -- Jeanfrancois



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: mod_jk2 jni connector: segfault in CreateJavaVM with Sun VM; IBM VM works fine

[Mladen Turk]

> Behalf Of Adam Megacz
> 
> Hey, I'm using mod_jk2 with Apache2 (prefork) on Linux, and 
> the Sun JVM (1.4 and 1.3) segfaults somewhere deep within 
> libjvm.so's CreateJavaVM call, yet IBM's JVM (1.4) works fine.
> 
> Has anybody else experienced this?  Any idea what causes it?
> 
> If this isn't enough info, I'll make a much more detailed 
> post later on.  I'm just hoping that somebody's seen this before.
> 
> Also, has anybody gotten the JNI connector to work with an 
> MPM other than prefork?  Or is that currently not supported?
> 

Try using threaded mpm, and limit mpm's to 1. The second call to the
CreateJavaVM will cause the JVM to shut down. I had the same behavior on
RH 8.0 with Sun JVM 1.4 (didn't try the IBM's). But it works with
threaded mpm. 

MT.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 10406] - Tomcat Memory Management

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10406

Tomcat Memory Management





--- Additional Comments From [EMAIL PROTECTED]  2003-01-29 07:59 ---
Hi,
 We tried calling System.gc() explicitly and it seems to work, at least in 
windows. I am not sure. Hope this works for others too.

regards, 

Srikanth. S.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]