SPNEGO SSO implementation for gatein tomcat packaging
by Tuyen The Nguyen
Hi all,
We are trying to make SPNEGO SSO work on gatein tomcat packaging.
Unfortunately, current spnego sso implementation of gatein only works on
jboss because it use Jboss Negotiation library - a specific library for
jboss.
So, i provide other spnego implementation for gatein tomcat packaging at
https://github.com/nttuyen/gatein-spnego, this implementation works as an
extension and i tested it on master and 3.7.x branch.
If there some one can review and have any feedback, i would appreciate.
Btw, is there any idea about where this implementation should be in gatein
codebase?
Thanks!
TuyenNT.
10 years, 7 months
GTNPORTAL-3500: testMemoryLeakWithMultiThread fails sometimes
by Peter Palaga
Hi Minh, I hope, you are still a part of the team?
This happened to me and other JBoss Portal devs and testers several
times recently. From quickly looking at the test, I was not able to
tell, what is wrong: (a) the test or (b) the DownloadService has leaks.
Could you please have a look?
Here are the detais:
https://issues.jboss.org/browse/GTNPORTAL-3500
org.exoplatform.download.TestDownloadService.testMemoryLeakWithMultiThread()
fails in some cases. The stack trace:
junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:48)
at junit.framework.Assert.assertTrue(Assert.java:20)
at junit.framework.Assert.assertTrue(Assert.java:27)
at
org.exoplatform.download.TestDownloadService.testMemoryLeakWithMultiThread(TestDownloadService.java:109)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
...
The line where it fails is
assertTrue(cache.getCacheSize() <= 10);
Version-Release number of selected component (if applicable):
GateIn 3.8.x or 3.9.x
Reproducible sometimes: 1/10 or even less. Happens both on Jenkins and
desktop.
Steps to Reproduce:
Not sure. It happens randomly. Perhaps overloading the machine with some
CPU-intensive task might help. Just build the
exo.portal.component.web.server artifact with tests repeatedly until it
fails.
Actual results:
Test fails
Expected results:
Not sure if the subject under the test is broken or the test itself.
Thanks,
Peter
10 years, 7 months
Request for review: Loading AMD JavaScript and CSS from a CDN
by Peter Palaga
Hi *,
could you please have a look at this pull request (the last two commits)?
https://github.com/gatein/gatein-portal/pull/863
A quickstart using the new feature can be found in this branch:
https://github.com/ppalaga/arcgis-gears-portlet/tree/GTNPORTAL-3485
We would like to include this in a milestone that we need to tag by
Thursday, 2014-05-29 EoD. So, please comment before that date if possible.
Esp. your comments are welcome on this topic:
Within JBoss Portal team, we have been discussing what should happen, if
an application wants to add a path mapping that is available in the
portal already.
Example:
* An application app.war wants to register the AMD module ID prefix
"dojo" to be mapped to "http://fastcdn.com/dojo/1.7.0".
* But the prefix "dojo" was registered already for
"http://othercdn.com/dojo/1.9.1" by some other application.
* What should the portal do upon a deployment of app.war?
In the present proposal, the solution is (A) to warn and ignore such
prefixes in new deployments.
The problem with (A) is clearly that although app.war requires dojo
1.7.0, it may get something wholly different and there is no guarantee
that the app will work with a path mapping that it has not provided itself.
After some discussion, we came to a conclusion, that (B) rejecting the
whole deployment would be a cleaner solution. I was not able to find a
way how I could cause the whole deployment to fail cleanly from the
context of PortalContainerPostInitTask.execute() [1]. There are no
checked exceptions defined for PortalContainerPostInitTask.execute(). I
have not tried to throw a RuntimeException, but I do not believe that
would cleanly reject the whole deployment.
Any ideas how to reach (B)?
[1]
https://github.com/ppalaga/gatein-portal/blob/GTNPORTAL-3485.1/component/...
Thanks,
Peter
10 years, 7 months
Request for review: GTNPORTAL-3459 Permissions Move Apps, Move Containers are not inherited to a newly created page
by Peter Palaga
Hi *,
from my PoV this is a follow up of GTNPORTAL-3364 "Implement UI part for
Restricted layout setting" done by nttuyen.
The present issue:
https://issues.jboss.org/browse/GTNPORTAL-3459
When creating new portal site, there are 4 permissions to set - Access,
Edit, Move Apps, Move Containers. When I create new portal and set some
permissions, then create new page in this portal, the owner of the new
page is the newly created portal, and Access and Edit permissions are
inherited or "copied" into the permissions of the new page. But Move
Apps, Move Containers permissions are set to "Everyone". This
permissions should probably also inherit the permissions from the owning
portal.
Steps to reproduce:
1. Create new portal site, set some permissions
2. Go to this new portal site, create new page. On the 3rd step of
creating the page, in View Page Properties, Permissions tab are
inherited only Access and Edit permissions.
Could you please review my fix?
https://github.com/gatein/gatein-portal/pull/841
Thanks,
Peter
10 years, 8 months
