RE: Next Release 5.5.11?
Howdy, Probably next weekend, but that's not guaranteed. It will be a 5.5.11. Feel free to use 5.5.9 or build a custom release from HEAD for yourself if you can't wait that long. Yoav Shapira System Design and Management Fellow MIT Sloan School of Management Cambridge, MA USA [EMAIL PROTECTED] / www.yoavshapira.com > -Original Message- > From: Thorsten Kamann [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 04, 2005 2:29 AM > To: tomcat-dev@jakarta.apache.org > Subject: Next Release 5.5.11? > > Hello, > > the current release is 5.5.10-alpha. Are there plans to change this in a > 5.5.10 or make a 5.5.11? > The bug #35894 (http://issues.apache.org/bugzilla/show_bug.cgi?id=35894) > Bill > has resolved today is a stopper, because the Tomcat cannot start with > SecurityManager enabled. > > Thorsten > > -- > Thorsten Kamann > Email: [EMAIL PROTECTED] > ICQ: 40746578 > Yahoo: ThorQue > > - > 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]
Next Release 5.5.11?
Hello, the current release is 5.5.10-alpha. Are there plans to change this in a 5.5.10 or make a 5.5.11? The bug #35894 (http://issues.apache.org/bugzilla/show_bug.cgi?id=35894) Bill has resolved today is a stopper, because the Tomcat cannot start with SecurityManager enabled. Thorsten -- Thorsten Kamann Email: [EMAIL PROTECTED] ICQ: 40746578 Yahoo: ThorQue - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next release?
OK, I can do that at monday. Thanx Peter Remy Maucherat schrieb: Peter Rossbach wrote: Hey Remy, yes, but I thing we need some test. Than I can made the complete integration. I vote in favor of doing the complete integration right now. Worst case it's as bad as the current code, which isn't exactly well tested in the 5.5 branch ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J2EE Systemarchitekt und Tomcat Experte http://objektpark.de/ http://tomcat.objektpark.org/ http://centaurus.sourceforge.net/ Am Josephsschacht 72, 44879 Bochum, Deutschland Telefon: (49) 234 9413228 Mobil:(49) 175 1660884 E-Mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next release?
Peter Rossbach wrote: Hey Remy, yes, but I thing we need some test. Than I can made the complete integration. I vote in favor of doing the complete integration right now. Worst case it's as bad as the current code, which isn't exactly well tested in the 5.5 branch ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next release?
Hey Remy, yes, but I thing we need some test. Than I can made the complete integration. Peter Remy Maucherat schrieb: Peter Rossbach wrote: Hey Remy, I have ready my first storeconfig module to better save server.xml and context.xml. At the first step I add the implementation as new module. I have wrote a StoreConfigLifecycleListener to register a new Mbean . Please read the short readme at jakarta-tomcat-catalina/modules/storeconfig/docs after my checkin. So I say we delay 5.5.7 so that it is integrated well (I would assume the main thing to do is to remove the old code). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J2EE Systemarchitekt und Tomcat Experte http://objektpark.de/ http://tomcat.objektpark.org/ http://centaurus.sourceforge.net/ Am Josephsschacht 72, 44879 Bochum, Deutschland Telefon: (49) 234 9413228 Mobil:(49) 175 1660884 E-Mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next release?
Peter Rossbach wrote: Hey Remy, I have ready my first storeconfig module to better save server.xml and context.xml. At the first step I add the implementation as new module. I have wrote a StoreConfigLifecycleListener to register a new Mbean . Please read the short readme at jakarta-tomcat-catalina/modules/storeconfig/docs after my checkin. So I say we delay 5.5.7 so that it is integrated well (I would assume the main thing to do is to remove the old code). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next release?
Hey Remy, I have ready my first storeconfig module to better save server.xml and context.xml. At the first step I add the implementation as new module. I have wrote a StoreConfigLifecycleListener to register a new Mbean . Please read the short readme at jakarta-tomcat-catalina/modules/storeconfig/docs after my checkin. Regards Peter Remy Maucherat schrieb: Yoav Shapira wrote: Hi, Happy new year everyone ;) I just got back from vacation and don't have time to read all the archives. What's the feeling as to a good time for the next 5.5 release? I did some more bugfixing. Hopefully the hot deployer will be fully functional in this build :) Is it ok to do a 5.5.7 tag ? 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]
Re: Next release?
Yoav Shapira wrote: Hi, Happy new year everyone ;) I just got back from vacation and don't have time to read all the archives. What's the feeling as to a good time for the next 5.5 release? I did some more bugfixing. Hopefully the hot deployer will be fully functional in this build :) Is it ok to do a 5.5.7 tag ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next release?
Yoav Shapira wrote: Hi, Happy new year everyone ;) I just got back from vacation and don't have time to read all the archives. What's the feeling as to a good time for the next 5.5 release? I know there's still some deployer related troubles with 5.5.6. That should be ok now. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Next release?
Hi, Happy new year everyone ;) I just got back from vacation and don't have time to read all the archives. What's the feeling as to a good time for the next 5.5 release? Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Next release
Hi, >IMHO, 1.5 would be the right way to go. For me mostly for performance, >and cleaner code reasons (generics, auto-boxing, enums, etc.). Please do NOT automatically equate JDK 1.5 with cleaner code. Cleanliness is obviously subjective. If you think auto-boxing is a good performance thing, you might want to benchmark a test program. >However, from what i remember from reading about NIO, it can enable much >fewer threads to handle the same amount of requests. I was left with the >impression that it could improve performance, although i also remember >that members of this list wasn't convinced from the beginning. I'd >appreciate any feedback on why NIO is not a good idea. Search this list's archives for a detailed discussion. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Re: Next release
Dear Valued Customer, Thank you for contacting Customer Support at www.ballystore.com. In an effort to increase the effectiveness of customer communication, we recently modified our customer support e-mail addresses, and our system is unable to accept the e-mail you sent us. Please visit our online Customer Support at www.ballystore.com/helpdesk for answers to questions about your order. If you are unable to find the answers you need, you may contact one of our Customer Service Representatives through our online e-mail form, also found in the Help Area of our website. We apologize for any inconvenience this may cause you. Sincerely, Customer Support at www.ballystore.com Original Message Follows: Remy Maucherat wrote: > >>> Another thing is that we might want to write the next Tomcat for JDK >> >> >> 1.5. >> >> Anything specific in JDK 1.5? We already spoke a bit about NIO in some >> form, but that's JDK 1.4. > > > Annotations :) (I saw EJB 3) > I have to assume we're going to have some annotations defined in the > spec, hence the requirement for JDK 1.5. Of course, this is > speculation on this point. > > Rémy > IMHO, 1.5 would be the right way to go. For me mostly for performance, and cleaner code reasons (generics, auto-boxing, enums, etc.). However, from what i remember from reading about NIO, it can enable much fewer threads to handle the same amount of requests. I was left with the impression that it could improve performance, although i also remember that members of this list wasn't convinced from the beginning. I'd appreciate any feedback on why NIO is not a good idea. 2 cents from the little guy... Thanks, Reshat. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next release
Remy Maucherat wrote: Another thing is that we might want to write the next Tomcat for JDK 1.5. Anything specific in JDK 1.5? We already spoke a bit about NIO in some form, but that's JDK 1.4. Annotations :) (I saw EJB 3) I have to assume we're going to have some annotations defined in the spec, hence the requirement for JDK 1.5. Of course, this is speculation on this point. Rémy IMHO, 1.5 would be the right way to go. For me mostly for performance, and cleaner code reasons (generics, auto-boxing, enums, etc.). However, from what i remember from reading about NIO, it can enable much fewer threads to handle the same amount of requests. I was left with the impression that it could improve performance, although i also remember that members of this list wasn't convinced from the beginning. I'd appreciate any feedback on why NIO is not a good idea. 2 cents from the little guy... Thanks, Reshat. smime.p7s Description: S/MIME Cryptographic Signature
Re: Next release
On Sun, 16 May 2004, Remy Maucherat wrote: | Costin Manolache wrote: | | > Remy Maucherat wrote: | > | >> Shapira, Yoav wrote: | >> | >>> One area to keep in mind there is performance. There's no argument on | >>> the utility of JMX at all. I also think most of the performance hit | >>> would be at initialization (and shutdown), as you're | >>> creating/naming/binding JMX operations/attributes. This is better than | >>> having a performance hit in the request processing pipeline, so we're | >>> OK, but it's nonetheless something to keep in mind as we're adding JMX | >>> instrumentation all over the place. | >> | >> | >> | >> AFAIK, the performance hit would be minimal (JBoss runs ok to me, so | >> JMX seems fast enough overall). It's an issue of cleaning the code, so | >> it's not useful by itself. I think Costin wanted to do that migration | >> to full JMX (we're a bit too much middle ground, and all those | >> listener interfaces are definitely not trendy these days ;) ). | > | > | > | > For the critical path probably it's good to keep using an interface, but | > for all "container changes" and other notification - there is no | > performance issue. | | Yes, but we can't be too bad either: if we take one minute to deploy a | webapp (unless we're precompiling on deploy ;) ) then it would be bad. The startup-time of Tomcat is -really- annoyingly slow..! So if you'd need some user/developer-type-user feedback: shorten the startup time! One -often- restarts tomcat when developing stuff - the redeploy stuff isn't always totally cool - then you'll have to wait "forever" for Tomcat to start. Another thing I'd love to see, which I probably at one point'll make myself if it doesn't get done (but I've been surviving for 4 years w/o so far, though!), is: The shutdown-thingy. When one invoke the remote shutdown procedure, it releases immediately after getting "the packet" out the door, not waiting a nanosecond for tomcat to actually shut down. I'd like to see the remote shutdown process (the java-thing) wait all the way till Tomcat actually has shut down, or -most probably- have shut down. This could be done in the following manner: the shutdown process will hook up to Tomcat, and send the shutdown-packet. It would then wait for the "shutdown done" packet. Tomcat would start shutting down, and -right before- it invokes System.exit(0), or the main terminates, it'll send the "shutdown done" packet. The shutdown process would then -wait- (sleep) 30 millis before exiting. This would ensure that any context-switching that needed be done at that time would be done (Thread.yield() does -not- actually yield the processor (at least not on Linux w/ sun java)! But sleeping some millis -does- yield! (try it!)), so that the Tomcat java-process actually exists, and then we'd go back to the shutdown process, and that'll exit. There are plenty of annoyances with the existing system, but most notably, is the init.d-shutdown-style scripting of most Unix-style Os'es (and most probably also with Windows): you can't be sure if the Tomcat process actually have exited at all when you shut down the machine - risking the abrupt termination of some important shutdown procedure for some of the webapps. Another good idea would be the possibility to use the Tomcat control class to poll that Tomcat -is up-, for the "other way around": when a system -starts-, you often can't continue with some things before some other things are ensured that have started. So the control-code could be invoked with "-ensureUp" or something, that would continously try to connect to the Tomcat process and get the "I'm up and running with all the initial webapps" acknowledgements. This would enable a startup script to first fire off a java-process with Tomcat -in the background-, then immediately afterwards fire off the control java-process with "-ensureUp" -in the foreground-. This would exit immediately when Tomcat actually is up, so that you could exit the control-shellscript or whatever. -- Mvh, Endre Stølsvik M[+47 93054050] F[+47 51625182] Developer @ CoreTrek AS - http://www.coretrek.com/ CoreTrek corporate portal / EIP - http://www.corelets.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next release
Remy Maucherat wrote: Costin Manolache wrote: Remy Maucherat wrote: For the critical path probably it's good to keep using an interface, but for all "container changes" and other notification - there is no performance issue. Yes, but we can't be too bad either: if we take one minute to deploy a webapp (unless we're precompiling on deploy ;) ) then it would be bad. Not so bad IMO ( and we should precompile on deploy :-) My answer is yes but no, since we would have to hack the webapp's web.xml. I think it won't always work. Tricky issue ... Tricky indeed, but no - you need to hack web.xml if you want it to become a portable pre-compile webapp. If it is done internally - we can put the extra config and classes in a private file. I know, I can live with the recursive behavior. The question is if we should keep one long chain including all types of modules in random order or have separate extension points. Jboss interceptors can be applied on any operation ( AFAIK ) - you don't have a single chain for all operations. Yes, I think it can be configured per EJB, but there's a big amount of XML to do that. My point was that AOP or jboss interceptors can be applied in multiple points. I didn't say it's easy to configure or understand all of them :-) For us - we only need 4-5 points and the config can be quite simple - just the list of valves for each chain. Most likely you won't need to change any code in the valves - just regroup them and add the extra config. The interface is still the same - and you could still put valves in a single row if you want. But it may be helpfull if we would provide additional "extension points" where valves could be inserted. For example auth, logging, etc. The benefit: - you could reuse some extension points for other purposes - logging or auth, etc - you may want to skip some chains for internal includes - it may be cleaner - we may get shorter stacktraces ( I know it's cosmetic :-) It's just applying the Valve pattern in more places. Still same pattern like in jboss ( or even closer !), they use this for much more than a single chain. "Extension point" is used in eclipse - it is a pretty good name :-) I'll think about it :) (shorter stacktraces is a goal anyway, which is the idea of going back to pre-4.0 valves, where one valve invocation used one line instead of two right now) As you know I would preffer iterative style, like in apache - but one line is ok too. Reducing the stacktraces is nice, but the real benefit is in better organizing things. In 3.3 the biggest problem was the fact that the module was a bit rigid - and that resulted in ordering issues. If you have separated chains - it's much simpler ( and it really doesn't matter if it's iterative or recursive ). I plan to start working on this refactoring in a "catalina2" folder in jakarta-tomcat-catalina (with an associated build script in jakarta-tomcat-5), and I'll mark it as a proposal. I don't know what's the chance of this making it in a full fledged release before the next Servlet spec (athough it hasn't been started yet, so who knows when it'll happen ...), so if there are benefits a new intemediate branch will be needed. I assume we're not going to get rid of the current servlet container impl, here. It may be better to make those changes incrementally, in the main release area, if possible. A lot of people haven't moved to tomcat5 yet. 5.0 should remain stable (right ?). There would be API breaking, big behavior changes, etc, so I don't see how it can happen in the same tree (but of course, it'll start off using the current code). If it can and if there isn't need for a proposal -> 5.0 branch, and break stuff (err, I mean work ;) ) in HEAD. Maybe a 5.1 ? My only concern is that if changes start adding up, it is much harder to get people to upgrade and to support multiple versions. Having 5.x releases adding more features and with relatively small API breakages may be easier to swallow. Plus it will get stable quicker - if it gets into another 1 year cycle then again many people will have to stay with the stable branch ( since that's what they use/maintain)... Don't know - I saw far too many painfull major changes. For example - each Ant version added few API/behavior changes, but I don't think it was perceived as a huge change. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next release
Costin Manolache wrote: Remy Maucherat wrote: For the critical path probably it's good to keep using an interface, but for all "container changes" and other notification - there is no performance issue. Yes, but we can't be too bad either: if we take one minute to deploy a webapp (unless we're precompiling on deploy ;) ) then it would be bad. Not so bad IMO ( and we should precompile on deploy :-) My answer is yes but no, since we would have to hack the webapp's web.xml. I think it won't always work. Tricky issue ... I still like the genericity actually, and since the pattern is still: 1) going in 2) invoke next (if you want to; if you don't processing stops) 2) going out JBoss does the same with its interceptors, and the API they used is the same as the pre-TC 4 (ie, you get a pointer to the next interceptor). I know, I can live with the recursive behavior. The question is if we should keep one long chain including all types of modules in random order or have separate extension points. Jboss interceptors can be applied on any operation ( AFAIK ) - you don't have a single chain for all operations. Yes, I think it can be configured per EJB, but there's a big amount of XML to do that. The interface is still the same - and you could still put valves in a single row if you want. But it may be helpfull if we would provide additional "extension points" where valves could be inserted. For example auth, logging, etc. The benefit: - you could reuse some extension points for other purposes - logging or auth, etc - you may want to skip some chains for internal includes - it may be cleaner - we may get shorter stacktraces ( I know it's cosmetic :-) It's just applying the Valve pattern in more places. Still same pattern like in jboss ( or even closer !), they use this for much more than a single chain. "Extension point" is used in eclipse - it is a pretty good name :-) I'll think about it :) (shorter stacktraces is a goal anyway, which is the idea of going back to pre-4.0 valves, where one valve invocation used one line instead of two right now) I don't quite see how "typed" valves would fit into this: instead the chains are associated with the containers. Yes, sort of a vertical chaining - you still have one long chain. I'm talking about a horizontal chaining - the valves are not "typed", the same valve can be used in multiple chains ( or like in the current single long chain ). The extension points are not typed either ( i.e. no special java interface ). I think I do understand the concept now. I plan to start working on this refactoring in a "catalina2" folder in jakarta-tomcat-catalina (with an associated build script in jakarta-tomcat-5), and I'll mark it as a proposal. I don't know what's the chance of this making it in a full fledged release before the next Servlet spec (athough it hasn't been started yet, so who knows when it'll happen ...), so if there are benefits a new intemediate branch will be needed. I assume we're not going to get rid of the current servlet container impl, here. It may be better to make those changes incrementally, in the main release area, if possible. A lot of people haven't moved to tomcat5 yet. 5.0 should remain stable (right ?). There would be API breaking, big behavior changes, etc, so I don't see how it can happen in the same tree (but of course, it'll start off using the current code). If it can and if there isn't need for a proposal -> 5.0 branch, and break stuff (err, I mean work ;) ) in HEAD. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next release
Remy Maucherat wrote: For the critical path probably it's good to keep using an interface, but for all "container changes" and other notification - there is no performance issue. Yes, but we can't be too bad either: if we take one minute to deploy a webapp (unless we're precompiling on deploy ;) ) then it would be bad. Not so bad IMO ( and we should precompile on deploy :-) If you are going to touch the architecture - one thing I allways hated was using the same path ( "extension point" ) for all request processing. That was one of my fundamental problems with the valves. Keep the valves if you like them - but have separate chains for authentication, authorization, logging, etc. It not only cleans the code, but it also opens stuff for reuse. I still like the genericity actually, and since the pattern is still: 1) going in 2) invoke next (if you want to; if you don't processing stops) 2) going out JBoss does the same with its interceptors, and the API they used is the same as the pre-TC 4 (ie, you get a pointer to the next interceptor). I know, I can live with the recursive behavior. The question is if we should keep one long chain including all types of modules in random order or have separate extension points. Jboss interceptors can be applied on any operation ( AFAIK ) - you don't have a single chain for all operations. The interface is still the same - and you could still put valves in a single row if you want. But it may be helpfull if we would provide additional "extension points" where valves could be inserted. For example auth, logging, etc. The benefit: - you could reuse some extension points for other purposes - logging or auth, etc - you may want to skip some chains for internal includes - it may be cleaner - we may get shorter stacktraces ( I know it's cosmetic :-) It's just applying the Valve pattern in more places. Still same pattern like in jboss ( or even closer !), they use this for much more than a single chain. "Extension point" is used in eclipse - it is a pretty good name :-) I don't quite see how "typed" valves would fit into this: instead the chains are associated with the containers. Yes, sort of a vertical chaining - you still have one long chain. I'm talking about a horizontal chaining - the valves are not "typed", the same valve can be used in multiple chains ( or like in the current single long chain ). The extension points are not typed either ( i.e. no special java interface ). I plan to start working on this refactoring in a "catalina2" folder in jakarta-tomcat-catalina (with an associated build script in jakarta-tomcat-5), and I'll mark it as a proposal. I don't know what's the chance of this making it in a full fledged release before the next Servlet spec (athough it hasn't been started yet, so who knows when it'll happen ...), so if there are benefits a new intemediate branch will be needed. I assume we're not going to get rid of the current servlet container impl, here. It may be better to make those changes incrementally, in the main release area, if possible. A lot of people haven't moved to tomcat5 yet. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next release
Costin Manolache wrote: Remy Maucherat wrote: Shapira, Yoav wrote: One area to keep in mind there is performance. There's no argument on the utility of JMX at all. I also think most of the performance hit would be at initialization (and shutdown), as you're creating/naming/binding JMX operations/attributes. This is better than having a performance hit in the request processing pipeline, so we're OK, but it's nonetheless something to keep in mind as we're adding JMX instrumentation all over the place. AFAIK, the performance hit would be minimal (JBoss runs ok to me, so JMX seems fast enough overall). It's an issue of cleaning the code, so it's not useful by itself. I think Costin wanted to do that migration to full JMX (we're a bit too much middle ground, and all those listener interfaces are definitely not trendy these days ;) ). For the critical path probably it's good to keep using an interface, but for all "container changes" and other notification - there is no performance issue. Yes, but we can't be too bad either: if we take one minute to deploy a webapp (unless we're precompiling on deploy ;) ) then it would be bad. I don't know if anyone has read the Eclipse design and code - it has some very interesting ideas with the "extension points" and osgi. Nope, I haven't read that. If you are going to touch the architecture - one thing I allways hated was using the same path ( "extension point" ) for all request processing. That was one of my fundamental problems with the valves. Keep the valves if you like them - but have separate chains for authentication, authorization, logging, etc. It not only cleans the code, but it also opens stuff for reuse. I still like the genericity actually, and since the pattern is still: 1) going in 2) invoke next (if you want to; if you don't processing stops) 2) going out JBoss does the same with its interceptors, and the API they used is the same as the pre-TC 4 (ie, you get a pointer to the next interceptor). I don't quite see how "typed" valves would fit into this: instead the chains are associated with the containers. I plan to start working on this refactoring in a "catalina2" folder in jakarta-tomcat-catalina (with an associated build script in jakarta-tomcat-5), and I'll mark it as a proposal. I don't know what's the chance of this making it in a full fledged release before the next Servlet spec (athough it hasn't been started yet, so who knows when it'll happen ...), so if there are benefits a new intemediate branch will be needed. I assume we're not going to get rid of the current servlet container impl, here. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next release
Remy Maucherat wrote: Shapira, Yoav wrote: One area to keep in mind there is performance. There's no argument on the utility of JMX at all. I also think most of the performance hit would be at initialization (and shutdown), as you're creating/naming/binding JMX operations/attributes. This is better than having a performance hit in the request processing pipeline, so we're OK, but it's nonetheless something to keep in mind as we're adding JMX instrumentation all over the place. AFAIK, the performance hit would be minimal (JBoss runs ok to me, so JMX seems fast enough overall). It's an issue of cleaning the code, so it's not useful by itself. I think Costin wanted to do that migration to full JMX (we're a bit too much middle ground, and all those listener interfaces are definitely not trendy these days ;) ). For the critical path probably it's good to keep using an interface, but for all "container changes" and other notification - there is no performance issue. I don't know if anyone has read the Eclipse design and code - it has some very interesting ideas with the "extension points" and osgi. If you are going to touch the architecture - one thing I allways hated was using the same path ( "extension point" ) for all request processing. That was one of my fundamental problems with the valves. Keep the valves if you like them - but have separate chains for authentication, authorization, logging, etc. It not only cleans the code, but it also opens stuff for reuse. Costin Another thing is that we might want to write the next Tomcat for JDK 1.5. Anything specific in JDK 1.5? We already spoke a bit about NIO in some form, but that's JDK 1.4. Annotations :) (I saw EJB 3) I have to assume we're going to have some annotations defined in the spec, hence the requirement for JDK 1.5. Of course, this is speculation on this point. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next release
Shapira, Yoav wrote: One area to keep in mind there is performance. There's no argument on the utility of JMX at all. I also think most of the performance hit would be at initialization (and shutdown), as you're creating/naming/binding JMX operations/attributes. This is better than having a performance hit in the request processing pipeline, so we're OK, but it's nonetheless something to keep in mind as we're adding JMX instrumentation all over the place. AFAIK, the performance hit would be minimal (JBoss runs ok to me, so JMX seems fast enough overall). It's an issue of cleaning the code, so it's not useful by itself. I think Costin wanted to do that migration to full JMX (we're a bit too much middle ground, and all those listener interfaces are definitely not trendy these days ;) ). Another thing is that we might want to write the next Tomcat for JDK 1.5. Anything specific in JDK 1.5? We already spoke a bit about NIO in some form, but that's JDK 1.4. Annotations :) (I saw EJB 3) I have to assume we're going to have some annotations defined in the spec, hence the requirement for JDK 1.5. Of course, this is speculation on this point. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Next release
Hi, >I think the valve is the right pattern, so thanks Craig :) The only >thing is that we shouldn't have the ValveContext which adds complexity >(worthless IMO, as we don't need the extra robustness for our >proprietary API, esp since its realm of application is getting lower due >to the spec improvements), and we should only have next.invoke(). I I agree that Filters have had time to mature a bit since their initial release, and they are gaining a wider user base. Users still don't evaluate Filters (or for that matter, Valves or Interceptors) as much as they should when considering design options, but that'll happen with time. So I agree that the Valve interface can become less flexible/robust, and more specific to our needs, now that users can do more with filters. >As for the listeners and stuff, I think Costin proposed using JMX. We'll >need to make everything JMX if we want to do that, and fix a few things >in commons-modeler. One area to keep in mind there is performance. There's no argument on the utility of JMX at all. I also think most of the performance hit would be at initialization (and shutdown), as you're creating/naming/binding JMX operations/attributes. This is better than having a performance hit in the request processing pipeline, so we're OK, but it's nonetheless something to keep in mind as we're adding JMX instrumentation all over the place. >Another thing is that we might want to write the next Tomcat for JDK 1.5. Anything specific in JDK 1.5? We already spoke a bit about NIO in some form, but that's JDK 1.4. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next release
Bill Barker wrote: "Remy Maucherat" <[EMAIL PROTECTED]> wrote in message +1 for doing this in the Catalina code. Doing it in the Connector code would mean that CoyoteConnector code for older TC versions would languish off in a branch. They have the same name :( I was obviously talking about the o.a.catalina.(Http)Request/Response that have been causing me pain for so long, and the instanceof which have been hurting my eyes. - the current valve design mirrors the filters, but is actually different in what it can do (now that filters can work in request dispatchers), so I don't see the point of using the same pattern anymore; using the model from Tomcat pre-4.0 (yes, I know, it's old ;) ) would lower the number method calls and reduce significantly the stack trace I'm probably the number 2 fan of the Tomcat 3.3 API ;-), but it still has its own set of drawbacks (e.g. it is very sensitive to editing server.xml). Awhile back, Costin proposed using something along the lines of the Axis Handlers (which are sort of a cross between the Catalina Valves and the TC 3 Interceptors). Even if it isn't the Axis model, IMHO the ideal API would combine both the strict chain of command of the Valves with flexability of the Listener-like Interceptors. I think the valve is the right pattern, so thanks Craig :) The only thing is that we shouldn't have the ValveContext which adds complexity (worthless IMO, as we don't need the extra robustness for our proprietary API, esp since its realm of application is getting lower due to the spec improvements), and we should only have next.invoke(). I regret Craig decided to change that without much asking right before 4.0 final, because it definitely had a cost in performance (it's much better now, but not zero either), and we could no longer break the API. As for the listeners and stuff, I think Costin proposed using JMX. We'll need to make everything JMX if we want to do that, and fix a few things in commons-modeler. Another thing is that we might want to write the next Tomcat for JDK 1.5. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next release
Remy Maucherat <[EMAIL PROTECTED]> wrote: I feel like starting working on the possible new codebase for Tomcat, now that Tomcat 5 is more or less stabilized. I have a few obvious items, but while a lot could be done to make the code more modern, it wouldn't make Tomcat actually run better, so I favor changing things only if it brings something very tangible. Note: This time, I favor changing the API, as with TC 5, I think we got as far as we could without. Some of my first items would be: - refactor the request and response API using concrete classes (CoyoteRequest and CoyoteResponse) rather than interfaces, in order to simplify the code and lower the amount of RTTI and casts - the current valve design mirrors the filters, but is actually different in what it can do (now that filters can work in request dispatchers), so I don't see the point of using the same pattern anymore; using the model from Tomcat pre-4.0 (yes, I know, it's old ;) ) would lower the number method calls and reduce significantly the stack trace - more JMX, such as redoing the notification model (questionable, since the gain isn't too evident) - (definitely) flexible configuration persistence (instead of the hack that is currently used ;) ) - I like the nested containers, and I think the server.xml structure is ok: I don't quite see how to simplify that without taking away from the functionality (Craig deserves some credit for the design, which aged rather well) - no non blocking IO for me, but introducing blocking NIO could be good Have you looked at EmberIO for this? It might be possible to use it in a way that doesn't break compliance. I started to look at it and thought it might be feasible. Not sure yet, since I don't understand the code well. peter - Do you Yahoo!? Yahoo! Movies - Buy advance tickets for 'Shrek 2'
Re: Next release
"Remy Maucherat" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I feel like starting working on the possible new codebase for Tomcat, > now that Tomcat 5 is more or less stabilized. I have a few obvious > items, but while a lot could be done to make the code more modern, it > wouldn't make Tomcat actually run better, so I favor changing things > only if it brings something very tangible. > Note: This time, I favor changing the API, as with TC 5, I think we got > as far as we could without. > > Some of my first items would be: > - refactor the request and response API using concrete classes > (CoyoteRequest and CoyoteResponse) rather than interfaces, in order to > simplify the code and lower the amount of RTTI and casts +1 for doing this in the Catalina code. Doing it in the Connector code would mean that CoyoteConnector code for older TC versions would languish off in a branch. > - the current valve design mirrors the filters, but is actually > different in what it can do (now that filters can work in request > dispatchers), so I don't see the point of using the same pattern > anymore; using the model from Tomcat pre-4.0 (yes, I know, it's old ;) ) > would lower the number method calls and reduce significantly the stack trace I'm probably the number 2 fan of the Tomcat 3.3 API ;-), but it still has its own set of drawbacks (e.g. it is very sensitive to editing server.xml). Awhile back, Costin proposed using something along the lines of the Axis Handlers (which are sort of a cross between the Catalina Valves and the TC 3 Interceptors). Even if it isn't the Axis model, IMHO the ideal API would combine both the strict chain of command of the Valves with flexability of the Listener-like Interceptors. > - more JMX, such as redoing the notification model (questionable, since > the gain isn't too evident) > - (definitely) flexible configuration persistence (instead of the hack > that is currently used ;) ) > - I like the nested containers, and I think the server.xml structure is > ok: I don't quite see how to simplify that without taking away from the > functionality (Craig deserves some credit for the design, which aged > rather well) > - no non blocking IO for me, but introducing blocking NIO could be good > > This should keep me busy :) > > Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Next release
I feel like starting working on the possible new codebase for Tomcat, now that Tomcat 5 is more or less stabilized. I have a few obvious items, but while a lot could be done to make the code more modern, it wouldn't make Tomcat actually run better, so I favor changing things only if it brings something very tangible. Note: This time, I favor changing the API, as with TC 5, I think we got as far as we could without. Some of my first items would be: - refactor the request and response API using concrete classes (CoyoteRequest and CoyoteResponse) rather than interfaces, in order to simplify the code and lower the amount of RTTI and casts - the current valve design mirrors the filters, but is actually different in what it can do (now that filters can work in request dispatchers), so I don't see the point of using the same pattern anymore; using the model from Tomcat pre-4.0 (yes, I know, it's old ;) ) would lower the number method calls and reduce significantly the stack trace - more JMX, such as redoing the notification model (questionable, since the gain isn't too evident) - (definitely) flexible configuration persistence (instead of the hack that is currently used ;) ) - I like the nested containers, and I think the server.xml structure is ok: I don't quite see how to simplify that without taking away from the functionality (Craig deserves some credit for the design, which aged rather well) - no non blocking IO for me, but introducing blocking NIO could be good This should keep me busy :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Problems with the next release
- Original Message -
From: "Mladen Turk" <[EMAIL PROTECTED]>
To: "'Tomcat Developers List'" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Friday, March 12, 2004 3:24 AM
Subject: RE: [5.0] Problems with the next release
>
>
> > -Original Message-
> > From: jean-frederic clere
> >
> > Mladen Turk wrote:
> > >
> > > What about linking to static microsoft libraries?
> >
> > That is probably not OK.
> >
>
> I know that, but I know too that the law doesn't have a term _probably_ in
> it's dictionary.
>
> >
> > > Do we need to sign that or ASF will perhaps provide us with the
> > > development tools needed?
> >
> > Use Open Source tools and/or help to improve existing ones.
> >
>
> Again, Is it required to use open source tools or not?
> Is it up to me and my moral or is there some ASF board decision on that?
> I had to sign for my current company that will take care that there are no
> illegal software on my boxes (as probably everyone else did).
>
> Take a look at http(apr, apr-util, etc...). The win32 port has vstudio
build
> files (like our connectors). My question is, where those tools comes from?
> ASF or developers that have couple of 1000$ to spend?
> Also I heard that the ASF has an agreement with InstallShield. I would
love
> to receive a license for some of those tools if possible :-).
A quick look at the VS build files for httpd shows that they are using
dynamic linking for the MS stuff ("Multithreaded DLL"). The tools
themselves aren't really relevant: gcc is GPL and glibc is LGPL.
>
> Since all of the board members are from httpd project, seems to me that
all
> the decisions have been made through this point of view. It's not hard to
> implement this decisions for that particular project. They done this so
far,
> although for different reasons (no ssl enabled dist, etc...).
>
> Henri, Remy and Costin proposed to move the binaries to sourceforge, until
> the things clears up.
> I'm in favor of that, and will support such a decision if voted.
>
> MT.
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
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: [5.0] Problems with the next release
Remy Maucherat wrote: Henri Gomez wrote: Please subscribe to [EMAIL PROTECTED] and follow the thread about 'clarification'. It seems there is a discussion on having non ASF binaries : 2) state that the ASF will allow the use of its infrastructure for the distribution of binary objects that are legally distributable standalone even if they do not originate from the ASF and are not covered by the apache license and create a policy that says that source code must be available alongside as well and no modification to the original packages must be in place [only patches alongside] Ok. So it's confusing ;) I'll revert my changes if the situation evolves. I suggest that we subscribe to [EMAIL PROTECTED] and participate to the thread ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Problems with the next release
Henri Gomez wrote: Please subscribe to [EMAIL PROTECTED] and follow the thread about 'clarification'. It seems there is a discussion on having non ASF binaries : 2) state that the ASF will allow the use of its infrastructure for the distribution of binary objects that are legally distributable standalone even if they do not originate from the ASF and are not covered by the apache license and create a policy that says that source code must be available alongside as well and no modification to the original packages must be in place [only patches alongside] Ok. So it's confusing ;) I'll revert my changes if the situation evolves. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Problems with the next release
Please subscribe to [EMAIL PROTECTED] and follow the thread about 'clarification'. It seems there is a discussion on having non ASF binaries : 2) state that the ASF will allow the use of its infrastructure for the distribution of binary objects that are legally distributable standalone even if they do not originate from the ASF and are not covered by the apache license and create a policy that says that source code must be available alongside as well and no modification to the original packages must be in place [only patches alongside] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.0] Problems with the next release
> -Original Message- > From: Henri Gomez > >> Henri, Remy and Costin proposed to move the binaries to > sourceforge, > >> until > >> the things clears up. > >> I'm in favor of that, and will support such a decision if voted. > > Well I didn't agreed on moving TC binaries to sf or others. > Sorry, It's been a lots of mails :-). > > > I am not. Temporary solutions may last long time. Blocking > situations > > normaly evolve faster. > > Yes, what will happen with board if WE decide to stop make Tomcat > release until the problem get fixed ? > I've got a feeling like somebody pulled the plug. They've made a declaration vithout a solution how to fix that (well, except mentioning ibiblio and sf). Further more that mail from board looked like: 'I don't give a shit about you'. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Problems with the next release
Henri Gomez wrote: Well I didn't agreed on moving TC binaries to sf or others. I mentioned that being also involved in projet like Jpackage, I know that's producing ready to use packages is not so easy, expecially when you have to explain to users that they have to get MANY external jars from outside sites. As Mladen say, the board came mainly from httpd team and in the NATIVE world there is allready distributions which provide the missing/required parts, like openssl, glibc But in Java land, there is no REAL distributions (only jpackage for RPM users), and there is a HUGE difference. Indeed. This move is only thought out in respect to httpd and the related native projects. I am not. Temporary solutions may last long time. Blocking situations normaly evolve faster. Yes, what will happen with board if WE decide to stop make Tomcat release until the problem get fixed ? Bad idea: I think they don't care ;) Right now, I'm in favor of doing solution A, and removing some of the distributions (the .exe and the embedded dist). It doesn't prevent doing B as well. I think we should post a statement on the Tomcat website explaning the reasons for the disappearance of the distributions, as well as voicing our opposition (if we indeed all agree we are opposed to this) to the latest board decision. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Problems with the next release
jean-frederic clere wrote: Mladen Turk wrote: -Original Message- From: jean-frederic clere Mladen Turk wrote: What about linking to static microsoft libraries? That is probably not OK. I know that, but I know too that the law doesn't have a term _probably_ in it's dictionary. Do we need to sign that or ASF will perhaps provide us with the development tools needed? Use Open Source tools and/or help to improve existing ones. Again, Is it required to use open source tools or not? No, it is required to avoid non ASF licensed elements in the binaries that are delivered by the ASF. We should ask about "contributed" builds (like the ones in apache/dist/httpd/binaries/) Is it up to me and my moral or is there some ASF board decision on that? I had to sign for my current company that will take care that there are no illegal software on my boxes (as probably everyone else did). Take a look at http(apr, apr-util, etc...). The win32 port has vstudio build files (like our connectors). My question is, where those tools comes from? ASF or developers that have couple of 1000$ to spend? I don't know I am (nearly) not using win32. Also I heard that the ASF has an agreement with InstallShield. I would love to receive a license for some of those tools if possible :-). Since all of the board members are from httpd project, seems to me that all the decisions have been made through this point of view. It's not hard to implement this decisions for that particular project. They done this so far, although for different reasons (no ssl enabled dist, etc...). Every one has an history. (ssl contains crypto some countries have restriction on such things). Henri, Remy and Costin proposed to move the binaries to sourceforge, until the things clears up. I'm in favor of that, and will support such a decision if voted. Well I didn't agreed on moving TC binaries to sf or others. I mentioned that being also involved in projet like Jpackage, I know that's producing ready to use packages is not so easy, expecially when you have to explain to users that they have to get MANY external jars from outside sites. As Mladen say, the board came mainly from httpd team and in the NATIVE world there is allready distributions which provide the missing/required parts, like openssl, glibc But in Java land, there is no REAL distributions (only jpackage for RPM users), and there is a HUGE difference. I am not. Temporary solutions may last long time. Blocking situations normaly evolve faster. Yes, what will happen with board if WE decide to stop make Tomcat release until the problem get fixed ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Problems with the next release
Mladen Turk wrote: -Original Message- From: jean-frederic clere Mladen Turk wrote: What about linking to static microsoft libraries? That is probably not OK. I know that, but I know too that the law doesn't have a term _probably_ in it's dictionary. Do we need to sign that or ASF will perhaps provide us with the development tools needed? Use Open Source tools and/or help to improve existing ones. Again, Is it required to use open source tools or not? No, it is required to avoid non ASF licensed elements in the binaries that are delivered by the ASF. We should ask about "contributed" builds (like the ones in apache/dist/httpd/binaries/) Is it up to me and my moral or is there some ASF board decision on that? I had to sign for my current company that will take care that there are no illegal software on my boxes (as probably everyone else did). Take a look at http(apr, apr-util, etc...). The win32 port has vstudio build files (like our connectors). My question is, where those tools comes from? ASF or developers that have couple of 1000$ to spend? I don't know I am (nearly) not using win32. Also I heard that the ASF has an agreement with InstallShield. I would love to receive a license for some of those tools if possible :-). Since all of the board members are from httpd project, seems to me that all the decisions have been made through this point of view. It's not hard to implement this decisions for that particular project. They done this so far, although for different reasons (no ssl enabled dist, etc...). Every one has an history. (ssl contains crypto some countries have restriction on such things). Henri, Remy and Costin proposed to move the binaries to sourceforge, until the things clears up. I'm in favor of that, and will support such a decision if voted. I am not. Temporary solutions may last long time. Blocking situations normaly evolve faster. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.0] Problems with the next release
> -Original Message- > From: jean-frederic clere > > Mladen Turk wrote: > > > > What about linking to static microsoft libraries? > > That is probably not OK. > I know that, but I know too that the law doesn't have a term _probably_ in it's dictionary. > > > Do we need to sign that or ASF will perhaps provide us with the > > development tools needed? > > Use Open Source tools and/or help to improve existing ones. > Again, Is it required to use open source tools or not? Is it up to me and my moral or is there some ASF board decision on that? I had to sign for my current company that will take care that there are no illegal software on my boxes (as probably everyone else did). Take a look at http(apr, apr-util, etc...). The win32 port has vstudio build files (like our connectors). My question is, where those tools comes from? ASF or developers that have couple of 1000$ to spend? Also I heard that the ASF has an agreement with InstallShield. I would love to receive a license for some of those tools if possible :-). Since all of the board members are from httpd project, seems to me that all the decisions have been made through this point of view. It's not hard to implement this decisions for that particular project. They done this so far, although for different reasons (no ssl enabled dist, etc...). Henri, Remy and Costin proposed to move the binaries to sourceforge, until the things clears up. I'm in favor of that, and will support such a decision if voted. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Problems with the next release
Mladen Turk wrote: -Original Message- From: Henri Gomez Here is a reply I got from the community list : This is not a complete prohibition on all third-party jars or libraries, but only on those third-party libraries which are licensed under terms more restrictive than the ASL. Ask them is there any list of accepted licenses and libraries. What about linking to static microsoft libraries? That is probably not OK. What can assure them that contributed binaries (and the code itself) are build with legally obtained software? "legally obtained software" if someone is using those he kills its own business! Do we need to sign that or ASF will perhaps provide us with the development tools needed? Use Open Source tools and/or help to improve existing ones. Perhaps they should think in that direction. However, mx4j is a good example because apparently it includes code licensed under the Jetty and Jython licenses Reading this seems that they've already made a decision, without the will to help us. What are we suppose to do? Hire a lawyer to clear every library that has a feature to link with the property software or they will? I mean, exactly the same situation as with the tomcat-connectors. Seem that we cannot provide the binaries for that too, cause IIS apparently doesn't falls nearly to the ASF license. Are we linking to the any of the prohibited libraries (like api32, kernel32, ws2_32)? I'm not sure. You have to use dynamic linking... Cygwin brings the same API but the license is not ASF like and the API is not 100% compatible. Too many questions, and such a small head ;-). MT. - 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: [5.0] Problems with the next release
Henri Gomez wrote: This is not a complete prohibition on all third-party jars or libraries, but only on those third-party libraries which are licensed under terms more restrictive than the ASL. In the case of mx4j, the code is licenced under the mx4j 1.0 License [1], which is a derivative of the ASL 1.1 license and therefore may potentially be included in ASF works. However, mx4j is a good example because apparently it includes code licensed under the Jetty and Jython licenses [2]. While I am not intimately familiar with mx4j, this may mean that the total legal effect of using mx4j is not contained within the mx4j license alone, but is in fact a combination of the terms of the three licenses. Since this combination may in fact be more restrictive than the terms in the mx4j license alone, the library may not be in the clear to be used by ASF projects. To confirm this, one would need to investigate all three licenses, understand which parts of mx4j fall outside of its own license, and then come to a decision on how the library can be used in the ASF. It is exactly this sort of confusion the ASF would like to avoid. While the mx4j developers may in fact be perfectly in compliance with using the Jetty and Jython licenses, users of mx4j will have to take into consideration not one, but _three_ licenses in order to determine how to legally use the library. Therefore, for the sake of our users it is best if an ASF product as a whole is licensed under terms no more restrictive than those set out in the ASL 2.0. For further inquries (including a specific resolution to the mx4j issue), I would suggest subscribing to the [EMAIL PROTECTED] list. This makes zero sense. None of the "more restrictive" licenses pose any problem for binary redistribution. Anyway, I won't include mx4j, as I'm not a lawyer, and I have a skewed opinion on licenses anyway. The biggest question is: what's next ? (it seems painfully obvious: zero non ASL 2.0 imports) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.0] Problems with the next release
> -Original Message- > From: Henri Gomez > > Here is a reply I got from the community list : > > This is not a complete prohibition on all third-party jars or > libraries, but only on those third-party libraries which are > licensed under terms more restrictive than the ASL. > Ask them is there any list of accepted licenses and libraries. What about linking to static microsoft libraries? What can assure them that contributed binaries (and the code itself) are build with legally obtained software? Do we need to sign that or ASF will perhaps provide us with the development tools needed? Perhaps they should think in that direction. > However, mx4j is a good example because apparently it > includes code licensed under the Jetty and Jython licenses Reading this seems that they've already made a decision, without the will to help us. What are we suppose to do? Hire a lawyer to clear every library that has a feature to link with the property software or they will? I mean, exactly the same situation as with the tomcat-connectors. Seem that we cannot provide the binaries for that too, cause IIS apparently doesn't falls nearly to the ASF license. Are we linking to the any of the prohibited libraries (like api32, kernel32, ws2_32)? I'm not sure. Too many questions, and such a small head ;-). MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Problems with the next release
Remy Maucherat wrote: Bill Barker wrote: I agree with Yoav that we can afford to wait a few days (if only so I don't have to take down the 3.3.2 binary distro :). However, I don't think that, without the ASF changing it's position, we can simply add some lines to the LICENSE file. That may work in C land, but in Java land it's the LGPL argument all over again. I agree we can wait a few days until we reach a consensus. IMHO, since we'd have to drop JMX and the Windows installer to ship from ASF, B) is the only reasonable choice. We would have to drop the Windows installer as well :( Here is a reply I got from the community list : Quoting Henri Gomez <[EMAIL PROTECTED]>: >> >> Should I understand that we could no more include third-party jars in >> ASF products, for example mx4j jars in Tomcat ? This is not a complete prohibition on all third-party jars or libraries, but only on those third-party libraries which are licensed under terms more restrictive than the ASL. In the case of mx4j, the code is licenced under the mx4j 1.0 License [1], which is a derivative of the ASL 1.1 license and therefore may potentially be included in ASF works. However, mx4j is a good example because apparently it includes code licensed under the Jetty and Jython licenses [2]. While I am not intimately familiar with mx4j, this may mean that the total legal effect of using mx4j is not contained within the mx4j license alone, but is in fact a combination of the terms of the three licenses. Since this combination may in fact be more restrictive than the terms in the mx4j license alone, the library may not be in the clear to be used by ASF projects. To confirm this, one would need to investigate all three licenses, understand which parts of mx4j fall outside of its own license, and then come to a decision on how the library can be used in the ASF. It is exactly this sort of confusion the ASF would like to avoid. While the mx4j developers may in fact be perfectly in compliance with using the Jetty and Jython licenses, users of mx4j will have to take into consideration not one, but _three_ licenses in order to determine how to legally use the library. Therefore, for the sake of our users it is best if an ASF product as a whole is licensed under terms no more restrictive than those set out in the ASL 2.0. For further inquries (including a specific resolution to the mx4j issue), I would suggest subscribing to the [EMAIL PROTECTED] list. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Problems with the next release
Bill Barker wrote: I agree with Yoav that we can afford to wait a few days (if only so I don't have to take down the 3.3.2 binary distro :). However, I don't think that, without the ASF changing it's position, we can simply add some lines to the LICENSE file. That may work in C land, but in Java land it's the LGPL argument all over again. I agree we can wait a few days until we reach a consensus. IMHO, since we'd have to drop JMX and the Windows installer to ship from ASF, B) is the only reasonable choice. We would have to drop the Windows installer as well :( Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Problems with the next release
Bill Barker wrote: I agree with Yoav that we can afford to wait a few days (if only so I don't have to take down the 3.3.2 binary distro :). However, I don't think that, without the ASF changing it's position, we can simply add some lines to the LICENSE file. That may work in C land, but in Java land it's the LGPL argument all over again. IMHO, since we'd have to drop JMX and the Windows installer to ship from ASF, B) is the only reasonable choice. +1 on B. This will give us the option to develop and ship modules that depend on LGPL with the binary tomcat, without adding "legal risks" to ASF. However this should only happen if we have consensus ( i.e. no -1 votes, all committers in agreement ). Distributing only source code from ASF is IMO an acceptable solution, there is no requirement for projects to distribute binaries ( I believe the httpd distro is source, with only contributed binaries ). Creating a link from tomcat page to the sf project should also be acceptable ( there are other projects linking to outside sites and distributions that include their code ). The name obviously can't be "tomcat" or "apache tomcat" - but there are lots of commercial distributions including tomcat, so I'm sure we can find an acceptable solution ( there is an ant-contrib on sf, we may do a tomcat-contrib or tomcat-dist or something like that ). Costin - Original Message - From: "Remy Maucherat" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Thursday, March 11, 2004 5:54 AM Subject: [5.0] Problems with the next release Hi, There are some problems with the next release, with the decision from the ASF board to mandate that all ASF releases are to be made of 100% ASL 2.0 licensed components (as a side note, I'd like to add that this is obviously a terrible decision). This has many consequences and some questions marks are left (such as for the JCP provided elements we are using). With Tomcat 5.0.x, the most pressing problem is with JMX, since there are no ASL 2.0 licensed implementations available. The options seem to be: A) Ship Tomcat 5.0.20 without JMX, and have it display a message with instructions on how to install JMX if it's not present (basically, everywhere but on JDK 1.5.0). B) Ship the binaries from non ASF servers (we could setup a project for that on Sourceforge). The sources can be shipped from the ASF servers as before. It is unclear to me if we can legally call these binaries Apache Tomcat or not. Comments ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [5.0] Problems with the next release
This account does not exist - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Problems with the next release
I agree with Yoav that we can afford to wait a few days (if only so I don't have to take down the 3.3.2 binary distro :). However, I don't think that, without the ASF changing it's position, we can simply add some lines to the LICENSE file. That may work in C land, but in Java land it's the LGPL argument all over again. IMHO, since we'd have to drop JMX and the Windows installer to ship from ASF, B) is the only reasonable choice. - Original Message - From: "Remy Maucherat" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Thursday, March 11, 2004 5:54 AM Subject: [5.0] Problems with the next release Hi, There are some problems with the next release, with the decision from the ASF board to mandate that all ASF releases are to be made of 100% ASL 2.0 licensed components (as a side note, I'd like to add that this is obviously a terrible decision). This has many consequences and some questions marks are left (such as for the JCP provided elements we are using). With Tomcat 5.0.x, the most pressing problem is with JMX, since there are no ASL 2.0 licensed implementations available. The options seem to be: A) Ship Tomcat 5.0.20 without JMX, and have it display a message with instructions on how to install JMX if it's not present (basically, everywhere but on JDK 1.5.0). B) Ship the binaries from non ASF servers (we could setup a project for that on Sourceforge). The sources can be shipped from the ASF servers as before. It is unclear to me if we can legally call these binaries Apache Tomcat or not. Comments ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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: [5.0] Problems with the next release
Hi, >The options seem to be: >A) Ship Tomcat 5.0.20 without JMX, and have it display a message with >instructions on how to install JMX if it's not present (basically, >everywhere but on JDK 1.5.0). >B) Ship the binaries from non ASF servers (we could setup a project for >that on Sourceforge). The sources can be shipped from the ASF servers as >before. It is unclear to me if we can legally call these binaries Apache >Tomcat or not. > >Comments ? Wait for a couple of days (AFAIK there's no pressure to do 5.0.20 immediately) to see the board's reactions to our complaints and requests for clarification. If no changes occur (and I think they will: we'll just have to modify our license file to include a paragraph about MX4J) then we'd vote on the above (I tend to like option A at the moment). Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Problems with the next release
I have to agree. the decision affects a lot of apache projects. I hope ASF board changes the policy slightly and lengths the time for this to take place. It's good to have Apache equivalents to many of the libraries being used in apache projects, but it's going to take time. I may have to create a SF project for the monitor plug, write a custom SAX documentHandler to parse the tomcat status, or assist the existing jaxb project on apache. on jmeter-dev we were discussing the possibility of creating a SF project to distribute versions that don't need manual downloads, but most likely that might not be feasible. I would hate to see jakarta projects fork, just so we can provide complete distributions. peter lin Remy Maucherat <[EMAIL PROTECTED]> wrote:Hi, There are some problems with the next release, with the decision from the ASF board to mandate that all ASF releases are to be made of 100% ASL 2.0 licensed components (as a side note, I'd like to add that this is obviously a terrible decision). This has many consequences and some questions marks are left (such as for the JCP provided elements we are using). With Tomcat 5.0.x, the most pressing problem is with JMX, since there are no ASL 2.0 licensed implementations available. The options seem to be: A) Ship Tomcat 5.0.20 without JMX, and have it display a message with instructions on how to install JMX if it's not present (basically, everywhere but on JDK 1.5.0). B) Ship the binaries from non ASF servers (we could setup a project for that on Sourceforge). The sources can be shipped from the ASF servers as before. It is unclear to me if we can legally call these binaries Apache Tomcat or not. Comments ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Do you Yahoo!? Yahoo! Search - Find what youre looking for faster.
Re: [5.0] Problems with the next release
Remy Maucherat wrote: Hi, There are some problems with the next release, with the decision from the ASF board to mandate that all ASF releases are to be made of 100% ASL 2.0 licensed components (as a side note, I'd like to add that this is obviously a terrible decision). This has many consequences and some questions marks are left (such as for the JCP provided elements we are using). With Tomcat 5.0.x, the most pressing problem is with JMX, since there are no ASL 2.0 licensed implementations available. The options seem to be: A) Ship Tomcat 5.0.20 without JMX, and have it display a message with instructions on how to install JMX if it's not present (basically, everywhere but on JDK 1.5.0). B) Ship the binaries from non ASF servers (we could setup a project for that on Sourceforge). The sources can be shipped from the ASF servers as before. It is unclear to me if we can legally call these binaries Apache Tomcat or not. Comments ? I send a note about this limitation to [EMAIL PROTECTED] and hope to see the board relax its position. Here's what I send to the list : > It seems worthwhile to state something that probably most people are aware > of, but a few recent incidents suggest is worth repeating. Followups are > being directed to [EMAIL PROTECTED], a list that is private to Apache > committers, where legal issues are discussed. Please subscribe to that > list (requires approval) before posting to it. > > First off, thank you to everyone who has transitioned to the new Apache > License 2.0. It is a board mandate that *all* software distributed by the > Apache Software Foundation be under this new license. This has some > subtle and not-so-subtle ramifications people should be aware of. > > *) Only software packages created by the Apache Software Foundation may be > redistributed from Apache's servers and mirrors. This means no tarballs > or binaries from other authors or organizations. We realize that many ASF > projects depend upon other software, and that these dependencies may make > it difficult for new users to bootstrap quickly. There are solutions to > that problem outside of the ASF: ibiblio, sourceforge, CPAN, etc. The > board might grant exceptions to this rule - bring it to us if you'd like > us to consider it. Should I understand that we could no more include third-party jars in ASF products, for example mx4j jars in Tomcat ? If it's the case this decision will put many, many users in big trouble since they couldn't use anymore ready-to-run package (zip or tarball containing everything needed for run). As one of the founder of the JPackage Projet, www.jpackage.org, which try to maintain a repository of java applications and libs, let me say that the task is not so easy, and for now works only on RPM based boxes, mostly Linux. What should do non-RPM users ? I could understand the board concern about incompatible license, but when developpers select third-party software to make ASF products, they take care of it isn't it ? So I strongly suggest board to reconsider this point or we may see in a near future ASF products distribution, containing both ASF and required third party software, outside Apache servers and it will not help users to find their way. Am I exact in thinking that the original ASF goal is to provide real products for real users, and that we should take care of users as much as we take care of performance, stability ? Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[5.0] Problems with the next release
Hi, There are some problems with the next release, with the decision from the ASF board to mandate that all ASF releases are to be made of 100% ASL 2.0 licensed components (as a side note, I'd like to add that this is obviously a terrible decision). This has many consequences and some questions marks are left (such as for the JCP provided elements we are using). With Tomcat 5.0.x, the most pressing problem is with JMX, since there are no ASL 2.0 licensed implementations available. The options seem to be: A) Ship Tomcat 5.0.20 without JMX, and have it display a message with instructions on how to install JMX if it's not present (basically, everywhere but on JDK 1.5.0). B) Ship the binaries from non ASF servers (we could setup a project for that on Sourceforge). The sources can be shipped from the ASF servers as before. It is unclear to me if we can legally call these binaries Apache Tomcat or not. Comments ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Next release
- Original Message - From: "Amy Roh" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Thursday, March 04, 2004 9:00 AM Subject: Re: [5.0] Next release > > - plenty of admin webapp patches need to be merged; Amy and Larry were > > the last persons seen maintaining this feature, so can one of you two do > > it if you have time ? > > Haven't had much time to spend on admin lately. Let me try to spend some > time on admin before the next release to update. Let me know if you're > aware of any patches other than the ones that come up in bugzilla when I > query for tomcat 5 admin. > Well, there is always the Gumpy build failures :). I don't know how soon Struts is to its next release, so I don't know how important it is to "fix" this. > Thanks, > Amy > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > 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: [5.0] Next release
Amy Roh wrote: - plenty of admin webapp patches need to be merged; Amy and Larry were the last persons seen maintaining this feature, so can one of you two do it if you have time ? Haven't had much time to spend on admin lately. Let me try to spend some time on admin before the next release to update. Let me know if you're aware of any patches other than the ones that come up in bugzilla when I query for tomcat 5 admin. No, nothing else. Thanks for maintaining this :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Next release
> - plenty of admin webapp patches need to be merged; Amy and Larry were > the last persons seen maintaining this feature, so can one of you two do > it if you have time ? Haven't had much time to spend on admin lately. Let me try to spend some time on admin before the next release to update. Let me know if you're aware of any patches other than the ones that come up in bugzilla when I query for tomcat 5 admin. Thanks, Amy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.0] Next release
oh yeah, and the bugs have been fixed :) (27296,27259) -Original Message- From: Filip Hanik (lists) [mailto:[EMAIL PROTECTED] Sent: Thursday, March 04, 2004 8:10 AM To: Tomcat Developers List Subject: RE: [5.0] Next release end of next week sounds good. I have some very minor fixes, and they I have to update the documentation. After that I will start working on the following: 1. Node merging, improve on the merge algorithm when two cluster nodes find each other 2. A primary/secondary replication solution, to be used if you have sticky sessions, for big clusters and faster performance Filip -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Thursday, March 04, 2004 1:36 AM To: Tomcat Developers List Subject: [5.0] Next release Hi, I'd like to follow on with the one-release-a-month rythm for now, since we still have interesting bugfixes here and there (ex: the cross context fix, plus some JSP fixes). So this means tagging 5.0.20 at the end of next week. It would be a good idea to attempt to fix all the remaining BZ items. - some SSI changes need to be merged back (23610) - plenty of admin webapp patches need to be merged; Amy and Larry were the last persons seen maintaining this feature, so can one of you two do it if you have time ? - the JK bugs should be resolved shortly with the new release - 27296: I think Filip did fix it already - 27259: I don't know ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.0] Next release
end of next week sounds good. I have some very minor fixes, and they I have to update the documentation. After that I will start working on the following: 1. Node merging, improve on the merge algorithm when two cluster nodes find each other 2. A primary/secondary replication solution, to be used if you have sticky sessions, for big clusters and faster performance Filip -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Thursday, March 04, 2004 1:36 AM To: Tomcat Developers List Subject: [5.0] Next release Hi, I'd like to follow on with the one-release-a-month rythm for now, since we still have interesting bugfixes here and there (ex: the cross context fix, plus some JSP fixes). So this means tagging 5.0.20 at the end of next week. It would be a good idea to attempt to fix all the remaining BZ items. - some SSI changes need to be merged back (23610) - plenty of admin webapp patches need to be merged; Amy and Larry were the last persons seen maintaining this feature, so can one of you two do it if you have time ? - the JK bugs should be resolved shortly with the new release - 27296: I think Filip did fix it already - 27259: I don't know ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[5.0] Next release
Hi, I'd like to follow on with the one-release-a-month rythm for now, since we still have interesting bugfixes here and there (ex: the cross context fix, plus some JSP fixes). So this means tagging 5.0.20 at the end of next week. It would be a good idea to attempt to fix all the remaining BZ items. - some SSI changes need to be merged back (23610) - plenty of admin webapp patches need to be merged; Amy and Larry were the last persons seen maintaining this feature, so can one of you two do it if you have time ? - the JK bugs should be resolved shortly with the new release - 27296: I think Filip did fix it already - 27259: I don't know ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WANTED: next release mod_jk2 after 14 months!!
Good morning All. Recently there was mention of a patch for Mod_Jk2 (to work with APR 1.0) which was questioned in regard to a previous 'bug' report. Since then, it is my understanding the previous correspondent was happy with a solution now in place regarding the earlier bug. Which, I think, brings us back again to the patch(s) needed for Mod_Jk2 to support APR 1.0 again. There has been at least one fix for Mod_Jk2 on NetWare put into CVS that would be nice to see appear in an authentic Apache binary, and it would be even nicer to see a resolution to the APR 1.0 patch submitted if a new release is to be made. A new release is 'due', especially if such a release is still able to work with earlier versions of Apache and APR. My 0.02c Norm - Original Message - From: "Günter Knauf" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, January 29, 2004 12:48 AM Subject: WANTED: next release mod_jk2 after 14 months!! > Hi all, > I'm sure that a lot of folks want to see a new release of mod_jk2; > and looking at: > http://www.apache.de/dist/jakarta/tomcat-connectors/jk2/source/ > it seems that the last version 2.0.2 was released 14 (!!) months ago > > comments? > > Guenter. > > > - > 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: WANTED: next release mod_jk2 after 14 months!!
Dominik Drzewiecki wrote: Hi all, I'm sure that a lot of folks want to see a new release of mod_jk2; and looking at: http://www.apache.de/dist/jakarta/tomcat-connectors/jk2/source/ it seems that the last version 2.0.2 was released 14 (!!) months ago comments? We sure DO WANT a new release. I also need a release and I will try to make it happend soon. regz, Dominik - 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: WANTED: next release mod_jk2 after 14 months!!
>Hi all, >I'm sure that a lot of folks want to see a new release of mod_jk2; >and looking at: >http://www.apache.de/dist/jakarta/tomcat-connectors/jk2/source/ >it seems that the last version 2.0.2 was released 14 (!!) months ago > >comments? We sure DO WANT a new release. regz, Dominik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
WANTED: next release mod_jk2 after 14 months!!
Hi all, I'm sure that a lot of folks want to see a new release of mod_jk2; and looking at: http://www.apache.de/dist/jakarta/tomcat-connectors/jk2/source/ it seems that the last version 2.0.2 was released 14 (!!) months ago comments? Guenter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [4.1.x] Next release
Hello, About the 4.1.25 tagging which is taking place. What is going to be the status of http gzip compression in 4.1.25? See bug 18073. Or will there follow a 4.1.26-BETA in the near future with some enhanced functionality? Greetings, Ronald. On Wednesday 02 April 2003 11:37, Remy Maucherat wrote: > Hi, > > As far as I am concerned, the focus for the next stable 4.1.x release > will be on small fixes. I do not want to introduce new features or > changes which would affect Tomcat's behavior. I think the ETA for that > next stable release could be within one to two months. > > So I would need to compile a list of issues which should be fixed in the > next release. > > As a starting point: > - Fix HTTP compression check (I think a small refactoring is needed to > make the feature cleaner). > - Fix FORM processing for more complex requests (bug 10229). > - Error message when the Java compiler is not found by Ant (if this is > fixable; Costin ?). > - Double wrapping of session objects. > > I'm waiting for some input to fill up the list. Note that for low > priority bugs, a patch will be required. The patch would need to: > - have a low impact > - be of good quality (no performance/scalability impact, clean code) > > Thanks, > Remy > > > - > 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: [4.1.x] Next release
+1 for the next 4.1 release to include only bug fixes. A quick query of bugzilla found 744 bugs for Tomcat 4 which are not either closed or resolved. Ouch! Perhaps we should set a goal for how much this number should be reduced before doing the release. Some of these are quite old and perhaps only need to be checked to see if they are still valid. Some are for mod_webapp. Since there is no volunteer to maintain this and we have removed it from the distribution, these could probably be closed as WONT FIX. Regards, Glenn Remy Maucherat wrote: Hi, As far as I am concerned, the focus for the next stable 4.1.x release will be on small fixes. I do not want to introduce new features or changes which would affect Tomcat's behavior. I think the ETA for that next stable release could be within one to two months. So I would need to compile a list of issues which should be fixed in the next release. As a starting point: - Fix HTTP compression check (I think a small refactoring is needed to make the feature cleaner). - Fix FORM processing for more complex requests (bug 10229). - Error message when the Java compiler is not found by Ant (if this is fixable; Costin ?). - Double wrapping of session objects. I'm waiting for some input to fill up the list. Note that for low priority bugs, a patch will be required. The patch would need to: - have a low impact - be of good quality (no performance/scalability impact, clean code) Thanks, Remy - 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: [4.1.x] Next release
- Original Message - From: "Jean-Francois Arcand" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Wednesday, April 02, 2003 12:37 PM Subject: Re: [4.1.x] Next release > > > Costin Manolache wrote: > > >Remy Maucherat wrote: > > > > > > > >>Could I get some details on that filter/facade bug ? > >> > >> > > > >Yes, Filter.init() is called with the Context object instead of the > >facade. While Servlet.init() is called correctly. > > > >This may allow access to the internals, and is just weird ( getting > >different context objects in the same app for a servlet and a filter ). > > > Fixed. I have ported the patch from Tomcat 5 (where no regression has > been found). > Now you just have to hope that the tab police don't catch you ;-). > -- Jeanfrancois > > > > >Costin > > > > > > > > > > > >>>>I'm waiting for some input to fill up the list. Note that for low > >>>>priority bugs, a patch will be required. The patch would need to: > >>>>- have a low impact > >>>>- be of good quality (no performance/scalability impact, clean code) > >>>> > >>>> > >>>Will the "patch" be a set of .jars, or a full release ? > >>> > >>> > >>I think this is going to be a full release when(ever) everything is in. > >> > >>Remy > >> > >> > > > > > > > >- > >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: [4.1.x] Next release
Remy Maucherat wrote: > Costin Manolache wrote: >> Remy Maucherat wrote: >> >> >>>Could I get some details on that filter/facade bug ? >> >> >> Yes, Filter.init() is called with the Context object instead of the >> facade. While Servlet.init() is called correctly. >> >> This may allow access to the internals, and is just weird ( getting >> different context objects in the same app for a servlet and a filter ). > > Does JFA patch fix this also ? > Yes. It needs to be backported. Regarding the other issue - can we at least have the .jars released separately - say for developer use ( for build ) or without any particular support ? ( i.e. no updater or patch release ) Costin > I'm going to add a bug list in CVS so we can easily edit it. > > Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [4.1.x] Next release
Remy Maucherat wrote: Costin Manolache wrote: Remy Maucherat wrote: Could I get some details on that filter/facade bug ? Yes, Filter.init() is called with the Context object instead of the facade. While Servlet.init() is called correctly. This may allow access to the internals, and is just weird ( getting different context objects in the same app for a servlet and a filter ). Does JFA patch fix this also ? Yes. -- Jeanfrancois I'm going to add a bug list in CVS so we can easily edit it. Remy - 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: [4.1.x] Next release
Costin Manolache wrote: Remy Maucherat wrote: Could I get some details on that filter/facade bug ? Yes, Filter.init() is called with the Context object instead of the facade. While Servlet.init() is called correctly. This may allow access to the internals, and is just weird ( getting different context objects in the same app for a servlet and a filter ). Fixed. I have ported the patch from Tomcat 5 (where no regression has been found). -- Jeanfrancois Costin I'm waiting for some input to fill up the list. Note that for low priority bugs, a patch will be required. The patch would need to: - have a low impact - be of good quality (no performance/scalability impact, clean code) Will the "patch" be a set of .jars, or a full release ? I think this is going to be a full release when(ever) everything is in. Remy - 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: [4.1.x] Next release
Costin Manolache wrote: Remy Maucherat wrote: Could I get some details on that filter/facade bug ? Yes, Filter.init() is called with the Context object instead of the facade. While Servlet.init() is called correctly. This may allow access to the internals, and is just weird ( getting different context objects in the same app for a servlet and a filter ). Does JFA patch fix this also ? I'm going to add a bug list in CVS so we can easily edit it. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [4.1.x] Next release
Remy Maucherat wrote: > Could I get some details on that filter/facade bug ? Yes, Filter.init() is called with the Context object instead of the facade. While Servlet.init() is called correctly. This may allow access to the internals, and is just weird ( getting different context objects in the same app for a servlet and a filter ). Costin > >>>I'm waiting for some input to fill up the list. Note that for low >>>priority bugs, a patch will be required. The patch would need to: >>>- have a low impact >>>- be of good quality (no performance/scalability impact, clean code) >> >> >> Will the "patch" be a set of .jars, or a full release ? > > I think this is going to be a full release when(ever) everything is in. > > Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [4.1.x] Next release
Costin Manolache wrote: Remy Maucherat wrote: Hi, As far as I am concerned, the focus for the next stable 4.1.x release will be on small fixes. I do not want to introduce new features or changes which would affect Tomcat's behavior. I think the ETA for that next stable release could be within one to two months. So I would need to compile a list of issues which should be fixed in the next release. As a starting point: - Fix HTTP compression check (I think a small refactoring is needed to make the feature cleaner). - Fix FORM processing for more complex requests (bug 10229). - Error message when the Java compiler is not found by Ant (if this is fixable; Costin ?). - Double wrapping of session objects. - The jk bugs that Jeff mentioned - the context facade and filters problem. Could I get some details on that filter/facade bug ? I'm waiting for some input to fill up the list. Note that for low priority bugs, a patch will be required. The patch would need to: - have a low impact - be of good quality (no performance/scalability impact, clean code) Will the "patch" be a set of .jars, or a full release ? I think this is going to be a full release when(ever) everything is in. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [4.1.x] Next release
> -Original Message- > From: news [mailto:[EMAIL PROTECTED] Behalf Of Costin Manolache > Sent: Wednesday, April 02, 2003 10:18 AM > To: [EMAIL PROTECTED] > Subject: Re: [4.1.x] Next release > > > Remy Maucherat wrote: > > > Hi, > > > > As far as I am concerned, the focus for the next stable 4.1.x release > > will be on small fixes. I do not want to introduce new features or > > changes which would affect Tomcat's behavior. I think the ETA for that > > next stable release could be within one to two months. > > > > So I would need to compile a list of issues which should be fixed in the > > next release. > > > > As a starting point: > > - Fix HTTP compression check (I think a small refactoring is needed to > > make the feature cleaner). > > - Fix FORM processing for more complex requests (bug 10229). > > - Error message when the Java compiler is not found by Ant (if this is > > fixable; Costin ?). > > - Double wrapping of session objects. > > - The jk bugs that Jeff mentioned > - the context facade and filters problem. > > > > > I'm waiting for some input to fill up the list. Note that for low > > priority bugs, a patch will be required. The patch would need to: > > - have a low impact > > - be of good quality (no performance/scalability impact, clean code) > > Will the "patch" be a set of .jars, or a full release ? > > Costin allow proxy support for the JK connectors (just like http), I'll submit a patch Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [4.1.x] Next release
Remy Maucherat wrote: > Hi, > > As far as I am concerned, the focus for the next stable 4.1.x release > will be on small fixes. I do not want to introduce new features or > changes which would affect Tomcat's behavior. I think the ETA for that > next stable release could be within one to two months. > > So I would need to compile a list of issues which should be fixed in the > next release. > > As a starting point: > - Fix HTTP compression check (I think a small refactoring is needed to > make the feature cleaner). > - Fix FORM processing for more complex requests (bug 10229). > - Error message when the Java compiler is not found by Ant (if this is > fixable; Costin ?). > - Double wrapping of session objects. - The jk bugs that Jeff mentioned - the context facade and filters problem. > I'm waiting for some input to fill up the list. Note that for low > priority bugs, a patch will be required. The patch would need to: > - have a low impact > - be of good quality (no performance/scalability impact, clean code) Will the "patch" be a set of .jars, or a full release ? Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[4.1.x] Next release
Hi, As far as I am concerned, the focus for the next stable 4.1.x release will be on small fixes. I do not want to introduce new features or changes which would affect Tomcat's behavior. I think the ETA for that next stable release could be within one to two months. So I would need to compile a list of issues which should be fixed in the next release. As a starting point: - Fix HTTP compression check (I think a small refactoring is needed to make the feature cleaner). - Fix FORM processing for more complex requests (bug 10229). - Error message when the Java compiler is not found by Ant (if this is fixable; Costin ?). - Double wrapping of session objects. I'm waiting for some input to fill up the list. Note that for low priority bugs, a patch will be required. The patch would need to: - have a low impact - be of good quality (no performance/scalability impact, clean code) Thanks, Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
