[JBoss JIRA] Created: (JBCLUSTER-145) Addd session passivation docs
by Hany Mesha (JIRA)
Addd session passivation docs
-----------------------------
Key: JBCLUSTER-145
URL: http://jira.jboss.com/jira/browse/JBCLUSTER-145
Project: JBoss Clustering
Issue Type: Task
Security Level: Public (Everyone can see)
Affects Versions: Q3Y6
Reporter: Hany Mesha
Assigned To: Hany Mesha
Fix For: Q3Y6
Add session passivation docs to the AS Guide. The docs will include introduction to session passivation for http session replication and how to enable session passivation. Conditions and limition on the cache configuration with session passivation such as cache loader store should always be non-sharable among cluster nodes. Also a wiki page to explain session passivation for http session replication and FAQs
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 6 months
[JBoss JIRA] Created: (JBCACHE-824) Don't call Channel.getView() in viewAccepted() callback
by Brian Stansberry (JIRA)
Don't call Channel.getView() in viewAccepted() callback
-------------------------------------------------------
Key: JBCACHE-824
URL: http://jira.jboss.com/jira/browse/JBCACHE-824
Project: JBoss Cache
Issue Type: Task
Security Level: Public (Everyone can see)
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: 1.4.1.GA, 2.0.0.GA
In the viewAccepted() callback we call determineCoordinator(), which in turn calls Channel.getView(). This is wacky, since viewAccepted() is passed the view and thus can directly determine if the node is coordinator. The call into Channel.getView() forces an ugly workaround in JChannel (see internal comments in JChannel in release 2.4).
While fixing this I'll tighten up how the determination of the coordinator works outside of viewAccepted. Get rid of Channel.getView() call. Basically if we haven't gotten a view wait on the members field, and when notified by viewAccepted() determine if coord based on the members field.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 6 months
[JBoss JIRA] Created: (JASSIST-23) Java 2 Security ProtiectionDomain is not associated with new generated classes
by Renat Zubairov (JIRA)
Java 2 Security ProtiectionDomain is not associated with new generated classes
------------------------------------------------------------------------------
Key: JASSIST-23
URL: http://jira.jboss.com/jira/browse/JASSIST-23
Project: Javassist
Issue Type: Bug
Environment: IBM WebSphere 5.1 with J2EE Security ON, Javassist 3.0, Tapestry 4.1, HiveMind 1.1.1
Reporter: Renat Zubairov
Assigned To: Shigeru Chiba
Priority: Blocker
Attachments: exception.txt
Classes that are generated using Javassist have no associated protection domain therefore it is not possible for JVM to assign permissions based on the static JAR files names, this is severe problem because it is not possible to grant permissions, hence all permissions are vorbidden, since that nothing works.
Javassist is used by HiveMind to generate proxy classes for it's services, an see the stack trace (in attachment) the generated classes can't be associated with any ProtectionDomain, therefore
_any Javassist supported application is impossble to start under strict security in Java_.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 6 months
[JBoss JIRA] Created: (JBPORTAL-1082) Unable to edit properties of portlet instances that ship with Portal
by Peter Johnson (JIRA)
Unable to edit properties of portlet instances that ship with Portal
--------------------------------------------------------------------
Key: JBPORTAL-1082
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1082
Project: JBoss Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Portal Core
Affects Versions: 2.4 Final
Environment: Windows XP, MySQL 5.0 & PostgreSQL 8.1., JBossAS 4.0.4GA
Reporter: Peter Johnson
Assigned To: Julien Viet
Fix For: 2.4.1 Final, 2.6.Alpha1
Back in 2.4.0CR3, I was able to create a new instance of the CMSPortlet and set the indexPage preference to some other html page.
With 2.4.0GA, and what I loaded from CVS this morning, I can no longer do this. Instead, when I click the Update button after entering in the new html page name, such as /deafult/project.html, I get a huge stack trace.
I cannot change the preferences on any of the portlets that ship with the portal. Even if I create new instances. I tried changing a preference for the weather portlet and got the same error.
In 2.4.0.CR3, the compoundPortletId for the CMS portlet was local._1 and for the weather portlet was local._9. In 2.4.0.GA, the componentPortletIds are local.portal.CMSPortlet and local.samples.WeatherPortlet. The StatefulPortletInvoker.setProperties method throws an exception if the simple portletId does not start with an underscore.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 6 months