RE: Concurrent calls to Session bean methods
I haven't seen the history on this issue, but it interests me. I had a quick look at the ShoppingClientControllerEJB class that is given as an example by Sun in the Session Facade design pattern, but couldn't see where they are synchronizing calls. Can you provide some more clues? Thanks, John H. The elephantwalker [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent by: cc: owner-orion-interest@orion Subject: RE: Concurrent calls to Session bean methods server.com 03/19/02 10:31 PM Please respond to Orion-Interest Vani, You can use the petstore trick. Use a facade class which sychronizes each call to your session bean. That should do the trick. This is a _famous_ problem with session beans. regards, the elephantwalker www.elephantwalker.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Vani H.S. Sent: Wednesday, March 20, 2002 12:04 AM To: Orion-Interest Subject: Concurrent calls to Session bean methods Hello All, I have been trying to deploy an application consisting of session beans and mdbs onto orion1.5.4. But I seem to run into deadlocks, because my session bean gets called concurrently. Please can anybody can tell me if there is a setting to allow concurrent calls so that, when a session bean method is called at one time, the EJB container blocks the concurrent method call and allows it to proceed when the previous call has completed? If not, how should this problem of concurrent calls be handled in orion? Please help. Thanks, Vani The allow-concurrent-calls element specifies whether a stateful session bean instance allows concurrent method calls. By default, allows-concurrent-calls is false. However, when this value is set to true, the EJB container blocks the concurrent method call and allows it to proceed when the previous call has completed. _ Join the world's largest e-mail service with MSN Hotmail. http://www.hotmail.com
RE: How to handle multiple developers
Using CVS, I have each developer keep their own source tree and commit changes to the repository on a regular basis. Then I have a fake user (called test, or prod, or whatever) that I use to check out a source tree whenever I get ready for a release. Prior to a release, I get all the developers to commit all their changes, then I check out the whole project tree using the test user and deploy it from there. If everything checks out OK, I have the prod user check out the updated code and deploy on the production server. John H. Nusairat, Joseph F. [EMAIL PROTECTED]@orionserver.com on 01/15/2002 02:00:59 PM Please respond to Orion-Interest [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] cc: Subject: RE: How to handle multiple developers I actuallly meant more in terms of storing the class files and then jaring them together. DO u all just store them on a shared drive instead?? And then alll jar em??? Joseph Faisal Nusairat, Sr. Applications Developer WorldCom tel: 614-723-4232 pager: 888-452-0399 textmsg: [EMAIL PROTECTED] -Original Message- From: Simon Kelly [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 15, 2002 2:55 PM To: [EMAIL PROTECTED] Subject: RE: How to handle multiple developers Use a Code Management tool such as Microsoft Visual SourceSafe or CVS(free)! Check out this link: http://www.martinfowler.com/articles/continuousIntegration.html Regards, Simon. -Original Message- From: Nusairat, Joseph F. [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, January 15, 2002 8:11 AM To: Orion-Interest Subject: How to handle multiple developers I was wondering how do u guys wrap up an application and store it when u have multiple developers coding for the same app? -joseph Joseph Faisal Nusairat, Sr. Applications Developer WorldCom tel: 614-723-4232 pager: 888-452-0399 textmsg: [EMAIL PROTECTED]
RE: question about ip allocation
On windows (NT) you can bind multiple IP addresses to a single NIC under the Advanced tab on the TCP/IP protocol properties dialog. Of course, you'll have to reboot... John H. Jarrod Roberson [EMAIL PROTECTED]@orionserver.com on 01/09/2002 11:06:29 AM Please respond to Orion-Interest [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] cc: Subject: RE: question about ip allocation this is incorrect, they is a port 80 for each IP address. As long as the clients can access each IP address, they can get to either port 80. Now Orion may be listening to ALL ip addresses on port 80 making it look like there is only one port 80. But each interface as a full compliment of ports. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Maximilian Eberl Sent: Wednesday, January 09, 2002 5:27 AM To: Orion-Interest Subject: Re: question about ip allocation Your machine has 2 IP-adresses but only one port 80 ! No 2 servers can listen on 1 port - no matter how many network cards You pull in. You have to bind the IPs to different ports. I am doing this on Linux but don't know how this is done on Windows. Max -- Maximilian Eberl - developer - netzdenker.de http://www.netzdenker.de mailto:[EMAIL PROTECTED] Ludwigstrasse 2 D-67346 Speyer / Germany tel: +49-6232-2602-02 fax: +49-6232-2602-05
Re: Aaarrrghhh!! CSS and Servlet again
The thing is, the specification you are working to defines the context path as a deployment decision. It is simply coincedence that the context path in all of your deployments is the same (root). Even in your situation, you should prefix ANY hard coded URLs with getContextPath, because that protects you. It is not a thing that ever fails, it will always work, and it will always protect you from different deployment issues. What happens it your www.site1.com decides to deploy the application as www.site1.com/app1...? The context path is set in the deployment descriptor, not in the code. You really should make your code independent of the deployment descriptor even if it just happens to be that your current deployment descriptors match your code. John H. Robert Koberg [EMAIL PROTECTED]@orionserver.com on 06/22/2001 10:21:15 AM Please respond to Orion-Interest [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] cc: Subject: Re: Aaarrrghhh!! CSS and Servlet again Hi John, I see why you are doing that but I don't agree it is a good way to go, at least for me. It looks like you are a corporate developer who builds for an intranet that would benefit from the context paths. But, for me (internet development - each site unique), it works out better for the whole team when the dev (and qa) server is setup with virtual hosts (? I am not a sys admin, so...): Dev server dev-site1.workingdomain.com dev-site2.workingdomain.com QA server qa-site1.workingdomain.com qa-site2.workingdomain.com Live server(s) www.site1.com www.site2.com This way everyone is working (and qa'ing) out of the same environment as it will be when live. As for my personal development, I do work on local machines at home (not the dev box) whenever possible. We keep everything in sync with CVS. I also have the 5 static IPs and keep a machine/static IP for each project. It is easier for me (and everyone else on the team) to work without the context path. I do see the context path as a problem in these containers especially when working on large projects/groups with a variety of skills and needs. I feel it is better to keep the same environment through the site promotion process. of course there are other ways to do it... Thanks for the discussion, Rob - Original Message - From: [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Thursday, June 21, 2001 3:34 PM Subject: Re: Aaarrrghhh!! CSS and Servlet again In a typical web application server, there can be applications deployed to several contexts within the container. Each context is differentiated using a URL prefix, e.g.: http://myhost/webstore http://myhost/benefits-admin Webstore and benefits-admin represent different Servlet contexts which are different applications served out of the same container. In most cases, these applications won't share resources, so the css files for the webstore application will be somewhere below the document root for webstore, and the css files for benefits-admin will be under it's document root, e.g.: /deploy/webapps/webstore/styles/main.css /deploy/webapps/benefits-admin/styles/main.css When you refer to the main.css file for the webstore app, it's URI is http://myhost/webstore/styles/main.css, or shortened to /webstore/styles/main.css. For benefits-admin, it's /benefits-admin/styles/main.css. The prefix part (/webstore, or /benefits-admin) is the context path and it is defined in your application deployment descriptor. This can be changed during deployment, so you don't want it hard coded in your HTML, JSP, or Servlets. It is possible to use relative paths to get to the URI, for example a servlet whose URL is /webstore/servlet/MyServlet can refer to the css file as ../styles/main.css, however that means that if you map a different URL to your servlet, the relative URL won't work anymore. Also, take an example of a JSP found at /webstore/cart.jsp. The relative URL of styles/main.css would work, but what happens if the cart.jsp is redirected to from a servlet using a RequestDispatcher? The browser thinks the URL is /webstore/servlet/DirectorServlet, so the relative URL breaks! Explicity referring to the context path and appending the absolute path to the resource within the deployed web application ensures that the reference will always work, so long as the resource is in the location specified by the absolute path. Obviously this is all irrelevant if you only have one context in your application server and it is deployed to the web site root. John H. Robert Koberg [EMAIL PROTECTED]@orionserver.com on 06/21/2001 01:28:51 PM Please respond to Orion-Interest [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] cc: Subject: Re: Aaarrrghhh!! CSS and Servlet again To be safe, you really ought to use request.getContextPath() to prefix the absolute URL of your css file relative to your
RE: Aaarrrghhh!! CSS and Servlet again
To be safe, you really ought to use request.getContextPath() to prefix the absolute URL of your css file relative to your document root. When you deploy to a context like: http://myhost:myport/mycontext All of your paths are prefixed by /mycontext. But if you change your deployment descriptor, you might change mycontext to something else. You don't want that hard-coded into your servlets. Also, the suggestion by elephantwalker is true - you can use relative paths (/mycontext/servlet/../blah.css will get you to /mycontext/blah.css) but if you decide to put your servlet in a package, or map a different URL pattern to it (e.g. /mycontext/MyServlet) this won't work. Using request.getContextPath() plus an absolute path is guaranteed to work so long as the resource stays where you put it relative to the document root. It also comes in very handy when you put the reference in a JSP - sometimes the JSP will be called directly (so the browser URL is /mycontext/myjsp.jsp) but sometimes you get there using a RequestDispatcher, so the browser thinks the URL is /mycontext/servlet/MyServlet. In this case, relative URLs don't work. So, put the css file in your document root and use: link rel=stylesheet type=text/css href=%= request.getContextPath() %/blah.css title=blah if your JSPs and out.println(link rel=\stylesheet\ type=\text/css\ href=\ + request.getContextPath() + /blah.css\ title=\blah\); in your servlets. John H. elephantwalker [EMAIL PROTECTED]@orionserver.com on 06/20/2001 05:55:45 PM Please respond to Orion-Interest [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] cc: Subject: RE: Aaarrrghhh!! CSS and Servlet again The url pattern for your servlet is the issue. Somehow it is /, which means just about everthing. I would use something different like, /employees or /employees.html. Your path to the css should be just ../blah.css, and include the blah.css in your war file at the root. regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Brynolf Andersson Sent: Wednesday, June 20, 2001 3:28 PM To: Orion-Interest Subject: Aaarrrghhh!! CSS and Servlet again Hi all again, I have been trying all lot of different ways to pick uppthe CSS file but without any success. So I'll try to see if anyone has some more thing to add to my problem. The question is still there, where should I put my CSS file and how should I pick it up from the servlet. Som information: server.xml: application name=Lab01 path=C:\oracle\JDeveloper 3.2.3\myprojects\lab_01 / default-web-site.xml: !-- LAB 01 -- web-app application=Lab01 name=web root=/lab01 / web.xml: ?xml version=1.0? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN http://java.sun.com/j2ee/dtds/web-app_2_2.dtd; web-app display-nameLab 01/display-name descriptiondesc/description servlet servlet-nameEmployeeServlet/servlet-name servlet-classtraining.EmployeeServlet/servlet-class /servlet servlet-mapping servlet-nametraining.EmployeeServlet/servlet-name url-pattern//url-pattern -- /servlet-mapping /web-app application.xml: ?xml version=1.0? !DOCTYPE application PUBLIC -//Sun Microsystems, Inc.//DTD J2EE Application 1.2//EN http://java.sun.com/j2ee/dtds/application_1_2.dtd; display-nameLab01/display-name module web web-uriweb/web-uri context-root//context-root /web /module /application Directory structure of the WEB-APP: _lab_01 |_META-INF | |_application.xml |_web ||WEB-INF ||web.xml ||classes ||pkg ||myServlet Help Get your FREE download of MSN Explorer at http://explorer.msn.com
Re: Aaarrrghhh!! CSS and Servlet again
In a typical web application server, there can be applications deployed to several contexts within the container. Each context is differentiated using a URL prefix, e.g.: http://myhost/webstore http://myhost/benefits-admin Webstore and benefits-admin represent different Servlet contexts which are different applications served out of the same container. In most cases, these applications won't share resources, so the css files for the webstore application will be somewhere below the document root for webstore, and the css files for benefits-admin will be under it's document root, e.g.: /deploy/webapps/webstore/styles/main.css /deploy/webapps/benefits-admin/styles/main.css When you refer to the main.css file for the webstore app, it's URI is http://myhost/webstore/styles/main.css, or shortened to /webstore/styles/main.css. For benefits-admin, it's /benefits-admin/styles/main.css. The prefix part (/webstore, or /benefits-admin) is the context path and it is defined in your application deployment descriptor. This can be changed during deployment, so you don't want it hard coded in your HTML, JSP, or Servlets. It is possible to use relative paths to get to the URI, for example a servlet whose URL is /webstore/servlet/MyServlet can refer to the css file as ../styles/main.css, however that means that if you map a different URL to your servlet, the relative URL won't work anymore. Also, take an example of a JSP found at /webstore/cart.jsp. The relative URL of styles/main.css would work, but what happens if the cart.jsp is redirected to from a servlet using a RequestDispatcher? The browser thinks the URL is /webstore/servlet/DirectorServlet, so the relative URL breaks! Explicity referring to the context path and appending the absolute path to the resource within the deployed web application ensures that the reference will always work, so long as the resource is in the location specified by the absolute path. Obviously this is all irrelevant if you only have one context in your application server and it is deployed to the web site root. John H. Robert Koberg [EMAIL PROTECTED]@orionserver.com on 06/21/2001 01:28:51 PM Please respond to Orion-Interest [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] cc: Subject: Re: Aaarrrghhh!! CSS and Servlet again To be safe, you really ought to use request.getContextPath() to prefix the absolute URL of your css file relative to your document root. why (just curious)? what is different if just use: link rel=stylesheet type=text/css href=/blah.css title=blah The above is more generic (you don't need to run JSP for every file) - Original Message - From: [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Thursday, June 21, 2001 7:29 AM Subject: RE: Aaarrrghhh!! CSS and Servlet again To be safe, you really ought to use request.getContextPath() to prefix the absolute URL of your css file relative to your document root. When you deploy to a context like: http://myhost:myport/mycontext All of your paths are prefixed by /mycontext. But if you change your deployment descriptor, you might change mycontext to something else. You don't want that hard-coded into your servlets. Also, the suggestion by elephantwalker is true - you can use relative paths (/mycontext/servlet/../blah.css will get you to /mycontext/blah.css) but if you decide to put your servlet in a package, or map a different URL pattern to it (e.g. /mycontext/MyServlet) this won't work. Using request.getContextPath() plus an absolute path is guaranteed to work so long as the resource stays where you put it relative to the document root. It also comes in very handy when you put the reference in a JSP - sometimes the JSP will be called directly (so the browser URL is /mycontext/myjsp.jsp) but sometimes you get there using a RequestDispatcher, so the browser thinks the URL is /mycontext/servlet/MyServlet. In this case, relative URLs don't work. So, put the css file in your document root and use: link rel=stylesheet type=text/css href=%= request.getContextPath() %/blah.css title=blah if your JSPs and out.println(link rel=\stylesheet\ type=\text/css\ href=\ + request.getContextPath() + /blah.css\ title=\blah\); in your servlets. John H. elephantwalker [EMAIL PROTECTED]@orionserver.com on 06/20/2001 05:55:45 PM Please respond to Orion-Interest [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] cc: Subject: RE: Aaarrrghhh!! CSS and Servlet again The url pattern for your servlet is the issue. Somehow it is /, which means just about everthing. I would use something different like, /employees or /employees.html. Your path to the css should be just ../blah.css, and include the blah.css in your war file at the root. regards, the elephantwalker
Re: response.sendRedirect problem
The path you provide to response.sendRedirect should be run through response.encodeRedirectURL first. This may help solve the problem because it will generate an absolute, fully qualified URL. John H. Rafael Alvarez [EMAIL PROTECTED]@orionserver.com on 06/13/2001 05:43:35 PM Please respond to Orion-Interest [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] cc: Subject: response.sendRedirect problem Hi all, this is the scenary: I have a 2 jsp pages and 2 servlet. The flow is: pag1.jsp --(via Post)-- --servlet1 --(via forward) -- --servlet2 --(via response.sendRedirect) -- -- pag2.jsp when viewed using some browsers in Mac (IE and Netscape alike), the redirect sends the url http://hostname/servlet/servlet2/http//hostname/servlet/servlet2 and I got a 400 Bad Request Error, no matter which url I use in the response.sendRedirect (as I recall, my last was foobar/whatever) On windows and unix browsers works fine. Any ideas? -- Best regards, Rafaelmailto:[EMAIL PROTECTED]
