Intellij license
by Julien Viet
It should expire next week.
I asked for a one year renewal.
I'll keep you informed.
Julien
12 years, 6 months
Re: [gatein-dev] PortalClusteredSSOSupportValve issue in Tomcat
by Sơn Trần
I have tested branch 'sso-valve' of Marek Posolda. It worked fine for
Tomcat version 7.32 and PortalClusteredSSOSupportValve wasn't available on
classpath with Tomcat packaging.
2013/3/26 Son Trong Tran <sontt(a)exoplatform.com>
>
>
> ---------- Forwarded message ----------
> From: Trong Tran <trongtt(a)gmail.com>
> Date: Tue, Mar 26, 2013 at 9:42 AM
> Subject: Fwd: [gatein-dev] PortalClusteredSSOSupportValve issue in Tomcat
> To: sontt(a)exoplatform.com
>
>
>
>
> ---------- Forwarded message ----------
> From: Marek Posolda <mposolda(a)redhat.com>
> Date: 25 March 2013 20:33
> Subject: Re: [gatein-dev] PortalClusteredSSOSupportValve issue in Tomcat
> To: Julien Viet <julien(a)julienviet.com>
> Cc: Trong Tran <trongtt(a)gmail.com>, "gatein-dev(a)lists.jboss.org" <
> gatein-dev(a)lists.jboss.org>
>
>
> I've created jira https://issues.jboss.org/browse/GTNPORTAL-2859 and I
> have fix available in branch
> https://github.com/mposolda/gatein-portal/tree/sso-valve . It's adding
> new module security-jboss, which is deployed only in JBoss but on Tomcat.
> So PortalClusteredSSOSupportValve is not available on classpath on Tomcat
> anymore.
>
> Could you please check it with your Spring application? I will send PR
> once confirmed from you that it works.
>
> Thanks,
> Marek
>
>
> On 19/03/13 08:22, Julien Viet wrote:
>
>
> http://static.springsource.org/spring/docs/3.0.0.M3/reference/html/ch04s1...
>
> On Mar 19, 2013, at 4:29 AM, Trong Tran <trongtt(a)gmail.com><trongtt(a)gmail.com>wrote:
>
> Yes, that was just a way to reproduce the issue.
>
> About the real usecase that Hoang has reported, it is a Spring 3.x web
> app. For a certain reason, Spring auto scans all Valves which causes the
> issue.
>
> On 18 March 2013 23:28, Julien Viet <julien(a)julienviet.com> wrote:
>
>> I think it was just a way to reproduce the issue and Trong does not want
>> to use the PortalClusteredSSOSupportValve in Tomcat :-)
>>
>> On Mar 18, 2013, at 5:14 PM, Marek Posolda <mposolda(a)redhat.com> wrote:
>>
>> Hi Trong,
>>
>> Notes inline.
>>
>> On 18/03/13 12:25, Trong Tran wrote:
>>
>> Hi,
>>
>> We can easily reproduce the problem in Tomcat by just reference the
>> PortalClusteredSSOSupportValve class in a Servlet Context listener of a web
>> app, to load it.
>>
>> yes, I am able to reproduce it with Servlet Context listener. But I am
>> still not sure if I understand the usecase. Why you need to access
>> PortalClusteredSSOSupportValve from some Servlet Context listener on
>> Tomcat? Thing is that PortalClusteredSSOSupportValve is meant to be used
>> only in JBoss because it uses JBoss specific clustered SSO valve. It does
>> not makes sense to use it in Tomcat.
>>
>> And it seems that moving PortalClusteredSSOSupportValve to
>> packaging/jboss7 won't solve your issue, because than you won't be able to
>> compile your listener anyway because PortalClusteredSSOSupportValve won't
>> be available. But maybe I still don't uderstand the usecase...
>>
>>
>>
>> I am able to have listener on Tomcat with code like this and it works
>> without throwing error:
>>
>> public class PortalSSOValveListener implements ServletContextListener {
>>
>> ValveBase portalClusteredSSOSupportValve;
>>
>> public void contextInitialized(ServletContextEvent sce) {
>>
>> if (new J2EEServerInfo().isJBoss()) {
>> PortalClusteredSSOSupportValve casted =
>> (PortalClusteredSSOSupportValve)portalClusteredSSOSupportValve;
>> // Do something with the valve
>> }
>> }
>>
>> public void contextDestroyed(ServletContextEvent sce) {
>> }
>>
>> private ValveBase findValve() {
>> // TODO: Find valve somehow...
>> return null;
>> }
>> }
>>
>>
>> I can see that it has been changed in
>> org.apache.catalina.valves.ValveBase since Tomcat API 7.0 which already
>> defined a final *start()* method from its indirect parent class
>> org.apache.catalina.util.LifecycleBase
>>
>> http://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/valves/Va...
>>
>> I confirmed that the problem doesn't happen in JBoss, so I guess this api
>> part is not consistent between Tomcat and JBossWeb.
>>
>> yes, It sucks that this api is changed...
>>
>>
>> In addition, there is no error in compile time as it is using tomcat
>> catalina version 6.0.29 declared in gatein-dep.
>>
>> Hmm... I tried to run "mvn dependency:tree" in module
>> component/web/security where PortalClusteredSSOSupportValve currently is.
>> And I am seeing that it's using jboss.web:jbossweb:jar:2.1.3.GA:provided
>> for compilation.
>>
>> Marek
>>
>>
>> Thanks,
>>
>>
>>
>>
>
>
> --
> *Trong Tran*
> *(+84) 983841909 | *trongtt(a)gmail.com
> Twitter: http://twitter.com/trongtt**
>
>
>
>
>
>
> --
> *Trong Tran*
> *(+84) 983841909 | *trongtt(a)gmail.com
> Twitter: http://twitter.com/trongtt**
>
>
12 years, 12 months
Remember me extension of all HTTP verbs
by Julien Viet
Hi,
we fixed an issue in gatein master that extends the remember filter filter to work with any kind of HTTP request.
Before it was limited to GET due to potential issues with servlet container authentication (could cause infinite loop because of redirections).
The use case is with ajax requests (POST) done by portlets when a user session expires that cause client side issues.
We would like to port it to 3.5.x as well.
Here is the commit for this patch : https://github.com/gatein/gatein-portal/commit/70f2b4be5d4895e245a2cbb7b7...
let us know if this is ok for you.
Julien
13 years
Mobile Updates
by Matt Wringe
I have been a bit quiet on this, I guess I need to communicate more on
the lists. There has been a bunch of work done on the mobile front and
we are getting close to be in a state to do a push to get this into
gatein master. There are still a bunch of issues we are currently fixing
and it will have a lot of limitations. I will create another email
thread to discuss the separate mobile site (which has been mostly
separated out into its own extension).
There are some things we would like to get changed in the current gatein
code base to make it work better with the new mobile site and to work
with mobile devices better in general. Things which currently don't work
well and we would like to modify:
1) the login.jsp page (shared between all the sites) needs to be written
to be mobile friendly. Villiam has already done this and should probably
be able to do a PR for this.
2) popups and modals. These currently don't work on mobile devices since
we have js to reposition the popup on a scroll event, and mobile devices
automatically scroll when entering forms to reposition the keyboard.
These both fight against each other and the forms are constantly being
hidden behind the keyboard. Having the js reposition also has latency
issues. I would like to remove the js positioning and position this
purely in css.
3) using hover with menu elements doesn't work nicely on mobile devices.
We would like to change the portlets in the shared menu so that this
works better on mobile devices. For example, clicking 'site' would
toggle a menu with the site names and a 'edit site' element. Clicking
'site' would no longer take you to the portal navigation page.
4) change some of the layout of the shared layout portlets and combine
the features of the banner portlet (ie login/register/language).
Basically just clean this up a bit and make it more consistent to where
things are done. The other option for this would be to remove the shared
layout for a particular site, but I don't know how much effort this
would entail (for the separate mobile site we have, we just set the css
for the shared layout to hidden and do everything in a header portlet).
5) mobile sites need to configure the viewport of a page, which is set
by a meta tag in the header. Any objections to add a viewport properly
to a sites settings or properties? This would just be a string property
that an admin could set. Or does anyone have an idea on how to add this
in a better manner or a more general option for adding things to the head?
6) adding javascript to a particular portal/site. For mobile sites you
usually can add a small sniplet of javacode to scroll the page to the
top when loaded (to scroll past the browser url bar and buttons). For
this I guess the best way is to use the resource manager and use the
portal scope
There has also been some suggestions to make some mobile friendly
enhancements to the classic site. These would be fairly simple changes,
and not something we would want to spend a lot of time on.
- a flexible (non-fixed-width) classic skin. Essentially the current
skin but where the width for UIWorkingWorkspace is set to its max-width
instead.
- a flexible container. This container would switch from a column layout
to a row layout depending on the current width of the container (note:
obviously only works if the site is not fixed width). This would just be
something simple to use with the non-fixed-width classic skin and would
be really useful for the mobile site.
Sorry for the long email. Any thoughts or objections to the proposed
changes?
Thanks,
Matt Wringe
13 years
CDI Portlet Implementation
by Ken Finnigan
I'm in the process of implementing the CDI support for GenericPortlet and would everyone's thoughts on how the changes in gatein-pc should be integrated into gatein-portal.
The changes in gatein-pc are purely around lifecycle modifications and enhancements, and don't entail anything CDI specific within them.
However, gatein-portal/component/pc is modified to add the listener to perform CDI injection within ExoPortletApplicationDeployer, and the code for the listener brings with it the need for CDI on the classpath of the module.
My current thinking is to create a gatein-portal/component/cdi module that contains the listener code, with dependencies on CDI, etc. Then in ExoPortletApplicationDeployer I try to instantiate the listener based on the class name, and do nothing if that fails.
I see the benefit of this being that we don't then have to ensure that each package option we provide also bundles a CDI implementation, as neither Tomcat or Jetty support CDI OOTB. So ExoPortletApplicationDeployer can simply not add the listener for CDI when the class is not present, and whether its present is determined by packaging.
Does that sound ok?
Also, the CDI scope implementations I think are best suited to be in a new repo under gatein on github, which contains the scopes and the CDI extension to activate them. And once again the packaging will be updated to include it for only environments that contain a CDI implementation, such as AS.
Thanks
Ken
========================
Senior Software Engineer / JBoss Enterprise Middleware Red Hat, Inc.
13 years
the master build failed
by Trong Tran
Hi,
is there anybody who has got the master build failed in recent days ?
For me, I have got :
*
[INFO] GateIn Redirect Admin UI Portlet .................. FAILURE [0.120s]
....
[ERROR] Failed to execute goal on project redirect-admin-ui: Could not
resolve dependencies for project
org.gatein.portal.portlet:redirect-admin-ui:war:3.6.0.MO1-SNAPSHOT: The
following artifacts could not be resolved:
org.richfaces.ui:richfaces-components-ui:jar:4.3.0-SNAPSHOT,
org.richfaces.core:richfaces-core-impl:jar:4.3.0-SNAPSHOT,
org.richfaces.sandbox.ui.bootstrap:bootstrap-ui:jar:4.3.0-SNAPSHOT: Failure
to find org.richfaces.ui:richfaces-components-ui:jar:4.3.0-SNAPSHOT in
http://repository.exoplatform.org/public was cached in the local
repository, resolution will not be reattempted until the update interval of
exo-central-server has elapsed or updates are forced -> [Help 1]*
It looks like the Redirect Admin UI Portlet is using SNAPSHOT versions for
its dependencies. Should it be changed to use latest released versions ?
Thanks
--
Tran The Trong
eXo Platform SEA
13 years
PortalClusteredSSOSupportValve issue in Tomcat
by Julien Viet
Hi,
there is an issue when deploying servlet 3.0 applications on Tomcat with PortalClusteredSSOSupportValve.
The scanning process find this valve and a classloading issue occurs (JBoss AS7 uses a Tomcat fork with slightly different code) and produces this error:
https://gist.github.com/vietj/b35b65f7dbe9d845ddd3
It would make sense at some point to move this code to gatein-sso (or wci) but I think it would not work at the moment.
An easy solution would be to move this class somewhere in packaging/jboss-as7 .
Would someone mind to have a look at this issue ?
thanks
Julien
13 years
Clean up and improve the usage of Resource Bundle files
by Trong Tran
Hi,
I intend to clean up and improve usage of Resource Bundle files in portal.
Basically, there are two things :
1. Remove ant configuration in the root POM which copies all
*_en.properties to the base ones (webui_en.properties to webui.properties
for instance). The copy is not efficient and not a clean way to maintain
resource bundle files. What we need is just to keep the base properties
file only, the default English language properties should be loaded
fallback by the base one normally.
2. Move resource bundle files from *src/main/webapp/WEB-INF/classes* to *
src/main/resources*. It is more compliant to Maven standard project
structure.
do you have any things / objections that I need to consider for these
changes ?
--
Tran The Trong
eXo Platform SEA
13 years
