Re: Osgifing Tomcat
Hello, As part of OW2 JOnAS 5.0 OSGi based application server we're interested to have Tomcat packaged as an OSGi bundle. All our modules are bundles and if tomcat is already a bundle we won't have to wrap it into a bundle on our side. Regards, Florent Henri Gomez wrote: Hi to all, Did there is plans, ideas or interest around about OSGI-fing Tomcat ? Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
> I've put a note about this a while ago in tomcat/trunk/PROPOSALS.txt > my original plan was just to make sure all the MANIFEST.MF for each file > would have enough in it so that each JAR can be a OSGi bundle. Well it shouldn't hurt updating MANIFEST.MF. Could you update some so we could take a look ? > after that, one can add on as much or as little as one wishes Correct - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
2008/4/23 Florent.BENOIT <[EMAIL PROTECTED]>: >Hello, > > As part of OW2 JOnAS 5.0 OSGi based application server we're interested to > have Tomcat packaged as an OSGi bundle. > All our modules are bundles and if tomcat is already a bundle we won't have > to wrap it into a bundle on our side. > > Regards, Hum do you have some stuff to contribute or show us for review ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: svn commit: r646229 - in /httpd/mod_ftp/trunk/modules/ftp: ftp_connection.c ftp_protocol.c]
> IMHO that's incorrect. > You cannot change mmn unless you support what mmn is supposed > to support. This is clear distribution error not mod_jk or httpd one. I contacted Suse packager, theu should fix it. > Distribution is simply laying saying: > "OK I support 2.2.5 API" while the real statement should be: > "I support something from 2.2.5 API, but it's up to you > to figure out what" I know :) > Pretty confusing, and we shouldn't bother with something > like that cause if we don't trust the headers in httpd, what's > the point? Agreed - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
Our bundle of Tomcat is exposing JOnAS service API. I think that from a tomcat bundle view it should expose its own interface like API for registering/deploying a war component, etc. If you want to see some source code, it's in the SVN. http://svn.forge.objectweb.org/cgi-bin/viewcvs.cgi/jonas/jonas/trunk/jonas/modules/services/web-container/tomcat/6.0.x/?rev=13842 Apache Felix iPOJO is used as well as the maven-bundle-plugin: for the maven bundle plugin : http://svn.forge.objectweb.org/cgi-bin/viewcvs.cgi/jonas/jonas/trunk/jonas/modules/services/web-container/tomcat/6.0.x/src/main/resources/META-INF/jonas-web-container-tomcat-6.0.bnd?rev=13488&view=markup metadata.xml for iPOJO : http://svn.forge.objectweb.org/cgi-bin/viewcvs.cgi/jonas/jonas/trunk/jonas/modules/services/web-container/tomcat/6.0.x/src/main/resources/metadata.xml?rev=13058&view=auto Regards Florent Henri Gomez wrote: 2008/4/23 Florent.BENOIT <[EMAIL PROTECTED]>: Hello, As part of OW2 JOnAS 5.0 OSGi based application server we're interested to have Tomcat packaged as an OSGi bundle. All our modules are bundles and if tomcat is already a bundle we won't have to wrap it into a bundle on our side. Regards, Hum do you have some stuff to contribute or show us for review ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
Yes, the modular aspect is for sure a better choice. So we can have a smaller Tomcat (by only using few bundles) or bundles loaded on demand. Regards, Florent Filip Hanik - Dev Lists wrote: Henri Gomez wrote: 2008/4/23 Florent.BENOIT <[EMAIL PROTECTED]>: Hello, As part of OW2 JOnAS 5.0 OSGi based application server we're interested to have Tomcat packaged as an OSGi bundle. All our modules are bundles and if tomcat is already a bundle we won't have to wrap it into a bundle on our side. Regards, Hum do you have some stuff to contribute or show us for review ? sure, for the whole bundle, it would look like this, but what I would like to do for trunk, is to do one per JAR file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
Henri Gomez wrote: 2008/4/23 Florent.BENOIT <[EMAIL PROTECTED]>: Hello, As part of OW2 JOnAS 5.0 OSGi based application server we're interested to have Tomcat packaged as an OSGi bundle. All our modules are bundles and if tomcat is already a bundle we won't have to wrap it into a bundle on our side. Regards, Hum do you have some stuff to contribute or show us for review ? sure, for the whole bundle, it would look like this, but what I would like to do for trunk, is to do one per JAR file Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-SymbolicName: org.apache.tomcat Bundle-Vendor: Apache Software Foundation Bundle-Version: 6.0.16 Import-Package: org.eclipse.core.resources;resolution:=optional, org.eclipse.core.runtime;resolution:=optional, org.eclipse.jdt.core;resolution:=optional, org.eclipse.jdt.core.compiler;resolution:=optional, org.eclipse.jdt.core.dom;resolution:=optional, org.eclipse.jdt.internal.compiler;resolution:=optional, org.eclipse.jdt.internal.compiler.apt.dispatch;resolution:=optional, org.eclipse.jdt.internal.compiler.ast;resolution:=optional, org.eclipse.jdt.internal.compiler.batch;resolution:=optional, org.eclipse.jdt.internal.compiler.classfmt;resolution:=optional, org.eclipse.jdt.internal.compiler.codegen;resolution:=optional, org.eclipse.jdt.internal.compiler.env;resolution:=optional, org.eclipse.jdt.internal.compiler.flow;resolution:=optional, org.eclipse.jdt.internal.compiler.impl;resolution:=optional, org.eclipse.jdt.internal.compiler.lookup;resolution:=optional, org.eclipse.jdt.internal.compiler.parser;resolution:=optional, org.eclipse.jdt.internal.compiler.parser.diagnose, org.eclipse.jdt.internal.compiler.problem;resolution:=optional, org.eclipse.jdt.internal.compiler.util;resolution:=optional, org.eclipse.jdt.internal.core;resolution:=optional, org.eclipse.jdt.internal.core.builder;resolution:=optional, org.eclipse.jdt.internal.core.util;resolution:=optional, com.springsource.engine.servlet.tomcat.loader;resolution:=optional, javax.mail;resolution:=optional, javax.mail.internet;resolution:=optional, javax.management;resolution:=optional, javax.management.loading;resolution:=optional, javax.management.modelmbean;resolution:=optional, javax.naming;resolution:=optional, javax.naming.directory;resolution:=optional, javax.naming.spi;resolution:=optional, javax.persistence;resolution:=optional, javax.security.auth;resolution:=optional, javax.security.auth.callback;resolution:=optional, javax.security.auth.login;resolution:=optional, javax.security.auth.spi;resolution:=optional, javax.sql;resolution:=optional, javax.xml.parsers;resolution:=optional, javax.xml.transform;resolution:=optional, javax.xml.transform.stream;resolution:=optional, javax.xml.ws;resolution:=optional Export-Package: javax.annotation, javax.annotation.security, javax.ejb, javax.el, javax.mail, javax.mail.internet, javax.persistence, javax.servlet, javax.servlet.http, javax.servlet.jsp, javax.servlet.jsp.el, javax.servlet.jsp.resources, javax.servlet.jsp.tagext, javax.servlet.resources, javax.xml.ws, org.apache, org.apache.catalina, org.apache.catalina.ant, org.apache.catalina.ant.jmx, org.apache.catalina.authenticator, org.apache.catalina.connector, org.apache.catalina.core, org.apache.catalina.deploy, org.apache.catalina.ha, org.apache.catalina.ha.authenticator, org.apache.catalina.ha.context, org.apache.catalina.ha.deploy, org.apache.catalina.ha.session, org.apache.catalina.ha.tcp, org.apache.catalina.ha.util, org.apache.catalina.loader, org.apache.catalina.manager, org.apache.catalina.manager.host, org.apache.catalina.manager.util, org.apache.catalina.mbeans, org.apache.catalina.realm, org.apache.catalina.security, org.apache.catalina.servlets, org.apache.catalina.session, org.apache.catalina.ssi, org.apache.catalina.startup, org.apache.catalina.tribes, org.apache.catalina.tribes.group, org.apache.catalina.tribes.group.interceptors, org.apache.catalina.tribes.io, org.apache.catalina.tribes.membership, org.apache.catalina.tribes.tipis, org.apache.catalina.tribes.transport, org.apache.catalina.tribes.transport.bio, org.apache.catalina.tribes.transport.bio.util, org.apache.catalina.tribes.transport.nio, org.apache.catalina.tribes.util, org.apache.catalina.users, org.apache.catalina.util, org.apache.catalina.valves, org.apache.coyote, org.apache.coyote.ajp, org.apache.coyote.http11, org.apache.coyote.http11.filters, org.apache.coyote.memory, org.apache.el, org.apache.el.lang, org.apache.el.parser, org.apache.el.util, org.apache.jasper, org.apache.jasper.compiler, org.apache.jasper.compiler.tagplugin, org.apache.jasper.el, org.apache.jasper.resources, org.apache.jasper.runtime, org.apache.jasper.security, org.apache.jasper.servlet, org.apache.jasper.tagplugins.jstl, org.apache.jasper.tagplugins.jstl.core, org.apache.jasper.util, org.apache.jasper.xmlparser, org.apache.jk, org.apache.jk.apr, org.apache.jk.common, org.apache.jk.config, org.apache.jk.core, org.apache.jk.server, org.a
DO NOT REPLY [Bug 37869] Cannot obtain client certificate with SSL / client certificate authentication using APR components
https://issues.apache.org/bugzilla/show_bug.cgi?id=37869 André Cruz <[EMAIL PROTECTED]> changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #15 from André Cruz <[EMAIL PROTECTED]> 2008-04-23 03:41:12 PST --- I see that 6.0 was patched. Will this be applied to 5.5 as well? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r650824 - /tomcat/trunk/PROPOSALS.txt
Author: fhanik Date: Wed Apr 23 04:09:56 2008 New Revision: 650824 URL: http://svn.apache.org/viewvc?rev=650824&view=rev Log: new idea Modified: tomcat/trunk/PROPOSALS.txt Modified: tomcat/trunk/PROPOSALS.txt URL: http://svn.apache.org/viewvc/tomcat/trunk/PROPOSALS.txt?rev=650824&r1=650823&r2=650824&view=diff == --- tomcat/trunk/PROPOSALS.txt (original) +++ tomcat/trunk/PROPOSALS.txt Wed Apr 23 04:09:56 2008 @@ -76,3 +76,10 @@ * Include tomcat-juli and tomcat-juli-adapters as an add on package when doing a release * Generate source jars for each maven jar posted + +Session Replication +=== +- New feature - only replicate upon demand + Runtime tomcat doesn't do live session replication + but you can move the sessions upon demand before shutting down a tomcat instance + and draining sessions \ No newline at end of file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r650826 - in /tomcat/trunk/java/org/apache/catalina/tribes: membership/McastServiceImpl.java transport/nio/NioSender.java
Author: fhanik
Date: Wed Apr 23 04:12:23 2008
New Revision: 650826
URL: http://svn.apache.org/viewvc?rev=650826&view=rev
Log:
notify user of the actual error and add a todo behavior for buffer copying
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/membership/McastServiceImpl.java
tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioSender.java
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/membership/McastServiceImpl.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/membership/McastServiceImpl.java?rev=650826&r1=650825&r2=650826&view=diff
==
---
tomcat/trunk/java/org/apache/catalina/tribes/membership/McastServiceImpl.java
(original)
+++
tomcat/trunk/java/org/apache/catalina/tribes/membership/McastServiceImpl.java
Wed Apr 23 04:12:23 2008
@@ -230,7 +230,12 @@
boolean valid = false;
if ( (level & Channel.MBR_RX_SEQ)==Channel.MBR_RX_SEQ ) {
if ( receiver != null ) throw new
IllegalStateException("McastService.receive already running.");
-if ( sender == null ) socket.joinGroup(address);
+try {
+if ( sender == null ) socket.joinGroup(address);
+}catch (IOException iox) {
+log.error("Unable to join multicast group, make sure your
system has multicasting enabled.");
+throw iox;
+}
doRunReceiver = true;
receiver = new ReceiverThread();
receiver.setDaemon(true);
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioSender.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioSender.java?rev=650826&r1=650825&r2=650826&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioSender.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioSender.java
Wed Apr 23 04:12:23 2008
@@ -338,6 +338,8 @@
if ( writebuf != null ) writebuf.clear();
else writebuf = getBuffer(length);
if ( writebuf.capacity() < length ) writebuf = getBuffer(length);
+
+ //TODO use ByteBuffer.wrap to avoid copying the data.
writebuf.put(data,offset,length);
//writebuf.rewind();
//set the limit so that we don't write non wanted data
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
On Tue, 2008-04-22 at 12:45 +0200, Henri Gomez wrote: > Hi to all, > > Did there is plans, ideas or interest around about OSGI-fing Tomcat ? The only thing which ever attracts you is pointless hype, it's quite funny ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
> The only thing which ever attracts you is pointless hype, it's quite > funny ;) Remy, I, and many others, will be happy, at least one time, see you discuss technicals and usage aspects of a Tomcat evolution. * What's the pros and cons ? * Interest, usage, openess OSGI is not buzz, it's real world, and if you want TC keep its RI status of servlet engine, please keep this in mind. Do you check latest netcraft review ? http://survey.netcraft.com/Reports/200804/ Do you want more Tomcat users switch to a more open minded engine like Jetty ? Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
>Yes, the modular aspect is for sure a better choice. So we can have a > smaller Tomcat (by only using few bundles) or bundles loaded on demand. +1 And select which part of the engine to be used. What make HTTPD server so successfull was its modular approach and openess. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
On Wed, 2008-04-23 at 14:23 +0200, Henri Gomez wrote: > > The only thing which ever attracts you is pointless hype, it's quite > > funny ;) > > Remy, I, and many others, will be happy, at least one time, see you > discuss technicals and usage aspects of a Tomcat evolution. > > * What's the pros and cons ? > > * Interest, usage, openess > > > OSGI is not buzz, it's real world, and if you want TC keep its RI > status of servlet engine, please keep this in mind. It's as real world as any other microcontainer spec that has shown up, and will show up afterwards. Thinking back about it, it was a really bad decision to not use Avalon way back then when we had a chance. > Do you check latest netcraft review ? > > http://survey.netcraft.com/Reports/200804/ I think it's a great domain names parking study. Don't hesitate to provide evidence that Netcraft means anything for the servlet container market (or even for httpd - see, it's falling really fast, any conclusion based on that ? - on the webserver market as whole, as it seems to measure what virtual hosters are using, which is nice to know, but that's about it). > Do you want more Tomcat users switch to a more open minded engine like Jetty ? I don't know if you noticed, but I have not really been participating in Tomcat's trunk development for months, and am only dealing with Tomcat 6.0. In trunk or any other future developments, at the moment my plan is only to comment (pretty much like Costin does). So fear not, your biggest problem is now gone, and you can now start contributing :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
On Wed, Apr 23, 2008 at 4:35 AM, Remy Maucherat <[EMAIL PROTECTED]> wrote: > On Tue, 2008-04-22 at 12:45 +0200, Henri Gomez wrote: > > Hi to all, > > > > Did there is plans, ideas or interest around about OSGI-fing Tomcat ? > > The only thing which ever attracts you is pointless hype, it's quite > funny ;) I share your concern about OSGI and hype :-) I spent few years working on a project using OSGI heavily, with people buying the hype. It was a big disaster, most time was spent reinventing the wheels and turning perfectly simple code to services, registering the services in a bundle and importing it in another, then figuring out why it's slow to start up or start order problems or manifests. On the other side - OSGI has a good class loader implementation, probably the best ( JBoss has a good one too - using a similar delegation mechanism ). As long as you stick to using the class loader - i.e. have manifests with imports/exports and the boilerplate - OSGI can be a benefit. Since IMO the main problem in tomcat is lack of modularity - it wouldn't be bad to give it a try. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
> I don't know if you noticed, but I have not really been participating in > Tomcat's trunk development for months, and am only dealing with Tomcat > 6.0. In trunk or any other future developments, at the moment my plan is > only to comment (pretty much like Costin does). I'm actually working in sandbox, and I plan to propose stuff for the trunk - and thus become active ( I'm very slow those days - I don't have a lot of free time ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
Yes, that looks great. Also, for OSGi, as all is done by package (import/export) the first step is to be sure that API and Implementation are never in the same package name. So we can export APIs and keep private the implementation. Florent Henri Gomez wrote: Yes, the modular aspect is for sure a better choice. So we can have a smaller Tomcat (by only using few bundles) or bundles loaded on demand. +1 And select which part of the engine to be used. What make HTTPD server so successfull was its modular approach and openess. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r650881 - in /tomcat/sandbox/tomcat-lite/java/org/apache/tomcat: lite/ servlets/addon/ servlets/jsp/ servlets/session/
Author: costin
Date: Wed Apr 23 07:23:28 2008
New Revision: 650881
URL: http://svn.apache.org/viewvc?rev=650881&view=rev
Log:
Add back JSP support - in a more flexible form, and without dep on jasper ( or
jsp for that matter :-).
While I don't think non-JSP files will use this, at least I don't feel bad
about tomcat-lite including jsp support
More cleanup, and a simpler way to locate extensions and move more code to
'user space'.
Added:
tomcat/sandbox/tomcat-lite/java/org/apache/tomcat/servlets/addon/AddonSupport.java
(with props)
tomcat/sandbox/tomcat-lite/java/org/apache/tomcat/servlets/addon/UserTemplateClassMapper.java
(with props)
tomcat/sandbox/tomcat-lite/java/org/apache/tomcat/servlets/jsp/
tomcat/sandbox/tomcat-lite/java/org/apache/tomcat/servlets/jsp/JspFileTemplateServlet.java
(with props)
tomcat/sandbox/tomcat-lite/java/org/apache/tomcat/servlets/jsp/PreCompileFilter.java
(with props)
tomcat/sandbox/tomcat-lite/java/org/apache/tomcat/servlets/jsp/SimpleTemplateClassMapper.java
(with props)
tomcat/sandbox/tomcat-lite/java/org/apache/tomcat/servlets/jsp/SingleThreadedProxyServlet.java
(with props)
tomcat/sandbox/tomcat-lite/java/org/apache/tomcat/servlets/jsp/WildcardTemplateServlet.java
(with props)
Modified:
tomcat/sandbox/tomcat-lite/java/org/apache/tomcat/lite/ServletConfigImpl.java
tomcat/sandbox/tomcat-lite/java/org/apache/tomcat/lite/ServletContextImpl.java
tomcat/sandbox/tomcat-lite/java/org/apache/tomcat/lite/ServletRequestImpl.java
tomcat/sandbox/tomcat-lite/java/org/apache/tomcat/lite/TomcatLite.java
tomcat/sandbox/tomcat-lite/java/org/apache/tomcat/servlets/addon/UserSessionManager.java
tomcat/sandbox/tomcat-lite/java/org/apache/tomcat/servlets/session/SessionManagerServlet.java
Modified:
tomcat/sandbox/tomcat-lite/java/org/apache/tomcat/lite/ServletConfigImpl.java
URL:
http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-lite/java/org/apache/tomcat/lite/ServletConfigImpl.java?rev=650881&r1=650880&r2=650881&view=diff
==
---
tomcat/sandbox/tomcat-lite/java/org/apache/tomcat/lite/ServletConfigImpl.java
(original)
+++
tomcat/sandbox/tomcat-lite/java/org/apache/tomcat/lite/ServletConfigImpl.java
Wed Apr 23 07:23:28 2008
@@ -53,16 +53,6 @@
private static final String[] DEFAULT_SERVLET_METHODS = new String[] {
"GET", "HEAD", "POST" };
-public static final String JSP_SERVLET_CLASS =
-"org.apache.tomcat.servlets.jsp.JspProxyServlet";
-
-public static final String JSP_SERVLET_NAME = "jsp";
-
-public static final String JSP_SERVLET_COMPILER_CLASS =
-"org.apache.tomcat.servlets.jsp.JspCompileServlet";
-
-public static final String JSP_SERVLET_COMPILER_NAME = "jspCompiler";
-
public static final String SINGLE_THREADED_PROXY =
"org.apache.tomcat.servlets.jsp.SingleThreadedProxyServlet";
Modified:
tomcat/sandbox/tomcat-lite/java/org/apache/tomcat/lite/ServletContextImpl.java
URL:
http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-lite/java/org/apache/tomcat/lite/ServletContextImpl.java?rev=650881&r1=650880&r2=650881&view=diff
==
---
tomcat/sandbox/tomcat-lite/java/org/apache/tomcat/lite/ServletContextImpl.java
(original)
+++
tomcat/sandbox/tomcat-lite/java/org/apache/tomcat/lite/ServletContextImpl.java
Wed Apr 23 07:23:28 2008
@@ -54,6 +54,7 @@
import org.apache.juli.logging.Log;
import org.apache.juli.logging.LogFactory;
+import org.apache.tomcat.servlets.addon.AddonSupport;
import org.apache.tomcat.servlets.addon.ConfigurableContextListeners;
import org.apache.tomcat.servlets.addon.ConfigurableServletContext;
import org.apache.tomcat.servlets.addon.UserSessionManager;
@@ -62,7 +63,6 @@
import org.apache.tomcat.servlets.config.ServletData;
import org.apache.tomcat.servlets.config.WebAppData;
import org.apache.tomcat.servlets.config.WebXml;
-import org.apache.tomcat.servlets.file.WebdavServlet;
import org.apache.tomcat.servlets.util.Enumerator;
import org.apache.tomcat.servlets.util.RequestUtil;
import org.apache.tomcat.servlets.util.UrlUtils;
@@ -98,10 +98,6 @@
transient Log log;
-/** Prefix for all internal webapps.
- */
-public static String CONTAINER_PREFIX = "__x_";
-
/**
* Prefix to use in servlet names that are used internally.
*/
@@ -301,52 +297,10 @@
* @param name Name of the context attribute to return
*/
public Object getAttribute(String name) {
-if (name.startsWith(CONTAINER_PREFIX)) {
-Object o = getContainerAttribute(name);
-if (o != null) return o;
-}
return (attributes.get(name));
}
/**
- * Tomcat-lite core has the goal to provide maximum power to webapps, by
- * exposing internals and
svn commit: r650885 - in /tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/buf: BufferInfo.java ByteChunk.java CharChunk.java
Author: costin
Date: Wed Apr 23 07:26:07 2008
New Revision: 650885
URL: http://svn.apache.org/viewvc?rev=650885&view=rev
Log:
Add 'Appendable' to ByteChunk.
Temp. add a BufferInfo to collect data about buffer usage ( could do it with a
profiler, seems nicer via JMX ).
I may remove this before proposing to trunk.
Added:
tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/buf/BufferInfo.java
(with props)
Modified:
tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/buf/ByteChunk.java
(contents, props changed)
tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/buf/CharChunk.java
(contents, props changed)
Added:
tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/buf/BufferInfo.java
URL:
http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/buf/BufferInfo.java?rev=650885&view=auto
==
---
tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/buf/BufferInfo.java
(added)
+++
tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/buf/BufferInfo.java
Wed Apr 23 07:26:07 2008
@@ -0,0 +1,67 @@
+/*
+ */
+package org.apache.tomcat.util.buf;
+
+import java.util.concurrent.atomic.AtomicInteger;
+
+/**
+ * For JMX - to see how many buffers we use.
+ *
+ * @author Costin Manolache
+ */
+public class BufferInfo {
+ static BufferInfo singleton = new BufferInfo();
+
+ // TODO: pass a 'domain' to identify where it's used.
+ // TODO: store an instance of BufferInfo in ByteChunk ?
+ // TODO: record destructions
+ public static BufferInfo get() {
+return singleton;
+ }
+
+ AtomicInteger allocatedBChunks = new AtomicInteger();
+ AtomicInteger allocatedBChunksLazy = new AtomicInteger();
+ AtomicInteger growBChunks = new AtomicInteger();
+ AtomicInteger allocatedBChunksBytes = new AtomicInteger();
+ AtomicInteger totalBChunks = new AtomicInteger();
+
+ AtomicInteger allocatedCChunks = new AtomicInteger();
+ AtomicInteger growCChunks = new AtomicInteger();
+ AtomicInteger allocatedCChunksBytes = new AtomicInteger();
+ AtomicInteger allocatedCChunksLazy = new AtomicInteger();
+ AtomicInteger totalCChunks = new AtomicInteger();
+
+ public int getAllocatedBChunks() {
+return allocatedBChunks.get();
+ }
+ public int getGrowBChunks() {
+return growBChunks.get();
+ }
+ public int getGrowCChunks() {
+return growCChunks.get();
+ }
+ public int getAllocatedBChunksBytes() {
+return allocatedBChunksBytes.get();
+ }
+ public int getAllocatedBChunksLazy() {
+return allocatedBChunksLazy.get();
+ }
+ public int getAllocatedCChunksLazy() {
+return allocatedCChunksLazy.get();
+ }
+
+
+ public int getTotalBChunks() {
+return totalBChunks.get();
+ }
+ public int getAllocatedCChunks() {
+return allocatedCChunks.get();
+ }
+ public int getAllocatedCChunksBytes() {
+return allocatedCChunksBytes.get();
+ }
+ public int getWrappedCChunks() {
+return totalCChunks.get();
+ }
+
+}
Propchange:
tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/buf/BufferInfo.java
--
svn:eol-style = native
Modified:
tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/buf/ByteChunk.java
URL:
http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/buf/ByteChunk.java?rev=650885&r1=650884&r2=650885&view=diff
==
---
tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/buf/ByteChunk.java
(original)
+++
tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/buf/ByteChunk.java
Wed Apr 23 07:26:07 2008
@@ -63,7 +63,7 @@
* @author Costin Manolache
* @author Remy Maucherat
*/
-public final class ByteChunk implements Cloneable, Serializable, CharSequence {
+public final class ByteChunk implements Cloneable, Serializable, CharSequence,
Appendable {
/** Input interface, used when the buffer is emptiy
*
@@ -117,7 +117,7 @@
private ByteInputChannel in = null;
private ByteOutputChannel out = null;
-private boolean isOutput=false;
+private boolean isOutput=false; // more like 'owns buffer'
private boolean optimizedWrite=true;
ByteBuffer bb = null;
@@ -125,10 +125,12 @@
* Creates a new, uninitialized ByteChunk object.
*/
public ByteChunk() {
+BufferInfo.get().totalBChunks.incrementAndGet();
}
public ByteChunk( int initial ) {
- allocate( initial, -1 );
+BufferInfo.get().totalBChunks.incrementAndGet();
+allocate( initial, -1 );
}
//
@@ -192,15 +194,16 @@
* Resets the message buff to an uninitialized state.
*/
public void recycle() {
- // buff = null;
- enc=null;
+
svn commit: r650886 - /tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/buf/MessageBytes.java
Author: costin
Date: Wed Apr 23 07:26:35 2008
New Revision: 650886
URL: http://svn.apache.org/viewvc?rev=650886&view=rev
Log:
Add appendable
Modified:
tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/buf/MessageBytes.java
(contents, props changed)
Modified:
tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/buf/MessageBytes.java
URL:
http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/buf/MessageBytes.java?rev=650886&r1=650885&r2=650886&view=diff
==
---
tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/buf/MessageBytes.java
(original)
+++
tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/buf/MessageBytes.java
Wed Apr 23 07:26:35 2008
@@ -514,6 +514,33 @@
return upper.indexOf( sU, starting );
}
+public int indexOfIgnoreCase(CharSequence src, int myOff ) {
+// Adapted from nio connector
+CharSequence my = getCharSequence();
+int myLen = my.length();
+
+char first = Character.toLowerCase(src.charAt(0));
+int srcLen = src.length();
+
+for (int i = myOff; i <= (myLen - srcLen); i++ ) {
+char c = Character.toLowerCase(my.charAt(i));
+if (c != first ) continue;
+// found first char, now look for a match
+int myPos = i + 1;
+for (int srcPos = 1; srcPos < srcLen; ) {
+c = Character.toLowerCase(src.charAt(i));
+char d = Character.toLowerCase(my.charAt(myPos++));
+if (c != d) {
+break;
+}
+if( srcPos == srcLen ) {
+return i; // found it
+}
+}
+}
+return -1;
+}
+
/**
* Returns true if the message bytes starts with the specified string.
* @param c the character
@@ -757,20 +784,11 @@
}
public char charAt(int index) {
- switch (type) {
- case T_STR:
- return strValue.charAt(index);
- case T_CHARS:
- return charC.charAt(index);
- case T_BYTES:
- return byteC.charAt(index);
- default:
- throw new ArrayIndexOutOfBoundsException();
- }
+return getCharSequence().charAt(index);
}
public int length() {
- return getLength();
+return getLength();
}
public CharSequence subSequence(int start, int end) {
@@ -790,5 +808,18 @@
throw new ArrayIndexOutOfBoundsException();
}
return result;
+}
+
+public CharSequence getCharSequence() {
+switch (type) {
+case T_STR:
+return strValue;
+case T_CHARS:
+return charC;
+case T_BYTES:
+return byteC;
+default:
+return null;
+}
}
}
Propchange:
tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/buf/MessageBytes.java
--
svn:eol-style = native
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r650888 - in /tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache: coyote/ coyote/http11/ coyote/http11/filters/ juli/ juli/logging/ tomcat/util/ tomcat/util/buf/ tomcat/util/buf/res/ tomc
Author: costin Date: Wed Apr 23 07:27:34 2008 New Revision: 650888 URL: http://svn.apache.org/viewvc?rev=650888&view=rev Log: Change attributes Modified: tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/coyote/ActionCode.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/coyote/ActionHook.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/coyote/Adapter.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/coyote/Constants.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/coyote/InputBuffer.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/coyote/OutputBuffer.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/coyote/Processor.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/coyote/ProtocolHandler.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/coyote/RequestGroupInfo.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/coyote/RequestInfo.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/coyote/Response.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/coyote/http11/Constants.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/coyote/http11/LocalStrings.properties (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/coyote/http11/OutputFilter.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/coyote/http11/filters/ChunkedOutputFilter.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/coyote/http11/filters/GzipOutputFilter.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/coyote/http11/filters/IdentityOutputFilter.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/coyote/http11/filters/VoidInputFilter.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/coyote/http11/filters/VoidOutputFilter.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/juli/ClassLoaderLogManager.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/juli/FileHandler.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/juli/JdkLoggerConfig.java (contents, props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/juli/JdkLoggerFormatter.java (contents, props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/juli/logging/DirectJDKLog.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/juli/logging/Log.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/juli/logging/LogConfigurationException.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/juli/logging/LogFactory.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/juli/logging/package.html (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/DomUtil.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/IntrospectionUtils.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/MutableInteger.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/buf/Ascii.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/buf/Base64.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/buf/C2BConverter.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/buf/DateTool.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/buf/HexUtils.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/buf/StringCache.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/buf/TimeStamp.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/buf/UDecoder.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/buf/UEncoder.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/buf/UTF8Decoder.java (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/buf/package.html (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/buf/res/LocalStrings.properties (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/buf/res/LocalStrings_es.properties (props changed) tomcat/sandbox/tomcat-lite/tomcat-coyote/org/apache/tomcat/util/buf/res/LocalStrings_fr.properties (props changed)
RE: Osgifing Tomcat
Remy - please consider the Apache guidelines about being respectful on the public lists. Key word: please. - Jim -Original Message- From: Remy Maucherat <[EMAIL PROTECTED]> Sent: Wednesday, April 23, 2008 7:35 AM To: Tomcat Developers List Subject: Re: Osgifing Tomcat On Tue, 2008-04-22 at 12:45 +0200, Henri Gomez wrote: > Hi to all, > > Did there is plans, ideas or interest around about OSGI-fing Tomcat ? The only thing which ever attracts you is pointless hype, it's quite funny ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project tomcat-catalina (in module jakarta-tomcat-4.0) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project tomcat-catalina has an issue affecting its community integration. This issue affects 4 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cargo : Cargo provides a Java API to manipulate Java Containers - jakarta-tomcat-4.0 : Servlet 2.3 and JSP 1.2 Reference Implementation - jakarta-tomcat-coyote-tomcat4 : Connectors to various web servers - tomcat-catalina : Servlet 2.3 and JSP 1.2 Reference Implementation Full details are available at: http://vmgump.apache.org/gump/public/jakarta-tomcat-4.0/tomcat-catalina/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [catalina.jar] identifier set to project name -ERROR- Output with id regexp was not found in project jakarta-regexp -ERROR- Unhandled Property: regexp.jar on: Ant on Project:tomcat-catalina -DEBUG- Dependency on jakarta-servletapi-4 exists, no need to add for property servlet.jar. -DEBUG- Dependency on commons-logging exists, no need to add for property commons-logging-api.jar. -DEBUG- Dependency on jakarta-regexp exists, no need to add for property regexp.jar. -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-tomcat-4.0/tomcat-catalina/gump_work/build_jakarta-tomcat-4.0_tomcat-catalina.html Work Name: build_jakarta-tomcat-4.0_tomcat-catalina (Type: Build) Work ended in a state of : Failed Elapsed: 49 secs Command Line: /usr/lib/jvm/java-1.5.0-sun/bin/java -Djava.awt.headless=true -Xbootclasspath/p:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dcommons-beanutils.jar=/srv/gump/public/workspace/apache-commons/beanutils/dist/commons-beanutils-23042008.jar -Djtc.home=/srv/gump/public/workspace/jakarta-tomcat-connectors -Dversion=4.1.25-dev -Dregexp.jar=*Unset* -Dcommons-logging-api.jar=/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-23042008.jar -Dservlet.jar=/srv/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar -Dcommons-logging.jar=/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-23042008.jar -Dcommons-collections.jar=/srv/gump/public/workspace/apache-commons/collections/build/commons-collections-23042008.jar -Dcommons-digester.jar= /srv/gump/public/workspace/apache-commons/digester/dist/commons-digester.jar deploy-catalina [Working Directory: /srv/gump/public/workspace/jakarta-tomcat-4.0/catalina] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-trax.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/jakarta-tomcat-connectors/util/build/lib/tomcat-util.jar:/srv/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/srv/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-23042008.jar:/srv/gump/public/workspace/apache-commons/fileupload/target/commons-fileupload-23042008.jar:/srv/gump/public/workspace/apache-commons/collections/build/commons-collections-23042008.jar:/srv/gump/publi c/workspace/apache-commons/beanutils/dist/commons-beanutils-23042008.jar:/srv/gump/public/workspace/apache-commons/digester/dist/commons-digester.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-23042008.jar - [mkdir] Created dir: /srv/gump/public/workspace/jakarta-tomcat-4.0/catalina/build/server/classes [mkdir] Created dir: /srv/gump/public/workspace/jakarta-tomcat-4.0/catalina/build/server/lib [mkdir] Created dir: /srv/gump/public/workspace/jakarta-tomcat-4.0/catalina/build/shared/classes [mkdir] Created dir: /srv/gump/public/workspace/jakarta-tomcat-4.0/catalina/build/shared/lib [mkdir] Created dir: /srv/gump/public/workspace/jakarta-tomcat-4.0/catalina/build/work [mkdir] Created dir: /srv/gump/public/workspace/jakarta-tomcat-4.0/catalina/build/temp copy-activation.jar: copy-daemon.jar: copy-dbcp.jar: copy-fi
Re: Osgifing Tomcat
> I share your concern about OSGI and hype :-) As a regular Eclipse user, I like OSGI, but from the plugin altitude. > I spent few years working on a project using OSGI heavily, with people > buying the hype. It was a big disaster, most time was spent > reinventing the wheels and turning perfectly simple code to services, > registering the services in a bundle and importing it in another, then > figuring out why it's slow to start up or start order problems or > manifests. Could we say that today OSGI is more mature and stable, ie Equinox or Felix ? > On the other side - OSGI has a good class loader implementation, > probably the best ( JBoss has a good one too - using a similar > delegation mechanism ). And OSGI help modularity > As long as you stick to using the class loader - i.e. have manifests > with imports/exports and the boilerplate - OSGI can be a benefit. > Since IMO the main problem in tomcat is lack of modularity - it > wouldn't be bad to give it a try. A big +1. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
> I'm actually working in sandbox, and I plan to propose stuff for the > trunk - and thus become active ( I'm very slow those days - I don't have a > lot of free time ). Ditto. I don't have a lot of free time, but I willing to take on my spare time for OSGIfying Tomcat. More all contributions, ideas, codes (Hi Jonas), are welcome. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
On Wed, 2008-04-23 at 16:00 +0200, Florent.BENOIT wrote: > Also, for OSGi, as all is done by package (import/export) the first step > is to be sure that API and Implementation are never in the same package > name. So we can export APIs and keep private the implementation. I think the first main problem with these frameworks is how intrusive they are, esp compared with whet they provide :( I suppose there's no problem with doing a tomcat-osgi in the sandbox if people want to. As I said I really don't care. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JNDIRealm
This patch will have some offset problems because it's off of my working
copy of the JNDIRealm class. But you should be able to get the general
idea of what's going on here.
-- Seth
Henri Gomez wrote:
Do you have a patch against the current JNDIRealm ?
2008/4/22, Seth Leger <[EMAIL PROTECTED]>:
Henri Gomez wrote:
I do some search today and debugged TC 6.0.x trunk from my eclipse.
Authentification works great and the only remaining problem it so
setup roles in AD for users.
I used :
className="org.apache.catalina.realm.JNDIRealm"
connectionURL="ldap://ldap.mycorp.com:389";
alternateURL="ldap://ldap.mycorp.com:389";
connectionName="cn=someldapaccounttobind,ou=MyCorp
Users,dc=mycorp,dc=com"
connectionPassword="someldapaccounttobindpassword"
userBase="ou=MyCorp Users,dc=mycorp,dc=com"
userSearch="(sAMAccountName={0})"
userSubtree="true"
referrals="follow"
userRoleName="memberOf"
debug="true"
/>
Yes, this use case will work with the current Tomcat 6.0.X JNDIRealm code
because your Active Directory administrator has given you search credentials
for the Active Directory server
(cn=someldapaccounttobind,ou=MyCorpUsers,dc=mycorp,dc=com/someldapaccounttobindpassword).
But not all Active Directory administrators are willing to give out a set of
credentials like this (for instance, a strict, enterprise environment where
password access is strictly controlled).
My patch removes that requirement from the JNDIRealm. Instead of relying on
a hard-coded value for authentication, it can fall back to using the
credentials being supplied to the authenticate() call to perform the JNDI
search (which will succeed because users have permissions to view their own
LDAP object instance, as far as I know this is always true). The password is
never stored; it is only transmitted at login time to the server (and this
transmission can be protected from interception with LDAP over SSL).
It's a pretty minor change, written similarly to the way that the current
JNDIRealm code retries during connection timeouts.
Seth Leger
Sr. Software Engineer
Raritan, Inc.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Index: JNDIRealm.java
===
@@ -943,7 +943,7 @@
curUserPattern < userPatternFormatArray.length;
curUserPattern++) {
// Retrieve user information
-User user = getUser(context, username);
+User user = getUser(context, username, credentials);
if (user != null) {
try {
// Check the user's credentials
@@ -968,7 +968,7 @@
return null;
} else {
// Retrieve user information
-User user = getUser(context, username);
+User user = getUser(context, username, credentials);
if (user == null)
return (null);
@@ -1001,7 +1001,7 @@
*
* @exception NamingException if a directory server error occurs
*/
-protected User getUser(DirContext context, String username)
+protected User getUser(DirContext context, String username, String
credentials)
throws NamingException {
User user = null;
@@ -1017,7 +1017,7 @@
// Use pattern or search for user entry
if (userPatternFormatArray != null) {
-user = getUserByPattern(context, username, attrIds);
+user = getUserByPattern(context, username, credentials, attrIds);
} else {
user = getUserBySearch(context, username, attrIds);
}
@@ -1041,6 +1041,7 @@
*/
protected User getUserByPattern(DirContext context,
String username,
+ String credentials,
String[] attrIds)
throws NamingException {
@@ -1056,6 +1057,32 @@
attrs = context.getAttributes(dn, attrIds);
} catch (NameNotFoundException e) {
return (null);
+} catch (NamingException e) {
+// If the getAttributes() call fails, try it again with the
+// credentials of the user that we're searching for
+try {
+// Set up security environment to bind as the user
+context.addToEnvironment(Context.SECURITY_PRINCIPAL, dn);
+context.addToEnvironment(Context.SECURITY_CREDENTIALS,
credentials);
+
+attrs = context.getAttribut
Re: Osgifing Tomcat
Well, adding OSGI-compatible manifests to the existing jars is not that intrusive, and could be easily done in the trunk. AFAIK an Activator is not required - i.e. if you don't need the BundleContext or to add services, you can have a bundle that just imports/exports packages. I agree with Remy that any 'intrusive' part of OSGI should be avoided and certainly not be done in trunk - changing existing packaging shouldn't be done just because OSGI requires a separate bundle for API and impl. Now - the really interesting part is not how to package tomcat to be used inside OSGI, but how to have tomcat use OSGI modules ( and package webaps as bundles ), and how to do this in a non-intrusive way. It looks like felix has a 'programmatic'/embedded mode, it would be interesting to see if it can be used, so all configuration stays inside web.xml/server.xml. Costin On Wed, Apr 23, 2008 at 7:49 AM, Remy Maucherat <[EMAIL PROTECTED]> wrote: > On Wed, 2008-04-23 at 16:00 +0200, Florent.BENOIT wrote: > > Also, for OSGi, as all is done by package (import/export) the first step > > is to be sure that API and Implementation are never in the same package > > name. So we can export APIs and keep private the implementation. > > I think the first main problem with these frameworks is how intrusive > they are, esp compared with whet they provide :( I suppose there's no > problem with doing a tomcat-osgi in the sandbox if people want to. As I > said I really don't care. > > Rémy > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Osgifing Tomcat
> Well, adding OSGI-compatible manifests to the existing jars is not > that intrusive, > and could be easily done in the trunk. AFAIK an Activator is not required - > i.e. > if you don't need the BundleContext or to add services, you can have a bundle > that just imports/exports packages. > > I agree with Remy that any 'intrusive' part of OSGI should be avoided > and certainly > not be done in trunk - changing existing packaging shouldn't be done > just because > OSGI requires a separate bundle for API and impl. > > Now - the really interesting part is not how to package tomcat to be > used inside OSGI, > but how to have tomcat use OSGI modules ( and package webaps as bundles ), > and > how to do this in a non-intrusive way. It looks like felix has a > 'programmatic'/embedded > mode, it would be interesting to see if it can be used, so all > configuration stays inside > web.xml/server.xml. > > Costin Silly question, but did experiments with OSGI could be done, first, in tomcatlight ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 44860] New: 6.0. 16 only - IE and Mozilla do not return version 1 cookie...
https://issues.apache.org/bugzilla/show_bug.cgi?id=44860
Summary: 6.0.16 only - IE and Mozilla do not return version 1
cookie...
Product: Tomcat 6
Version: 6.0.16
Platform: All
OS/Version: All
Status: NEW
Severity: regression
Priority: P2
Component: Servlet & JSP API
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Only happens when setVersion(1) and cookie.setPath("/" ) are used : cookie is
not returned on IE and Mozilla.
Works fine on Firefox.
Code enclosed.
Cookie TEST is retuned correctly back to the server... but TEST1 is not on IE
and Mozilla...Firefox returns both.
Any clue?
<%
String val1 = "[EMAIL PROTECTED]";
String val = "Foo=bar";
Cookie ck = new Cookie("TEST", val);
Cookie ck1 = new Cookie("TEST1", val1);
ck.setDomain(".idp.com");
ck.setPath("/");
ck.setVersion(1);
ck1.setVersion(1);
response.addCookie(ck);
response.addCookie(ck1);
%>
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 44862] New: Creation of new Thread Pool
https://issues.apache.org/bugzilla/show_bug.cgi?id=44862 Summary: Creation of new Thread Pool Product: Tomcat 4 Version: 4.1.37 Platform: Sun OS/Version: Solaris Status: NEW Severity: enhancement Priority: P3 Component: Connector:Coyote HTTP/1.1 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I am not able to create new thread pools, the idea is to create new thread pool and allocate specific thread pool to each Servlet I have created. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 44864] New: optionalNoCA not honored
https://issues.apache.org/bugzilla/show_bug.cgi?id=44864
Summary: optionalNoCA not honored
Product: Tomcat 6
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Severity: major
Priority: P2
Component: Native:JK
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Even when SSLVerifyClient="optionalNoCA" is specified in the connector, invalid
client certificates still lead to invalid SSL handshakes.
This is because SSL_get_verify_result(con->ssl) in sslnetwork.c still returns
!= X509_V_OK even though SSL_callback_SSL_verify() returns ok in these cases.
There is an extra check in openssl itself which is returning the error.
The way this is dealt on mod_ssl in apache (ssl_engine_io.c) is:
if ((verify_result != X509_V_OK) ||
sslconn->verify_error)
{
if (ssl_verify_error_is_optional(verify_result) &&
(sc->server->auth.verify_mode == SSL_CVERIFY_OPTIONAL_NO_CA))
{
/* leaving this log message as an error for the moment,
* according to the mod_ssl docs:
* "level optional_no_ca is actually against the idea
* of authentication (but can be used to establish
* SSL test pages, etc.)"
* optional_no_ca doesn't appear to work as advertised
* in 1.x
*/
ap_log_cerror(APLOG_MARK, APLOG_INFO, 0, c,
"SSL client authentication failed, "
"accepting certificate based on "
"\"SSLVerifyClient optional_no_ca\" "
"configuration");
ssl_log_ssl_error(APLOG_MARK, APLOG_INFO, c->base_server);
}
else {
const char *error = sslconn->verify_error ?
sslconn->verify_error :
X509_verify_cert_error_string(verify_result);
ap_log_cerror(APLOG_MARK, APLOG_INFO, 0, c,
"SSL client authentication failed: %s",
error ? error : "unknown");
ssl_log_ssl_error(APLOG_MARK, APLOG_INFO, c->base_server);
return ssl_filter_io_shutdown(filter_ctx, c, 1);
}
}
Even though verify_result is not OK, if optional_no_ca is specified, the
request should be valid.
The release notes specify that bugs in this code should be filed under
"Native:JNI" component but I could find it in the pull-down.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
On Wed, Apr 23, 2008 at 8:36 AM, Henri Gomez <[EMAIL PROTECTED]> wrote: > > Silly question, but did experiments with OSGI could be done, first, in > tomcatlight ? > I'm not sure it's the best idea, my goal is to move it out of sandbox, it already has enough experiments that need completion. and the main goal is to be 'lite' :-). It has a simple Addon mechanism, and I don't mind having an optional addon manager impl using OSGI - but I don't want to get distracted, I started tomcat-lite experiment >2 years ago. The first part ( adding manifests to existing tomcat ) seems to have support so could be done in the trunk. I don't see any reason for having non-intrusive OSGI support developed in sandbox - as long as the code is in a package that is excluded from the official distro, and is released as a separate unit it could live in trunk. It'll need the 3 +1 to be released, of course - but the whole point of modularity is to be able to develop modules independent of the container. IMO sandbox is for experiments that would replace existing tomcat components or core stuff. If you do it in trunk - it's easier to get it released eventually, and you may get better reviews and attention. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
> I'm not sure it's the best idea, my goal is to move it out of sandbox, > it already has enough experiments > that need completion. and the main goal is to be 'lite' :-). It has a > simple Addon mechanism, and I don't mind > having an optional addon manager impl using OSGI - but I don't want to > get distracted, I started > tomcat-lite experiment >2 years ago. > Yep, time to stabilize > The first part ( adding manifests to existing tomcat ) seems to have > support so could be done in the trunk. And no consequences outside OSGI world > I don't see any reason for having non-intrusive OSGI support developed > in sandbox - as long > as the code is in a package that is excluded from the official distro, > and is released as a separate > unit it could live in trunk. It'll need the 3 +1 to be released, of > course - but the whole point of > modularity is to be able to develop modules independent of the container. Right > IMO sandbox is for experiments that would replace existing tomcat > components or core stuff. If you do it in > trunk - it's easier to get it released eventually, and you may get > better reviews and attention. Indeed I'll try to spend some time on mavenize tomcatlight first and how it could be done then for tomcat trunk. Next how to OSGIfy the mavenized tomcats, experiences and advices welcomed here - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r650941 - in /tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/coyote/adapters: CoyoteServer.java EchoAdapter.java MapperAdapter.java MessageReader.java SleepAdapter.java StaticAdap
Author: costin
Date: Wed Apr 23 10:21:20 2008
New Revision: 650941
URL: http://svn.apache.org/viewvc?rev=650941&view=rev
Log:
Few more fixes and adapters to help testing.
Added:
tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/coyote/adapters/EchoAdapter.java
(with props)
tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/coyote/adapters/SleepAdapter.java
(with props)
Modified:
tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/coyote/adapters/CoyoteServer.java
tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/coyote/adapters/MapperAdapter.java
tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/coyote/adapters/MessageReader.java
tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/coyote/adapters/StaticAdapter.java
Modified:
tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/coyote/adapters/CoyoteServer.java
URL:
http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/coyote/adapters/CoyoteServer.java?rev=650941&r1=650940&r2=650941&view=diff
==
---
tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/coyote/adapters/CoyoteServer.java
(original)
+++
tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/coyote/adapters/CoyoteServer.java
Wed Apr 23 10:21:20 2008
@@ -5,7 +5,9 @@
import org.apache.coyote.Adapter;
import org.apache.coyote.ProtocolHandler;
import org.apache.coyote.http11.Http11NioProtocol;
+import org.apache.coyote.http11.simple.SimpleProtocolHandler;
import org.apache.juli.JdkLoggerConfig;
+import org.apache.tomcat.util.buf.BufferInfo;
import org.apache.tomcat.util.modeler.Registry;
@@ -14,25 +16,37 @@
*
*/
public class CoyoteServer {
- int port = 8800;
- String args[];
+ protected int port = 8800;
+ protected String args[]; // saved to allow additional param extraction
+ protected boolean daemon = false;
+ /**
+ * Note indicating the response is COMET.
+ */
+ public static final int COMET_RES_NOTE = 2;
+ public static final int COMET_REQ_NOTE = 2;
+
+ public static final int ADAPTER_RES_NOTE = 1;
+ public static final int ADAPTER_REQ_NOTE = 1;
+
protected ProtocolHandler proto;
- Registry registry;
+ protected Registry registry;
protected Adapter adapter;
- int maxThreads = 20;
+ protected int maxThreads = 20;
+ boolean started = false;
- public CoyoteServer() {
+
+ public CoyoteServer() {
}
public CoyoteServer(int i) {
-port = i;
+setPort(i);
}
public CoyoteServer(int i, Adapter adapter) {
-port = i;
+setPort(i);
addAdapter("/", adapter);
}
@@ -71,9 +85,12 @@
start();
}
+ public void setDaemon(boolean b) {
+daemon = b;
+ }
+
public void init() {
-new JdkLoggerConfig();
-initJMX();
+JdkLoggerConfig.loadCustom();
}
protected void initAdapters() {
@@ -83,7 +100,11 @@
}
public void stop() throws Exception {
+if (!started) {
+ return;
+}
proto.destroy();
+started = false;
}
/**
@@ -100,32 +121,67 @@
}
}
- public void setPort() {
+ public void setPort(int port) {
+initJMX();
this.port = port;
}
-
+
/**
*/
- public static ProtocolHandler getDefaultConnector(int port) {
+ public static ProtocolHandler getDefaultConnector(int port, boolean daemon) {
+//try {
+// Library.initialize("tcnative-1");
+// Http11AprProtocol proto = new Http11AprProtocol();
+// proto.setCompression("on");
+// proto.setCompressionMinSize(32);
+// proto.setPort(port);
+// proto.getEndpoint().setDaemon(daemon);
+// return proto;
+//} catch (Exception e) {
+// e.printStackTrace();
+// //throw new RuntimeException(e);
+//}
+
+SimpleProtocolHandler proto = new SimpleProtocolHandler();
+proto.setPort(port);
+proto.setDaemon(daemon);
+
+return proto;
+ }
+
+ public void setNioConnector() {
Http11NioProtocol proto = new Http11NioProtocol();
proto.setCompression("on");
proto.setCompressionMinSize(32);
proto.setPort(port);
-proto.getEndpoint().setDaemon(false);
-return proto;
+proto.getEndpoint().setDaemon(daemon);
+setConnector(proto);
+ }
+
+ public void setConnector(ProtocolHandler h) {
+ this.proto = h;
}
public void start() {
try {
- proto = getDefaultConnector(port);
+ if (started) {
+return;
+ }
+ if (proto == null) {
+ proto = getDefaultConnector(port, daemon);
+ }
initAdapters();
registry.registerComponent(adapter, ":name=adapter" + (port), null);
+ registry.registerComponent(BufferInfo.get(), ":name=BufferInfo" + port,
+ "BufferInfo");
proto.setAdapter(adapter);
registry.registerComponent(proto, ":name=ep-" + port, null);
- proto.start();
svn commit: r650945 - in /tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/tomcat/util/net: SelectorCallback.java SelectorThread.java SelectorThreadNio.java
Author: costin
Date: Wed Apr 23 10:29:58 2008
New Revision: 650945
URL: http://svn.apache.org/viewvc?rev=650945&view=rev
Log:
Ok, finally - the first part of the new connector, or the last part of
tomcat-lite experiment :-)
It is obviously quite independent of the rest of tomcat-lite, probably the last
to move out of sandbox.
I have an Apr impl as well, but it's broken now, need to fix it again.
This is the IO abstraction - the connector goal is to do all I/O in
non-blocking mode and allow
completely non-blocking adapters ( i.e. a bit more than regular coyote ).
Added:
tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/tomcat/util/net/SelectorCallback.java
(with props)
tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/tomcat/util/net/SelectorThread.java
(with props)
tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/tomcat/util/net/SelectorThreadNio.java
(with props)
Added:
tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/tomcat/util/net/SelectorCallback.java
URL:
http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/tomcat/util/net/SelectorCallback.java?rev=650945&view=auto
==
---
tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/tomcat/util/net/SelectorCallback.java
(added)
+++
tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/tomcat/util/net/SelectorCallback.java
Wed Apr 23 10:29:58 2008
@@ -0,0 +1,87 @@
+/* Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.tomcat.util.net;
+
+import java.io.IOException;
+import java.nio.channels.Channel;
+
+/**
+ * Notiy user code of events. All methods are called from the selector thread,
+ * they should not block. The reason is to allow parsing and non-blocking
+ * processing to be done as fast as possible, and avoid the need for
+ * SelectorThread to deal with a thread pool.
+ *
+ * This class wraps the Channel. For APR we wrap the socket and few other
+ * fields we need for non-blocking operation in a ByteChannel, the code
+ * seems cleaner and it's nice to be able to use APR more portably.
+ * ( older version used long - but non-blocking connect needs a second param )
+ */
+public class SelectorCallback {
+ protected SelectorThread.SelectorData selectorData = new
SelectorThread.SelectorData(this);
+
+ public SelectorThread getSelector() {
+return selectorData.sel;
+ }
+
+ /**
+ * Called when the protocol is connected.
+ */
+ public void connected(SelectorThread selThread)
+ throws IOException {
+ }
+
+ /**
+ * It is possible to write data.
+ * For both read and write - re-enable interest if you want more data.
+ */
+ public void dataWriteable(SelectorThread selThread) throws IOException {
+ }
+
+ /**
+ * Data available for read.
+ * For both read and write - re-enable interest if you want more data.
+ */
+ public void dataReceived(SelectorThread selThread) throws IOException {
+ }
+
+ /**
+ * nextTimeEvent reached.
+ */
+ public void timeEvent(SelectorThread selThread) {
+ }
+
+ /**
+ * Close was detected, or an unhandled exception happened while processing
+ * this callback.
+ */
+ public void channelClosed(SelectorThread selThread, Throwable ex) {
+ }
+
+ /**
+ * Called on a callback created with acceptor() or inetdAcceptor() when
+ * a new connection is accepted.
+ *
+ * @return callback to use on the new channel.
+ *
+ * TODO: is there any case where something else besides registering read
+ * interest on the new connection is needed ? Maybe it could read some data ?
+ */
+ public SelectorCallback connectionAccepted(SelectorThread selThread,
+ Channel sockC) {
+return null;
+ }
+
+}
\ No newline at end of file
Propchange:
tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/tomcat/util/net/SelectorCallback.java
--
svn:eol-style = native
Added:
tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/tomcat/util/net/SelectorThread.java
URL:
http://svn.apache.org/viewvc/tomc
svn commit: r650947 - /tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/tomcat/util/net/SelectorPool.java
Author: costin
Date: Wed Apr 23 10:32:02 2008
New Revision: 650947
URL: http://svn.apache.org/viewvc?rev=650947&view=rev
Log:
Missed one file
Added:
tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/tomcat/util/net/SelectorPool.java
(with props)
Added:
tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/tomcat/util/net/SelectorPool.java
URL:
http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/tomcat/util/net/SelectorPool.java?rev=650947&view=auto
==
---
tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/tomcat/util/net/SelectorPool.java
(added)
+++
tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/tomcat/util/net/SelectorPool.java
Wed Apr 23 10:32:02 2008
@@ -0,0 +1,65 @@
+/* Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.tomcat.util.net;
+
+import java.util.concurrent.atomic.AtomicInteger;
+
+
+/**
+ * Support for multiple SelectorThreads.
+ *
+ * This is a placeholder, one thread only used right now to make it easier to
+ * debug/test. For small servers one thread should be enough anyways, and
+ * that's the first target for lite.
+ *
+ * TODO: discover if APR is available and use it, or fall back to NIO.
+ *
+ * @author Costin Manolache
+ */
+public class SelectorPool {
+ // TODO: discover apr
+ // TODO: pool, balanced usage
+ static AtomicInteger id = new AtomicInteger();
+ int seq;
+
+ SelectorThread selector;
+ private boolean daemon;
+ static SelectorPool defaultSPool = new SelectorPool();
+
+ public SelectorPool() {
+seq = id.incrementAndGet();
+ }
+
+ public static SelectorPool defaultPool() {
+ return defaultSPool;
+ }
+
+ public void stop() {
+ selector.stop();
+ }
+
+ public SelectorThread getSelector() {
+ if (selector == null) {
+ selector = new SelectorThreadNio(daemon);
+ ((SelectorThreadNio)selector).setName("SelectorThread-" + seq);
+ }
+ return selector;
+ }
+
+ public void setDaemon(boolean daemon) {
+ this.daemon = daemon;
+ }
+}
Propchange:
tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/tomcat/util/net/SelectorPool.java
--
svn:eol-style = native
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r650949 - /tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/tomcat/util/http/Http11Parser.java
Author: costin
Date: Wed Apr 23 10:34:22 2008
New Revision: 650949
URL: http://svn.apache.org/viewvc?rev=650949&view=rev
Log:
Extracted from apr and nio connectors, transformed to completely non-blocking,
independent of the io.
Added:
tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/tomcat/util/http/Http11Parser.java
(with props)
Added:
tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/tomcat/util/http/Http11Parser.java
URL:
http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/tomcat/util/http/Http11Parser.java?rev=650949&view=auto
==
---
tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/tomcat/util/http/Http11Parser.java
(added)
+++
tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/tomcat/util/http/Http11Parser.java
Wed Apr 23 10:34:22 2008
@@ -0,0 +1,761 @@
+/*
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.tomcat.util.http;
+
+import java.io.IOException;
+import java.nio.ByteBuffer;
+
+import org.apache.tomcat.util.buf.MessageBytes;
+
+/**
+ * Non-blocking parser for request and response line and headers.
+ *
+ * This could/should replace the parsing parts of InternalAprInputBuffer,
+ * InternalNioInputBuffer, but the main goal is to be used in non-blocking
+ * client code.
+ *
+ * All parse methods will return a negative number if more data is needed
+ * and leave the buffer position/limit unchanged. After more data is
+ * available, call again setBuffer() and the same parse method. If enough
+ * data ia available, 'pos' will be moved to the first byte after the
+ * parsed data.
+ *
+ * The next get() will be a header (after parseRequestLine,
+ * parseResponseLine, parseHeader), a LF after the last parseHeader, or
+ * the first byte of the payload for parseRequest()/parseResponse().
+ *
+ * TODO: use a ByteChunk instead of byte[], enhance methods using ByteBuffer
+ *
+ * @author mailto:[EMAIL PROTECTED]">Remy Maucherat
+ * @author Costin Manolache
+ */
+public class Http11Parser {
+
+/**
+ * CRLF.
+ */
+public static final String CRLF = "\r\n";
+
+/**
+ * CR.
+ */
+public static final byte CR = (byte) '\r';
+
+
+/**
+ * LF.
+ */
+public static final byte LF = (byte) '\n';
+
+
+/**
+ * SP.
+ */
+public static final byte SP = (byte) ' ';
+
+
+/**
+ * HT.
+ */
+public static final byte HT = (byte) '\t';
+
+
+/**
+ * COLON.
+ */
+public static final byte COLON = (byte) ':';
+
+/**
+ * SEMI_COLON.
+ */
+public static final byte SEMI_COLON = (byte) ';';
+
+/**
+ * 'A'.
+ */
+public static final byte A = (byte) 'A';
+
+
+/**
+ * 'a'.
+ */
+public static final byte a = (byte) 'a';
+
+
+/**
+ * 'Z'.
+ */
+public static final byte Z = (byte) 'Z';
+
+
+/**
+ * Lower case offset.
+ */
+public static final byte LC_OFFSET = A - a;
+
+/**
+ * '?'.
+ */
+public static final byte QUESTION = (byte) '?';
+
+/**
+ * HTTP/1.0.
+ */
+public static final String HTTP_10 = "HTTP/1.0";
+
+public static final byte[] _200_BYTES = {'2', '0', '0'};
+
+public static final byte[] _400_BYTES = {'4', '0' , '0'};
+
+public static final byte[] _404_BYTES = { '4', '0', '4' };
+
+/**
+ * HTTP/1.1.
+ */
+public static final String HTTP_11 = "HTTP/1.1";
+
+public static final byte[] HTTP_11_BYTES = HTTP_11.getBytes();
+
+
+// == Buffer
+
+/** Last valid byte in the buf[]
+ */
+public int lastValid; // limit - 1
+
+/** Position in the buffer.
+ */
+public int pos;
+
+/**
+ * Pointer to the current read buffer.
+ */
+public byte[] buf;
+
+// TODO: same thing with ByteChunk, ByteBuffer
+// Since ByteChunk can be easily wrapped as ByteBuffer - only second is
+// needed. Replace:
+// buf[pos++] with bb.get();
+// pos-- with bb.position(bb.position() - 1);
+//ByteBuffer bb;
+
+
+
+// =
+
+// restart from this position
+int lastParsed = 0;
+
+// 0: parsing request line
+// 1: parsing headers
+// 2: request done
+public int state = 0;
+
+public static int STATE_REQUEST_LINE = 0;
+public static int S
DO NOT REPLY [Bug 44860] 6.0. 16 only - IE and Mozilla do not return version 1 cookie...
https://issues.apache.org/bugzilla/show_bug.cgi?id=44860 Filip Hanik <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Filip Hanik <[EMAIL PROTECTED]> 2008-04-23 10:35:22 PST --- correct, this has been fixed in trunk and 6.0.x branch, and will be released in the next version of 6.0 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
Henri Gomez wrote: Indeed I'll try to spend some time on mavenize tomcatlight first and how it could be done then for tomcat trunk. Next how to OSGIfy the mavenized tomcats, experiences and advices welcomed here Once Tomcat has been mavenized, with maven-bundle-plugin you can produce bundles by specifying the import/export/private/etc. package in a specific file or in the maven pom.xml file. This plugin can analyze the existing classes (with BND tool) and may do a lot of work for you to detect the packages that you want to import/export/etc. After that, you may begin to start to use OSGi Declarative Services, Apache Felix iPOJO, etc. Florent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
- Original Message - From: "Henri Gomez" <[EMAIL PROTECTED]> To: "Tomcat Developers List" Sent: Wednesday, April 23, 2008 2:24 PM Subject: Re: Osgifing Tomcat Yes, the modular aspect is for sure a better choice. So we can have a smaller Tomcat (by only using few bundles) or bundles loaded on demand. +1 And select which part of the engine to be used. I dont know about the whole OSGI thing, to be honest I fall asleep just after the introduction to the thing ;) and ok a cell phone wants it so it can do a form of plug and play, but then I cant see microsoft adding that to their service manager, so for me its neither here nor there. In my pragmatic user view, what I think would be nice is a "brainless" interface to embedded. So something like this... tomcat user uses full tomcat, gets all the XML configured, webapps tested and running and then "presses a button" so to speak, and that creates a little embedded source code example, the xml is translated into a property file, the webapps placed in a "loadme folder", if clustering is not needed, those libs fall out, and TC's remnants are stuck in a lib folder... ie the user just needs to compile the template for their first embedded app. Something like that I think would be good for TC, and I think it would result in a more modular tomcat. From "that" embedded program, the "user" has the choice of OSGIenabling, or not, OSGI may even be an add on at that level. So you morphing TC not bulking it, kind of idea. If TC did have a "push my button to embed me" kind of utility... I think, big sales. A kind of "use the big tomcat"... "and we'll make the little one for you"... thing. I mention it because TC is definitely losing "sales" on embedded... the user actually assumes it works a little like the "press my button" analogy... and its nothing like it... lost sale. I think TC's popularity comes from being fairly easy to use, and its out of the box up and running... good theme to follow... maybe ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r650962 - in /tomcat/sandbox/tomcat-lite: .project coyote-extensions/org/apache/coyote/adapters/CoyoteServer.java coyote-extensions/org/apache/coyote/adapters/EchoAdapter.java java/org/apa
Author: costin
Date: Wed Apr 23 10:51:52 2008
New Revision: 650962
URL: http://svn.apache.org/viewvc?rev=650962&view=rev
Log:
Remove deps on classes that are not committed yet
Modified:
tomcat/sandbox/tomcat-lite/.project
tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/coyote/adapters/CoyoteServer.java
tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/coyote/adapters/EchoAdapter.java
tomcat/sandbox/tomcat-lite/java/org/apache/tomcat/lite/TomcatLite.java
Modified: tomcat/sandbox/tomcat-lite/.project
URL:
http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-lite/.project?rev=650962&r1=650961&r2=650962&view=diff
==
--- tomcat/sandbox/tomcat-lite/.project (original)
+++ tomcat/sandbox/tomcat-lite/.project Wed Apr 23 10:51:52 2008
@@ -1,6 +1,6 @@
- tomcat-lite
+ tomcat-lite-clean
Modified:
tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/coyote/adapters/CoyoteServer.java
URL:
http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/coyote/adapters/CoyoteServer.java?rev=650962&r1=650961&r2=650962&view=diff
==
---
tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/coyote/adapters/CoyoteServer.java
(original)
+++
tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/coyote/adapters/CoyoteServer.java
Wed Apr 23 10:51:52 2008
@@ -5,7 +5,6 @@
import org.apache.coyote.Adapter;
import org.apache.coyote.ProtocolHandler;
import org.apache.coyote.http11.Http11NioProtocol;
-import org.apache.coyote.http11.simple.SimpleProtocolHandler;
import org.apache.juli.JdkLoggerConfig;
import org.apache.tomcat.util.buf.BufferInfo;
import org.apache.tomcat.util.modeler.Registry;
@@ -126,29 +125,6 @@
this.port = port;
}
- /**
- */
- public static ProtocolHandler getDefaultConnector(int port, boolean daemon) {
-//try {
-// Library.initialize("tcnative-1");
-// Http11AprProtocol proto = new Http11AprProtocol();
-// proto.setCompression("on");
-// proto.setCompressionMinSize(32);
-// proto.setPort(port);
-// proto.getEndpoint().setDaemon(daemon);
-// return proto;
-//} catch (Exception e) {
-// e.printStackTrace();
-// //throw new RuntimeException(e);
-//}
-
-SimpleProtocolHandler proto = new SimpleProtocolHandler();
-proto.setPort(port);
-proto.setDaemon(daemon);
-
-return proto;
- }
-
public void setNioConnector() {
Http11NioProtocol proto = new Http11NioProtocol();
proto.setCompression("on");
@@ -168,7 +144,8 @@
return;
}
if (proto == null) {
- proto = getDefaultConnector(port, daemon);
+ // Default for now.
+ setNioConnector();
}
initAdapters();
registry.registerComponent(adapter, ":name=adapter" + (port), null);
Modified:
tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/coyote/adapters/EchoAdapter.java
URL:
http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/coyote/adapters/EchoAdapter.java?rev=650962&r1=650961&r2=650962&view=diff
==
---
tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/coyote/adapters/EchoAdapter.java
(original)
+++
tomcat/sandbox/tomcat-lite/coyote-extensions/org/apache/coyote/adapters/EchoAdapter.java
Wed Apr 23 10:51:52 2008
@@ -5,7 +5,7 @@
import org.apache.coyote.Adapter;
import org.apache.coyote.Request;
import org.apache.coyote.Response;
-import org.apache.coyote.client.AsyncHttp;
+//import org.apache.coyote.client.AsyncHttp;
import org.apache.tomcat.util.buf.ByteChunk;
import org.apache.tomcat.util.net.SocketStatus;
@@ -24,7 +24,7 @@
public void service(Request req, final Response res) throws Exception {
ByteChunk reqBuf = new ByteChunk(1024);
reqBuf.append("REQ HEAD:\n");
- AsyncHttp.serializeRequest(req, reqBuf);
+ //AsyncHttp.serializeRequest(req, reqBuf);
reqBuf.append("CONTENT_LENGTH:")
.append(Integer.toString(req.getContentLength()))
.append("\n");
Modified: tomcat/sandbox/tomcat-lite/java/org/apache/tomcat/lite/TomcatLite.java
URL:
http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-lite/java/org/apache/tomcat/lite/TomcatLite.java?rev=650962&r1=650961&r2=650962&view=diff
==
--- tomcat/sandbox/tomcat-lite/java/org/apache/tomcat/lite/TomcatLite.java
(original)
+++ tomcat/sandbox/tomcat-lite/java/org/apache/tomcat/lite/TomcatLite.java Wed
Apr 23 10:51:52 2008
@@ -22,11 +22,11 @@
import org.apache.coyote.ActionCode;
import org.apache.coyote.ActionHook;
import org.apache.coyote.Adapter;
+import org.apache.coyote.OutputBuffer;
import org.apache.coyote.Request;
import org.ap
Re: Osgifing Tomcat
Henri Gomez wrote: I'm not sure it's the best idea, my goal is to move it out of sandbox, it already has enough experiments that need completion. and the main goal is to be 'lite' :-). It has a simple Addon mechanism, and I don't mind having an optional addon manager impl using OSGI - but I don't want to get distracted, I started tomcat-lite experiment >2 years ago. Yep, time to stabilize The first part ( adding manifests to existing tomcat ) seems to have support so could be done in the trunk. And no consequences outside OSGI world I don't see any reason for having non-intrusive OSGI support developed in sandbox - as long as the code is in a package that is excluded from the official distro, and is released as a separate unit it could live in trunk. It'll need the 3 +1 to be released, of course - but the whole point of modularity is to be able to develop modules independent of the container. Right IMO sandbox is for experiments that would replace existing tomcat components or core stuff. If you do it in trunk - it's easier to get it released eventually, and you may get better reviews and attention. Indeed I'll try to spend some time on mavenize tomcatlight first and how it could be done then for tomcat trunk. LOL, ouch, you just opened up the can of worms we thought we put a lid on :) he he basically, Tomcat 6 is mavenized, and we publish the individual JARs to ASF Maven repo. Next how to OSGIfy the mavenized tomcats, experiences and advices welcomed here my feeling is though, is that you are going for the "mavenization" just to run the BND or BNE or whatever the plugin is called, that generates the OSGi manifests. having personally done that, I can say that it simply doesn't work. IT works in most cases, but not in Tomcat, and even in the cases it works, the output it produces into the manifest file is completely useless to the human eye. the amount of stuff it exports and imports is insane, in in most cases irrelevant to the data you actually wanna export/import that's why I posted my combined version of the Export/Import, nice and clean, when/if we do it on a per jar basis, I would hope we aim to produce the same quality data as the example I showed. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
So nobody object for some experimentation around mavenizing Tomcat 6 ? Of course no commit just testing on my own eclipse/m2 workspace. >2008/4/23 Filip Hanik - Dev Lists <[EMAIL PROTECTED]>: > > Henri Gomez wrote: > > > > > > I'm not sure it's the best idea, my goal is to move it out of sandbox, > > > it already has enough experiments > > > that need completion. and the main goal is to be 'lite' :-). It has a > > > simple Addon mechanism, and I don't mind > > > having an optional addon manager impl using OSGI - but I don't want to > > > get distracted, I started > > > tomcat-lite experiment >2 years ago. > > > > > > > > > > > > > Yep, time to stabilize > > > > > > > > > The first part ( adding manifests to existing tomcat ) seems to have > > > support so could be done in the trunk. > > > > > > > > > > And no consequences outside OSGI world > > > > > > > > > I don't see any reason for having non-intrusive OSGI support developed > > > in sandbox - as long > > > as the code is in a package that is excluded from the official distro, > > > and is released as a separate > > > unit it could live in trunk. It'll need the 3 +1 to be released, of > > > course - but the whole point of > > > modularity is to be able to develop modules independent of the > container. > > > > > > > > > > Right > > > > > > > > > IMO sandbox is for experiments that would replace existing tomcat > > > components or core stuff. If you do it in > > > trunk - it's easier to get it released eventually, and you may get > > > better reviews and attention. > > > > > > > > > > Indeed > > > > I'll try to spend some time on mavenize tomcatlight first and how it > > could be done then for tomcat trunk. > > > > > LOL, ouch, you just opened up the can of worms we thought we put a lid on > :) he he > basically, Tomcat 6 is mavenized, and we publish the individual JARs to ASF > Maven repo. > > > > Next how to OSGIfy the mavenized tomcats, experiences and advices welcomed > here > > > > > my feeling is though, is that you are going for the "mavenization" just to > run the BND or BNE or whatever the plugin is called, that generates the OSGi > manifests. > having personally done that, I can say that it simply doesn't work. IT > works in most cases, but not in Tomcat, and even in the cases it works, the > output it produces into the manifest file is completely useless to the human > eye. the amount of stuff it exports and imports is insane, in in most cases > irrelevant to the data you actually wanna export/import > > that's why I posted my combined version of the Export/Import, nice and > clean, when/if we do it on a per jar basis, I would hope we aim to produce > the same quality data as the example I showed. > > Filip > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
hi Henri, Henri Gomez wrote: So nobody object for some experimentation around mavenizing Tomcat 6 ? no one can object what you do on your own time. It's your given right. However, if you look at the previous discussions around the Maven topic, you will see it is highly unlikely that the Tomcat community as it is today will adapt Maven anytime soon, if ever. No one has yet produced a viable reason for us to do so, and the OSGi-fying features of Maven, are not good at all, and one can produce a much better and cleaner manifest manually or simple package scanners with tools like jarjar. Filip Of course no commit just testing on my own eclipse/m2 workspace. 2008/4/23 Filip Hanik - Dev Lists <[EMAIL PROTECTED]>: Henri Gomez wrote: I'm not sure it's the best idea, my goal is to move it out of sandbox, it already has enough experiments that need completion. and the main goal is to be 'lite' :-). It has a simple Addon mechanism, and I don't mind having an optional addon manager impl using OSGI - but I don't want to get distracted, I started tomcat-lite experiment >2 years ago. Yep, time to stabilize The first part ( adding manifests to existing tomcat ) seems to have support so could be done in the trunk. And no consequences outside OSGI world I don't see any reason for having non-intrusive OSGI support developed in sandbox - as long as the code is in a package that is excluded from the official distro, and is released as a separate unit it could live in trunk. It'll need the 3 +1 to be released, of course - but the whole point of modularity is to be able to develop modules independent of the container. Right IMO sandbox is for experiments that would replace existing tomcat components or core stuff. If you do it in trunk - it's easier to get it released eventually, and you may get better reviews and attention. Indeed I'll try to spend some time on mavenize tomcatlight first and how it could be done then for tomcat trunk. LOL, ouch, you just opened up the can of worms we thought we put a lid on :) he he basically, Tomcat 6 is mavenized, and we publish the individual JARs to ASF Maven repo. Next how to OSGIfy the mavenized tomcats, experiences and advices welcomed here my feeling is though, is that you are going for the "mavenization" just to run the BND or BNE or whatever the plugin is called, that generates the OSGi manifests. having personally done that, I can say that it simply doesn't work. IT works in most cases, but not in Tomcat, and even in the cases it works, the output it produces into the manifest file is completely useless to the human eye. the amount of stuff it exports and imports is insane, in in most cases irrelevant to the data you actually wanna export/import that's why I posted my combined version of the Export/Import, nice and clean, when/if we do it on a per jar basis, I would hope we aim to produce the same quality data as the example I showed. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
First define 'mavenizing' please :-) If you mean exporting tomcat components in maven repository - fine with me. If you mean building tomcat with maven instead of ant - the opposite, absolutely not fine. Maintaining a separate maven build file - unofficial, i.e. the default build instructions still point to ant - maybe. Costin On Wed, Apr 23, 2008 at 12:52 PM, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: > hi Henri, > > > Henri Gomez wrote: > > > So nobody object for some experimentation around mavenizing Tomcat 6 ? > > > > > no one can object what you do on your own time. It's your given right. > However, if you look at the previous discussions around the Maven topic, > you will see it is highly unlikely that the Tomcat community as it is today > will adapt Maven anytime soon, if ever. No one has yet produced a viable > reason for us to do so, and the OSGi-fying features of Maven, are not good > at all, and one can produce a much better and cleaner manifest manually or > simple package scanners with tools like jarjar. > > Filip > > > > > Of course no commit just testing on my own eclipse/m2 workspace. > > > > > > > > > 2008/4/23 Filip Hanik - Dev Lists <[EMAIL PROTECTED]>: > > > > > > Henri Gomez wrote: > > > > > > > > > > > > > > > > > > I'm not sure it's the best idea, my goal is to move it out of > sandbox, > > > > > it already has enough experiments > > > > > that need completion. and the main goal is to be 'lite' :-). It has > a > > > > > simple Addon mechanism, and I don't mind > > > > > having an optional addon manager impl using OSGI - but I don't want > to > > > > > get distracted, I started > > > > > tomcat-lite experiment >2 years ago. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yep, time to stabilize > > > > > > > > > > > > > > > > > > > > > > > > > The first part ( adding manifests to existing tomcat ) seems to > have > > > > > support so could be done in the trunk. > > > > > > > > > > > > > > > > > > > > > > > > And no consequences outside OSGI world > > > > > > > > > > > > > > > > > > > > > > > > > I don't see any reason for having non-intrusive OSGI support > developed > > > > > in sandbox - as long > > > > > as the code is in a package that is excluded from the official > distro, > > > > > and is released as a separate > > > > > unit it could live in trunk. It'll need the 3 +1 to be released, > of > > > > > course - but the whole point of > > > > > modularity is to be able to develop modules independent of the > > > > > > > > > > > > > > > > > container. > > > > > > > > > > > > > > > > > > > > > > > > Right > > > > > > > > > > > > > > > > > > > > > > > > > IMO sandbox is for experiments that would replace existing tomcat > > > > > components or core stuff. If you do it in > > > > > trunk - it's easier to get it released eventually, and you may get > > > > > better reviews and attention. > > > > > > > > > > > > > > > > > > > > > > > > Indeed > > > > > > > > I'll try to spend some time on mavenize tomcatlight first and how it > > > > could be done then for tomcat trunk. > > > > > > > > > > > > > > > > > > > LOL, ouch, you just opened up the can of worms we thought we put a lid > on > > > :) he he > > > basically, Tomcat 6 is mavenized, and we publish the individual JARs to > ASF > > > Maven repo. > > > > > > > > > > > > > > > > Next how to OSGIfy the mavenized tomcats, experiences and advices > welcomed > > > > > > > > > > > here > > > > > > > > > > > > > > > > > my feeling is though, is that you are going for the "mavenization" just > to > > > run the BND or BNE or whatever the plugin is called, that generates the > OSGi > > > manifests. > > > having personally done that, I can say that it simply doesn't work. IT > > > works in most cases, but not in Tomcat, and even in the cases it works, > the > > > output it produces into the manifest file is completely useless to the > human > > > eye. the amount of stuff it exports and imports is insane, in in most > cases > > > irrelevant to the data you actually wanna export/import > > > > > > that's why I posted my combined version of the Export/Import, nice and > > > clean, when/if we do it on a per jar basis, I would hope we aim to > produce > > > the same quality data as the example I showed. > > > > > > Filip > > > > > > > > > > > > > > > > > > > - > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > -
Re: Osgifing Tomcat
> First define 'mavenizing' please :-) Yes > If you mean exporting tomcat components in maven repository - fine with me. It's allready done (by hand) ? > If you mean building tomcat with maven instead of ant - the opposite, > absolutely not fine. it was the idea. > Maintaining a separate maven build file - unofficial, i.e. the default > build instructions still point to ant - maybe. To modularise we should use modules layout ie : pom.xml -- catalina pom.xml -- catalina-ant pom.xml -- catalina-ha pom.xml -- jasper pom.xml -- jasper-jdt pom.xml So some changes in the actual source layout. we could also provide ant scripts to build also from this new layout. Could you comment why maven is not the welcome here, ASF JackRabbit or ApacheDS are pretty large projects and allready use it. I don't want to start a pros/cons maven, but it will ease : - build TC from scratch - upload artifact to maven repos - fit finelly with IC tools, like Hudson or TeamCity - maven tools like maven-bundle-plugin will ease the OSGI bundle stuff Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
On Wed, Apr 23, 2008 at 1:17 PM, Henri Gomez <[EMAIL PROTECTED]> wrote: > > First define 'mavenizing' please :-) > > Yes > > > > If you mean exporting tomcat components in maven repository - fine with > me. > > It's allready done (by hand) ? > > > > If you mean building tomcat with maven instead of ant - the opposite, > > absolutely not fine. > > it was the idea. Sorry, -1 from me ( again ). > > > > Maintaining a separate maven build file - unofficial, i.e. the default > > build instructions still point to ant - maybe. > > To modularise we should use modules layout ie : > > pom.xml > > -- catalina > pom.xml > So some changes in the actual source layout. And that would be the reason for -1. If a build system requires intrusive changes and forces a particular code organization - it shouldn't be used. > Could you comment why maven is not the welcome here, ASF JackRabbit or > ApacheDS are pretty large projects and allready use it. It is a choice each project can make, some people like intrusive tools :-) I think it is great to have alternative build files - as long as the build system plays nicely with others and doesn't set conditions on how we should organize code. In particular - we have eclipse build support, it would be great to add idea/netbeans if anyone can support them - and if you can add maven in the same way ( i.e. just maven files in a separate dir, without changes to source layout just because maven needs them) - no problem with me. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 43957] service.bat doesn' t configure logging like the Windows installer
https://issues.apache.org/bugzilla/show_bug.cgi?id=43957 --- Comment #4 from Richard Fearn <[EMAIL PROTECTED]> 2008-04-23 13:26:22 PST --- I've tested this in Tomcat 5.5 and 6.0 and it works fine. Thanks for getting my patch into the tree. Who should close the bug? You or me? Thanks. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
> > it was the idea. > > Sorry, -1 from me ( again ). Sic... > And that would be the reason for -1. > If a build system requires intrusive changes and forces a particular code > organization - it shouldn't be used. that's maven phylosophy, not so bad. > It is a choice each project can make, some people like intrusive tools :-) Intrusive ? Nope, just maven convention. > I think it is great to have alternative build files - as long as the > build system plays > nicely with others and doesn't set conditions on how we should organize code. > In particular - we have eclipse build support, it would be great to > add idea/netbeans > if anyone can support them - and if you can add maven in the same way ( i.e. > just maven files in a separate dir, without changes to source layout > just because > maven needs them) - no problem with me. I use eclipse with m2eclipse and the support for multi modules is right. Netbeans has a great maven support with mevenide (may be the best) and some co-workers use IDEA and are very happy with its maven support. >From my experience a mavenized project is buildable from command line and with majors IDEs. I've got a decent experiences after converting more than 100 projects from ant to maven and make them as confortable under Eclipse than previously. Using maven and keeping the actual layout will be possible, but will complexify the mvn and poms. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
Henri Gomez wrote: First define 'mavenizing' please :-) Yes If you mean exporting tomcat components in maven repository - fine with me. It's allready done (by hand) ? If you mean building tomcat with maven instead of ant - the opposite, absolutely not fine. it was the idea. This subject has been beaten do death, with the same outcome, I don't think it does anyone any good going there again Filip Maintaining a separate maven build file - unofficial, i.e. the default build instructions still point to ant - maybe. To modularise we should use modules layout ie : pom.xml -- catalina pom.xml -- catalina-ant pom.xml -- catalina-ha pom.xml -- jasper pom.xml -- jasper-jdt pom.xml So some changes in the actual source layout. we could also provide ant scripts to build also from this new layout. Could you comment why maven is not the welcome here, ASF JackRabbit or ApacheDS are pretty large projects and allready use it. I don't want to start a pros/cons maven, but it will ease : - build TC from scratch - upload artifact to maven repos - fit finelly with IC tools, like Hudson or TeamCity - maven tools like maven-bundle-plugin will ease the OSGI bundle stuff Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 43957] service.bat doesn' t configure logging like the Windows installer
https://issues.apache.org/bugzilla/show_bug.cgi?id=43957 --- Comment #5 from Mark Thomas <[EMAIL PROTECTED]> 2008-04-23 13:38:05 PST --- It's all yours ;) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
I grab jackrabbit and apacheds right now from eclipse : - added their repositories to eclipse - checkout maven project from SVN - got the main project and modules in the eclipse workspace - mvn package and voila it works ! Hard to be simpler :) Just a note, I'm not a maven evangelist :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
On Wed, Apr 23, 2008 at 6:56 PM, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: > > Henri Gomez wrote: > > > > > > I'm not sure it's the best idea, my goal is to move it out of sandbox, > > > it already has enough experiments > > > that need completion. and the main goal is to be 'lite' :-). It has a > > > simple Addon mechanism, and I don't mind > > > having an optional addon manager impl using OSGI - but I don't want to > > > get distracted, I started > > > tomcat-lite experiment >2 years ago. > > > > > > > > > > > > > Yep, time to stabilize > > > > > > > > > The first part ( adding manifests to existing tomcat ) seems to have > > > support so could be done in the trunk. > > > > > > > > > > And no consequences outside OSGI world > > > > > > > > > I don't see any reason for having non-intrusive OSGI support developed > > > in sandbox - as long > > > as the code is in a package that is excluded from the official distro, > > > and is released as a separate > > > unit it could live in trunk. It'll need the 3 +1 to be released, of > > > course - but the whole point of > > > modularity is to be able to develop modules independent of the > container. > > > > > > > > > > Right > > > > > > > > > IMO sandbox is for experiments that would replace existing tomcat > > > components or core stuff. If you do it in > > > trunk - it's easier to get it released eventually, and you may get > > > better reviews and attention. > > > > > > > > > > Indeed > > > > I'll try to spend some time on mavenize tomcatlight first and how it > > could be done then for tomcat trunk. > > > > > LOL, ouch, you just opened up the can of worms we thought we put a lid on > :) he he > basically, Tomcat 6 is mavenized, and we publish the individual JARs to ASF > Maven repo. > > > > Next how to OSGIfy the mavenized tomcats, experiences and advices welcomed > here > > > > > my feeling is though, is that you are going for the "mavenization" just to > run the BND or BNE or whatever the plugin is called, that generates the OSGi > manifests. Someone recently pointed out to me that the Bnd tool comes with ant tasks. I haven't tried that (we've used maven in commons) and I suspect that there isn't the option to just produce the manifest (rather than jar and manifest) as there is in the maven plugin. If that was required then in might be worth requesting that: http://www.aqute.biz/Code/Bnd > having personally done that, I can say that it simply doesn't work. IT > works in most cases, but not in Tomcat, and even in the cases it works, the > output it produces into the manifest file is completely useless to the human > eye. the amount of stuff it exports and imports is insane, in in most cases > irrelevant to the data you actually wanna export/import Are you talking about all the "uses" statements it adds? If so an option to turn off producing them was recently added to the Bnd tool - which improves the situation. It still wraps everything to 72 characters which is harder to read than a manually created manifest - but I think automating this to reduce the chance of errors from manually keying in is worth the trade off. Niall > that's why I posted my combined version of the Export/Import, nice and > clean, when/if we do it on a per jar basis, I would hope we aim to produce > the same quality data as the example I showed. > > Filip > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r651075 - /tomcat/trunk/java/org/apache/tomcat/util/threads/ThreadPool.java
Author: markt
Date: Wed Apr 23 14:37:09 2008
New Revision: 651075
URL: http://svn.apache.org/viewvc?rev=651075&view=rev
Log:
Generics changes for o.a.t.util.threads
No fucntional change
Modified:
tomcat/trunk/java/org/apache/tomcat/util/threads/ThreadPool.java
Modified: tomcat/trunk/java/org/apache/tomcat/util/threads/ThreadPool.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/threads/ThreadPool.java?rev=651075&r1=651074&r2=651075&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/threads/ThreadPool.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/threads/ThreadPool.java Wed Apr 23
14:37:09 2008
@@ -96,9 +96,11 @@
/** The threads that are part of the pool.
* Key is Thread, value is the ControlRunnable
*/
-protected Hashtable threads=new Hashtable();
+protected Hashtable threads =
+new Hashtable();
-protected Vector listeners=new Vector();
+protected Vector listeners =
+new Vector();
/** Name of the threadpool
*/
@@ -180,10 +182,10 @@
// Set for future threads
this.threadPriority = threadPriority;
- Enumeration currentThreads = getThreads();
+ Enumeration currentThreads = getThreads();
Thread t = null;
while(currentThreads.hasMoreElements()) {
-t = (Thread) currentThreads.nextElement();
+t = currentThreads.nextElement();
t.setPriority(threadPriority);
}
}
@@ -270,7 +272,7 @@
public void addThread( Thread t, ControlRunnable cr ) {
threads.put( t, cr );
for( int i=0; i getThreads(){
return threads.keys();
}
@@ -784,7 +786,7 @@
*/
public String threadStatusString() {
StringBuffer sb=new StringBuffer();
-Iterator it=threads.keySet().iterator();
+Iterator it=threads.keySet().iterator();
sb.append("");
while( it.hasNext()) {
sb.append("");
@@ -807,7 +809,7 @@
*/
public String[] getThreadStatus() {
String status[]=new String[ threads.size()];
-Iterator it=threads.keySet().iterator();
+Iterator it=threads.keySet().iterator();
for( int i=0; ( i it=threads.keySet().iterator();
for( int i=0; ( i
svn commit: r651076 - /tomcat/trunk/java/org/apache/tomcat/util/res/StringManager.java
Author: markt
Date: Wed Apr 23 14:38:09 2008
New Revision: 651076
URL: http://svn.apache.org/viewvc?rev=651076&view=rev
Log:
Generics changes for o.a.t.util.res
No fucntional change
Modified:
tomcat/trunk/java/org/apache/tomcat/util/res/StringManager.java
Modified: tomcat/trunk/java/org/apache/tomcat/util/res/StringManager.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/res/StringManager.java?rev=651076&r1=651075&r2=651076&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/res/StringManager.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/res/StringManager.java Wed Apr 23
14:38:09 2008
@@ -236,7 +236,8 @@
// STATIC SUPPORT METHODS
// --
-private static Hashtable managers = new Hashtable();
+private static Hashtable managers =
+new Hashtable();
/**
* Get the StringManager for a particular package. If a manager for
@@ -246,7 +247,7 @@
* @param packageName The package name
*/
public synchronized static StringManager getManager(String packageName) {
- StringManager mgr = (StringManager)managers.get(packageName);
+ StringManager mgr = managers.get(packageName);
if (mgr == null) {
mgr = new StringManager(packageName);
managers.put(packageName, mgr);
@@ -275,7 +276,7 @@
*/
public synchronized static StringManager getManager(String
packageName,Locale loc) {
- StringManager mgr =
(StringManager)managers.get(packageName+"_"+loc.toString());
+ StringManager mgr = managers.get(packageName+"_"+loc.toString());
if (mgr == null) {
mgr = new StringManager(packageName,loc);
managers.put(packageName+"_"+loc.toString(), mgr);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r651082 - /tomcat/trunk/java/org/apache/jasper/compiler/Generator.java
Author: markt
Date: Wed Apr 23 14:52:11 2008
New Revision: 651082
URL: http://svn.apache.org/viewvc?rev=651082&view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=43617
Correctly handle quotes in attribute values for tag(x) files.
Modified:
tomcat/trunk/java/org/apache/jasper/compiler/Generator.java
Modified: tomcat/trunk/java/org/apache/jasper/compiler/Generator.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/Generator.java?rev=651082&r1=651081&r2=651082&view=diff
==
--- tomcat/trunk/java/org/apache/jasper/compiler/Generator.java (original)
+++ tomcat/trunk/java/org/apache/jasper/compiler/Generator.java Wed Apr 23
14:52:11 2008
@@ -1755,6 +1755,7 @@
String value = attrs.getValue(i);
if (value.indexOf('"') != -1) {
quote = SINGLE_QUOTE;
+value = value.replace("\"", DOUBLE_QUOTE);
}
out.print(quote);
out.print(value);
@@ -1777,6 +1778,7 @@
String value = attrs.getValue(i);
if (value.indexOf('"') != -1) {
quote = SINGLE_QUOTE;
+value = value.replace("\"", DOUBLE_QUOTE);
}
out.print(quote);
out.print(value);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
Niall Pemberton wrote: On Wed, Apr 23, 2008 at 6:56 PM, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: Henri Gomez wrote: I'm not sure it's the best idea, my goal is to move it out of sandbox, it already has enough experiments that need completion. and the main goal is to be 'lite' :-). It has a simple Addon mechanism, and I don't mind having an optional addon manager impl using OSGI - but I don't want to get distracted, I started tomcat-lite experiment >2 years ago. Yep, time to stabilize The first part ( adding manifests to existing tomcat ) seems to have support so could be done in the trunk. And no consequences outside OSGI world I don't see any reason for having non-intrusive OSGI support developed in sandbox - as long as the code is in a package that is excluded from the official distro, and is released as a separate unit it could live in trunk. It'll need the 3 +1 to be released, of course - but the whole point of modularity is to be able to develop modules independent of the container. Right IMO sandbox is for experiments that would replace existing tomcat components or core stuff. If you do it in trunk - it's easier to get it released eventually, and you may get better reviews and attention. Indeed I'll try to spend some time on mavenize tomcatlight first and how it could be done then for tomcat trunk. LOL, ouch, you just opened up the can of worms we thought we put a lid on :) he he basically, Tomcat 6 is mavenized, and we publish the individual JARs to ASF Maven repo. Next how to OSGIfy the mavenized tomcats, experiences and advices welcomed here my feeling is though, is that you are going for the "mavenization" just to run the BND or BNE or whatever the plugin is called, that generates the OSGi manifests. Someone recently pointed out to me that the Bnd tool comes with ant tasks. I haven't tried that (we've used maven in commons) and I suspect that there isn't the option to just produce the manifest (rather than jar and manifest) as there is in the maven plugin. If that was required then in might be worth requesting that: http://www.aqute.biz/Code/Bnd doesn't really matter what you wrap the Bnd tool in, if the tool produces poor data. having personally done that, I can say that it simply doesn't work. IT works in most cases, but not in Tomcat, and even in the cases it works, the output it produces into the manifest file is completely useless to the human eye. the amount of stuff it exports and imports is insane, in in most cases irrelevant to the data you actually wanna export/import Are you talking about all the "uses" statements it adds? If so an option to turn off producing them was recently added to the Bnd tool - which improves the situation. It still wraps everything to 72 characters which is harder to read than a manually created manifest - but I think automating this to reduce the chance of errors from manually keying in is worth the trade off. no, just the basic import/export. one can still automate it, just do it smarter than Bnd tool does Filip Niall that's why I posted my combined version of the Export/Import, nice and clean, when/if we do it on a per jar basis, I would hope we aim to produce the same quality data as the example I showed. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r651083 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: markt Date: Wed Apr 23 14:54:32 2008 New Revision: 651083 URL: http://svn.apache.org/viewvc?rev=651083&view=rev Log: Propose fix for 43617. Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=651083&r1=651082&r2=651083&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Wed Apr 23 14:54:32 2008 @@ -117,3 +117,9 @@ http://svn.apache.org/viewvc?rev=649993&view=rev +1: markt, remm -1: + +* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=43617 + Correctly handle quotes in attribute values for tag(x) files + http://svn.apache.org/viewvc?rev=651082&view=rev + +1: markt + -1: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 43617] attribute values within a .tag(x) file are not properly escaped
https://issues.apache.org/bugzilla/show_bug.cgi?id=43617 --- Comment #2 from Mark Thomas <[EMAIL PROTECTED]> 2008-04-23 14:51:28 PST --- I think you meant " rather than & in your patch. I have commited a variation to trunk and proposed it for 6.0.x -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 44856] add host alias using jmx doesn' t take affect until restart
https://issues.apache.org/bugzilla/show_bug.cgi?id=44856 Mark Thomas <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Mark Thomas <[EMAIL PROTECTED]> 2008-04-23 14:56:22 PST --- I'll add a note to 42707 to port the fix to TC5. *** This bug has been marked as a duplicate of bug 42707 *** -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 42707] add host alias using jmx doesn' t take affect until restart
https://issues.apache.org/bugzilla/show_bug.cgi?id=42707 --- Comment #2 from Mark Thomas <[EMAIL PROTECTED]> 2008-04-23 14:56:22 PST --- *** Bug 44856 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 42707] add host alias using jmx doesn' t take affect until restart
https://issues.apache.org/bugzilla/show_bug.cgi?id=42707 --- Comment #3 from Mark Thomas <[EMAIL PROTECTED]> 2008-04-23 14:56:47 PST --- Note to self - need to port this to 5.5.x when fixed. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
On Wed, Apr 23, 2008 at 1:38 PM, Henri Gomez <[EMAIL PROTECTED]> wrote: > > And that would be the reason for -1. > > If a build system requires intrusive changes and forces a particular code > > organization - it shouldn't be used. > > that's maven phylosophy, not so bad. The layout may be good ( by some people taste ) - the bad is imposing it on others. We need build tools, not philosophy. > > It is a choice each project can make, some people like intrusive tools > :-) > > Intrusive ? Nope, just maven convention. If the maven convention is to move files around just to use a particular tool - that's quite intrusive IMO. > Using maven and keeping the actual layout will be possible, but will > complexify the mvn and poms. That's maven's problem - I don't think there is any value in continuing this discussion, again - if you can support maven by adding a build/maven directory and whatever files inside - you have my +1, I'm all for making it easy to build - as long as the tools are not intrusive and don't force in their religion and arbitrary conventions. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r651123 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: remm Date: Wed Apr 23 17:29:22 2008 New Revision: 651123 URL: http://svn.apache.org/viewvc?rev=651123&view=rev Log: - Votes. Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=651123&r1=651122&r2=651123&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Wed Apr 23 17:29:22 2008 @@ -79,13 +79,7 @@ * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=43683 Need to identify new wrapper for queued request after reload http://svn.apache.org/viewvc?rev=650648&view=rev - +1: markt - -1: remm (there's a check for null on the next line -> not good; other than that small glitch, - this is not an expensive check unless it is unavailable so it's probably fine; honestly, - I would still consider adding isStarted to Container - maybe it should be in Lifecycle, - but I'd say any container should have the flag) - markt - It was easy to work around this time. - Maybe adding isStarted is something for 6.2.x/7.0.x? + +1: markt, remm -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=43656 @@ -121,5 +115,5 @@ * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=43617 Correctly handle quotes in attribute values for tag(x) files http://svn.apache.org/viewvc?rev=651082&view=rev - +1: markt + +1: markt, remm -1: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
> That's maven's problem - I don't think there is any value in > continuing this discussion, > again - if you can support maven by adding a build/maven directory and > whatever files > inside - you have my +1, I'm all for making it easy to build - as long > as the tools are not > intrusive and don't force in their religion and arbitrary conventions. Ok, I'll work on this direction, keeping the actual layout and adding files / folders to mimic the modules structure - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
