Hi all, Thanks for all of the information, it does sound like some common approach would be useful in uPortal. I don't particularly like the idea of replicating the uportal-impl structure for each environment, I'd rather manage that via configuration.
The way it works in Sakai is we have one central file called sakai.properties where all configuration is kept, but can be overriden by a local.properties file and then it's all loaded at startup - its not used as a filter though, we have a properties loader (called ServerConfigurationService) that is injected into the impl/webapps and can access the configuration params when requested. Jen, I'd like to probe a bit more into your setup since this is almost identical to what we have. With your filter file below, I assume that you have made corresponding changes in other parts of uportal to replace the hardcoded information (like db connection url for instance) with a placeholder for these properties, then adjust the uportal-impl pom to filter src/main/resources with this local filter file? Ie you would have placeholders in security.properties etc. But how do you manage rdbm.properties? Placeholders in there don't seem to be substituted, and those values are in turn used for the datasourceContext.xml - still nutting this one out. We also had to modify the bookmarks portlet and webproxy portlet since they both filter via the uportal-impl rdbm.properties, so adjusted it to use the local filter file instead. cheers, Steve On 02/12/2010, at 4:25 AM, Jen Bourey wrote: > Hi Steve, > > As Drew mentioned, Unicon's been using a maven filtering-based approach for > several years now based on work we originally did for an internal demo > instance. I presented on this at the 2009 Jasig conference, and there are > some slides left over from that here: > https://wiki.jasig.org/download/attachments/22940141/uPortal_Build.pdf?version=1&modificationDate=1236555418744. > From your description, it sounds like our approaches are very similar. > > Basically the strategy we've followed consists of using a single maven filter > file that's used for both the portal and all bundled portlets. I'd strongly > suggest that whatever strategy we adopt be capable of configuring both the > portal and bundled portlets, since it's so common for portlets to share > information about the CAS server, database connection parameters, log > directory, etc. I'd be more than happy to share customizations we've made to > accomplish this. > > I've included a sample filter file below. We generally have one folder named > "filter" at the root of the portal, and place one file for each environment > in that folder. Filter files toggling is controlled by a environment > variable that can be set on the command line (like ant deploy-ear > -Denvironment.name=jen). This will all become a lot simpler once uPortal is > built only by maven, but for the time being, we've added hooks to pass the > environment name through during ant builds. > > We also did custom work to allow configuration of the database dependency via > ant or maven parameters. This approach is still a bit awkward because of > uPortal's ant build strategy, but it does work. While most deployments > probably use the same database driver, having the driver be easily > configurable can be helpful for local developer instances (I don't really > want to install Oracle on my laptop). > > The one downside of using maven filter files is that this approach can become > confusing for users who aren't completely familiar with how maven works and > developers with slower laptops tend to be frustrated by having to run a full > "ant clean deploy-ear" to deploy a simple database connection change. It can > also confuse sysadmins who don't use maven much, since if you don't > explicitly run a clean, maven of course doesn't know that the filter file in > the parent directory has changed and doesn't bother to update the portlet > overlays. > > I'd personally love this or some similar solution to become part of the > uPortal source. It'd certainly be much easier than maintaining all the > modifications ourselves, and it sounds like this use case is becoming > increasingly common. I think the patch Drew's already contributed looks like > it contains most of our changes, minus the ones designed to allow database > dependency switching. Since we can at least control the dependency for the > portal and all portlets from the main pom.xml right now, I'm inclined to > think we should just leave that part out for now. I would be all for > applying Drew's current patch to the uPortal trunk and building on that, if > it seems to meet other people's needs as well as ours. > > Sample shared filter file for my personal development environment (with > passwords and such commented out, of course): > > environment.build.logging.dir=/usr/local/tomcat_instances/up32-showcase/logs > > # Database configuration properties > environment.build.hibernate.connection.driver_class=org.postgresql.Driver > environment.build.hibernate.connection.url=jdbc:postgresql://localhost/up3 > environment.build.hibernate.connection.username=uportal > environment.build.hibernate.connection.password=<password> > environment.build.hibernate.connection.validationQuery=select 1 > environment.build.hibernate.dialect=org.hibernate.dialect.PostgreSQLDialect > > # uPortal server configuration properties > environment.build.uportal.server=localhost:8443 > environment.build.uportal.protocol=https > environment.build.uportal.context=/uPortal > > # CAS server configuration properties > environment.build.cas.server=localhost:8443 > environment.build.cas.protocol=https > > # LDAP Configuration > environment.build.ldap.url=ldap://<ldapserver>:389 > environment.build.ldap.username=<ldapusername> > environment.build.ldap.password=<ldappassword> > environment.build.ldap.userbase=<ldapuserbase> > environment.build.ldap.uidattribute=sAMAccountName > > # Facebook portlet > environment.build.facebook.api_key=<apiKey> > > > > On Nov 30, 2010, at 5:27 PM, Steve Swinsburg wrote: > >> Hi all, >> >> I am wondering how people manage multiple build environments using the one >> source tree of uPortal. What I mean is that we have several developers as >> well as dev, test, uat and prod environments all with different details for >> the hostname, tomcat path and database connection details. And we want to >> run this all out of one source tree. >> >> What we've come up with so far is to use a local properties file which each >> environment has, and is kept out of SVN, which contains a number of >> properties specific to that environment, like the server.home url, CAS call >> back URLs and db connection details. >> >> I've added this to Ant to it get picked up before the build.properties file >> (so it loads the server.home var), and adjusted parts of the the uportal-war >> and uportal-impl to use these property placeholders instead of being >> hardcoded, then added the filter to the poms for each project, and *almost* >> everything is working. >> >> I've found some bundled portlets perform filtering of their own from other >> properties files in the uportal-impl (ie Bookmarks portlet grabs values for >> its own datasource.properties file from uportal-impl rdbms.properties) and >> I'm wondering if it would make more sense to have a global properties file >> that can be customised for this exact purpose. Eg see below. >> >> Happy to submit a patch, but it would mean that how you configure uPortal >> would be different, but IMO easier - ie the most common properties that you >> can customise are in one file rather than multiples, and would make source >> control that much easier when dealing with multiple environments - edit one >> file at the root level, not multiples all over the place. >> >> Thoughts? >> >> regards, >> Steve >> >> >> >> Current bookmarks portlet pulls its config from uportal-impl: >> <configuration> >> <filters> >> >> <filter>${basedir}/../../uportal-impl/src/main/resources/properties/rdbm.properties</filter> >> </filters> >> <webResources> >> <resource> >> <directory>${basedir}/src/main/resources</directory> >> <targetPath>WEB-INF/classes</targetPath> >> <filtering>true</filtering> >> </resource> >> </webResources> >> </configuration> >> >> >> Proposed change: >> <configuration> >> <filters> >> <filter>${basedir}/../../local.properties</filter> >> </filters> >> <webResources> >> <resource> >> <directory>${basedir}/src/main/resources</directory> >> <targetPath>WEB-INF/classes</targetPath> >> <filtering>true</filtering> >> </resource> >> </webResources> >> </configuration> >> >> Likewise, the CAS settings in uportal-war would be: >> >> <filter> >> <filter-name>CAS Validate Filter</filter-name> >> >> <filter-class>org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter</filter-class> >> <init-param> >> <param-name>casServerUrlPrefix</param-name> >> <param-value>${cas.host}</param-value> >> </init-param> >> <init-param> >> <param-name>serverName</param-name> >> <param-value>${uportal.host}</param-value> >> </init-param> >> <init-param> >> <param-name>proxyCallbackUrl</param-name> >> <param-value>${uportal.callback}</param-value> >> </init-param> >> <init-param> >> <param-name>proxyReceptorUrl</param-name> >> <param-value>/CasProxyServlet</param-value> >> </init-param> >> </filter> >> -- >> >> You are currently subscribed to [email protected] as: >> [email protected] >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/uportal-dev > > -- > > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
