RE: Stateful Session timeout, JSPs
Very interesting. I never did consider this. I think there are different approaches as to the best way to accomplish this. Because the network can get bottlenecked, I understand its best to use STATELESS ejb session beans. That is, they simply do logic, but do not store any session information. The session information is stored in the HttpSession instead. I don't quite know why this prevents a bottleneck over the network. It seems to me that no matter what you do on the web server side, you'll have to mimmick the data on the ejb side and somehow pass that info from the web server to the ejb session bean, have it do its work and return the data back to the web server so that it can be stored sessionaly. However, this would resolve your time-out problem, which among other things may be why some choose to do this. I don't know if you are trying to store the info twice..but if you are, I'd not do that. Store it in the HttpSession or the EJB session, but not both. Thus, your "bouncer" include file should be checking either the HttpSession or calling the EJB session to check for the object there. Not both. I would still prefer to use Stateless ejb beans and store everything in the HttpSession. Maybe the bottleneck is because the "view" is on the web server..and you may often need to view dynamic content far more than you deal with transactions..so it makes sense to store info in the HttpSession and just use stateless ejb to do the work. Make any sense? ;) > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Thomas Munro > Sent: Thursday, May 04, 2000 9:37 AM > To: Orion-Interest > Subject: Stateful Session timeout, JSPs > > > Hello > > I have a design question. > > I have a (1) JSP session which stores a reference to (2) a stateful > session EJB. If either times out, I want the user to be bounced to a page > where they have to log in (again). The problem is that the JSP session > and the session EJB time out under different conditions -- that is to say, > merely surfing around the web application will keep the JSP session alive, > but the EJB is only kept alive by accessing it, which doesn't necessarily > happen on every page. Otherwise, I could simply set the EJB to timeout > after a longer time than the JSP session. > > I have a <%@ include file="/system/bouncer.jsp" %> at the top of all my > JSP pages, which tests whether the JSP session has timed out (among other > things), and if so, it bounces to the log-in page. > > However, for the session EJB, I have to catch > "java.rmi.NoSuchObjectException: Session has timed out" to know that the > EJB has expired. > > In the interests of tidiness, I am inclined to try to put this test in the > same included file. > > Which is the better design? (A) to make a dummy method "ping()" on my > EJB, and then try to call it inside a try block from the included JSP (= > extra network hit per page view), or (B) make each JSP page which uses the > EJB capable of redirecting to the log-in page if the Exception is thrown > (thus coding the same thing in many places, and potentially introducing > the need to buffer everything, in order to be able to > response.sendRedirect()). > > Or perhaps (C), I'm way off the mark (I'm not using JavaBeans or a taglib > to access the EJB, for example, which might well be the source of my > vexation). > > Opinions, solutions, experiences much appreciated. > > > -- > Thomas Munro <[EMAIL PROTECTED]> "Travelling through hyperspace > http://www.gi-technology.com/ isn't like dusting crops, boy." > GI Technology (Paris) > >
RE: Some issues re: deploying the JPS on another J2EE container
Good Point! > -Original Message- > From: Magnus Stenman [mailto:[EMAIL PROTECTED]] > Sent: Friday, 5 May 2000 9:23 AM > To: Neville Burnell; Orion-Interest > Subject: Re: Some issues re: deploying the JPS on another > J2EE container > > > I wouldnt as vendor X be too proud if it deployed in my > server since what > that implies is missing error checks. > The JPS team has contacted us for details on the buglist and > we're writing > it up now, the count is up to 10 so far, we'll see where it winds up. > Hopefully they'll act swiftly, once they do we'll put up a > detailed doc on > how to install the JPS into Orion. > > Have a nice day! :) > > /Magnus Stenman, the Orion team > > > > Hmmm, > > > > Looks like other J2EE servers, ie iPlanet, can deploy the > JPS. Hopefully > > Orion will be able to claim the same soon. > > > > Regards > > > > Neville Burnell > > Business Manager Software > >
Re: Some issues re: deploying the JPS on another J2EE container
I wouldnt as vendor X be too proud if it deployed in my server since what that implies is missing error checks. The JPS team has contacted us for details on the buglist and we're writing it up now, the count is up to 10 so far, we'll see where it winds up. Hopefully they'll act swiftly, once they do we'll put up a detailed doc on how to install the JPS into Orion. Have a nice day! :) /Magnus Stenman, the Orion team > Hmmm, > > Looks like other J2EE servers, ie iPlanet, can deploy the JPS. Hopefully > Orion will be able to claim the same soon. > > Regards > > Neville Burnell > Business Manager Software
FW: Some issues re: deploying the JPS on another J2EE container
Hmmm, Looks like other J2EE servers, ie iPlanet, can deploy the JPS. Hopefully Orion will be able to claim the same soon. Regards Neville Burnell Business Manager Software -Original Message- From: Inderjeet Singh [mailto:[EMAIL PROTECTED]] Sent: Friday, 5 May 2000 7:12 AM To: [EMAIL PROTECTED] Subject: Re: Some issues re: deploying the JPS on another J2EE container Hi Neville, Many thanks to the Orion team for the bug reports. We will integrate these bug fixes in a future release of Java Pet Store Demo. As the app-server become J2EE complaint, most of these problems will go away. This is already happening, for example, iPlanet' latest release runs JPS without any problems. thanks inder, J2EE Blueprints Neville Burnell wrote: > > FYI notes below. > > Its a real problem that the JavaPetStore 1.0 "j2ee reference app" > will only deploy on the J2EE RI. > > We think it is very important that the JPS will deploy on other J2EE > compliant > servers - after all that is the whole point of J2EE - that app > developers can > "write once, deploy anywhere" - and the JPS & Sun Blueprints are our > training > wheels until we all come up to speed with the technology and can stand > on our > own feet. > > The J2EE RI is a great achievement as a server reference. The JPS needs > work > as an app reference! > > Kind Regards > > Neville Burnell > Business Manager Software > > -Original Message- > From: Magnus Stenman [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, 3 May 2000 8:54 PM > To: Neville Burnell; Orion-Interest > Cc: Orion-Interest > Subject: Re: Orion 1.0 RC 1 released > > Hi, > this is what we found during some inital analasys of the Estore (JPS): > 1. errorpage.jsp does not import java.io (but implicitly uses it). > 2. The web.xml for the web-app has an ejb-ref by the name of > ejb/inventory > which lists inventory as a session while it in fact is an entity. > 3. Internal errors are not logged (swallowed by errorpage and not logged > from there either). Severe bug for paranoid admins (disables the > containers > logging, ie alerting the admin by mail etc). > 4. Internal errors sometimes lead to a simple "the user id is already > taken" > without any hint regarding the real error. > 5. JSP Tags are used to store state outside of their own scope - This is > a > programmer error since tags are usually reused once they're out of scope > (after doEndTag()) so the state will get corrupted. > > Cannot dig deeper at the moment I'm afraid as it'd involve rewriting too > much of the Estore itself (which is not a top priority right now, we > hope > the JPS team fixes these issues by themselves). > > /Magnus Stenman, the Orion team > > - Original Message - > From: "Neville Burnell" <[EMAIL PROTECTED]> > To: "Orion-Interest" <[EMAIL PROTECTED]> > Cc: "Orion-Interest" <[EMAIL PROTECTED]> > Sent: Wednesday, May 03, 2000 1:44 AM > Subject: RE: Orion 1.0 RC 1 released > > > Hi Karl, > > > > Great Stuff. > > > > Now that Orion is RC1 and the JavaPetStore is FCS, could you publish > > instructions on how to deploy the JPS estore.ear on Orion pls? > > > > We have an app developed with the J2EE RI that is based on the JPS and > I > > want to use Orion as our deployment server of choice, but my attempts > to > > get the JPS deployed have Orion failed. > > > > Kind Regards > > > > Neville Burnell > > Business Manager Software > > > > > -Original Message- > > > From: Karl Avedal [mailto:[EMAIL PROTECTED]] > > > Sent: Tuesday, 2 May 2000 10:11 PM > > > To: Orion-Interest > > > Subject: Orion 1.0 RC 1 released > > > > > > > > > We are proud to announce the availablibilty of the first Orion 1.0 > > > Release Candidate. As usual it contains many bug fixes and also many > > > enhancements. A few productivity related improvements worth > mentioning > > > are: > > > > > > Auto-compilation of web-components. Now all web-code will be > > > automatically compiled if development mode is set to true. > > > (http://www.orionserver.com/docs/orion-web.xml.html) shows > > > the location > > > of the development attribute). > > > > > > For example, this means that you can make a servlet, > > > MyServlet.java, put > > > it in the right dir, and the server will automatically pick it up > and > > > compile it. This goes for tag extension libraries, etc. as well. > > > > > > Auto-generation of common custom finders (for CMP beans). If you > have > > > finders called findAll() or findByX() (where X can be anything), the > > > finders will be automatically generated for finding all enties > > > (findAll()) or find the entities matching a specific field-value > > > (findByX()). > > > > > > As some of you might have noticed, Orion now also provide > > > full JSP line > > > information in stack traces and compilation errors. You are not only > > > given the line number for the generted class, but for the actual JSP > > > file. > > > > > > The Orion team > > > > > >
Object-relational mapping
I'm not quite able to figure out the syntax for orion-ejb-jar to map a dependent object list to its own table in a cmp entity. I've read the object/relational documentation carefully :-), but I haven't been able to find the answer. Assume an EJB with a primary key field: key1. Assume further a dependent object with three fields: depKey, field2, and field3. The primary key for the dependent table should be key1 (a migrated key) plus depKey. The closest I can get is something like the following, which gives a correct mapping but incorrectly makes the primary key consist solely of key1 (I've tried a lot of other permutations): Thanks for any help, Dan
RE: Stateful Session timeout, JSPs
I bet you don't really want to have a dummy ping method to burden your server load. If the current implementation will throw java.rmi.NoSuchObjectException when session beans timeout, you could define in your war archive configuration to redirect to a particular page automatically if this error is thrown unhandled. Hence you don't need to remember to put handling code everywhere in your pages. Conrad -Original Message- From: Thomas Munro [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 04, 2000 9:37 AM To: Orion-Interest Subject: Stateful Session timeout, JSPs Hello I have a design question. I have a (1) JSP session which stores a reference to (2) a stateful session EJB. If either times out, I want the user to be bounced to a page where they have to log in (again). The problem is that the JSP session and the session EJB time out under different conditions -- that is to say, merely surfing around the web application will keep the JSP session alive, but the EJB is only kept alive by accessing it, which doesn't necessarily happen on every page. Otherwise, I could simply set the EJB to timeout after a longer time than the JSP session. I have a <%@ include file="/system/bouncer.jsp" %> at the top of all my JSP pages, which tests whether the JSP session has timed out (among other things), and if so, it bounces to the log-in page. However, for the session EJB, I have to catch "java.rmi.NoSuchObjectException: Session has timed out" to know that the EJB has expired. In the interests of tidiness, I am inclined to try to put this test in the same included file. Which is the better design? (A) to make a dummy method "ping()" on my EJB, and then try to call it inside a try block from the included JSP (= extra network hit per page view), or (B) make each JSP page which uses the EJB capable of redirecting to the log-in page if the Exception is thrown (thus coding the same thing in many places, and potentially introducing the need to buffer everything, in order to be able to response.sendRedirect()). Or perhaps (C), I'm way off the mark (I'm not using JavaBeans or a taglib to access the EJB, for example, which might well be the source of my vexation). Opinions, solutions, experiences much appreciated. -- Thomas Munro <[EMAIL PROTECTED]> "Travelling through hyperspace http://www.gi-technology.com/ isn't like dusting crops, boy." GI Technology (Paris)
RE: Stateful Session timeout, JSPs
Hi Thomas, I haven't worked in detail with EJB beans yet, however I am very close. I have used a particular design in a pure JSP/servlet solution. I created a LoginBean that contains the user login information, and id from the database. On top of that I also built in an expiration. This expiration would time out before the bean is timed out. Therefore, when the expiration has passed I can redirect them to the login page, and even reuse the username password to populate the login fields on the jsp page. This also helps with performance because the Login Bean is already created. If they want to login again, I use the same bean, I don't need to create a new instance. I think in your case I would centralize the expiration in one location. Therefore you don't have to worry about synchronization. I would defiantly put in in the servlet session context. I like to think of Servlets/JSP as the front end to an EJB application. The login is a key you use to get into the EJB application, it exists outside the EJB application, therefore I would control it outside the EJB app. I'm interested to know what design you finally choose on. I will have to make the same decision myself. -Steve Rock -Original Message- From: Thomas Munro [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 04, 2000 1:45 PM To: Orion-Interest Subject: Stateful Session timeout, JSPs Hello I have a design question. I have a (1) JSP session which stores a reference to (2) a stateful session EJB. If either times out, I want the user to be bounced to a page where they have to log in (again). The problem is that the JSP session and the session EJB time out under different conditions -- that is to say, merely surfing around the web application will keep the JSP session alive, but the EJB is only kept alive by accessing it, which doesn't necessarily happen on every page. Otherwise, I could simply set the EJB to timeout after a longer time than the JSP session. I have a <%@ include file="/system/bouncer.jsp" %> at the top of all my JSP pages, which tests whether the JSP session has timed out (among other things), and if so, it bounces to the log-in page. However, for the session EJB, I have to catch "java.rmi.NoSuchObjectException: Session has timed out" to know that the EJB has expired. In the interests of tidiness, I am inclined to try to put this test in the same included file. Which is the better design? (A) to make a dummy method "ping()" on my EJB, and then try to call it inside a try block from the included JSP (= extra network hit per page view), or (B) make each JSP page which uses the EJB capable of redirecting to the log-in page if the Exception is thrown (thus coding the same thing in many places, and potentially introducing the need to buffer everything, in order to be able to response.sendRedirect()). Or perhaps (C), I'm way off the mark (I'm not using JavaBeans or a taglib to access the EJB, for example, which might well be the source of my vexation). Opinions, solutions, experiences much appreciated. -- Thomas Munro <[EMAIL PROTECTED]> "Travelling through hyperspace http://www.gi-technology.com/ isn't like dusting crops, boy." GI Technology (Paris)
Stateful Session timeout, JSPs
Hello I have a design question. I have a (1) JSP session which stores a reference to (2) a stateful session EJB. If either times out, I want the user to be bounced to a page where they have to log in (again). The problem is that the JSP session and the session EJB time out under different conditions -- that is to say, merely surfing around the web application will keep the JSP session alive, but the EJB is only kept alive by accessing it, which doesn't necessarily happen on every page. Otherwise, I could simply set the EJB to timeout after a longer time than the JSP session. I have a <%@ include file="/system/bouncer.jsp" %> at the top of all my JSP pages, which tests whether the JSP session has timed out (among other things), and if so, it bounces to the log-in page. However, for the session EJB, I have to catch "java.rmi.NoSuchObjectException: Session has timed out" to know that the EJB has expired. In the interests of tidiness, I am inclined to try to put this test in the same included file. Which is the better design? (A) to make a dummy method "ping()" on my EJB, and then try to call it inside a try block from the included JSP (= extra network hit per page view), or (B) make each JSP page which uses the EJB capable of redirecting to the log-in page if the Exception is thrown (thus coding the same thing in many places, and potentially introducing the need to buffer everything, in order to be able to response.sendRedirect()). Or perhaps (C), I'm way off the mark (I'm not using JavaBeans or a taglib to access the EJB, for example, which might well be the source of my vexation). Opinions, solutions, experiences much appreciated. -- Thomas Munro <[EMAIL PROTECTED]> "Travelling through hyperspace http://www.gi-technology.com/ isn't like dusting crops, boy." GI Technology (Paris)
EJB Deployment in Orion
Hi all, Since Assembly of component is not a problem (other tools like J2EE deplytool exist), my main problem is for deploying applications in Orion. I can install applications (ear) but, How can access them ? In J2EE, in the deployment phase, a Client.jar file is generated that enables your standalone application access and test EJBs. Now I can only create servlets (WAR components) that access these EJBs. Could you give a simple example of the deployment of a EJB (using files)? How do you generate the client jar file ? Can I use the client jar generated by the J2EE ? Thank you in advance.
Problem with orion.jar and servlet.jar
Hi All, I keep all my J2EE java .jar files under jdk1.2.2/jre/lib/ext/, including the newest servlet sdk 2.2. I just downloaded it twice from java.sun.com. However, whenever I have the servlet.jar in this directory, the Orion server won't start. It gives me the error: Servlet API version 2.2 or greater required. orion.jar contains the Servlet 2.2 API but a case of library shadowing has been detected. Remove any potential old/offending libraries from the classpath and retry. The offending library resides at: file:/E:/jdk1.2.2/jre/lib/ext/servlet.jar If I remove the servlet.jar, then the Orion server can start. Why is this jar file giving me problems, if it's the correct version. I would like to keep the servlet.jar file in the jdk1.2.2 subfolder so when I do my programming, my IDE can find the servlet api and compile my classes properly. Any comments are appreciated. Steven Rock
how do you shut down the server?
The documentation doesn't appear to say how to shut down the server. Following the 'Usage' statement that was printed when I typed 'java -jar shutdown.jar', I tried this: java -jar shutdown.jar ormi://localhost admin pentacom restart And got this: Error: com.evermind.reflect.UndeclaredExceptionTypeException: java.lang.ClassNotFoundException Then, following the 'Usage' statement that was printed when I typed 'java -jar admin.jar', I tried this: java -jar admin.jar ormi://localhost admin pentacom -shutdown And got this: Error: com.evermind.reflect.UndeclaredExceptionTypeException: java.lang.ClassNotFoundException Benjamin Geer __ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/
Enhydra/XMLC 3.0.1 works with Orion
Applying some patches to the xerces version (1.0.3) included in orion is possible to use the Enhydra/XMLC 3.0.1 compiler. For people who don't know it, XMLC is an elegant solution (better than JSP on my opinion) to separate HTML/XML from java code. If you are interested I can send you details on how to use XMLC in orion. Luciano
