I would have tried clustering by using the interface
javax.servlet.http.HttpSessionActivatiionListener in which you have a method :
sessionDidActivate(HttpSessionEvent se)
this method is called whenever you fail over another node and the servlet
container deserialize your http session coming
the SFSB is a good idea except JNDI.
JNDI is not meant to scale according to your user number. In addition when a
statefull bean is evicted it would not be unbound from the JNDI tree and you
would have to make some garbage by yourself.
Try with JBoss treecache which can be either replicated
I have come up with a approach for communication between portlet applications
and I would like to get some feedback. My requirements are:
* a session that is visible across portlet applications
* an approach that will work well in a clustered environment (Julian, I
couldn't easily see how to
Thanks Julien. I'll send you my email address. I also have a follow up
question that I thought would be good to have on the forum. Will you take this
capability in to account as you test the JBoss Portal in a cluster? Thanks for
the assistance.
View the original post :
my current try is not for cluster, but could be adapted I think.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3873331#3873331
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3873331
If you have some ideas on an approach, we would be happy to do some of the work.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=387#387
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=387
I have two Portlet Applications in two separate .war files. I need to set a
user session variable in one Portlet Application and then read it in the second
application. Per the Portlet Spec this does not work using
PortletSession session = request.getPortletSession();
|
you can try to use a static map where you key objects with session ID because
they will be the same. Of course you need an eviction mechanism to remove the
expired objects.
I have some prototype sitting in my intellij projects, send me an email if you
want me to send you the code.
View the
I did some testing with JBoss Portal Beta 1 and JBoss AS 4.0.2RC1 and the HTTP
Session and Portlet Session were being handled correctly per the Portlet spec.
I did have to add crossContext=true to each of the context.xml files (portal
core and portlets). I understand that you won't need to do
what do you call inter portlet communication ?
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3871944#3871944
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3871944
---
SF
I'd like to be able to deploy a configuration with the HTTPSession and
PortletSession working as Julien describes above. Today, I built the latest
version of JBossAS from the cvs head (5.0.0alpha), and followed the deployment
instructions on the WIKI. I did copy the jgroups.jar and the
no they don't share it, they only have the jessionid in common.
that enables to have the same session wether you access the webapp by request
dispatch from the portal or directly for the browser.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3867735#3867735
this is a tricky issue :-) and has been solved recently.
there have been a lot of discussions about this and the solution today is : use
jboss 4 head with tomcat 5.5.8
what is does is pretty simple, all web apps share the same JSESSIONID which is
issues under /, this is achieved in tomcat with
btw this is what the spec mandates :-)
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3867677#3867677
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3867677
---
SF email
ok, there is only one more question for me then:
if all portlet apps share the same JSESSIONID , do they also share the same
HttpSession ? I beliefe they shouldn't . If I remember correctly then the J2EE
spec requires every context (WAR) to have it's own session for the same
JSESSIONID, with
15 matches
Mail list logo
