Setting up SSL for your Development Environment

Staff Blogs December 1, 2010 By Michael Young Staff

Recently I needed to set up SSL in my development environment in order to debug an issue. I needed to make sure that 

  • Tomcat could serve SSL content properly
  • As an Http client, the JVM could accept a self-signed (untrusted) certificate. If you've ever come across a website that asked you if you want to accept an untrusted certificate, this is basically the same thing, but there's no UI to import certificates into the JVM.  

 

While this sounds simple to do, there's a lot of scattered information on the web about setting this up and nothing that matched the exact use case that I needed.

  1. Create a self-signed certificate using keytool. The following command generates a certificate keystore with one self-signed certificate inside it with filename keystore. I used the password "changeit", but you can use whatever you want. Just make sure the Tomcat configuration uses the same. 
    keytool -genkey -alias tomcat -keyalg RSA -keystore keystore 
  2. Configure Tomcat to use the certificate / keystore that we just generated. This tells Tomcat to send the certificate whenever you access the server @ https://host:8443. In server.xml look for the SSL connector:

    <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
        maxThreads="150" scheme="https" secure="true"
        clientAuth="false" sslProtocol="TLS" 
        keystoreFile="/Users/myoung/projects/portal/trunk/tomcat/keystore" 
        keystorePass="changeit" />
     
  3. Import the certificate into the JVM's keystore. This tells the JVM that this is a "trusted" certificate so that when Liferay makes https requests to Tomcat it will proceed without errors
    • Export the key from the keystore you generated in step 1. This extracts the certificate so that you can import it into the JVM's store
      keytool -export -alias tomcat -keypass changeit  -file server.crt -keystore keystore
    • Import the cert into the JVM. "cacerts" is the filename of the JVM keystore. The path will be different on Windows (should be in %JAVA_HOME%/jre/lib/security/cacerts).
      keytool -import -alias tomcat -file server.crt -keypass changeit -keystore /System/Library/Java/Support/Deploy.bundle/Contents/Home/lib/security/cacerts
  4. Check to see that the certificate was properly imported.
    keytool -list -keypass changeit -keystore /System/Library/Java/Support/Deploy.bundle/Contents/Home/lib/security/cacerts

OpenSocial Gadgets: Custom Preferences UI

Staff Blogs July 1, 2010 By Michael Young Staff

 In an earlier post I demonstrated how to add OpenSocial Gadgets as first-class citizens within Liferay. In this post I'd like to show you how  we have created a custom preferences UI.

This sample gadget has three preferences: pref1, pref2, and pref3.

 

<?xml version="1.0" encoding="UTF-8" ?>

<Module>

<ModulePrefs title="Multiple SetPref - Iframe">

  <Require feature="setprefs"/>

</ModulePrefs>

<UserPref name="pref1"

          datatype="string"

          default_value="0" />

<UserPref name="pref2"

          datatype="string"

          default_value="0" />

<UserPref name="pref3"

          datatype="string"

          default_value="0" />

<Content type="html">

...

</Content>

</Module>

To access our custom preference UI, go to "Configuration" :

 

Liferay 6: OpenSocial Gadgets

Staff Blogs June 3, 2010 By Michael Young Staff

 Liferay 6 will feature an OpenSocial container based on Shindig. OpenSocial Gadgets present as first-class citizens via the "Add Application" menu, just like portlets.

To configure a Gadget in Liferay, all you need is the Gadget URL. In the screenshots below I've configured three gadgets:

  1. http://www.labpixies.com/campaigns/todo/todo.xml
  2. http://www.google.com/ig/modules/horoscope.xml
  3. http://localhost:8080/opensocial-portlet/gadgets/files/samplecontainer/examples/SocialHelloWorld.xml (this is a sample Shindig gadget)

 

 

Migrating SVN Servers for Everyone

Staff Blogs January 12, 2009 By Michael Young Staff

Back in Nov 2008 we migrated SVN servers for committers. We pushed our commits to the Sourceforge SVN server on a regular basis, and that worked well for some time. Recently we discovered that large commits could not be synced and we've had an outdated Sourceforge repository for a couple weeks.

Now that our new SVN servers are quite stable and we've completed the migration for all committers, we've opened anonymous read access for everyone.

To migrate your local source code to the new servers, simply issue a relocate command, like this:

svn switch --relocate https://lportal.svn.sourceforge.net/svnroot/lportal svn://svn.liferay.com/repos/public

or

svn switch --relocate https://lportal.svn.sourceforge.net/svnroot/lportal http://svn.liferay.com/repos/public

 

 

Fisheye Server

Staff Blogs November 21, 2008 By Michael Young Staff

One of the benefits of having our own dedicated SVN servers is that we have been able to set up a Fisheye server at http://svn.liferay.com. We tried to set up Fisheye against our Sourceforge.net servers, but because of the size of our repository and remote connection we could never get the initial index to complete.

We've also set up the Fisheye plugin for JIRA so that you can view the changelog associated with every issue.

A big thank you to Atlassian for granting us open source licenses.

Liferay Read-Write Database Splitting

Staff Blogs November 3, 2008 By Michael Young Staff

The Beauty of Sponsored Development

As a company that likes to work very closely with our community, we're often given the opportunity to work on some very interesting (and many times very challenging) features. The following is one such feature being sponsored by one of our marquee partners: Read-Write database splitting. They are planning a Liferay deployment that scales to several millions of users

Because of the dynamic data-intensive nature of this deployment, they've identified that they're likely to to database-bound during peak load.  In order to scale database throughput they wanted to us to implement a mechanism within Liferay that would direct transactional (write) and read-only operations to separate data sources.

How was this done?

First, by using one of lesser-known features of the Spring Framework, target sources, we implmented a custom DynamicDataSourceTargetSource to do the job (if you're not familiar with target sources, one of the nifty things you can do is hot-swap a dynamic proxy's target object at runtime). This DynamicDataSourceTargetSource allows us to switch between read and write data sources at the appropriate time.

Secondly, we wanted to take advantage of Spring's transactional boundaries to help us decide when to use the appropriate data source. Before we did that, there were a couple items that needed cleanup and refactoring:

1) Use @Transactional in favor of xml transaction configuration. Annotations are a better fit for transactions because they allow better fine-grained control of transaction rules. Luckily this transition was very easy because all of our services are autogenerated via ServiceBuilder, so very little coding was needed.

2) We created our own @Transactional interface free of Spring dependencies so that it can be used in our plugins environment. This is virtually a mirror of Spring's @Transactional. We decomposed Spring's <tx:annotation-driven /> and replaced it with our own:

<bean id="transactionAdvice" class="org.springframework.transaction.interceptor.TransactionInterceptor">
<property name="transactionManager" ref="liferayTransactionManager" />
<property name="transactionAttributeSource">
<bean class="org.springframework.transaction.annotation.AnnotationTransactionAttributeSource">
<constructor-arg>
<bean class="com.liferay.portal.spring.annotation.PortalTransactionAnnotationParser" />
</constructor-arg>
</bean>
</property>
</bean>

As you can see we had to implement our own PortalTransactionAnnotationParser to read our custom @Transactional annotation.

3) Now that we have the annotations in place, it's very simple to add additional logic to swap data sources. We created a DynamicDataSourceTransactionInterceptor (subclass of Spring's TransactionInterceptor). This interceptor piggybacks spring's transaction boundary logic to help us decide when to use read or write data sources:

<bean id="transactionAdvice" class="com.liferay.portal.dao.jdbc.aop.DynamicDataSourceTransactionInterceptor">
<property name="dynamicDataSourceTargetSource" ref="dynamicDataSourceTargetSource" />
<property name="transactionManager" ref="liferayTransactionManager" />
<property name="transactionAttributeSource">
<bean class="org.springframework.transaction.annotation.AnnotationTransactionAttributeSource">
<constructor-arg>
<bean class="com.liferay.portal.spring.annotation.PortalTransactionAnnotationParser" />
</constructor-arg>
</bean>
</property>
</bean>

Enabling Read-Write Database Splitting

1) Set up your database for master / slave replication. All major databases support at least a master / slave setup. See some sample instructions for the mysql database. Hint: Make sure you create a read-only user for the slave database so that no one can write directly to the slave.

2) Configure your app server / servlet container for each the master and slave databases. Sample ROOT.xml for Tomcat:

<Resource
name="jdbc/LiferayReadPool"
auth="Container"
type="javax.sql.DataSource"
driverClassName="com.mysql.jdbc.Driver"
url="jdbc:mysql://localhost:3308/lportal..."
username="read_only"
password="password"
maxActive="20"
/>


<Resource
name="jdbc/LiferayWritePool"
auth="Container"
type="javax.sql.DataSource"
driverClassName="com.mysql.jdbc.Driver"
url="jdbc:mysql://localhost:3307/lportal..."
username="root"
password="password"
maxActive="20"
/>

3) Set portal-ext.properties to enable the Spring configuration for dynamic data sources:

  spring.configs=\
META-INF/base-spring.xml,\
\
META-INF/hibernate-spring.xml,\
META-INF/infrastructure-spring.xml,\
META-INF/management-spring.xml,\
\
META-INF/util-spring.xml,\
\
META-INF/jcr-spring.xml,\
META-INF/messaging-spring.xml,\
META-INF/scheduler-spring.xml,\
META-INF/search-spring.xml,\
\
META-INF/counter-spring.xml,\
META-INF/documentlibrary-spring.xml,\
META-INF/lock-spring.xml,\
META-INF/mail-spring.xml,\
META-INF/portal-spring.xml,\
META-INF/portletcontainer-spring.xml,\
\
META-INF/mirage-spring.xml,\
\
META-INF/ext-spring.xml, \
META-INF/dynamic-data-source-spring.xml

You now have read-write data source setup. Over the next several months we'll post an update with some performance numbers on a read-write configured set up.  Enjoy :)

5.1.2 Released

Staff Blogs October 6, 2008 By Michael Young Staff

A number of important issues have been addressed. 5.1.2 is a highly recommended upgrade. Highlights include:

  • LDAP Synchronization and Authentication
  • JSR 286 Conformance
  • Transaction (Spring Tx) Propogation was not functioning properly
  • Layout Caching handling of Internationalized Websites
  • Removed a situation where database connections may leak under heavy load
  • Improvements to Spring Integration and Transactions
  • Siteminder Integration (via Authentication Pipeline). Thanks Mika!
  • ...and hundreds of additional Selenium Tests

Complete releases notes can be found at http://support.liferay.com/secure/ReleaseNote.jspa?version=10321&styleName=Html&projectId=10014&Create=Create

Downloads:

http://www.liferay.com/web/guest/downloads/portal

Plugins (Themes, Portlets, etc)

http://www.liferay.com/web/guest/downloads/official_plugins

http://www.liferay.com/web/guest/downloads/community_plugins

5.2.0 is about a month away. Lots of goodies in there including a new control / admin panel, knowledge base application, new tagging system for both taxonomies and folksonomies, private messaging, and much much more.

 

New JIRA projects

Staff Blogs October 3, 2008 By Michael Young Staff

If you went to the Los Angeles Meetup in August or the European Symposium last week, you already have a leg up on some of our upcoming offerings: Liferay Enterprise Edition and Liferay Social Office. We'll be deploying a new website within the next week which will describe these new offerings and will hopefully answer all your questions and concerns as well.  So stay tuned for that...

In preparation of these new offerings we've created new JIRA projects for you to file your issues:

1) Liferay Portal Standard Edition

2) Liferay Social Office Standard Edition

Please redirect your issues to these projects. 

The old LEP project still exists as read-only. You won't be able to create new tickets but you can still comment and edit existing issues. You may also see two parallel projects: Liferay Portal Enterprise Edition and Liferay Social Office Enterprise Edition. These are the JIRA projects we'll be using to manage our enterprise releases. The issues in these projects will parallel those in their respective Standard Editions, but will specifically address long term stability, security, and performance -- all the good stuff that enterprises need.

Hope this eliminates some confusion the next time you log in to support.liferay.com.

Thanks everyone.

 

5.1.0, out!

Staff Blogs July 17, 2008 By Michael Young Staff

I want to give a quick update regarding 5.1.0, released this morning.

Dropping the RC

Now that the JSR 286 specification has been officially approved, we can drop the "RC" portion from our release. Even though 5.0.0 RC, 5.0.1 RC were production quality, they were labeled as such because the JSR 286 guidelines state that we can't go final until the specification is approved.

Contributions from Sun

The Sun portal teams is making many contributions -- the Open Portal Container has been fully integrated into Liferay. The Sun team is also fixing many bugs and is really giving our development effort a huge lift. Some things to look forward to from the Sun team: WSRP 2.0 Producer / Consumer Integration, SAW workflow, and a presence engine. Keep up the great work guys!

Plugins and Themes

Over the next few days we will be updating all the plugins, portlets, layouts and themes to 5.1.0.

Noteworthy Features

  • Roles-based Access Control – We implemented a new permissioning algorithm which limits assignment of permissions to Roles. Other objects like Users, Groups, User-Groups and Organizations will not be available during permission assignment. Rather Roles are assigned to those instead. This significantly reduces the cost of assigning permissions and performing permission checks, delivering a huge performance boost.
  • Scheduled Staging and Remote Staging – This allows for a more nimble and flexible process of data transfer whereby groups of data, as specified by the user, in a particular site (ie, communities or organizations) can be sent to remote servers in the same physical machine, the same portal instance (JVM), or to servers that are geographically dispersed. The data import process is flexible enough to take care of various use cases for handling the imported data. Essentially this feature simplifies and speeds up the data transfer process while providing transactional security in its use of logic for handling how data should be inserted into the remote systems. Remote publishing also allows for the scheduling of both data transfers as well as data reversion
  • Announcements/Alerts are two portlets that can be used to broadcast messages to a list of users within a known scope. Essentially, they provide a mass messaging engine similar to a "news letter" or one-way messaging. Please see Architect, Ray Auge’s blog entry for more information
  • Alerts Portlet – This portlet allows administrators to create customizable alerts for users.
  • Alert Management and User Alert Configuration – Users can individually configure how each "type" of alert is delivered to them: SMS (optional), Email (optional), web (not optional). There are also more types that are configurable in the portal properties.
  • Integration with the latest jQuery and jQuery UI components
  • Scheduling Engine Upgrade – In 5.1, the internal scheduling engine was refactored SOA service.
  • Search Engine Upgrade – SOLR has been added as a search engine option in addition to Lucene. Other implementations are pluggable.
  • Asynchronous messaging and light weight message bus – Portlets can now communicate together in an SOA fashion within Liferay without having to use a full ESB.
  • User Group Page templates – Administrators are now allowed to create template pages (e.g. default portlets on a page, layout, theme).
  • New Mail Portlet – Performance and scalability enhancements have been made, as well as support for multiple accounts.
  • Groupwise Portlets – The Novell Groupwise Portlets have been verified for this release
  • And of course, a ton of bugs have been fixed
     

Thanks to everyone involved. Enjoy :).

 

Release Process Changes

Staff Blogs December 5, 2007 By Michael Young Staff

We had a long conversation at the office regarding release process, versioning, etc, that we'll be presenting at the LA retreat this year.

But in a nutshell the goals were to:

- increase timeliness
- improve the quality
- lock down features
- have a LTS / EOL plan for incremental micro (x.y.z)/ minor (x.y)releases
- formalize a QA process
- start a beta testing program

5.0 will be almost exclusively PC 2.0 (JSR-286) upgrade and WSRP 2.0 and sample plugins excercising these upgrades. There will be bug fixes and minor features of course.

5.1+ will be the build out of the other focused product lines and core improvements, including to but not limited to:

- workflow
- business intelligence
- enhanced clustering, terracotta and standalone
- security
- social networking apps (producer / consumer)
- remote staging

Many of these features are sponsored by our customers, clients, and the community. Please contact us if your organization would like to sponsor a new feature and we'll get it on the roadmap.

If you are interested in participating in the beta testing program, please let us know!

Jorge will be expanding in more detail some of the things we talked about during our brainstorm session.

A walk down memory lane

Staff Blogs December 3, 2007 By Michael Young Staff

Before I joined Liferay I used to check up on Brian's work from time to time, hoping I could somehow be a part of this small piece of software called Liferay EP. As we're approaching our 9th year in development and our second annual Liferay retreat, I became a little reflective of the early days. Here's a sneak peak of Liferay EP 1.7.5 (October 10, 2002). Note that back then you had to use a full J2EE server with CMP. Even this early release is on JDK 1.4. What JDK are we compliant to now?

A whopping 16 MB download. Enjoy :).

I feel incredibly blessed to be a part of something very special now...

1)  Landing Page

2) Login

3) Home Page

4) Personalize

5) Color Schemes

 6) User / Group / Role Management

Application Integration and Remoting Technologies

Staff Blogs October 29, 2007 By Michael Young Staff

I've been thinking a bit about the different technologies available to those thinking about integrating external applications into portal environments. One of the most requested questions we get in client situtations is "How do we integrate our exising applications written in PHP, Perl, Ruby, etc?

I wish there was a straightforward answer to that, but unfortunately the answer is: it depends. It really depends what you're trying to integrate and how much you're trying to integrate. From my experience we've seen that the level of integration is directly proportional to the level of effort required. On one end of the spectrum you have those who are simply trying to pull in static content from a content management system, and on the other end you're talking close integration with portal artifacts: Window States, Modes, Two-Phase Commit, Single-Sign On, Permissions, Asset Management, Tagging, etc. Currently there are several solutions already available address these integrations.

IFrame

IFrame is probably the simplest and cheapest technology to implement. It requires very little development effort to get up and going, and if you have a "Smarter" IFrame portlet, it will authenticate, perform single sign-on and even resize the portlet window depending on how much content contained in the target application. However there are some serious drawbacks:

  • State loss (ie when switching portal pages)
  • No look and feel integration (ie you'll have two sets of headers and footers)
  • No integration with portal artifacts
  • Little to no control of the target application's content

 

Web Proxy

A web proxy allows you to fetch content from an external application on the server side proxy it into the portlet environment. PortletBridge provides a good implementation of this, however it seems that development has stopped in the past two years. One of the greatest features of PortletBridge is that it allows you to filter the content using a regex so that you have a chance to rewrite content and URL before it is presented to the user. This allows you to strip out content (like headers and footers) that the IFrame could not do.

While this solution addresses some of the problem from the IFrame option, it introduces some of it's own. The most significant problem is the potential for a type cross-site scripting. There's actually a pretty good chance that proxied app or the portal itself will have interfering CSS, Javascript, or HTML that will cause one or both applications not to function.

However, if you have some control of the target application, this can be minimized.

WSRP

WSRP is the most powerful, yet most complex application integration option. The idea behind WSRP is that any WSRP consumer should be able to consume portlets seamlessly from a WSRP compliant producer (ie Liferay should be able consume portlets from a remote BEA, Oracle, or IBM portal server). Unlike the IFrame and Web Proxy solutions, WSRP actually respects a lot of the Portlet artifacts like Window States, Modes, and a Two Phase Commit. Theoretically this seems like a great, seamless technology.

In practice however, this is hardly the case. There are enough ambiguities in the WSRP specification that make it pretty difficult to consume more than the simplest of portlets. Anything requiring SSO, file uploads, or other complex interaction is not possible without some propreitary integration. The whole point to WSRP is the removal of anything propreitary.

Just Migrate the Whole Thing!

And of course the cleanest integration is to migrate the whole thing into a Portlet JSR-168 environment. As we know many companies with large legacy applications do not always have the resources to do this. However, this does provide most seamless solution.

Final Thoughts

There really isn't a one-stop solution for application integration, the solution really depends on what problems you're trying to solve and your resource situation.

I've been having some discussions with Jorge and some others within Liferay how we can improve our application integration options. Already we have a prototype available for the Liferay WAI. There's also an idea for Simple Remote Portlets. We've been looking at the likes of Facebook, Google Gadgets, and REST-style architectures to see what we can provide for future versions of Liferay, and we think the future is bright.

Jorge will be giving talk at W-JAX in Munich, Germany on Nov 1 about this future.

Herren Young

Staff Blogs October 25, 2007 By Michael Young Staff

One of the things I love about my job is the opportunity to travel to different countries and experience everything about the culture. On this particular trip I've had the pleasure of visiting Germany (Langen-Stuttgart-Munich) to do some "special ops" consulting for a large German company.

Among the things I've observed about the Germans are that they eat, walk, and work rather efficiently. Also, they don't waste (although this might be more reflective of countries not U.S.) time, food, or natural resources. I'm so used to taking a wad of napkins at a self-service dispensers and using only three :), but here I'm more conscious of what and how much I take.

What I'm really not used to, particularly in the corporate environment, is being addressed as Mr. Young on a regular basis. The pecking order is quite pronounced in even in high-tech here, and you just don't address others (your superiors are a definite no-no) by first name -- there's definitely a level of respect that you have to give, almost to the point where it can seem counter productive (or I might just be naive). We're so used to just spouting our mouths back at home at work it's something we really take for granted.

I've also had the chance to visit Suresh and the Liferay GmbH office in Langen (near Frankfurt). Will share my thoughts about that in a later post.

Showing 13 results.
Items 20
of 1