Welcome to Radio Liferay, a peek into what is going on in Liferay from the people doing it themselves.
Radio Liferay Episode 60: Performance and Permissions with Preston Crary
An episode on the "Per" things: Performance and Permissions. I spoke to Preston Crary, who amazingly was not mad at me for losing an earlier recording.
- We open with the attention to detail that's required for working on performance tuning and some short conversation about this topic.
- Sadly, there's not often a single silver bullet, but many areas of dust.
- Sometimes the fastest code is not the most optimal
- Continuing with Preston's work on Permissions:
- ResourceBlock is deprecated, and there's an easy migration path
- an example upgrade path for bookmarks
- The usecase for Resources, ResourcePermission, and ResourceBlocks (as they're not at all visible on the UI)
- Preston's way through Liferay from Support to working on the topics that he's now working on
- The new API for Permissions - and the documentation is also done already (as of me writing this article, not yet published, but available on github - should be a matter of days or hours)
- Should you implement your own permission system? (and how the answer to this question might change in 7.1)
- Upgrades are being performance tuned. I smell a future episode coming up. Paging the team that is working on this area
- The remarkable memory savings that refactoring the UserBag introduced
- What happend during login
- Passwords are PBKDF2WithHmacSHA1/160/128000 hashed, a deliberately expensive password hashing algorithm.
- LPS-75747 and an update to my hardball question: Document Library's default.xml is still in core, can't be updated through a module, just through an ext.
You'll find this episode - and make sure that you don't miss any of the future episodes - by subscribing to http://feeds.feedburner.com/RadioLiferay. You can also subscribe on itunes.: Just search for "Radio Liferay" or just "Liferay" in the podcast directory. Make sure to write a review for the podcast directory of your choice - or find everything about Radio Liferay on radioliferay.com.
Or just download the MP3 here:
Radio Liferay Episode 52: Ray Auge - Modularization II - Upgrading your Plugins
A continuation of last week's episode, Milen Dyankov stepped in as a co-host and helped me ask the right questions: Ray Augé answers all sorts of questions about the Modularization in Liferay 7 and what to do with your existing investment in Liferay Plugins - what to do with the plugins you already have, where you will have to re-learn and what you can, should or shouldn't continue to do..
As we recorded this on site at Devcon, you'll hear more background noise than usual - Auphonic did their best to clean the recording, and they did a great job.
- If you're not interacting with Liferay, e.g. a pure JSR-286 portlet: No changes required
- JSF: Last kinks are worked out - test the more complex the JSF implementation is
- If you're using Liferay API: You'll have to resolve API changes - e.g. recompile and check if the API is still valid. Check these breaking changes - well documented, huh? And even better: The document is machine-readable and there will be migration tools (future episode planned)
- If the service is still in Liferay's core: No change needs to be made.
- If the service is now in a module: Check if the package was updated. Fix if necessary and if the migration tool didn't do it for you.
- Circumstances under which Liferay automatically "translates" WAR file into OSGi bundles - and the caveats
- Extensions to Liferay MVC portlet: Check for the nature of those changes
- The use of CDI - especially when the appserver's implementation/resources are utilized - still requires some work.
- Everybody who's doing really advanced stuff on sophisticated frameworks is welcome to try it out now and let us know now if there are any problems that remain
- How little of OSGi can I get away with?
- Many of the hooks - especially on services and models will continue to work, but won't have more power than in 6.2. They're prime candidates to be converted to an OSGi module as this will enable them to tap into a lot more extension points in Liferay 7.
- Struts Action Hooks probably need changes - while they still work, most of the underlying actions have been reimplemented without Struts \o/, so possible overloads in Struts actions won't be taken into account for the new implementation.
- (most likely: You need to convert to an MVC Command, injected as an OSGi module. There are samples available)
- Liferay 7 has a lot more extension points than prior versions. The documentation is being made available on dev.liferay.com - obviously this is still work in progress, but is scheduled to be there until release.
- How can IDE and other tools help identifying which extension points are in use? And how to make lots of friends within the Liferay Community
- Overriding Language Keys is quite simple - choose "global" or "per portlet" - those are the two available scopes that a translation can live in.
- For migration you might have to decide which scope your changes should go into.
- Encoding still is done in UTF-8
- JSP-Hooks: The elephant in the room: Seems to be very popular, but always has aimed at the implementation rather than to an API.
- As drastic UI changes happened in Liferay, these implementation need to be implemented on the new infrastructure, leveraging new techniquest (e.g. Lexicon). Also, most of the functionality has been moved into modules - JSP-Hooks only affected the core jsps...
- New options: JSPs can be deployed as proper OSGi bundles.
- There's still danger because technically the implementation is unchanged compared to earlier versions
- New fragment modules enable you to override JSPs in any portlet - not only core ones.
But you shouldn't limit yourself to JSP-overrides: There are more ways to change Liferay's UI, e.g.
- replace the render-phase of a portlet through a portlet filter.
- A new "dynamic include" API to inject extension points at very specific places - e.g. at those UIs commonly targetted by overrides. (let us know which are missing)
- Ext Plugins work just like before (in core). But most likely, the implementation has changed anyway, so that you need to make sure your code is still valid for the current version - but that's what you expected when you started writing that ext anyways, right?
- Of course you'll have to check if your changes still are contained in Liferay core. If they're extracted to a module, ext won't be yours any more (for these changes)
Ideally, ext will be the easiest plugin, as it probably will be a lot smaller than before.
We haven't covered all possible questions and are planning a "Listener Questions" episode. Please ask your questions in the comments to the blog article for this episode to get them answered in the next episode with Ray.
You'll find this episode - and make sure that you don't miss any of the future episodes - by subscribing to http://feeds.feedburner.com/RadioLiferay. You can also subscribe on itunes.: Just search for "Radio Liferay" or just "Liferay" in the podcast directory. If you like this, make sure to write a review for the podcast directory of your choice - or find everything about Radio Liferay on liferay.com/radio.
Or just download the MP3 here: