dissabte, 23 juliol de 2011

Zeep o'Tron for Liferay 6

Hi back!

Since my last post I've received some requests about a working sample for Liferay 6. Ok then...here it goes!
First there are some things I have to tell you....

Since some libraries and packages have changed from Liferay 5.2.3 to Liferay 6, I had to do some refactoring, so, taking advantage of this, I've made some modifications to the Zeep o'Tron version for Liferay 5.2.3.

As I told in some other posts, one of the features of Zeep o'Tron was the possibility to override/add your own Spring beans to Liferay core. Since Liferay already provides the possibility to add your own services through the service tag in hook's definition files, I've eliminated this feature from Zeep o'Tron. Maybe I missed something when taking that decision, so, if you think of any situation where adding your own Spring beans could be an advantage, just let me know, and I'll put it back.

Another thing that has been changed is the way Struts and Tiles configurations are loaded. In previous version, Zeep o'Tron just scanned any deployed hook for classes and libs and added them to Liferay's classloader, then, looked for a "struts-config.xml" file under hook's WEB-INF directory, scanned it, and added those configs to Liferay's struts configs. Finally, searched for a "tiles-defs.xml" file, under the same directory, and added those Tiles configurations to Liferay's Tiles configurations.
Thinking about it, I find it too much aggressive, I mean Zeep o'Tron  was applied to each and every deployed hook, and, sometimes, it makes no sense. That's why I've decided to modify the version for Liferay 6 to make it work different, so that not only you can choose which hooks will be parsed by Zeep o'Tron, but which kind of configurations you want to be loaded, and which files contain those configs.
How does it work now? From now on, when a hook is deployed, Zeep o'Tron will look for a file called zeep-o-tron.properties under hook's WEB-INF directory. If it is found, it will check for two properties: 'struts.file.path' and 'tiles.file.path'. If there is a filled 'struts.file.path' property, Struts configurations found in that file (the one represented in the property value) will be loaded into Liferay's Struts configurations, overriding and adding whatever is needed. Besides, all classes and libs found in the hook will be added to Liferay's classloader, so that we can make sure that all classes needed by those configurations are available to Liferay.
At last, something similar is done for Tiles configurations: if a value is found for the property 'tiles.file.path', that file is parsed and all Tiles configurations found in there, added to Liferay's Tiles definitions.
You can take a look at the same hook for the details.

So, the sample hook you'll find in this entry, will work exactly as that shown in Liferay Portal Server: avoiding use of extension. JAR and sample for Liferay 5.2.3, except by the Spring part:

  1. Install Zeep o'Tron for Liferay 6 the same way as explained for Liferay 5.2.3
  2. Start Liferay, and deploy the sample hook provided later on in this entry 
  3. Create an event in the Calendar portlet and have a look at the logs (remember the sample hook outputs to the logs just by using System.out) to check Zeep o'Tron's Struts functionality
  4. Try to see the details of an event, to check Zeep o'Tron's Tiles functionallity
For more details about the testing the sample hook, check out the blog entry related to Zeep o'Tron for Liferay 5.2.3 (and remember to avoid the Spring part, of course!).

Finally, here you can download Zeep o'Tron for Liferay 6, and a sample hook. Sorry for uploading the artifacts in such a place, but found nothing better..

Enjoy!!


Have any idea on how to improve it? Just let me know!

11 comentaris:

  1. Dude you are awesome works like a charm. Thank you for your great work

    ResponElimina
  2. Thanks Sharl! Glad you find it useful!!

    ResponElimina
  3. it is really useful given the fact that liferay 6.1 is still beta.

    i noticed that i am not able to undeploy teh hook after applying your fix. It would be rather great if you could guide us (me and others) on how to modify the source to avoid such issue.

    Thanks again for your great addition :)

    ResponElimina
  4. I'll put hands on.
    Can you tell me how do you undeploy the hook to check that bug?

    ResponElimina
  5. I've get a forward does not exist exception anyone ?

    ResponElimina
  6. Sorry Tom...don't understand what you mean...

    ResponElimina
  7. Hello,
    i cant get the file to download. The Url is broken. Can you tell me how can I get the Zeep o'Tron for Liferay 6 and the sample hook.

    Thanks again for your great addition :)

    ResponElimina
  8. Hi!
    sorry but currently have not much time to spent on the blog ;(
    Thanks for letting me know...I've updated the link, so feel free to download it.

    ResponElimina
  9. Hi again,

    many thanks again, your code is really cool ;-)
    I managed to get it to work in my environment.

    Thumbs up for your effort!
    Lisa

    ResponElimina
  10. Hi,

    for us, the JAR works perfectly. But I still have a question..

    Every time we deploy the hook, the action class is not correctly set up-to-date if we made changes to it.
    We then need to stop the server, remove the hook manually, restart the server, and redeploy the hook.
    This gives us the correct and up-to-date version of our action class.

    Is there a reason for this, and more importantly, can we work around this problem? It would be great
    if our changes were accepted every time we deploy the hook, even if the server is running. That would
    be a great time-saver.. ;-)

    Many thanks in advance!
    Lisa

    ResponElimina
  11. Hi Lisa,

    don't know exactly what is your case. Anyway I can give you a hint that may help you on your issue.
    If you have a look at the source code, you'll find out that the class replacement is not a replacement itself. What it does is just adding a new source in the classloader so that when the class is needed by the classloader, it will find the newly added class first; this way, you'll have your "replacement". Having this in mind, think about your case. For example, Struts framework tries to reuse the same instance of an Action as many times as it can. So, if you have "used" that action, Struts won't look in the classloader for that class to create a new instance, since it will already have one in the heap; so you'll have no replacement.
    You know, I don't have time enough to create a JRebel by myself :p
    By the way, what you can do, as a workaround in development steps, is just changing the action definition so that Struts will have to load the class again.

    Last by not least, keep in mind that those loaded classes won't be erased from Permanent Space, so, if you abuse about that you'll end up with and OutOfMemory in PermGen space. (you'll end up with this if you abuse of Liferay's hot deploy too!)..so keep this in mind for production environments.

    Hope this helps!

    ResponElimina