On Thu, Jan 7, 2010 at 1:03 PM, Boleslaw Dawidowicz <
boleslaw.dawidowicz(a)gmail.com> wrote:
Yes I have it. I have looked briefly once more at it and I can't
find any
direct answer to my question nr. 3) and only indirect ones to other
questions. However I assume following answers then:
1) Not possible?
As Patrice said the only possibility is to tie the corresponding components
(HibernateService and OrganizationService) to the RootContainer by declaring
them into a jar in conf/configuration.xml and to "un-tie" them from the
PortalContainers by ensuring that they are not declared into a jar in
conf/portal/configuration.xml or in the configuration files in the
portal.war file. In your case those components are only declared in
portal.war/WEB-INF/conf/database/database-configuration.xml
and portal.war/WEB-INF/conf/organization/hibernate-configuration.xml (If we
only talk about hibernate), so to override those configurations files, you
just need to create the exact same file name in the war of your extension,
duplicate the content and remove from the content the configuration that you
want to remove. The new files for sample-portal will
be sample-portal.war/WEB-INF/conf/database/database-configuration.xml and
sample-portal.war/WEB-INF/conf/organization/hibernate-configuration.xml
2) Following the best practices suggested in the docs I should duplicate at
least the OrganizationService config file to sample-portal to be able to
provide separate LDAP settings in a more clean way. Any objections for this?
If I understand correctly kernel will be smart enough to pick org service
defined from sample-portal.war/WEB-INF/conf/configuration.xml?
Yes, read the sections *How to import properly a configuration file using
the prefix "war:"?* , *How the platform interprets the dependency order
defined into the PortalContainerDefinition? * and *How to define and
register a PortalContainerDefinition*? for more details
3) Not possible? This is painful - maybe not anymore if I do the 2) but....
To quote the doc this is suggested tip under "How to avoid duplicating
configuration files just to rename a simple value?". In my case this is the
xml config file name that is passed in another config file as a service
parameter. To use it to pass different files depending on the deployed
container I need to handle both "" and "_portal" values for the
default one
depending on the deployment env....
Am I right?
Actually if you have:
- empty string in tomcat deployment
- "_portal" and "_sample-portal" in jboss deployment
It means that tomcat is not well configured, it is probably due to the fact
that you did not deploy the jar files that contains the
PortalContainerDefinition into tomcat/lib which
are exo.portal.sample.extension.config-XXX.jar
and exo.portal.sample.portal.config-XXX.jar (WARNING the name could have
changed). In fact to ensure backward compatibility, If I cannot find
any PortalContainerDefinitions, I assume that we want the old behavior.
See How to deploy the sample extension? (on Tomcat) or How to deploy the
sample portal? (on Tomcat)
On Jan 7, 2010, at 12:26 PM, Nicolas Filotto wrote:
> Did you get and read the documentation about the extensions in GateIn?
>
> It seems that the doc has been sent to Thomas, I don't know if he shares
it with you
>
> On Thu, Jan 7, 2010 at 12:13 PM, Boleslaw Dawidowicz <
boleslaw.dawidowicz(a)gmail.com> wrote:
> 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.
> _______________________________________________
> gatein-dev mailing list
> gatein-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/gatein-dev
>
>
>
> --
> Nicolas Filotto
> JCR Product Manager
> Project Manager
> eXo Platform SAS
> nicolas.filotto(a)exoplatform.com
> +33 (0)6 31 32 92 19
--
Nicolas Filotto
JCR Product Manager
Project Manager
eXo Platform SAS
nicolas.filotto(a)exoplatform.com
+33 (0)6 31 32 92 19