Re: Cookies larger than 20k
This page from Netscape: http://home.netscape.com/newsref/std/cookie_spec.html states that you shouldn't expect clients or severs to deal with cookies over 4k in size. It even suggests that cookies longer than that should be truncated. Not sure if there is a relevant RFC that supercede this information. mark The Procter Gamble Co. [EMAIL PROTECTED] Internet Mail Message Received from host: Joseph B. Ottinger [EMAIL PROTECTED]To: Orion-Interest [EMAIL PROTECTED] Sent by:cc: (bcc: Mark Mascolino-MR/PGI) [EMAIL PROTECTED]Subject: Re: Cookies larger than 20k 06/27/01 07:08 AM Please respond to Orion-Interest On Tue, 26 Jun 2001, Orion Developers wrote: We're having problems passing cookies greater then 20k in size. We get a http: 413 error, and the servlets seem to truncate over that limit. There's some seriously debatable value in using cookies over 20k in size. I'd really suggest you reconsider this. Really. And no, I have no worthwhile contribution other than a sense of Gee, do you REALLY want to hang yourself or your users like this? Also, is there a version/bug fix list available to the public? we are on 1.4.5 and I am wondering about 1.5.2, and what issues have been addressed. Check out changes.txt, as usual. Finally, has ANYONE had any success getting ahold of Cadrion, the alleged 'support partner' of Orion?? While I can't speak for Cadrion *or* Ironflare... I understand Cadrion had some issues a while back, unrelated to Orion. Check www.atlassian.com/support/ out; it looks like LITERALLY the same thing. _ Get your FREE download of MSN Explorer at http://explorer.msn.com --- Joseph B. Ottinger [EMAIL PROTECTED] http://adjacency.org/ IT Consultant
Re: getRemoteAddr() - APACHE as proxy !!
Oracle 9iAS uses Apache as the web server so prehaps this addition of AJP13 support was added because of Oracle's licensing. m Mark R Mascolino Technology Missionary The Procter Gamble Co. [EMAIL PROTECTED] Internet Mail Message Received from host: Marcel Schutte [EMAIL PROTECTED]To: Orion-Interest [EMAIL PROTECTED] Sent by:cc: (bcc: Mark Mascolino-MR/PGI) [EMAIL PROTECTED]Subject: Re: getRemoteAddr() - APACHE as proxy !! 06/05/01 01:52 PM Please respond to Orion-Interest Hi, I don't know how it works, but in orion's changes.txt it says 'Added AJP13 support.' for version 1.4.8 . Unfortunately the docs don't mention it at all. As far as I know this is the protocol used by Tomcat to communicate with Apache. Perhaps it solves your problem, leaving you with the problem of getting AJP13 to work ofcourse :). Marcel - Original Message - From: Eddie [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Tuesday, June 05, 2001 6:29 PM Subject: Re: getRemoteAddr() - APACHE as proxy !! OK, In the meantime I found out what is wrong: I am using apache as a proxy server, and therefore I do get the IP address of the server. How can I overcome this ?? Such that getRemoteAddr() does return the client's IP address in my servlets. Eddie - Original Message - From: Eddie To: Orion-Interest Sent: Tuesday, June 05, 2001 2:12 PM Subject: getRemoteAddr() Hellu there, If I use getRemoteAddr() to get the IP address of the client the makes the servlet requests it return the IP address of the server ?? (also getRemoteHost() returns the server name). Any idea how come ?? I am running jdk 1.3 and the servlets run on the application server Orion 1.5.1 (OS: Linux redhat 7.0) (I can remember that a JSP on JSERv on apache didn't had this problem, so I quess it's Orion .. not ??) Eddie
Re: Struts (was: I switch from X to Orion because: )
The reason for reimplementing ResourceBundle as MessageResources is that ResourceBundle is not Serializable. Some containers, notable WebLogic 6, have issues with non-serializable objects being stored in things like the application and session context. Its also very important that you only throw Serializable things in there espacially if you plan on using the distributable / tag in your web.xml. mark Mark R Mascolino The Procter Gamble Co. [EMAIL PROTECTED] Internet Mail Message Received from host: "Jeff Schnitzer" [EMAIL PROTECTED]To: Orion-Interest Sent by:[EMAIL PROTECTED] [EMAIL PROTECTED]cc: (bcc: Mark Mascolino-MR/PGI) Subject: Struts (was: I switch from X to 02/28/01 08:25 PMOrion because: ) Please respond to Orion-Interest This subject is especially timely for me because I just finished evaluating both WebWork and Struts. I decided to go with WebWork. It wasn't so much that I was drawn to WebWork's technological coolness - there are some neat ideas there, but I think most could be adapted into Struts with a little effort. The problem was that when I looked deeply into Struts, I didn't like what I saw. I spent a *lot* of time wavering; on one hand, Struts has a solid user community and good javadocs, on the other hand, WebWork is simpler and easier to teach future members of the team. I kept switching my favor back and forth when I discovered something new I did or didn't like. What finally pushed me over the edge was my experience hunting down the problem preventing Struts from working with Orion out of the box. Here's the story: If you've ever tried loading the Struts 1.0 example app, you are immediately confounded by missing resource errors. There is a lot of complaint in the Orion and Struts archives about this, but the closest anyone has come to nailing it down is this message: http://www.mail-archive.com/struts-user@jakarta.apache.org/msg00582.html in which the principal author of Struts, Craig, implies that Orion's classloader has a problem preventing it from working with the standard JDK ResourceBundle. I knew there was something wrong with this because WebWork uses ResourceBundle without issue. So I looked through Struts' source to see how it might be using ResourceBundle differently, and what I discovered is that Struts doesn't use ResourceBundle at all! In fact, Struts has a whole homebrewed framework for handling properties which mirrors the ResourceBundle API but doesn't use any of its classes or interfaces. There are javadoc comments to the effect that the Struts code should be faster than ResourceBundles, but looking at the JDK 1.3 source code, both frameworks seem to be doing pretty much the same thing. For those curious, the actual problem with Orion is that Struts uses ClassLoader.getResourceAsStream() to build the Properties object, and (I checked the decompiled code) the Orion classloader does not implement getResourceAsStream(). Orion's fault, and logged as bug #340. But why re-invent the wheel?!? The JDK provides resource management for us! Even if the Struts code was slightly faster (which I doubt), any performance gain is going to be negligable compared to the amount of time spent processing taglibs, etc. I can't believe that whoever wrote the Struts MessageResources classes ever bothered to run the code through a profiler to find out where the real bottlenecks are. All this extra code and duplicated infrastructure is nothing but an opportunity for more bugs, IMHO. At this point I decided to go with WebWork. It is certainly not without issues as well, but I'm very happy with the results. And I am finding that in a framework this simple, fundamental changes are easy to make. I could elaborate on the differences between WebWork and Struts if anyone is really interested. If you're still writing JSP-centric applications, you *really* should look into an MVC framework. Jeff -Original Message- From: Arved Sandstrom [mailto:[EMAIL PROTECTED]] Sent: Wednesday
RE: Any news from Orion yet??: Rebuttle...
Its close to app server independence, but the spec doesn't go far enough in some areas. One good example is User Management. I would love to use the security constraints stuff in the web.xml file, but the mechanism to add/modify/delete users is server proprietary. I'm sure this is just one of serveral areas that are like this in the spec. m Mark R Mascolino The Procter Gamble Co. [EMAIL PROTECTED] Internet Mail Message Received from host: Ozzie Gurkan [EMAIL PROTECTED] Sent by:To: Orion-Interest [EMAIL PROTECTED] [EMAIL PROTECTED]cc: (bcc: Mark Mascolino-MR/PGI) Subject: RE: Any news from Orion yet??: Rebuttle... 01/15/01 11:41 AM Please respond to Orion-Interest Not to sound like a hipocrat but I believe the J2EE standard calls for a pplication server independence flexibility. You must think to yourself what makes your application so dependent on the server it is deployed onto. Besides the custom deployment descriptors (orion-ejb-jar, weblogic-ejb-jar, jboss, and so on) you should architect your system independent of any app server dependent features like clustering, fail-over and load balancing. If you sit down and outline the layers that are dependent on the underlying mechanism, you will be able to isolate and separate your application. Do you rememeber that Java is supposed to be independent of its OS? So, coming back to my point: even if Orion does go under, you should be able to switch out to another server and modify some deployment descriptors with no problem. I have my application running under Weblogic, Orion, and Jboss with only the deployment descriptors different. I hope this helps and triggers some thought. Thanks, Ozzie Gurkan --- Robert Krueger [EMAIL PROTECTED] wrote: Of course, this is a little unfair - weblogic hadn't had a new release for several months, either. They've just had a major release recently, which makes it seem like they're more active than Orion, when that's not necessarily the case. It might be, but that's not implied by the situation at present. For the most part, Orion is still very much ahead of the pack, and the speed is stil EXCELLENT. While I'm very much looking forward to a new doesn't buy you much if it isn't reliable. that's the sad thing. it's true that they are ahead of the pack in a number of fields but if you're stuck with a serious bug without the slightest hint when things will be fixed it's still a KO criterion (germanism?). at the moment we're not switching to an alternative because 1. most of our projects where orion is currently used in production wouldn't allow a switch to WLS budgetwise 2. OSS alternatives are still far from the completeness orion offers (sad but it's the truth), which especially hurts if you have a large number of deployed J2EE applications which we do 3. there is some (not too much) hope left, they have learned their lesson and won't underestimate QA requirements in the future once they come back and start releasing updates again at the moment we settled for living with a number of strange behaviours and awkward workarounds that we simply hope won't break our necks the next day (which is not a good feeling to live with). one lesson I have learned is that there is a substantial risk involved in choosing a brandnew (even standard) technology. I would be more careful next time. Now too much work has gone into the current setup to change it to other alternatives and other products supporting the same standards are simply too expensive. round of released bug fixes, I'm still waiting for some things to shake out before I abandon ship. but you have to admit that it's getting harder to hold on to that? my 2 c robert -Original Message- From: Santosh Kumar [mailto:[EMAIL PROTECTED]] Sent: Monday, January 15, 2001 12:57 AM To: Orion-Interest Subject: Re: Any news from Orion yet?? Hi kevin
JDom and Orion
Hi all, I am trying to use the most excellent JDom in my web app on Orion (1.3.9) and running into a little snag. For certain parts of its funcationality, JDom requires a very recent version of Xerces. The datestamp on it is Sep 1, 2000 and it is approx 1,464KBs. As you can tell this is almost three times as big as the xerces jar that is shiped with Orion. I have tried to include the new xerces.jar in the /WEB-INF/lib directory of my war file but to no avail. Orion seems content to pick up its version of the jar (I imagine its a classloader thing). So my question is, is it ok to swap out Orion's old xerces.jar for the new one? Will I run into unforseen trouble down the road? Is there another way of solving this problem that i am unaware of or too ignorant to figure out? thanks a bunch... mark Mark R Mascolino The Procter Gamble Co. [EMAIL PROTECTED]
