JBoss has a release version with bundled Tomcat that will auto-deploy an EAR -- splits the wars to the Tomcat container, ejb jars to the JBoss container. They have quite a hefty support mailing list as well, although I am currently not on it.
> -----Original Message----- > From: Jerry Jalenak [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 13, 2002 11:41 AM > To: 'Struts Users Mailing List' > Subject: RE: Please help clarify or confirm -- HttpSession > > > Kevin, > > I actually thought about the EJB solution, but we are trying to do this on > the cheap without having to buy an EJB container (i.e. JBOSS). > Something I > was wondering about though - is it possible to run an EAR structure under > Tomcat? I'm not very familiar with EJB, so forgive me if I sound stupid > here, but is it possible to create a pseudo-J2EE environment and create an > Entity-Bean that can do this? > > The XML-Soap solution also is appealing, but we would like to be able to > integrate these various app's with a minimum of re-write. > > Jerry > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 13, 2002 1:18 PM > To: Struts Users Mailing List > Subject: RE: Please help clarify or confirm -- HttpSession > > > > The container makes sure that Session ID's are unique. It sets the cookie > as well - nothing in the webapp has to do this. This is just how the > containers work. > > Regarding storing "objects from webapp A in a shared classloader class > keyed by the sessionID and retrieve them from > webapp B". > > First, you can't physically store an object in another webapp because the > memory spaces are isolated from each other. Second, having common > directories on the two CLASSPATHS for the two webapps allows you to load > CLASSES to create new objects, but not to share the objects once they are > created. > > But there are ways to share objects (in addition to classes) between > webapps. And at times there may be good reasons to do so. > > For example, imagine you have an object representing a transaction to be > executed on your system (maybe a stock trade). What if: > > - The user who entered the transaction wants to see its real-time status. > - A trader who is going to execute the transaction needs to see it, and > - An auditor needs to monitor all trades currently in the system. > > Imagine also you want them to use three seperate webapps (or non-servlet > applications) to do their work. While not the only approach, it > is possible > to have all access the same physical Java object. Here are some ways: > > 1. Implement the Object as an Entity EJB in an EJB container such > as JBOSS. > Have all the webapps (or whatever) connect to the same EJB Container > instance and manipulate the data in the object. The EJB container will > manage locking and transactional integrity for you as well. > > 2. Create the object as a singleton in some JVM somewhere and wrap an RMI > server around it. This is basically a hack, but I saw it done > once to allow > clustered applications to share Properties objects between them (ensuring > they were all using the same Properties). (And, yes - it was a pain.) > > 3. Put the object behind a web service and access it via SOAP. This allows > some of the clients to be non-Java. > > All these solutions are based on putting the object in some place OUTSIDE > any of the individual webapps. > > > > > > > > > > > > > > > > > > > > "Joseph Barefoot" <[EMAIL PROTECTED]> on 06/13/2002 02:09:43 PM > > Please respond to "Struts Users Mailing List" > <[EMAIL PROTECTED]> > > To: "Struts Users Mailing List" <[EMAIL PROTECTED]> > cc: (bcc: Kevin Bedell/Systems/USHO/SunLife) > Subject: RE: Please help clarify or confirm -- HttpSession > > > hmmm...but the sessionIDs have to be unique, even across web apps., > correct? > If there weren't unique, URL rewriting would not work correctly if two > users > using two webapps on the same app. server happened to get the same session > ID. Therefore, one *should* be able to store objects from webapp A in a > shared classloader class keyed by the sessionID and retrieve them from > webapp B. > > Am I missing something here? (besides why the hell you would want to do > this) > :) > > > joe > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, June 13, 2002 10:46 AM > > To: Struts Users Mailing List > > Subject: RE: Please help clarify or confirm -- HttpSession > > > > > > > > In general, there is no way session info from one webapp can be made > > visible to other webapps. Some details of this may vary > depending on your > > app server. > > > > Sessions are controlled by cookies being set on the client. The > "cookies" > > that are set by each webapp are scoped for that webapp only. As > > an example, > > create the following .jsp file and name it session.jsp. Put it in > > "webapp1" > > > > <html> > > <head> > > <title>Testing Session Management</title> > > </head> > > <body> > > <% out.print("Session ID = " + request.getSession().getId() ); %> > > </body> > > </html> > > > > > > > > Then, if you were to do a low-level http request from the server, > > you'd see > > something like: > > > > > > bash-2.05$ ./telnet -E localhost 8080 [ <-- I type ] > > Trying 127.0.0.1... > > Connected to localhost. > > Escape character is 'off'. > > > > GET /webapp1/session.jsp HTTP/1.0 [ <-- I type ] > > > > HTTP/1.1 200 OK > > Content-Type: text/html;charset=ISO-8859-1 > > Date: Wed, 12 Jun 2002 00:39:49 GMT > > Server: Apache Tomcat/4.0.3 (HTTP/1.1 Connector) > > Connection: close > > Set-Cookie: JSESSIONID=AC75B22FD1D283D1CEF0136928110679;Path=/webapp1 > > > > <html> > > <head> > > <title>Testing Session Management</title> > > </head> > > <body> > > Session ID = AC75B22FD1D283D1CEF0136928110679 > > </body> > > </html> > > > > Connection closed by foreign host. > > bash-2.05$ > > > > > > The JSESSIONID cookie is used by the servlet container to > manage the user > > session. > > > > > > Notice that the the scope of the JSESSIONID Cookie in this example is > > limited to the '/webapp1' web application. So even if you have many web > > applications (or Struts applications) deployed in a servlet container, > > session tracking is isolated between them. > > > > > > > > <ShamelessPlug> > > I'll be covering topics such as this and others in my upcoming book > > "Struts: Rapid Working Knowledge" to be published by SAMS later this > year. > > </ShamelessPlug> > > > > > > HTH, > > > > Kevin > > > > > > > > > > > > "Jerry Jalenak" <[EMAIL PROTECTED]> on 06/13/2002 01:43:50 PM > > > > Please respond to "Struts Users Mailing List" > > <[EMAIL PROTECTED]> > > > > To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> > > cc: (bcc: Kevin Bedell/Systems/USHO/SunLife) > > Subject: RE: Please help clarify or confirm -- HttpSession > > > > > > This is something I've wondered about, especially in a team development > > environment where there are several programmers working on different > > webapps > > that need to share a common framework - in other words, something like > > this: > > > > Tomcat\webapps > > framework-application > > WEB-INF > > ... > > webapplication_1 > > WEB-INF > > ... > > webapplication_2 > > WEB-INF > > ... > > etc etc etc > > > > Can the classes in webapplication_1 'see' session data that was > > created and > > stored in the session by the framework-application? > > > > Jerry > > > > -----Original Message----- > > From: emmanuel.boudrant [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, June 13, 2002 12:39 PM > > To: Struts Users Mailing List > > Subject: Re: Please help clarify or confirm -- HttpSession > > > > > > > > At my knowledge, under tomcat each webapp have his own > > "memory space" so you can't share HttpSession between > > 2 webapp. You can share object between 2 webapp with > > one condition, the class to be shared must be loaded > > in same ClassLoader. > > > > > > Did you understand my english ;) > > > > -Emmanuel > > > > > > > > --- "Yuan, Tony" <[EMAIL PROTECTED]> a écrit : > > > Hi Guys, > > > Can anyone help clarify or confirm the relationship > > > between an HttpSession > > > and a web application? I mean, can two WAR (two > > > application) share one > > > common HttpSession and whatever resource this > > > HttpSession contains? > > > > > > My understanding is that if WARs are deployed > > > separately, then there will be > > > different HttpSessions and therefore you can not > > > share resources among them. > > > Can anyone help confirm this? or correct if I am > > > wrong? > > > > > > Thanks! > > > > > > > > > -- > > > To unsubscribe, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > > > > > ___________________________________________________________ > > Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! > > Yahoo! Mail : http://fr.mail.yahoo.com > > > > -- > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > This transmission (and any information attached to it) may be > confidential > > and is intended solely for the use of the individual or entity to which > it > > is addressed. If you are not the intended recipient or the person > > responsible for delivering the transmission to the intended > recipient, be > > advised that you have received this transmission in error and > > that any use, > > dissemination, forwarding, printing, or copying of this information is > > strictly prohibited. If you have received this transmission in error, > > please immediately notify LabOne at (800)388-4675. > > > > > > > > -- > > To unsubscribe, e-mail: < > > mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: < > > mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: < > mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: < > mailto:[EMAIL PROTECTED]> > > > > > > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
