struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joseph Barefoot" <jose...@hereuare.com>
Subject RE: Please help clarify or confirm -- HttpSession
Date Thu, 13 Jun 2002 19:10:46 GMT
They have a very open license too.  You can redistribute JBoss however you
want, pretty much, as long as you leave it intact (i.e., you can't hack out
bits of it and incorporate into your own software, ala Microsoft)  It also
fully implements the EJB 2.0 specification, with message-driven beans, local
interfaces, etc.

Finally, it supports deployement of 'vanilla' EJB jars, i.e., you don't have
to put a propietary deployment descriptor (although there is an optional
one) into the jar, and you don't have to run some tool on it before
deployment (e.g. ejbc in Weblogic).  It uses a very clever class byte
generation mechanism (for stub/skeleton classes) to accomplish super-fast
hot deployment and un-deployment.

I give it a thumbs up. :)

> -----Original Message-----
> From: Jerry Jalenak [mailto:Jerry.Jalenak@LABONE.com]
> Sent: Thursday, June 13, 2002 11:54 AM
> To: 'Struts Users Mailing List'; 'jerome.jacobsen@gentootech.com'
> Subject: RE: Please help clarify or confirm -- HttpSession
>
>
> Free?  Didn't realize that......
>
> -----Original Message-----
> From: Jerome Jacobsen [mailto:jerome.jacobsen@gentootech.com]
> Sent: Thursday, June 13, 2002 1:50 PM
> To: Struts Users Mailing List
> Subject: RE: Please help clarify or confirm -- HttpSession
>
>
> Huh?  JBoss is FREE.
>
> -----Original Message-----
> From: Jerry Jalenak [mailto:Jerry.Jalenak@LABONE.com]
> Sent: Thursday, June 13, 2002 2:41 PM
> 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: Kevin.Bedell@sunlife.com [mailto:Kevin.Bedell@sunlife.com]
> 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" <josephb@hereuare.com> on 06/13/2002 02:09:43 PM
>
> Please respond to "Struts Users Mailing List"
>       <struts-user@jakarta.apache.org>
>
> To:   "Struts Users Mailing List" <struts-user@jakarta.apache.org>
> 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: Kevin.Bedell@sunlife.com [mailto:Kevin.Bedell@sunlife.com]
> > 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" <Jerry.Jalenak@LABONE.com> on 06/13/2002 01:43:50 PM
> >
> > Please respond to "Struts Users Mailing List"
> >       <struts-user@jakarta.apache.org>
> >
> > To:   "'Struts Users Mailing List'" <struts-user@jakarta.apache.org>
> > 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:b7st@yahoo.fr]
> > 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" <Tony.Yuan@cingular.com> 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:struts-user-unsubscribe@jakarta.apache.org>
> > > For additional commands, e-mail:
> > > <mailto:struts-user-help@jakarta.apache.org>
> > >
> >
> > ___________________________________________________________
> > Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
> > Yahoo! Mail : http://fr.mail.yahoo.com
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:struts-user-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> > <mailto:struts-user-help@jakarta.apache.org>
> >
> >
> > 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:struts-user-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail: <
> > mailto:struts-user-help@jakarta.apache.org>
> >
> >
> >
> >
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:struts-user-help@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:   <
> mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <
> mailto:struts-user-help@jakarta.apache.org>
>
>
>
>
>
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:struts-user-help@jakarta.apache.org>
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:struts-user-help@jakarta.apache.org>
>
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:struts-user-help@jakarta.apache.org>
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:struts-user-help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message