Re: Small refactoring in Http11Processor
Mark Thomas wrote: Costin Manolache wrote: Is there any plan to do a bit of cleanup ? Maybe move some of the dead code in connectors (mod_webap, jk2, etc ) to a new repo ? And maybe add a new 'sandbox' repository ? I'll start a new thread to gather candidates to move to the archive area. There are lots of things inside connectors that needs to be archived. For example: /ajp, /jk/native2, /jk/webapp. Also, not sure what the '/scandoc' is used for. Further more, inside jk/native the docs, domino, nt_service and isapi folders are obsolete. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Small refactoring in Http11Processor
Mark Thomas wrote: Mladen Turk wrote: Costin Manolache wrote: Hi, Also, I would like to add another directory under j-t-c, with a build file and few classes for a 'mini' experiment - i.e. using the connector standalone, as a minimal http server, and also a target to build a minimal servlet container as a single self-contained jar. We don't have a sandbox, and j-t-c seems closest to that :-) Hi Costin, Nice to have you back :) Anyhow, seems that the SVN transition is in progress. If the time is acceptable, perhaps you can postpone that, and simply create a branch in SVN. I'm not sure when the code will be moved to SVN, perhaps Mark will know. I am about to kick of TC3 and TC4. Once that is complete (few days?) I'll do the last batch which will be TC5, Connectors and Jasper. Mark Is there any plan to do a bit of cleanup ? Maybe move some of the dead code in connectors (mod_webap, jk2, etc ) to a new repo ? And maybe add a new 'sandbox' repository ? Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Small refactoring in Http11Processor
Costin Manolache wrote: Mark Thomas wrote: I am about to kick of TC3 and TC4. Once that is complete (few days?) I'll do the last batch which will be TC5, Connectors and Jasper. Mark Is there any plan to do a bit of cleanup ? Maybe move some of the dead code in connectors (mod_webap, jk2, etc ) to a new repo ? And maybe add a new 'sandbox' repository ? I think a clean-up is a very good idea. An archive area already exists and contains jakarta-tomcat-service and jakarta-tools. We should do any clean-up after the svn migration is complete. That way we keep migration issues separate from clean-up issues so it is clear what the cause is if something breaks. I'll start a new thread to gather candidates to move to the archive area. I also think a sandbox is a good idea. Remy will have to do this as he is the only one of us (as PMC chair) with karma at the top of our repo and karma to change the svn authorisation file. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Small refactoring in Http11Processor
Mladen Turk wrote: Costin Manolache wrote: Hi, Also, I would like to add another directory under j-t-c, with a build file and few classes for a 'mini' experiment - i.e. using the connector standalone, as a minimal http server, and also a target to build a minimal servlet container as a single self-contained jar. We don't have a sandbox, and j-t-c seems closest to that :-) Hi Costin, Nice to have you back :) Anyhow, seems that the SVN transition is in progress. If the time is acceptable, perhaps you can postpone that, and simply create a branch in SVN. I'm not sure when the code will be moved to SVN, perhaps Mark will know. I am about to kick of TC3 and TC4. Once that is complete (few days?) I'll do the last batch which will be TC5, Connectors and Jasper. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Small refactoring in Http11Processor
Costin Manolache wrote: Hi, Also, I would like to add another directory under j-t-c, with a build file and few classes for a 'mini' experiment - i.e. using the connector standalone, as a minimal http server, and also a target to build a minimal servlet container as a single self-contained jar. We don't have a sandbox, and j-t-c seems closest to that :-) Hi Costin, Nice to have you back :) Anyhow, seems that the SVN transition is in progress. If the time is acceptable, perhaps you can postpone that, and simply create a branch in SVN. I'm not sure when the code will be moved to SVN, perhaps Mark will know. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Small refactoring in Http11Processor
- Original Message - From: Costin Manolache [EMAIL PROTECTED] To: tomcat-dev@jakarta.apache.org Sent: Thursday, September 08, 2005 10:56 PM Subject: Small refactoring in Http11Processor Hi, I have a small patch, spliting the JMX-dependent code in Http11Processor, i.e. the few lines of code dealing with the registration of the thread pool and per thread data - and moving all non-jmx code in a separate base class. I know Tomcat5 is heavily dependent on JMX, but the connector can be used in other containers, or it can be used standalone. This small change won't affect any functionality on tomcat - all methods are used only for intialization anyway, not in the critical path. Please review and let me know if it's ok to commit the change. It seems that the only thing this patch does is to allow you to exclude jmx.jar, so it's usefulness seems very minimal :). TC 3.3 4.1 already run very happily with the current code without JMX enabled. Something better would be a refactor that would remove the duplicated code between Http11Processor and Http11AprProcessor (which one doesn't do :). Of course, none of this is enough for me to veto your scratching an itch :). Also, I would like to add another directory under j-t-c, with a build file and few classes for a 'mini' experiment - i.e. using the connector standalone, as a minimal http server, and also a target to build a minimal servlet container as a single self-contained jar. We don't have a sandbox, and j-t-c seems closest to that :-) I agree with Mladen that this would work better if you could wait a couple of weeks until we are up on SVN. Costin This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Small refactoring in Http11Processor
Bill Barker wrote: - Original Message - From: Costin Manolache [EMAIL PROTECTED] To: tomcat-dev@jakarta.apache.org Sent: Thursday, September 08, 2005 10:56 PM Subject: Small refactoring in Http11Processor Hi, I have a small patch, spliting the JMX-dependent code in Http11Processor, i.e. the few lines of code dealing with the registration of the thread pool and per thread data - and moving all non-jmx code in a separate base class. I know Tomcat5 is heavily dependent on JMX, but the connector can be used in other containers, or it can be used standalone. This small change won't affect any functionality on tomcat - all methods are used only for intialization anyway, not in the critical path. Please review and let me know if it's ok to commit the change. It seems that the only thing this patch does is to allow you to exclude jmx.jar, so it's usefulness seems very minimal :). TC 3.3 4.1 already run very happily with the current code without JMX enabled. True, it allows a smaller package. TC3.3 and 4.1 don't register the connector, so no JMX-related code is called, but it still requires jmx.jar to be around. Something better would be a refactor that would remove the duplicated code between Http11Processor and Http11AprProcessor (which one doesn't do :). Yes, I've been thinking about this too :-), and also InternalAprBuffer and maybe add conditional compilation for the apr. But I didn't want to make the diff too big and risky. Of course, none of this is enough for me to veto your scratching an itch :). Also, I would like to add another directory under j-t-c, with a build file and few classes for a 'mini' experiment - i.e. using the connector standalone, as a minimal http server, and also a target to build a minimal servlet container as a single self-contained jar. We don't have a sandbox, and j-t-c seems closest to that :-) I agree with Mladen that this would work better if you could wait a couple of weeks until we are up on SVN. Ok, sounds good, I need to clean up the code anyway ( well, there are 2-3 classes only and some build.xml ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Small refactoring in Http11Processor
Hi,
I have a small patch, spliting the JMX-dependent code in
Http11Processor, i.e. the few lines of code dealing with the
registration of the thread pool and per thread data - and moving all
non-jmx code in a separate base class.
I know Tomcat5 is heavily dependent on JMX, but the connector can be
used in other containers, or it can be used standalone. This small
change won't affect any functionality on tomcat - all methods are used
only for intialization anyway, not in the critical path.
Please review and let me know if it's ok to commit the change.
Also, I would like to add another directory under j-t-c, with a build
file and few classes for a 'mini' experiment - i.e. using the connector
standalone, as a minimal http server, and also a target to build a
minimal servlet container as a single self-contained jar. We don't have
a sandbox, and j-t-c seems closest to that :-)
Costin
? src/java/org/apache/coyote/http11/Http11BaseProtocol.java
Index: src/java/org/apache/coyote/http11/Http11Protocol.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Protocol.java,v
retrieving revision 1.64
diff -b -u -w -r1.64 Http11Protocol.java
--- src/java/org/apache/coyote/http11/Http11Protocol.java 22 May 2005
17:12:11 - 1.64
+++ src/java/org/apache/coyote/http11/Http11Protocol.java 9 Sep 2005
05:31:50 -
@@ -56,98 +56,12 @@
* @author Remy Maucherat
* @author Costin Manolache
*/
-public class Http11Protocol implements ProtocolHandler, MBeanRegistration
+public class Http11Protocol extends Http11BaseProtocol implements
MBeanRegistration
{
public Http11Protocol() {
-cHandler = new Http11ConnectionHandler( this );
-setSoLinger(Constants.DEFAULT_CONNECTION_LINGER);
-setSoTimeout(Constants.DEFAULT_CONNECTION_TIMEOUT);
-setServerSoTimeout(Constants.DEFAULT_SERVER_SOCKET_TIMEOUT);
-setTcpNoDelay(Constants.DEFAULT_TCP_NO_DELAY);
+super();
}
-/**
- * The string manager for this package.
- */
-protected static StringManager sm =
-StringManager.getManager(Constants.Package);
-
-/** Pass config info
- */
-public void setAttribute( String name, Object value ) {
-if( log.isTraceEnabled())
-log.trace(sm.getString(http11protocol.setattribute, name,
value));
-
-attributes.put(name, value);
-}
-
-public Object getAttribute( String key ) {
-if( log.isTraceEnabled())
-log.trace(sm.getString(http11protocol.getattribute, key));
-return attributes.get(key);
-}
-
-public Iterator getAttributeNames() {
-return attributes.keySet().iterator();
-}
-
-/**
- * Set a property.
- */
-public void setProperty(String name, String value) {
-setAttribute(name, value);
-}
-
-/**
- * Get a property
- */
-public String getProperty(String name) {
-return (String)getAttribute(name);
-}
-
-/** The adapter, used to call the connector
- */
-public void setAdapter(Adapter adapter) {
-this.adapter=adapter;
-}
-
-public Adapter getAdapter() {
-return adapter;
-}
-
-
-/** Start the protocol
- */
-public void init() throws Exception {
-ep.setConnectionHandler( cHandler );
-try {
-checkSocketFactory();
-} catch( Exception ex ) {
-log.error(sm.getString(http11protocol.socketfactory.initerror),
- ex);
-throw ex;
-}
-
-if( socketFactory!=null ) {
-Enumeration attE=attributes.keys();
-while( attE.hasMoreElements() ) {
-String key=(String)attE.nextElement();
-Object v=attributes.get( key );
-socketFactory.setAttribute( key, v );
-}
-}
-
-// XXX get domain from registration
-try {
-ep.initEndpoint();
-} catch (Exception ex) {
-log.error(sm.getString(http11protocol.endpoint.initerror), ex);
-throw ex;
-}
-if(log.isInfoEnabled())
-log.info(sm.getString(http11protocol.init, getName()));
-
-}
ObjectName tpOname;
ObjectName rgOname;
@@ -178,460 +92,18 @@
( cHandler.global, rgOname, null );
}
-try {
-ep.startEndpoint();
-} catch (Exception ex) {
-log.error(sm.getString(http11protocol.endpoint.starterror), ex);
-throw ex;
-}
-if(log.isInfoEnabled())
-log.info(sm.getString(http11protocol.start, getName()));
-}
-
-public void pause() throws Exception {
-try {
-ep.pauseEndpoint();
-} catch (Exception ex) {
-log.error(sm.getString(http11protocol.endpoint.pauseerror), ex);
-throw ex;
-
