Trouble with SSL in Orion
I hope anyone can help me with Taking SSL on Orion Server I made all the constructions mentioned in the "ssl-tips.html" part: "Guide to getting a valid SSL certificate" but the Orion Server Makes the Error:"Unrecoverable Key" (There is no problem in other AppServers such as Tomcat). Thanx Mohammad Mahdi AmirianDo You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger.
RE: Stored procedures and J2EE
Is it correct to state that from a performance and design perspective using stored procedures is helpfull if you need access from outside the J2EE environment? If no out side access is necessary, the stored procedures are likely to be helpfull for perfomance if they filter out a lot of data or when you are using recursive logic (this way you are reducing the overhead of the remote calls), or am I missing a point with respect to performance differences between Stored Procedures and plain old SQL? Further more I realize now Stored Procedures are an interesting option in case of severe security requirements. You can differentiate access constraints to the Stored Procedures and minimise the amount off people / systems that have full access to you system. FE On Thursday, September 06, 2001 8:08 PM, Juan Lorandi (Chile) [SMTP:[EMAIL PROTECTED]] wrote: I (empirically) reached the same conclusion; but instead of dropping CMP, we provided performance improvements ON TOP of the EJB's (VO's and VO caches). Thank god we did it this way, because the DB can't scale as easily as the app-server cluster. My 2c, JP -Original Message- From: Rian Schmidt [mailto:[EMAIL PROTECTED]] Sent: Jueves, 06 de Septiembre de 2001 12:51 To: Orion-Interest Subject: Re: Stored procedures and J2EE I'm interested as to how you can say this... we just did a series of tests here to see what the effect of pulling out some fairly complex stored procedures into CMP beans, and the performance impact was enormous. We've actually gone the other way, that is, developing stored procedures for each anticipated database. The fallback is that the logic is done in the beans, but that is a worst-case scenario. Now, I realize that this would be considered such bad form in a Sun-controlled world of pure J2EE that I hesitate to even mention it... but in the real world, any significant hit on performance is enough to convince us to denormalize a bit, so to speak. I don't think that you can say there's absolutely no hit on performance not to use stored procedures, particularly if that procedure requires repeated queries of the data in a pseudo-recursive way. Do you really think that any performance hit that we've seen is a result of poor design? I'm really interested in your reasoning. Rian - Original Message - From: The mailto:[EMAIL PROTECTED] elephantwalker To: Orion-Interest mailto:[EMAIL PROTECTED] Sent: Thursday, September 06, 2001 2:23 AM Subject: RE: Stored procedures and J2EE As for distributing your business logic between the datastore and middle tier...aren't you making your life more complex than it needs to be? There is absolutely no hit on performance if you pull out all of your business logic into a slsb or cmp...there's just no need to use store procedures any more. File: ATT0.html
Re: UNSUSCRIBE
So annoing Whom shall we address the request to fix that BUG or it is wrong instaructions in FAQ??? Regards, D.S. - Original Message - From: Vinay Khandelwal [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Saturday, September 08, 2001 12:46 AM Subject: UNSUSCRIBE __ Do You Yahoo!? Get email alerts NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com
Re: ORacle db string over 4000 chars
Hi, I've implemented a couple of applications that stored files inside the database using the Oracle thin driver (we never use any driver type but the thin). To do so we just used LONG RAW columns and getBinaryStream() and setBinaryStream(). Even though we also used ZipInputStream/ZipOutputStream to compress/decompress the files as they were getting in/out of the database, files were pretty much always bigger than 4K. Now we started using Blobs because of the advantages they give you on the database side, even though their handling in Java is not that simple. Just my 2c, D. The elephantwalker wrote: the oracle thin driver can't handle any types larger than 4000 char, period. It doesn't matter whether you use long raw or whatever. If you have larger stuff, you will need to use clob or blob...these require reading and writing the character data or the byte[] data, taking care to use the empty_clob() and empty_blob() functions before your do your writing.We will be posting an example of how to do this with a slsb on our site soon...stay tuned...regards,the elephantwalkerwww.elephantwalker.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Nusairat, Joseph F. Sent: Friday, September 07, 2001 12:10 PM To: Orion-Interest Subject: RE: ORacle db string over 4000 chars I do realise oracle has 4000 varchar limits ... but i have seen other systems get around this by using LONG or LONG RAW data types instead however when i use those i still have it bug out at 4000 chars Joseph Faisal Nusairat, Sr. Project Manager WorldCom tel: 614-723-4232 pager: 888-452-0399 textmsg: [EMAIL PROTECTED] -Original Message- From: Nusairat, Joseph F. [mailto:[EMAIL PROTECTED]] Sent: Friday, September 07, 2001 11:39 AM To: Orion-Interest Subject: ORacle db string over 4000 chars Does anyone know how to handle this oracle 8.x u can have a varchar set to 4k ... sooo to do more than that i tried using a long and a long raw and inserting it that way ... however whenver i go over 4000 chars it bombs any one come across this problem? Joseph Faisal Nusairat, Sr. Project Manager WorldCom tel: 614-723-4232 pager: 888-452-0399 textmsg: [EMAIL PROTECTED]
Re: FORM based authentication with form-login-page as a JSP
Hi, I've never tried using FORM based authentication, but if orion uses the forward mechanism to redirect the request to the login page, I think I remember there is a method to get the original request URL when you do so... let me see... no, I can't seem to find it in the spec. I've just found something like that if you use the include mechanism. You might try to check the Attributes of the request, using getAttributeNames, to see if there's any object that tells you where the original request was directed to. good luck, D. SAURUGGER,PETER (A-PaloAlto,ex2) wrote: Would be interesting to control where a user goes, e.g. always redirecting them to the home page. Unfortunately, I don't have an answer to your question, just another observation: you don't even have to submit the page to j_security_check (see e.g. atm/atm-web/login.jsp) - orion -knows- where to send the request from the page specified in FORM based authentication. The regular case would be that the same page is served (without specifying the ACTION attribute to the FORM), but Orion nicely processes your request and does the 'appropriate' thing. I have not had time to try to look inside orion to find out what they are doing internally. If an answer is found to this question, I'd sure like to hear about it --peter -Original Message- From: Trujillo, Kris [mailto:[EMAIL PROTECTED]] Sent: Friday, September 07, 2001 1:24 PM To: Orion-Interest Subject: FORM based authentication with form-login-page as a JSP Here's some starting context for my question I have a war file that has been configured to use FORM based authentication. I have set the form-login-page in the web.xml of the war file to point to a jsp file in my war file. I have setup constraints against different jsps in the war file (/foo/foo.jsp, /foo2/foo.jsp, etc). When a user invokes any jsp without being logged in the login jsp is displayed. The user enters the userid/password submits the page to j_security_check, is validated and redirected to the requested page. My question is ... Has anyone ever tried discovering the page that the user is trying to access from within the jsp page referenced as the form-login-page? I have tried checking the HTTP headers and session, but have not discovered it being saved anywhere. Usually when a page invokes another page the HTTP header REFERER exists with the URL to the previous page. I have noticed that once the user posts the login form on my login.jsp to j_security_check and is authenticated they are redirect to the correct location .. correct location being back to the page they wanted to access originally. This would mean that it has to be somewhere, but where??
RE: ORacle db string over 4000 chars
I remember seeing some thing like this with Oracle8.1.6 that got fixed in 8.1.7. Khaled --- Nusairat, Joseph F. [EMAIL PROTECTED] wrote: I do realise oracle has 4000 varchar limits ... but i have seen other systems get around this by using LONG or LONG RAW data types instead however when i use those i still have it bug out at 4000 chars Joseph Faisal Nusairat, Sr. Project Manager WorldCom tel: 614-723-4232 pager: 888-452-0399 textmsg: [EMAIL PROTECTED] -Original Message- From: Nusairat, Joseph F. [mailto:[EMAIL PROTECTED]] Sent: Friday, September 07, 2001 11:39 AM To: Orion-Interest Subject: ORacle db string over 4000 chars Does anyone know how to handle this oracle 8.x u can have a varchar set to 4k ... sooo to do more than that i tried using a long and a long raw and inserting it that way ... however whenver i go over 4000 chars it bombs any one come across this problem? Joseph Faisal Nusairat, Sr. Project Manager WorldCom tel: 614-723-4232 pager: 888-452-0399 textmsg: [EMAIL PROTECTED] __ Do You Yahoo!? Get email alerts NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com
RE: RE: Stored procedures and J2EE
The whole point of n-tier distributed programming is to keep business logic outside of the database layer. Stored Procedures do have performance benefits, but it's much better from a design perspective to keep all logic in the middle layer and leave the database as a dumb persistence layer. Some would say that it's better to incorporate all the logic in the data layer and so multiple applications can call it without need to reduplicate code. But the same thing can be said of having the logic reside in the middle layer, where you also have the benefits of a strong OO machine independent language. - Brian Chan ([EMAIL PROTECTED]) -Original Message- From: Frank Eggink [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Subject: RE: Stored procedures and J2EE Date: Sat Sep 08 08:07:53 GMT 2001 Is it correct to state that from a performance and design perspective using stored procedures is helpfull if you need access from outside the J2EE environment? If no out side access is necessary, the stored procedures are likely to be helpfull for perfomance if they filter out a lot of data or when you are using recursive logic (this way you are reducing the overhead of the remote calls), or am I missing a point with respect to performance differences between Stored Procedures and plain old SQL? Further more I realize now Stored Procedures are an interesting option in case of severe security requirements. You can differentiate access constraints to the Stored Procedures and minimise the amount off people / systems that have full access to you system. FE On Thursday, September 06, 2001 8:08 PM, Juan Lorandi (Chile) [SMTP:[EMAIL PROTECTED]] wrote: I (empirically) reached the same conclusion; but instead of dropping CMP, we provided performance improvements ON TOP of the EJB's (VO's and VO caches). Thank god we did it this way, because the DB can't scale as easily as the app-server cluster. My 2c, JP -Original Message- From: Rian Schmidt [mailto:[EMAIL PROTECTED]] Sent: Jueves, 06 de Septiembre de 2001 12:51 To: Orion-Interest Subject: Re: Stored procedures and J2EE I'm interested as to how you can say this... we just did a series of tests here to see what the effect of pulling out some fairly complex stored procedures into CMP beans, and the performance impact was enormous. We've actually gone the other way, that is, developing stored procedures for each anticipated database. The fallback is that the logic is done in the beans, but that is a worst-case scenario. Now, I realize that this would be considered such bad form in a Sun-controlled world of pure J2EE that I hesitate to even mention it... but in the real world, any significant hit on performance is enough to convince us to denormalize a bit, so to speak. I don't think that you can say there's absolutely no hit on performance not to use stored procedures, particularly if that procedure requires repeated queries of the data in a pseudo-recursive way. Do you really think that any performance hit that we've seen is a result of poor design? I'm really interested in your reasoning. Rian - Original Message - From: The mailto:[EMAIL PROTECTED] elephantwalker To: Orion-Interest mailto:[EMAIL PROTECTED] Sent: Thursday, September 06, 2001 2:23 AM Subject: RE: Stored procedures and J2EE As for distributing your business logic between the datastore and middle tier...aren't you making your life more complex than it needs to be? There is absolutely no hit on performance if you pull out all of your business logic into a slsb or cmp...there's just no need to use store procedures any more. File: ATT0.html
