DO NOT REPLY [Bug 43957] service.bat doesn' t configure logging like the Windows installer
https://issues.apache.org/bugzilla/show_bug.cgi?id=43957 Richard Fearn <[EMAIL PROTECTED]> changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #6 from Richard Fearn <[EMAIL PROTECTED]> 2008-04-24 11:49:00 PST --- Thanks Mark. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 44871] New: Cookie parsing issue
https://issues.apache.org/bugzilla/show_bug.cgi?id=44871 Summary: Cookie parsing issue Product: Tomcat 5 Version: 5.5.26 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Servlet & JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] We've discovered an issue with the latest version of Tomcat 5 (5.5.25) & Tomcat 6 (6.0.16). The problem arises when doing base64 encoding of cookies in our application. When the cookie is encoded, the '=' character is used for padding. When it reaches the browser, the cookie is a valid base 64 encoded cookie and the '=' character is the last character. However when the application retrieves the cookies sent back from the browser using a simple request.getCookie, we can see that the '=' char has been stripped away. This results in a an error when trying to decode. It could be as a result of the '=' being used as a delimiting character resulting in the request headers being incorrectly parsed. This is only an issues with the latest versions of Tomcat 5 & 6. Previous version work ok. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 44679] Cookies are treated differently between 6.0. 16 and 6.0.14
https://issues.apache.org/bugzilla/show_bug.cgi?id=44679 Filip Hanik <[EMAIL PROTECTED]> changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #9 from Filip Hanik <[EMAIL PROTECTED]> 2008-04-24 14:33:12 PST --- *** Bug 44871 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 44871] Cookie parsing issue
https://issues.apache.org/bugzilla/show_bug.cgi?id=44871 Filip Hanik <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Filip Hanik <[EMAIL PROTECTED]> 2008-04-24 14:33:12 PST --- *** This bug has been marked as a duplicate of bug 44679 *** -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
On Apr 22, 2008, at 6:25 PM, Paul Benedict wrote: Is that enough so that web applications, either as a whole or in partial, can be upgraded without stopping them? It's my understanding that if web applications are loaded in an OSGi classloader, these kind of things are possible. I've heard various claims of this nature from osgi zealots, but when talking to apparent experts the only things resembling this they seemed to know about were grad student experiments that did not have production use as even a far-in-the-future goal. Do you know of any actual examples of this kind of behavior that actually work under load? thanks david jencks Paul On Tue, Apr 22, 2008 at 7:24 PM, Filip Hanik - Dev Lists <[EMAIL PROTECTED] > wrote: Henri Gomez wrote: Hi to all, Did there is plans, ideas or interest around about OSGI-fing Tomcat ? I've put a note about this a while ago in tomcat/trunk/PROPOSALS.txt my original plan was just to make sure all the MANIFEST.MF for each file would have enough in it so that each JAR can be a OSGi bundle. after that, one can add on as much or as little as one wishes Filip Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
I'm not an expert, but I think I can tell you that yes, "hello world" applications can be upgraded without stopping, real applications can't. As long as you use sessions or statics or you make config changes - you have to restart the webapp. OSGI is good of having 2 versions of a bundle running at the same time - but it won't help you much, the servlet engine needs to know where to send the requests, it has no clue a request should go to the old version or the new. Costin On Thu, Apr 24, 2008 at 5:17 PM, David Jencks <[EMAIL PROTECTED]> wrote: > > On Apr 22, 2008, at 6:25 PM, Paul Benedict wrote: > > > > Is that enough so that web applications, either as a whole or in partial, > > can be upgraded without stopping them? It's my understanding that if web > > applications are loaded in an OSGi classloader, these kind of things are > > possible. > > > > > I've heard various claims of this nature from osgi zealots, but when > talking to apparent experts the only things resembling this they seemed to > know about were grad student experiments that did not have production use as > even a far-in-the-future goal. Do you know of any actual examples of this > kind of behavior that actually work under load? > > thanks > david jencks > > > > > > > Paul > > > > On Tue, Apr 22, 2008 at 7:24 PM, Filip Hanik - Dev Lists > <[EMAIL PROTECTED]> > > wrote: > > > > > > > Henri Gomez wrote: > > > > > > > > > > Hi to all, > > > > > > > > Did there is plans, ideas or interest around about OSGI-fing Tomcat ? > > > > > > > > > > > > > > > I've put a note about this a while ago in tomcat/trunk/PROPOSALS.txt > > > my original plan was just to make sure all the MANIFEST.MF for each file > > > would have enough in it so that each JAR can be a OSGi bundle. > > > > > > after that, one can add on as much or as little as one wishes > > > > > > Filip > > > > > > > > > > Regards > > > > > > > > - > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
> OSGI is good of having 2 versions of a bundle running at the same time > - but it won't help you much, the servlet > engine needs to know where to send the requests, it has no clue a > request should go to the old version or the new. May be additions to servlet specs should be planned, ie, by allowing such informations about which version to take care of ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
> I've heard various claims of this nature from osgi zealots, but when > talking to apparent experts the only things resembling this they seemed to > know about were grad student experiments that did not have production use as > even a far-in-the-future goal. Do you know of any actual examples of this > kind of behavior that actually work under load? We'll see how OSGI works underload with Glassfish v3. BTW, performance is only a point in an IT infrastructure, ease of deployment and administration is often more important (from my day to day experience) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
