Recent Bloggers

Jan Eerdekens

8 Mensagens
6 de Fevereiro de 2016

Zeno Rocha

Staff
13 Mensagens
4 de Fevereiro de 2016

Gregory Amerson

Staff
27 Mensagens
3 de Fevereiro de 2016

Sachin J

2 Mensagens
2 de Fevereiro de 2016

Janne Hietala

10 Mensagens
1 de Fevereiro de 2016

Dominik Marks

2 Mensagens
31 de Janeiro de 2016

Olaf Kock

Staff
111 Mensagens
26 de Janeiro de 2016

Javeed Chida

4 Mensagens
22 de Janeiro de 2016

Lauri Hiltunen

7 Mensagens
19 de Janeiro de 2016

Krzysztof Gołębiowski

2 Mensagens
17 de Janeiro de 2016

Radio Liferay Episode 54: Scott Nicklous and Neil Griffin on JSR 362 - Portlet 3.0

Company Blogs 26 de Janeiro de 2016 Por Olaf Kock Staff

  In this episode, recorded at Liferay's Devcon 2015 in Darmstadt/Germany, I'm talking to Scott Nicklous and Neil Griffin. Scott is the specification lead for JSR-362 - otherwise known as the Portlet Specification 3.0 - and Neil serves as Liferay's representative on the expert group.

Here are some of the topics that we talked about:

  • JSR 362 page with all the latest and current information (spec, prototype implementation and javadoc)
  • The expert group
  • JSR 286 portlets will run unchanged on JSR 362 (runtime and compiletime compatibility)
  • My repeat favourite statement about frameworks in the web world.
  • JSR 362 and its impact on UI, there's a Client-Side standard (on ECMA script) for the first time in the portlet spec
  • The big question: When will it be done? (Some time 2016)
  • Early Draft Review Spec available, ~80-90% of content is expected to be there (That's the statement from Devcon, in October 2015)
  • Reference Implementation (to prove that the spec can be implemented) and TCK still missing (again, October 2015)
  • Reference Implementation and TCK will be implemented under the Apache Pluto project, help required
  • New Features include Bean-Portlet-Approach (portlet methods specified through Annotations in any Managed Bean), portlet.xml file no longer required if Annotations used
  • specifies a JS API despite being a JSR, which covers traditionally only Java
  • Dependency to JavaEE: Minimum is JavaEE 7, e.g. Servlet 3.1 etc.
  • Portlet Spec is not part of the JavaEE, but extends some of its elements.
  • CDI
  • JSR 378: Portlet 3.0 bridge for JSF (where Neil is the spec lead), being built in parallel with JSR-362
  • Multiplatform Support, Websocket, Devices
  • The E-Mail Archive of the specification process is public - contribution and comments are very welcome

Follow @RadioLiferay on twitter for news about the latest episodes, and occasionally more.

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 liferay.com/radio.

Or just download the MP3 here:

download audio file

Radio Liferay Episode 53: Nate Cavanaugh - New frontend features in Liferay 7

Company Blogs 30 de Novembro de 2015 Por Olaf Kock Staff

  I met repeat guest Nate Cavanaugh, Liferay's Director of UI Engineering, at this year's Devcon and he answered all UI-based questions that we could quickly think about - specifically with regards to Liferay 7.

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.

Here are some of the topics that we talked about:

  • UI frameworks get out of style soon. Can I still use AngularJS?
  • Do I have to throw everything away that I have invested already?
  • The YUI story and what its discontinuation means for AlloyUI
  • Will AUI be reimplemented on jQuery? Is jQuery part of Liferay 7? What about different versions of jQuery?
  • metal.js
  • Lexicon, UI-Language, User Interface Guidelines
  • Artifacts and Implementation of Lexicon
  • Bootstrap, Bootstrap components, Atlas, the bootstrap versions in Liferay 6.2 and the components of it that are available.
  • What happens when Bootstrap 4 comes out?
  • Single Page Application, SPA, SennaJS: Go without full page reloads, largely by default.
  • New Theming Tools - You can also use new tools in Liferay 6.2 (AYOR though). No more _diffs folder, pure frontend packages, themelets.
  • What kind of themelets do we wish to have?
  • We probably have forgotten something. Ask your questions in the comment section of this episode to be covered in future episodes.

Follow @RadioLiferay (Nate) and @olafk (me) on twitter.

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:

download audio file

Radio Liferay Episode 52: Ray Auge - Modularization II - Upgrading your Plugins

Company Blogs 23 de Novembro de 2015 Por Olaf Kock Staff

  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.

Here are some of the topics that we talked about:

Portlets:

  • 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?

Hooks

  • 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)
        Application Adapters

Ext

  • 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.

Follow @RadioLiferay, @rotty3000 (Ray) and @olafk (me) on twitter.

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:

download audio file

Radio Liferay Episode 51: Ray Auge - Modularization I - Motivation

Company Blogs 16 de Novembro de 2015 Por Olaf Kock Staff

   Another Devcon "private" session - I missed his presentations, but got the summary right when he was done: Ray Augé took the time to answer all sorts of questions about the Modularization in Liferay 7. In fact, he answered so many questions that we made it a 2-episode recording. This week it's about the motivation for modularization: What problem does it solve? Next week will be more technical, telling you about the implications of the updated architecture to your code.

As we recorded this on site at Devcon, you'll hear more background noise than usual - As usual, Auphonic did their best to clean the recording, and they did a great job.

Here are some of the topics that we talked about:

  • OSGi in Liferay 6.2 vs Liferay 7.0
  • Modularization of Liferay 7.0
  • Surprisingly (not!), modularization is not yet fully done, but it came a lot further than expected initially
  • How much do you have to re-learn to build plugins for Liferay 7
  • James: Community Roadmap Talk from Devcon (note: Ray also had several presentations at Devcon, you'll find his recordings there as well)
  • Now everybody should be able to work the same way: Internally in Liferay's core as well as externally, in the plugins.
  • Ant vs Maven vs others? What's the story with Liferay's supported Build environments? More energy will go into build tools other than the SDK
  • Of course we cover a release date :) I'm getting a very rough one from Ray :)

Follow @RadioLiferay, @rotty3000 (Ray) and @olafk (me) on twitter.

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:

download audio file

Radio Liferay Episode 50: Jens Bruhn - Pimp my script engine

Technical Blogs 9 de Novembro de 2015 Por Olaf Kock Staff

   Wow, 50 episodes already. At this year's Devcon I spoke with Jens Bruhn. He's Software Architect at Prodyna AG, a Liferay Partner and the author of Nabucco Script Center, a Liferay App available on the Marketplace. He also convened the "Pimp my Scripting Engine" workshop at Liferay's Devcon 2015, which I missed. But this only provided a perfect reason and excuse to speak to him.

As we recorded this on site at Devcon, you'll hear more background noise than usual - As usual, Auphonic did their best to clean the recording, and they did a great job.

For the visuals, please see the screenshots in this article as well as the plugin's homepage.

Here are some of the topics that we talked about:

  • The Elevator Pitch: What's Nabucco Script Center?
  • Scripting in Liferay: The native script console, its use and its shortcomings (solved in NSC)
  • a short demo of Script Center. It makes sense to check the screenshots alongside, or even install the plugin:
    • various scripts (for example: Reset Terms of Use Acceptance) and instruct content editors to execute this script whenever they change the actual Terms of Use Article)
    • Automatically run scripts (again, same example, this time executed automatically on every update of the article) - comparable to a model listener plugin for Liferay's Service Builder
    • Scheduled Script execution. And basic sanity checks: When deactivating user accounts, you might want to have a few exceptions to your rules, e.g. in order to not lock out administrators that can help you gaining back control, but are not logging in every day.
    • Prodyna has scripts available on the app's homepage - e.g. What happened during the last 24 hours? How many users logged in yesterday? Basic data on usage on the start page ("heartbeat"). Warn authors in time before review dates of their content. Assign permissions based on categorization of content.
    • Fine grained permissions can be granted per script, e.g. just because you're able to upload/edit a script you might not be able to execute it - and vice versa.
  • Feadback required - is this useful and what else is needed to make it more useful?
  • How to develop without and with Script Center - where can it help you in your development process. Here are the slides that we talk about:


  • Best Practices when implementing features in scripts: It's easy to accidentally make mistakes - there should be some basic safeguards.
  • Script Center offers a third option to two customization approaches mentioned my earlier blog article

Follow @RadioLiferay, @DocBruhn (Jens) and @olafk (me) on twitter.

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:

download audio file

Radio Liferay Episode 49: Tomáš Polešovský from Liferay's Security Team

Technical Blogs 3 de Novembro de 2015 Por Olaf Kock Staff

  It's been a long time and finally... Radio Liferay is back with several episodes in the queue. Today, Tomáš Polešovský starts of by talking about Liferay's security team and -procedures as well as his work within that team. Tom has already been a guest on Radio Liferay's ancient episode 9

Here are some of the topics that we talked about:

  • The glorious glamorous days one has on the security team (consisting mostly of email, tickets, pullrequests)
    • Different ways to make Liferay more secure
    • Gathering feedback from community and customers
    • Monitoring Liferay Forums and full disclosure mailing lists (also about the various libraries that are used in Liferay)
    • Scan source code for problems
  • Liferay cooperates with external security researchers for penetration testing
  • Customers perform external audits as well.
  • An example of an actual audit report: 49 very alarming false positives vs. 1 real cornercase
  • The security issue fixing process
  • The first security episode with Sam Kong
  • Link to community security update page. CE updates always only against the latest GA version
  • Some low hanging fruits in secure Liferay administration (on the fly)
    • Disable "create new accounts" if you don't want random users to create new accounts (e.g. in an intranet)
    • JSONWS access
    • Disable Control Panel, add "My Account" to user's personal pages instead
    • The securing Liferay series and "additional Resources" here
  • What will happen with Liferay 7?
  • OAuth, and the related Radio Liferay episode 44 with Stian
  • SQRL (disclaimer: I misled Tom by mispronouncing this library - he's aware, but there's no implementation - yet - for Liferay)

Follow @RadioLiferay, @topolik (Tom) and @olafk (me) on twitter.

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 leave your feedback on www.liferay.com/radio.

Or just download the MP3 here:

download audio file

Einladung zum Community Meeting in Wien/Österreich (Vienna/Austria)

Company Blogs 3 de Novembro de 2015 Por Olaf Kock Staff


Hofburg, Wien CC by-nd 2.0 by R. Halfpaap
(English summary below)

Servus nach Österreich. Mal wieder bin ich auf dem Weg nach Österreich. Aber dieses Mal komme ich nicht alleine angereist: Anlass ist dieses Mal das LPSF - oder Liferay Portal Solutions Forum - in Wien. Im Anschluss öffnen wir die Veranstaltung und laden zum Community Meeting ein. Die Veranstaltung ist frei und offen für alle Interessierten - allerdings ist eine Registrierung nötig, damit wir den Platzbedarf einschätzen können.

Am Donnerstag, 19. November um 18:00 Uhr ist es soweit. Anmeldung bitte bis 12. November per Mail an marketing-dach ät liferay.com.

Vermutlich wird das Treffen im Sofitel stattfinden, dem Veranstaltungsort des LPSF (siehe Link oben). Falls das doch nicht möglich sein sollte, benachrichtigen wir die registrierten Teilnehmer noch per Mail (in dem Fall würde es ein Veranstaltungsort in der Nähe werden).

English Summary: As it's a german language event: This is about a community meeting that will largely be held in the german language, although everybody is welcome and there are plenty of english speaking people there. If you're in Vienna/Austria, you'll be able to parse the meeting time and location from the text above. Please register 1 week in advance, so that we can let the caterer know how many people to expect.

Liferay Devcon 2015 recovery

Company Blogs 15 de Outubro de 2015 Por Olaf Kock Staff

I'm slowly back to my regular sleep rhythm, after the highly anticipated sleep deprivation week that Devcon always is. Those ~450 participants that were there and made it the biggest and greatest Devcon so far will have seen that Liferay becomes a lot more serious in terms of messaging while still staying accessible on all levels. I've seen lots of connections being made and can attest that Liferay seems to be one of the companies and products with the most accessible team in the background.

Project Managers, Engineers, Supporters, Consultants, Legal- and Sales-people have been available for customers and community. They gave information about the current product, the roadmap and collected feedback and new ideas for future versions.

We've started with the always informal and extremely productive unconference at day 0 - this format was offered for the third time and was sold out long before the event. If you want to participate next year: Be sure to register as early as possible. If you don't know what to expect at an unconference: Come and see for yourself - prepare to be surprised.

For the first time ever we also had to close the community meetup registration in order to guarantee enough space for everyone and enough air to breathe. Sorry for that to those that weren't able to come, take this as a hint that early registration really helps us to plan for such an event.

This year we introduced a new Priority Check In, welcoming Liferay Certified Developers on the red carpet they deserved, and several goodies. We'll make it even more priority next year, promised. If nothing else - take this as a motivation to be certified as a Liferay Developer before you come to Devcon next year.

Devcon itself was the biggest (by quantity as well as quality) Devcon we had so far. 450 attendees and long two days of sessions and workshops. You can find all of them in the agenda - very soon the slides and videos will be available as well.

Octoberfest, the big party at Devcon, was fun. And while James is still uncertain if there was some hidden agenda with his barrel-opening, he did a great job. Here's what could also have happened

In case you had to leave before the raffle, nothing bad has happened to you: All the winners were still present and while you missed some great content in the end, at least you didn't miss the additional luggage. I'm still wondering how some of the winners transported their prices back home.

Would you like to re-live Devcon? I want to, as I've missed so many presentations. You'll find some summary in the tweets, hashtagged with #LRDevcon, also there's a flickr-album and I'm sure that you'll find other resources. Stay tuned for the Recap Site, which will be updated once all the material is ready and the video recordings are postprocessed. I've recorded several episodes for Radio Liferay, which will be published during the next weeks.

If you have more photos that you took during the event, please upload them through the app and they'll appear in the flickr stream.

And if you missed the event due to continental restrictions, consider to come to the North American Symposium in November in Chicago or Brazil Symposium in São Paulo. If it were only national restrictions we have more european options with technical sessions this year in Spain, UK and Italy. Or just keep updated on everything - business and technical - on our events page.

Thank you

A big Thank You goes to the team that made this all possible. If you want to express your gratitude, flood @PBrusset and @Thirelu with your thank-you-tweets (or postcards to the german office) - Pascal and Ruth did the heavy lifting, supported by a big team. They will forward your notes to the whole team.

The right tool for the job? Chapter 2: Customizing a Core Portlet

Company Blogs 5 de Outubro de 2015 Por Olaf Kock Staff

Liferay comes with so many features that it's hard to judge when a feature is a good solution for a given problem. I'd like to shine some light onto some of these features and common misconceptions about them because it's easy to abuse them for purposes for which they're not well suited - despite making the impression they might.
CC BY-ND 2.0 by S. Benno

This chapter is about modifications that are commonly done to Liferay's out-of-the-box portlets.

It's easy to modify the OOTB-portlets: For the UI side you can introduce JSP hooks. On the action-handling side, you can override Struts-Actions (for example). You can go even further and fiddle with request parameters (e.g. in servlet filters), but let's keep it at the first two options for now.

Why does Liferay's Portlet not do what I want?

Liferay (the portal) is a platform that must be everything to everybody. As a platform vendor, Liferay (the company) must implement Liferay (the portal) with as broad applicability as possible. You (the implementor of a specific portal) on the other hand typically need to focus on one very specific problem: Your portal. You don't need all this flexibility and configurability beyond your own usecases. You're just interested in implementing your own requirements.

Consequently, some of Liferay's implementations might be overly generic for you. You can be happy that they are, because that means that there's a very good chance that there's an overlap with your requirements. And if it isn't big enough an overlap, you can still customize Liferay's portlets and UI to match your requirements. Knowing that you can change the UI with "just a simple JSP hook" is tempting. If all you need is a simple change to a simple UI, go for it. The more complex either your change or the changed Liferay component is, the more you should refrain from such a quick fix.

What to do when OOTB is not enough?

So what - you need a change to a complex UI. There are JSP-Hooks and Struts Action overloads. They might do what you want, and are readily available, quickly done. Are they always the tools that you should use? Well...

There are two aspects that you should keep in mind when thinking about JSP hooks and changing Liferay's OOTB-portlets in general: Maintainability of your changes and the fact that customizations are global to the whole portal. Any customization that you're doing to a portlet will be available everywhere (I'm ignoring Application Adapters here, but you'll get the point).

The elephant in the room is Maintainability. If you're looking at Liferay's JSPs, most of them - especially the more flexible, configurable ones - are not the files that you want to touch. Imagine yourself changing them, and then receiving an update from Liferay. Be it the next CE GA version or the next EE Servicepack. When this update changes the file that you've customized as well, you're up for a three-way merge. Enjoy. Potentially on every update. Rinse, repeat. Probably not what you're looking forward for.

What other options do you have?

All other things being equal (which they never are), I personally value maintainability higher than any other aspect of a customization. Particularly higher than quick implementation. For that reason, sometimes I rather suggest custom portlets that do exactly what you want them to do - no configuration, no nothing. Consider the options: For something that's close, but not 100% of Asset Publisher, you can hard code exactly the functionality that you'd like to see in your own tiny custom hard-coded portlet, or modify Asset Publisher to pay attention to just one more option.

If you know Liferay, you'll know that Asset Publisher is a very powerful portlet, possibly the one with the most configuration options. Maintaining your changes in Asset Publisher's JSPs will be really hard - particularly because there are so many conditions that need to be taken care of. Typically a more complex component attracts more bugfixes than a very simple component, so the odds of three-way-merges are quite high. Writing your own hard coded plugin on the other hand is guaranteed not to interfere with any future updates of Liferay.

Have you just heard a suggestion to hard-code portlets?

Yes indeed. Hardcode as much as makes sense in your portal: In your portal, you need to take care of your requirements. Your requirements are typically not as broad as Liferay's. You don't (always) need to implement a generically configurable system. At least you don't need the configurability to the same level as Liferay does. Where Liferay needs an "Asset Publisher" (just the name is quite abstract), you might need an "Interesting Facts" portlet. The criteria for interesting facts can totally be hardcoded - you might want to configure the number of items shown, maybe some more, but not 20+ options like Asset Publisher does.

If all you have is a hammer...

...the world looks like a nail. This article is meant to add more tools to your toolbox. Just because Liferay makes its UI available for customizations this doesn't mean you must always use this technique to implement your customizations. Create your own simple navigation portlet, if Liferay's is insufficient for you. Create your Web Content filter by accessing the CMS-API instead of modifying Asset Publisher. Think simple, think maintainable. The more of the core you change, the harder you'll resist to updating your portal, even on a minor update - let alone on a security update. And that will bite you sooner or later.

If the message sounds vaguely familiar, here it is again, with a more specific example. And yes, the complexity that I'm suggesting here is: A few hours of creativity for creating the new plugin, rather than the same hours of trying to understand and patch any of Liferay's existing portlets.

You can still do that, but choose wisely when you'll actually change vs when you create your own portlet. Whatever you do: Remember that most effort will go into the maintenance of your code. Optimize the maintenance time.

Overriding features from different Hooks - Chapter 2: Struts Actions

Company Blogs 25 de Setembro de 2015 Por Olaf Kock Staff

Do you remember the article that I wrote in March? It talked about Liferay's limitation to have each overloaded JSP only customizable from one hook. The limitation was not enforced, so deploying multiple hooks that overload the same JSP lead to undefined behaviour, potentially deleting the original JSP.
CC BY 2.0 by David Goehring
Luckily that has been fixed (currently in EE only, feature needs to be enabled), but I still like my version better: It's more verbose in its error messages. And then - there's more: The very same limitation (albeit not as destructive) is in effect for Struts Actions: If you override the same Struts Action from two different plugins, the last deployed plugin wins, the first one's Action will be forgotten. And when we inspect this further, we have some undefined behaviour as well: Let's say Hook A and Hook B override the same Struts Action and are deployed in that order. Now only Hook B's version will ever be executed (as it was deployed last).

In case Hook A is now undeployed, the runtime system will detect that Hook A intended to override the Struts Action and remove the customization. Now, despite the fact that Hook B is still deployed, its Struts Override is no longer deployed. Luckily, this is not destructive like with JSPs, but you might still pull out your hair when you're debugging such a situation. Let me save your hair - I know how it feels to walk around with little hair. Mine is not enough (and too short) to pull it out:

An updated HookDeployer \o/

The hook that I've presented in the old blog article received an update and now is aware of Struts Actions. You can go to github, build the ext plugin and deploy it. Be aware that the code is "Proof of Concept" quality.
CC BY 2.0 by David Goehring and yours truly
Before using it in production you should really validate that it does what you expect.

About the implementation

If you look at the code, you'll see that there's a relatively small class that just does the checking. In case everything is right, it delegates to the original deployer. This is why I expect this code to be compatible with all 6.2 releases (and potentially even 6.1 without checking). One way to write maintainable ext plugins is to add new code in new classes and delegate to the original classes: If the original classes are changed in some future release, the additional code has a good chance to go without changes. It's Liferay's business to change the implementation, thus I've avoided to change the original HookHotDeployListener class.

Check out the code on github - fork and send pullrequests: Again, note the "Proof Of Concept" disclaimer. Please try, test & inspect on it out on your platform & version. I deliberately won't tell you which version I've tested it on to force you to test :)

Like in March (this is the same plugin as back then): I can't make it available on marketplace, as it's an ext-plugin. Sorry.

It's Event Season again

Company Blogs 27 de Agosto de 2015 Por Olaf Kock Staff

It looks like I'll stay on this™ side of the atlantic ocean this year, so I'm concentrating on introducing the big events that I'm attending next and link to the others, in the hope that I'm not missing any. If you are in other parts of the world: All of our events are worth going to and you'll get your personal share of ideas, contacts and great conversations.

I got my first share of Liferay knowledge during one of these events (yes, it was a while ago) - and since then, all the events continued to amaze me on communication of knowledge as well as on getting to know other customers as well as Liferay staff. This is the prime opportunity to meet&greet and get your questions answered.

We will open the season with another great combination in Darmstadt/Germany. For the second year in a row we're having Liferay Portal Solutions Forum and the Liferay Developer Conference in the same venue in Darmstadt - and I'm looking forward to your participation. Here's what the two events are about

Liferay Portal Solutions Forum Germany

This is a german language event, focussed on the business side of Liferay. Due to the event language, it feels appropriate to announce it in german language. If you don't understand this next block, the event is not for you, but scroll down past the box, there's more. If you do understand it and it resonates: Register.

Neue Möglichkeiten der Digitalisierung

Auf dem Liferay Portal Solutions Forum am 6. Oktober 2015 erwarten Sie spannende Anwendervorträge namhafter Großunternehmen, innovativer Mittelständler sowie weiterer Organisationen, die mit Liferay ihre digitale Business Strategie aufbauen.

  • Praxisvorträge von Liferay Kunden liefern Einblicke in Erfahrungen und Projekte auf Basis des Liferay Enterprise Portals
  • Keynote von Liferay CEO Bryan Cheung zur Vision von Liferay
  • Aktuelle Liferay Produkt-Informationen und Ausblick auf Liferay 7.0
  • Keynote von Prof. Dr. Alexander Rossmann, Universität Reutlingen zum Thema “Digital Business”
  • Moderierte Expert Exchange Gruppen
  • One-on-One-Consulting - Ihre Gelegenheit alle Ihre Fragen zu klären

More information on the event's homepage

Liferay Devcon

The technical event for Enterprise IT and Devs on 7.-8. October 2015. Meet the community, learn everything there is to Liferay on the technical side. Come one day early to the Unconference (but hurry, it's already almost sold out)

Lets meet at DEVCON 2015

Featuring over 40 in-depth sessions and technical workshops, the 2-day Liferay Developer Conference is a great opportunity to build your Liferay expertise and apply fresh knowledge and perspectives to your current and future projects. Watch our our recap video and learn more.

More information on the event's homepage. Note that Early Bird Registration savings are open until 11. September, but the Unconference will probably sell out sooner than that is already sold out - We'll register on a first-come, first-served basis.

There are great savings if you register early, in groups, as Liferay customers or as a repeat guest (Alumni). Don't miss them.

If you're coming to Devcon, note that there's yet another Community Meetup in Darmstadt the night before DevCon (6. October). Registration is free and necessary if you want to get free drink vouchers. (If you have been at those events earlier, you'll know the drill)

Other events

I promised you, we have more. Some are later this year, some are on the "other" side of the ocean (it's all a matter of standpoint). Here's what you should pay attention to if LPSF-DACH and Devcon are not for you due to continental or language restrictions - and no regret if you can't meet me there (quite ego-centric, huh?) - my other colleagues and the community of Liferay-Users are well worth meeting too - say "Hi" from me ;)

Liferay Symposium Spain

21.-22. October 2015, Madrid

Liferay Portal Solutions Forum - UK

5. November, London

Liferay Symposium Italy

12.-13. November, Firenze

Liferay Symposium North America

16.-17. November, Chicago

Liferay Symposium Brazil

2.-3. December 2015, São Paulo

The Learning Curve, Chapter 7 - Training

Company Blogs 26 de Junho de 2015 Por Olaf Kock Staff

Are you new to Liferay? Found Liferay and want to know what it can do for you? Or are you with Liferay and still remember the time when you were new and unexperienced? Where did you come from and what was the biggest problem you faced? Can you ever learn enough? And how do you keep up with the current trends and new features?

A platform as big as Liferay spans several technologies and areas of best practices that are beneficial to know of. Nobody can know everything - there's always a learning curve. At the beginning, it's quite steep. Some argue that it's flattening the more you know. Some argue that it gets steeper: The more you know, the more you know what you don't know.

I'd like to give you pointers to resources that are available to you, in order to learn about Liferay, resources that help you avoid steep detours, when there are flatter direct connections. This is meant to be (eventually) comprehensive but I'm sure that it will never be complete. It's just what I remember while I write this article, the previous ones in the series and the follow ups (yes, there are more, see the list at the end)

Today's Target Audience: Today there will be something for everybody

As this is all about training, let me start with an actual story from one of the trainings that I led. This is a good summary of the reason to consider working with a well-trained team:

My (best, but) least anticipated training experience

Once upon a time (back in 2011, one and a half year after I became a Liferay Trainer) I was sent to a customer to conduct an onsite "Portal Administrator" training with their development team (The name of this class recently changed to "Mastering Liferay Fundamentals"). The team that I was meant to train was highly experienced in Liferay, developed plugins and customizations for solid three years back then. They've had high-profile Liferay people on site, among them even one of our core engineers that we never send out (don't ask).

Now, "Mastering Fundamentals" is basically giving an overview over what Liferay can do - the whole backend, user management, page management, sites, organizations, portlets and out-of-the-box functionality. It's approaching everything from the feature- and front-end side. It felt like 3 years too late for that team - they must have found every single feature already long time ago - or so I thought. Trust me, I was really nervous. I expected getting through the class in record time, followed by a lot of complex and challenging questions on their project. (not that I'd mind challenging questions, but I didn't know their project at all. And I like to make a good impression)

Instead of finishing early and lots of complicated questions, we finished the class right in time (after two days), with the participants constantly checking back to each other - "Wow - did you know Liferay can do this? Remember how it took us 3 weeks to implement similar functionality? And now we'll have to maintain that code". I was stunned.

So, what do we learn from this story?

Even as a well experienced developer it makes sense to get the a nontechnical introduction to the platform. If the only toolset you have at hand is your compiler, you'll think along its lines. If you know what you build on, know the infrastructure that you're integrating with, you can use it to your advantage and just configure it to make the required features available. Maybe tweak them a bit.

Of course a developer can solve all problems you throw at them, typically with some more code. But new code might not always be the best way to solve every problem. If all you have is a hammer, the world looks like a nail.

And, by the way, some years later, one of those students recognized their class when I told this story at an event (without revealing their identity). He confirmed that they had the same experience.

The best maintainable software feature is one that you don't need to write, because it's already done. Know what's available for your to tweak and you can utilize it with ridiculously low effort.

So - what are your options?

Liferay has several training classes, readily available. You can either join us at one of the public trainings or schedule a trainer to come to your location and have a private training with just your team. Let's go through them and identify the target audiences. For a full description I've linked the full course topics and contents in the headlines:

Mastering Liferay Fundamentals

This is the class that the story above was about. Fundamentals are really good for everybody who has a saying in the structure of a portal. Those who will have to configure Liferay to meet the needs of all stakeholders. You'll learn about many features that Liferay has out-of-the-box.

It's also a great way to make sure you don't develop the same features that Liferay already brings with it - so at least some of your developers should have a deeper knowledge of the platform.

This course is also offered online. The online version is spanning three days, with the afternoons free of class.

Developing for the Liferay Platform 1

Any portal/portlet developer should know what we cover in this course. From relating the portlet API to the servlet API over service builder, utilizing Liferay MVC, Liferay's runtime-configurable permission system and customizing Liferay on many different levels, it provides the basic tools to explore Liferay from an API point of view.

It's encouraged to have visited Mastering Fundamentals upfront (see my story), but not mandatory.

With this course you'll be able to write your own applications, extend Liferay and know where to look for when you want to customize it. It should contain most (apart from some experience and routine) of what you need for getting certified as "Certified Professional Developer" .

From the feedback that I've had about "Developer 1" training: Everybody has gotten something from that class - even the more experienced developers that thought they already know everything. In fact, we're coming with several interesting bonus exercises for the more experienced students so that you definitely don't get bored just because you're quicker than the newbies.

Administering Liferay Systems

Are you setting up Liferay systems? Configure them? If you're responsible for maintaining, tuning, backing up and the general server health, this is your class. You'll learn about all of these topics, set up a cluster, and get to pick the brain of an experienced trainer on so many topics. We'll come with a ready-to-go VM, but you can also bring your own appserver and database for installation.

Styling Liferay with Themes

Your portal should look like your portal. To adopt the Look&Feel you'll need a theme - this is the one custom plugin that everybody typically has. We'll cover the basic structure of Liferay's themes, principles and building blocks and build a custom theme. This covers best practices, responsive layouts, tipps & tricks and more. Naturally, the result won't look like your CI, but you'll have experienced all the different extension points and can easily use this knowledge for the implementation of your own theme.

Some HTML and CSS knowledge is required - we'll just adopt it to the Liferay world and help you build a well maintainable theme.

Managing Content with Liferay

If you're responsible for the content side of Liferay, you might want to learn more about its CMS, go in depth in workflow, the Asset Framework, Structured content, Staging and how to build and maintain the content of your portal. This class is for you then. We're setting up Liferay on your own computer so that you go home with your own installation and can continue working on it after the class.

Developing for the Liferay Platform 2

It's number 2, so it must be more advanced than number 1, right? Well, this class starts exactly where "Developing for the Liferay Platform 1" stops and picks up the resulting code from that course, refining it further. If your portal makes good use of Liferay's internal concepts like Assets, Workflow and features like Rating, Commenting, this course is for you. Same if you want to be even better prepared for the certification.

Just remember: You really should take the first course before the second as all the ground works is layed out there and your trainer might not explain the "old" concepts and code again (out of respect for those who indeed have been in "Developer 1").

Who's the trainer?

All of Liferay's classes are led by experienced trainers. When we're certifying trainers, we're paying attention to their experience as well as their teaching style. Every trainer is able to go beyond just covering the course curriculum. So, of course you should bring your questions with you.

Check the list of upcoming trainings in your region, timezone and language. Also, check the shiny badges on the personal profile page (here's mine) that you can show off with. You'll get them after each of the trainings that I mentioned if you take them straight from the source - Liferay - or from one of our certified training partners.

Community Meeting in Wien/Österreich (Vienna/Austria)

Company Blogs 23 de Junho de 2015 Por Olaf Kock Staff


Hofburg, Wien CC by-nd 2.0 by R. Halfpaap
Servus nach Österreich. Kurzfristig verschlägt es mich wieder nach Wien und was ist schöner, als sich dort mit freundlichen Menschen zu treffen, die das gleiche Gesprächsthema haben.

Am Mittwoch, 1. Juli, 18:30 Uhr ist es soweit. Anmeldung (damit ich weiß, ob wir einen Tisch oder Ballsaal benötigen) bitte per Kommentar hier, twitter (@olafk) oder per Mail (olaf.kock ät liferay.com).

Ich suche noch einen Ort und werde diesen Artikel aktualisieren, sobald wir einen gefunden haben.

Die Entscheidung ist gefallen: Wir treffen uns im Universitätsbräuhaus, Alser Straße 4, 1090 Wien.

Community Meeting in München (Munich) / Germany

General Blogs 12 de Maio de 2015 Por Olaf Kock Staff

Update! Wir treffen uns am Donnerstag, 21. Mai 2015, 18:30 Uhr in den Räumen der Inovex GmbH: Valentin-Linhof-Straße 2, 81829 München - Vielen Dank für die Unterstützung an Peter Dimitri von Inovex. Zur Planung des benötigten Platzes: frühzeitige Anmeldung via meetup erbeten!

munich (symbolic)
Community Meeting in München (Symbolbild)
CC-by-2.0 by Jason Paris
Aufgrund des Veranstaltungsortes werden wir auch Vorträge einplanen. Auch für Diskussionen wird genug Raum, Zeit und Möglichkeit vorhanden sein.

In English: Servus, Grüezi und Hallo to the Liferay Community in and around the southern parts of Germany. I'd like to call for another community meeting in Munich (illustration similar). Due to the location this will most likely be interesting for the german speaking community and I'll continue this post in german language. Feel free to come even if you don't speak german.

Updates hier und immer wieder zwischendurch via @olafk. Vielen Dank an Inovex GmbH für das Sponsoring.

The right tool for the job? Chapter 1: Instances

Company Blogs 18 de Março de 2015 Por Olaf Kock Staff

Liferay comes with so many features that it's hard to judge when a feature is a good solution for a given problem. I'd like to shine some light onto some of these features and common misconceptions about them because it's easy to abuse them for purposes for which they're not well suited - despite making the impression they might.
CC BY-ND 2.0 by S. Benno

Today I'm starting with Liferay Instances.

TL;DR? Skip to the last paragraph, giving the common "wrong problems" that instances are used to solve. While they are a great feature, they don't necessarily solve all of the problems they get thrown at in the expected way.

What is an instance?

If you go to Control Panel / Configuration / Portal Instances, you'll find the list of available instances and can add more. A new instance is introducing a totally separate data area - you'll have a new user database, new content, new sites etc. They have nothing in common with the other instances that you have in the portal. Nothing? Well, they share the same application server - so at least the portlets and plugins are shared, and naturally the maintenance intervals & downtime. But, on the data side: Nothing.

As you would expect, Liferay starts with a single instance that is used to handle all requests. Only if you actively introduce a second instance, you'll use multiple instances. The reason for this is that instances are detected through the server name: If you connect to the server depicted above with spaceprogram.liferay.com, the server will serve with the content of the second instance. All hostnames that can't be associated will be handled by the default instance.

This is called multi-tenancy. You may have multiple portals on a single application server. Great, isn't it?

Using Multiple Instances

Now assume you're providing services for multiple customers. You have your first customer's portal running at customer1.example.com in the first instance and you'd like to add customer2.example.com as a completely separated portal: Neither the content, nor the user administration should interfere with each other.

On first sight, you'd easily just introduce another instance named customer2.example.com and populate it with the required data - done. Two customers, two instances.

That was too easy, wasn't it? Where's the shortcoming?

Well, you'll end up with two instances with different features - one is more special than the other

Different features?

The first instance on Liferay is a special instance: It enables you to administer the application server (garbage collection, reindex search index, show memory consumption), install new plugins, access marketplace, etc.

Compare this part of the Control Panel of the first instance

with the same part of the second instance: You'll easily see that all of the server administration, application installation etc. is only to be found on the very first instance. (I promise that I'm logged in as Administrator on both instances).

As long as your first customer is not more special than your second one (and allowed to administer infrastructure for all of them), you might want to limit yourself to a particular different use of instances:

Make the first instance a purely administrative instance, e.g. administration.example.com. Then add all of your customer's sites as secondary (tertiary etc) instances. You'll end up with n+1 instances. The default instance should only have a few administrative users, while the other instances have whatever those instances need.

Now your first instance's administrators can maintain the whole site while your customer's administrators can't install server side plugins and maintain them - great, because the plugins are always available to all other sites, and they might not even know whom they share the server with. Imagine your customer1 to update customer2's theme... (see comments below)

Commonalities and Differences

Remember, all instances still share the same server. If one of the instances is really busy, the performance of the others might go down with it. If one requires downtime for updating a component, the others will go down with it. If one of the customers needs a specific plugin to be deployed, all of the customers will get it.

On a firewall level: If one of the instances needs access to a particular backend system (of customer1), connections to it will originate "at Liferay", thus no firewall can detect which instance the connection is coming from.

Separating instances

What happens when - some time in the future - you want to separate the instances from each other? If you follow my suggestion to have an administrative instance as first instance, life is (relatively) easy: Create a copy of your whole portal (all instances) and delete all the unused customer's instances from each of the instances. You'll end up with two portal servers with an administrative instance (which is a copy of each other).

Everything well? Or the wrong problem or the wrong solution?

Shiny, huh? But do instances solve all of your problems?

They can easily simulate to solve them. But they can also trick you into believing that they're a good solution. More often than not they aren't. Let's look at some shortcomings and issues that you should be aware of:

  • You'll have to administer each Instance as if it was a new portal: User Management, Single Sign On, User Profiles, Groups, Roles, Templates, ADTs, everything. If you update any in one instance, they won't be updated in the others. This might be what you expect, or it might be doubling your work. Typically it's some of both.
  • All instances share the same plugins (and their versions). If your customers use plugins that contain business logic specifically for them, this business logic might accidentally be published on other customer's instances. Themes and Hooks are shared between all instances as well - don't select your customer1-theme for the sites of customer2. Check the comments: You can limit your theme to specific instances
  • If one of your instances is really popular and draws a lot of traffic (enough to slow down the site), the other instances will also suffer performance and your customers might not be happy if you can't quickly serve their few web visitors.
  • If you need to cluster one instance, you must cluster all of them. Liferay's caches need to be dimensioned properly to serve the commonly requested content for all instances.
  • Some of Liferay's content types (e.g. ADTs, Web Content Templates) execute server side code. When these are done inappropriately, they might make it possible for customers to access other instance's data. You'll need to trust the individual Administrators with permissions to edit these content types to not do harm to others.
  • Instances always assume that you can predetermine the host names that users are using. You should not make your administrative site available to the internet as "the default" when you don't know the host. Thus there's some extra work that IMHO requires a webserver in front of the appserver. But that's good practice anyway.

Did I forget something?

Did this discourage you from using instances? It shouldn't - it just should help you make an informed decision when you consider using them and how.

Overriding JSPs from multiple hooks - promising the cure

Company Blogs 17 de Março de 2015 Por Olaf Kock Staff

One message that I have to give out in trainings doesn't fail to stun the students: When you deploy multiple hooks that override the same JSP in Liferay, you will first get undefined behavior and later end up with a damaged installation.
CC BY 2.0 by David Goehring
When you are installing applications from Liferay's marketplace you don't even have control over the JSPs that these apps change. And there seem to be certain hotspots that everybody wants to change - experiencing a conflict is merely a question of time.

Out of the box you'll have to deal with this behavior on an organizational level - there's no safeguard, no tool, no oversight - not even logging - in Liferay. Yes, I admit: this is a shortcoming of the platform. And it puzzled me so often that I finally took action to solve this problem. After all, you can change any behavior of Liferay, right?

What's the problem?

Let's say you want to override /test/view.jsp. When you deploy the hook, Liferay will rename the original file to /test/view.portal.jsp and use your patched one as the new /test/view.jsp. Great - now you can include the original file from yours and add your changes (if you want). Undeploy of the hook reverses the process. Smart, right?

One problem now is that this is a one-step process:
CC BY 2.0 by David Goehring and yours truly
If you deploy a second hook overriding the same file, the mentioned procedure will repeat. In that process the original /test/view.jsp (later /test/view.portal.jsp) will be overwritten and lost forever. Now undeploy both hooks and no  /test/view.jsp is left. Did I tell you that deployment order of hooks is not guaranteed, so you never know what you end up with?

And the solution?

Due to the nature of hooks (deployment order not guaranteed), the solution must tie deeper into Liferay and an ext-plugin is in order: We need code that is running before the first hook is deployed. This will replace your original hook deployer with a safeguarding version - first testing for conflicts and denying deployment if there is any duplicate overridden JSP. Granted, it will not magically make everything work, but it will keep you from destroying your installation.

Check out the code on github - fork and send pullrequests: Beware, it's currently meant as a proof of concept. Please test, try & pound on it out on your platform & version. I have built and tested on 6.2 EE SP8, but due to the nature of the code it is probably working well on other versions and on CE with little or no change at all.

Due to being an ext-plugin this can't be made available on marketplace, but we can try it out here (and in future articles if necessary).

About the code

I've started with patching HookHotDeploymentListener.java - but when you look at that class you'll see that it's not meant to be extended. For all future upgrades this would have resulted in three-way-merges. And I hate three-way-merges. Thus I've changed the implementation to a wrapper. The new CheckingHookHotDeploymentListener just does its sanity check before delegating execution to the original HookHotDeploymentListener.

If you have your own ext-plugin already, you might want to move it in there, because I also need to override portal-ext.properties in order to replace the original hotdeploylistener: Each file (like portal-ext.properties) can be overridden from only one ext-plugin and the odds are that you want to change the same file anyway - portal-ext.properties is among the very popular hotspots for ext-changes.

Please give feedback and help testing it on other versions. There might be a distributable result if you help. And based on the twitter feedback (and the stunned faces in training) there seems to be a demand for this functionality.

I already have a portlet that shows the list of rejected contexts to the control panel and will share it soon. Find it on github as well. It will add itself to the Apps section of Control Panel. Until then you'll have to stick with the log output. For testing just create a few hooks that modify a new, currently unknown jsp and deploy them all - see if you can break it.

Update: Oh, look at this

Dragging and dropping portlets

Company Blogs 18 de Fevereiro de 2015 Por Olaf Kock Staff

This is a repeat post - same topic as in July 2013, when I've solved exactly the same problem on Liferay 6.1. Now it's time to update the solution to Liferay 6.2. But I am ahead of myself: What seems to be the problem?

Liferay offers various layout templates that determine how the portlets are arranged on the page. When you build a Liferay page, you can drag&drop portlets on the page, according to the layout template. But it's not always obvious, where you can drop portlets. And if you happen to not know the layout template that has been chosen for the current page, you might not even know that there's another column or row. Especially when you have one of the multiple row layout templates.

Try it: Choose one of the layouts from that screenshot on the right, then drag&drop portlets: The only indicator you have is the blue line. Nothing indicates the additional row that still might be available unless you happen to hover over it.

Wouldn't it be nice to have all of the columns well visible - at least while you're dragging & dropping portlets? Like this "Hello World" portlet that's currently being dragged (note that the dotted style doesn't really show in this scaled image. Yes, I should have chosen a different border style. View that full image to see the unscaled version, or use your CSS imagination):

In 6.1, all the required CSS was available in the default theme, thus you only needed some javascript to add to the page. In 6.2 I couldn't find the CSS any more, thus I've had to add some custom rules. Do this in your theme, or just adhoc on the page (Site Administration/Pages/Look&Feel). You will need CSS like this:

And in addition, the same javascript that I mentioned in that old article still works (and is required as well). To try it out immediately, just go to "Site Administration/Pages/Javascript", then paste this code:

That's it, you're set: To persist the settings and have them available always, add these few lines to your themes and from then on even your inexperienced page maintainers will always easily identify the drop zones for portlets.

If you wonder what I'm doing when I'm travelling by train - this is an example. And as I am able to "make things look different" rather than "make things look nice", you might want to post some nicer CSS fragments as comment to this article.

Oh, and fyi: I've filed this as LPS-53664 so that there's a chance for it to be fixed soon - or at least for 7.0. I'll just have to find some time to do it yet again, on master. And, thanks to Daniel, there's also a CSS-only version that I've missed when I ported the 6.1 solution:

The Learning Curve, Chapter 6 - Java Web Development

Company Blogs 18 de Fevereiro de 2015 Por Olaf Kock Staff

Are you new to Liferay? Found Liferay and want to know what it can do for you? Or are you with Liferay and still remember the time when you were new and unexperienced? Where did you come from and what was the biggest problem you faced? Can you ever learn enough? And how do you keep up with the current trends and new features?

A platform as big as Liferay spans several technologies and areas of best practices that are beneficial to know of. Nobody can know everything - there's always a learning curve. At the beginning, it's quite steep. Some argue that it's flattening the more you know. Some argue that it gets steeper: The more you know, the more you know what you don't know.

I'd like to give you pointers to resources that are available to you, in order to learn about Liferay, resources that help you avoid steep detours, when there are flatter direct connections. This is meant to be (eventually) comprehensive but I'm sure that it will never be complete. It's just what I remember while I write this article and the follow ups (yes, there are more, already drafted)

Today's Target Audience: Developers, new to Liferay

Java Web Technology

You new Developers will have to know some things about the internals of an Application server. Don't worry, not the implementation, but the Servlet Specification (which assumes that you know Java). In a Java Application, you typically deal with a lot of different classloaders - no difference in Liferay, although this is mostly abstracted away. In some random cases it's coming back at you though.

Where to learn about the Servlet Specification? The spec is going back quite far - it's been updated a few times, but I can't even remember how I learnt it back when I did. I'm relying on suggestions in this article's comments on what resources to recommend (and why). I know there are trainings offered, you can even get certified. IMHO nothing beats experience. So even after you've read a book or been in training: You want to get your hands dirty and actually use that knowledge in practice. (and while you're at it, it's probably good to learn the basics of JSPs). After all, a typical plugin to Liferay starts as nothing else but yet another web application on the same server.

Having some experience in Java and Java Web Development is the precondition to take Liferay Developer Training 1, where we help you map that knowledge onto the portal world. From a comparison of portlets to servlets, JSR-286, through an introduction of service builder and the Liferay API and into extending Liferay through Themes, Layout Templates, Hooks and Ext plugins, you'll have some time to learn the basics of everything - hands on - and can ask your questions to an experienced trainer. Check the schedule for the next available public trainings in your area.

This training also covers most of what's required for becoming a Liferay 6.2 Certified Professional Developer. Add some experience and routine and the certification should be a breeze.

Choosing and learning Frameworks

Did I really just mandate knowledge of servlets? Well, knowing them really makes it easy to transfer the existing knowledge to portlets. But do you want to develop application logic in servlets, or in portlets that are nothing more than the Portlet-Spec implementation? Most likely not.

There's a lot of frameworks for you to choose - but even then: To debug your code and understand application classloader problems, experience with raw servlets sometimes brings you a long way solving problems, or just understanding answers that you get on random places on the internet.


CC BY 3.0 (by Oliver Widder, geek&poke)

Liferay does not mandate any UI technology or framework for you to use. You should pick one of the existing frameworks - they're all good and have different pros and cons. Liferay Portlet MVC? JSF? Vaadin? Spring (portlet) MVC? All fine. Any that I've not named here? Probably also fine - there are too many frameworks to name them here and compare them in a single blog post.

If you're looking at Liferay's implementation, you'll find plenty of JSPs as well as Liferay's MVC portlet and some use of Struts. This, however, does not imply anything for your own applications and portlets - if you're embarrassed to see Struts in use: Don't worry - there's not a lot of it and you don't get in contact with unless you specifically customize existing functionality implemented in struts. Liferay is agnostic to the framework you use in your extensions and plugins. Choose whatever you're most familiar with. If you're not familiar with one framework: Check back with your team. Or just pick one. SRSLY - it's your choice.

More?

Planned for next chapters:

  • Training
  • The search engine of your least distrust
  • Asking questions on the community forums and other platforms.

For more "Learning Curve" tips, check the previous chapters (listed below, under "Related")

Community Meeting in Wien

General Blogs 27 de Janeiro de 2015 Por Olaf Kock Staff

Ich bin mal wieder auf Reisen - und zwar in Wien. Und welche bessere Gelegenheit Land und Leute kennenzulernen gibt es, als ein Liferay Community Meeting (oder Radio Liferay Hörertreffen)?
Hofburg, Wien CC by-nd 2.0 by R. Halfpaap
Es gibt keine Agenda, aber mit Liferay wahrscheinlich ein gemeinsames Gesprächsthema. Anmeldung erbeten (dann kümmere ich mich um Platzreservierung und Getränke) per Kommentar unter diesem Blogpost (bevorzugt), email an olaf punkt kock ät liferay.com oder tweet an @olafk. Bitte so früh wie möglich und hoffentlich nicht weniger als 24 Stunden vorher.

Wir treffen uns am Dienstag, 3. Februar um 19 Uhr im Bierteufl, Ungargasse 5.

Die ganz Schnellen können sich auch noch für das "Mastering Liferay Fundamentals" Training am 2.+3, Februar anmelden - Anmeldeschluss für das Training ist morgen, Mittwoch der 28. Januar.

English summary:

We'll have a community meeting in Vienna/Austria. Identify date/time/location above and register (by commenting on this blogpost) if you intend to come and want me to pay for beer.

Radio Liferay Episode 48: James Falkner on Release Plans and the 6.2 CE GA3 release

Company Blogs 20 de Janeiro de 2015 Por Olaf Kock Staff

  A short Inbetweenisode on the release of 6.2 CE GA3 with repeat guest and Community Manager James Falkner. During Devcon James promised the release for the 15. January - while I stated that this release date was wishful thinking. Now we actually hit the promised release date for the first time known to both of us. Enough reason to get together and talk about the underlying cause and intents.

We're talking about general release practice and the plan that was put together last October, how Liferay CE will be delivered and how we're preparing to meet the promise. There's a 6 month release plan for new CE releases - and there will continue to be only one updated version of CE, e.g. once 7.0 is out, there won't be any more updates to 6.2 CE. If you need long term stability and support you should shoot for an Enterprise Edition subscription. This ensures your support for 5 years from release.

We also talk about the next release dates, how to get issues scheduled for that release (hint: Get votes on the issue, talk about it). Also, you get new ideas and features into the next release by rolling the drum for your idea - file an issue and do some marketing for it. This way it will float to the top and get recognized.

James has a quite thorough blog article about the content of 6.2 GA3 which contains quite a lot of fixed issues and - as is typical for maintenance releases - no new features.

To keep up to date on what to expect for Liferay 7.0, keep an eye on the milestones (coming out every 2 months) and Jorge's blog articles about them.

Follow @RadioLiferay, @schtool (James) and @olafk (me) on twitter.

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 leave your feedback on www.liferay.com/radio.

Or just download the MP3 here:

download audio file

Mostrando 1 - 20 de 111 resultados.
Items 20
de 6