Re: [gatein-dev] Commit rights for GateIn
by Dimitri
It exists GTNPORTAL-509
Dimitri BAELI
VP Quality -- eXo Platform
Le 20 janv. 2010 à 20:26, Julien Viet <julien(a)julienviet.com> a
écrit :
> it's an issue because the JIRA is not outside of your VPN, could you
> make a pending issue in GateIn JIRA ?
>
> On Jan 20, 2010, at 6:29 PM, Prabhat Jha wrote:
>
>> Just to clarify: Michal is not going to be fixing tests that Dimitri
>> sent recently. I think it will be counter productive at this stage.
>> It's for future purpose.
>>
>> Thomas: I think it will be good idea to give commit rights to Marek
>> Posolda, Viliam and myself as well.
>>
>> ----- Original Message -----
>> From: "Michal Vančo" <mvanco(a)redhat.com>
>> To: gatein-dev(a)lists.jboss.org
>> Sent: Wednesday, January 20, 2010 11:24:39 AM GMT -06:00 US/Canada
>> Central
>> Subject: [gatein-dev] Commit rights for GateIn
>>
>> Hi,
>>
>> is it possible to grant me the commit rights to svn?
>> I'd like to fix some of the UI tests for gatein (related with
>> https://jira.jboss.org/jira/browse/JBQA-3004 ).
>>
>> Thanks in advance.
>>
>> Regards,
>> Michal Vanco
>>
>> _______________________________________________
>> gatein-dev mailing list
>> gatein-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/gatein-dev
>>
>> _______________________________________________
>> gatein-dev mailing list
>> gatein-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/gatein-dev
>
>
> _______________________________________________
> gatein-dev mailing list
> gatein-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/gatein-dev
14 years, 3 months
Bug at event-based portlets in GateIn
by Michal Vančo
Hi,
after yesterday and today testing and verifying of portets with
event-based communication in GateIn, I've created a most basic sample
with 2 portlets and events communication.
I found out that these sample works fine on JBoss Portal, but doesn't
work on GateIn (tried on beta4 and on trunk version - revision 1366 -
today).
Cycle is following:
- enter text to input in portlet1
- portlet1 calls processAction, read this value (OK), setEvent with
this value (OK)
- portlet2 calls processEvent (OK), read value from event (OK), set
response.setRenderParameter(val)
- in doView of portlet2 there is no value in parameter!
I think that setting values from event (in processEvent method) to
renderParameter is the correct way that should work.
I attach the source of sample event portlets and WAR file.
Thanks for reply
Regards
Michal
14 years, 3 months
Happy new Year
by Thomas Heute
As Julien noticed we changed year :) And so copyright date.
As far as I know there is no need to change the existing file copyright
date. But for new files please remember to change your code template to
reflect the new year.
We will change the date that is displayed on the theme, at the bottom of
each page.
Thanks,
Thomas.
14 years, 3 months
Sugestions
by rafael liu
Hey, guys
I'm an outsider, since I use GateIn/eXo a lot, I subscribed to this list.
Some time ago I wrote to both Benjamin about some suggestions regarding the
products I was using.
I'm forwarding the document we exchanged with comments by exo and me. I
believe the suggestions concerning the Portal is pretty much valid still.
Could you give me a feedback for further discussions?
BTW, nice work. GateIn is looking amazing.
--
Rafael Liu
+55 61 9608-7722
http://rafaelliu.net
14 years, 3 months
sample-portal questions
by Boleslaw Dawidowicz
I have few questions about sample-portal and how the services are started. What concerns me the most is that currently services seems to be started separately for each container. This means that we end up with two HibernateServices and OrganizationService instances. Obviously it may be desired to have separate identity realm per container but I believe that there may be some situations in which single OrganizationService would also be expected. So for the more specific questions:
1) Is it possible to have both containers use same service instances? Some configuration way to mark services as shared and bootstrapped only once.
2) I'm a bit confused by the way the service configuration is separated. AFAIK one benefit of the separate container config is to push configuration out of gatein.ear. That way things can be configured in sample-portal.ear/sample-portal.war. However most of services configuration currently remain in gatein.ear/portal.war/WEB-INF/conf and rely on the ${container.name.suffix} replaced by the kernel. One example is HibernateService which creates separate DB instances this way. Now if I want to plug LDAP the natural way is to provide several xml files with names following ${container.name.suffix} pattern. But those are defined in config remaining in gatein.ear - then portal admin need to mess with config in both ears. Wouldn't it make sense to duplicate more service configuration in sample-portal.ear?
My use case is PicketLink IDM integration with LDAP enabled. As it is natural to provide separate LDAP DNs for different portal containers I can either put additional config file in sample-portal.war or have two different ones in gatein.ear/portal.war. So it is either configuring sample-portal.war inside gatein.ear/portal.war or having part of identity config in portal.war and part in sample-portal.war... I think it would make sense to duplicate at least HibernateService and OrganizationService config in both war files.
3) Current behavior is to replace the ${container.name.suffix} by:
- empty string in tomcat deployment
- "_portal" and "_sample-portal" in jboss deployment
It works fine when the suffix is used to create the HSQLDB file name on the fly but when used to refer to different configuration files it means that there need to be 3 xml files.. where 2 are duplicated ones to serve main portal container in tomcat and jboss. Could we have ${container.name.suffix} be replaced by "portal" in both jboss and tomcat? Also is there any other property that could be used as a prefix? Like to have the choice between "portal_", "portal" and "_portal" for flexibility in nice config files naming.
Bolek.
14 years, 4 months
GateIn portal component test infrastructure
by Julien Viet
I worked on starting to create an infrastructure for making the
various unit test of GateIn easier to configure. Actually it is an
attempt to fix several points that hurts us today:
1/ control the services that are used during the unit test : we had an
issue a couple of weeks ago by a service declared in core component
(in exo-jcr repo) that was declaring an hibernate service shadowing in
some unit test the same service declared in GateIn. While it was fixed
in core component (requiring a release only for that purpose), the
fact to import all the configuration is pretty much an issue for
several reasons (dependencies are not controlled, boot time is impacted)
2/ avoid to repeat the configuration for testing over and over. We
want to achieve reusability and minimality when we write unit test for
a module. For instance if a module requires a JCR repo and the
organization service, we want:
- not declare them locally unless a special configuration is required
- share that configuration between module unit tests
3/ fix the absolute path required for several unit tests (not now,
when effort will be achieved)
For that matter I started the effort by providing a minimal set of
code to reuse in unit test (namely the AbstractGateInTest class) that
works by filtering the configuration loaded from the classpath by
removing all configuration except the explicitly defined
configuration. Configured is explicitly defined by annotating the unit
test either with shared reusable configuration or with custom
configuration found in the classpath (usually located in the test /
resources of the module).
The initial reusable module is the JCR module that when booted
provides a repository with a unique workspace called "portal-test".
For now only one module uses it and that is the component/common
module. For other modules (like component/portal or component/
application-registry), there is a need for doing an organization
module and that is not yet done.
Note that each test component is a standalone maven module in order to
express the classpath dependencies of the test component.
I started to write things in the wiki on this page http://www.jboss.org/community/wiki/GateInPortalTestComponent
I hope we can complete that effort soon and achieve the following:
1/ rationalized configuration
2/ not reuse portal configuration
3/ no more absolute path needed
4/ fast boot time for unit test providing a better productivity for
developers
cheers
Julien
14 years, 4 months
