[Design of JBoss Portal] - Re: shared state between HttpSession and PortletSession
Julien@Jboss.Com 12 April 2005 13:35:10
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 the attribute useEmptyPath="true" on the connector which should be the default today in jboss 4 head.
the other solution is to use stateless link, i.e put in your link to the servlet enough info to recreate the context for the content it must produce.
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
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 the exception of WARs that are packaged inside the same EAR. Those do share the same HttpSession and JSESSIONID
....but my memory might fail me, it's done it before ....
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
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 jboss-cache.jar from the all/lib to the default/lib. I'm using JDK 1.4.2_06. I am also using the beta2b1 binary release of the portal. The error stack trace I am getting is below. It looks like an incompatibility with interceptors?
Can you give me some guidance on what I should try? If you know of a configuration that will support the HTTPSession and PortletSession requirements per the Portlet spec, I am happy to try that configuration (JBossAS and Portal versions?).
Thanks, Doug
17:03:26,401 INFO [WrapperDataSourceService] Bound connection factory for resource adapter for ConnectionManager 'jboss.jca:name=PortalDS,service=DataSourceBinding to JNDI name 'j vaortalDS' 17:03:26,401 ERROR [UserModuleImpl] Starting failed portal:service=Module,type=User javax.naming.NameNotFoundException: portal not bound at org.jnp.server.NamingServer.getBinding(NamingServer.java:491) at org.jnp.server.NamingServer.getBinding(NamingServer.java:499) at org.jnp.server.NamingServer.getObject(NamingServer.java:505) at org.jnp.server.NamingServer.rebind(NamingServer.java:147) at org.jnp.interfaces.NamingContext.rebind(NamingContext.java:495) at org.jnp.interfaces.NamingContext.rebind(NamingContext.java:462) at javax.naming.InitialContext.rebind(InitialContext.java:363) at org.jboss.naming.NonSerializableFactory.rebind(NonSerializableFactory.java:165) at org.jboss.portal.core.modules.AbstractModule.startService(AbstractModule.java:45) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:271) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:172)
17:03:26,401 INFO [WrapperDataSourceService] Bound connection factory for resource adapter for ConnectionManager 'jboss.jca:name=PortalDS,service=DataSourceBinding to JNDI name 'j vaortalDS' 17:03:26,401 ERROR [UserModuleImpl] Starting failed portal:service=Module,type=User javax.naming.NameNotFoundException: portal not bound at org.jnp.server.NamingServer.getBinding(NamingServer.java:491) at org.jnp.server.NamingServer.getBinding(NamingServer.java:499) at org.jnp.server.NamingServer.getObject(NamingServer.java:505) at org.jnp.server.NamingServer.rebind(NamingServer.java:147) at org.jnp.interfaces.NamingContext.rebind(NamingContext.java:495) at org.jnp.interfaces.NamingContext.rebind(NamingContext.java:462) at javax.naming.InitialContext.rebind(InitialContext.java:363) at org.jboss.naming.NonSerializableFactory.rebind(NonSerializableFactory.java:165) at org.jboss.portal.core.modules.AbstractModule.startService(AbstractModule.java:45) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:271) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:172)
17:04:12,868 INFO [PortletContainer] Created portlet object org.jboss.portal.core.portlet.test.TestPortlet 17:04:12,868 INFO [TestPortlet] failed 17:04:12,888 ERROR [ServerManagerImpl] An error occured org.jboss.portal.server.kernel.ServiceFailureException: java.lang.Exception: The portlet threw a portlet exception during init at org.jboss.portal.server.kernel.UpgradeMethod.invoke(UpgradeMethod.java:58) at org.jboss.portal.server.kernel.Kernel.start(Kernel.java:382) at org.jboss.portal.server.impl.ServerManagerImpl.install(ServerManagerImpl.java:442) at org.jboss.portal.server.impl.ServerManagerImpl.deploy(ServerManagerImpl.java:362) at org.jboss.portal.server.impl.ServerManagerImpl.deploy(ServerManagerImpl.java:373) at org.jboss.portal.server.impl.ServerManagerImpl.deploy(ServerManagerImpl.java:373) at org.jboss.portal.server.impl.ServerManagerImpl.deploy(ServerManagerImpl.java:340) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:144)
------------------------------------------------------- This SF.net email is sponsored by: 2005 Windows Mobile Application Contest Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones for the chance to win $25,000 and application distribution. Enter today at http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click
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 this after the next release of the JBoss AS 4.0.2. Has anyone looked at an approach for intra portlet communication across portlet applications? I have a requirement for this that will work well in a clustered environment.
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
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(); | session.setAttribute("User Variable", myUserVar, PortletSession.APPLICATION_SCOPE);
So if you can't do it using the PortletSession, then what is the best way to do this (based on your best practices ).
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
Julien@Jboss.Com 9 April 2005 01:48:41 [ permanent link ]
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.
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
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.
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
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 extend a static map so I started down an alternate path)
What I plan to do is create a Stateful Session Bean for each active user during login. When the Session Bean is first created, I will put the remote reference in the JBoss naming directory using the user's ID as the key. Portlets that need to read or update attributes that cross portlet applications will lookup the remote reference using JNDI and interact with the user's instance of the Session Bean. I believe this approach will behave well in a cluster since JNDI and Stateful Session Beans are well supported in a JBoss AS cluster, right?
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
Julien@Jboss.Com 12 April 2005 13:35:10 [ permanent link ]
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 or local, using the user ID as key. You can specific an eviction policy and it can be replicated. And actually now http session replication is using treecache to replicate its session (JBossCacheSessionManager).
"schnelzer" wrote : 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 extend a static map so I started down an alternate path) | | | What I plan to do is create a Stateful Session Bean for each active user during login. When the Session Bean is first created, I will put the remote reference in the JBoss naming directory using the user's ID as the key. Portlets that need to read or update attributes that cross portlet applications will lookup the remote reference using JNDI and interact with the user's instance of the Session Bean. I believe this approach will behave well in a cluster since JNDI and Stateful Session Beans are well supported in a JBoss AS cluster, right? | | Any feedback is appreciated.
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
![[Design of JBoss Portal] - Re: shared state between HttpSession and PortletSession](http://qaix.com/i/logo_new.gif){kind=logo}
