Foren

Overriding ServicePreAction.java

Paperboy -, geändert vor 17 Jahren.

Overriding ServicePreAction.java

Junior Member Beiträge: 25 Beitrittsdatum: 17.08.06 Neueste Beiträge
We want to override ServicePreAction.java, ThemeDisplay.java and VelocityVariables.java by copying these to its respective /ext/ext-ejb/src/com/liferay/portal folders and then modify them.

In that way when we deploy with the /ext/build.xml script we should basically have three classes in ext.ejb.jar that overrides the classes in portal-ejb.jar.

Now, our problem is that this doesn't happen.

No functionality added in the overriden ServicePreAction class are visible when com.liferay.portal.events.ServicePreAction is instantiated.

This must mean that com.liferay.portal.events.ServicePreAction actually goes to the file in portal-ejb/src/com/liferay/portal/events instead of ext-ejb/src/com/liferay/portal/events.

For someone who just started coding java again after 5 years, this is somewhat of a mystery.

What can I do to ensure that ext-ejb/src/com/liferay/portal/events/ServicePreAction.java is used?
thumbnail
Joel Kozikowski, geändert vor 17 Jahren.

RE: Overriding ServicePreAction.java

Expert Beiträge: 405 Beitrittsdatum: 28.06.06 Neueste Beiträge
I don't think that you CAN override a Java file that is part of the core portal system and have it merged in from your extension environment. I asked a similar question in this post.

Note that the "extension environment" concept is something that is unique to Liferay. There is a lot of custom code in the Ant build scripts that "merge" in your code with the Liferay distribution code to make an "extended" version of Liferay. This was all architected by the Liferay team, and is not something that is inherint with Java.

The bottom line issue you are running into is that the file you want to modify has its .class file stored in portal-ejb.jar. I know that the build scripts does support merging fragments from various .xml files in your /ext directory with the base .xml files from the /portal dir, but I don't think that same support is extended to the .class files in portal-ejb.jar (at least, that is my impression based on Mike Young's response to my question in the above referenced post).

I think the only approach is to make a custom version of portal-ejb.jar. You could modify the extension environment's Ant script to unpack the portal-ejb.jar to a temp directory, copy your custom .class files and overwrite the ones in the temp dir, and then re-jar the portal-ejb.jar file. Ideally, this would already be part of the Liferay extension system (and if it is, someone please let me know!), but if its not, you'll have to grow your own.
thumbnail
Brian Chan, geändert vor 17 Jahren.

RE: Overriding ServicePreAction.java

Liferay Master Beiträge: 753 Beitrittsdatum: 05.08.04 Neueste Beiträge
Call your class:

com.something.CustomServicePreAction

Put it in ROOT/WEB-INF/classes/com/something/

Modify ROOT/WEB-INF/classes/portal-ext.properties

to call:

servlet.service.events.pre=com.something.CustomServicePreAction

Note, you can also chain these

servlet.service.events.pre=com.liferay.portal.events.ServicePreAction,com.something.CustomServicePreAction

to call ours first, then yours.

What do you need added? If it's generic enough, we'll get it in the core. Thanks.
thumbnail
Brian Chan, geändert vor 17 Jahren.

RE: Overriding ServicePreAction.java

Liferay Master Beiträge: 753 Beitrittsdatum: 05.08.04 Neueste Beiträge
Ok.. read your thing more carefully (what I wrote earlier still applies), but I have a better idea of why it's failing for you now.

Basically, ext-ejb.jar and portal-ejb.jar get copied to

ROOT/WEB-INF/lib/

Since there are 2 definitions of the ServicePreAction class, you have no guarantee which one will get loaded first.

The servlet spec says that if a class exists in

ROOT/WEB-INF/classes/ (exploded)

It'll get loaded before

ROOT/WEB-INF/lib/ (jar'd) up.

So one way is to just place the compiled class in WEB-INF/classes

But I'd still recommend not naming classes the same package/name. You shoudl really put your events in..

com.something.MyServicePreAction

Then it'll sit in your ext-ejb/src/com/something/MyServicePreAction.java, get compield to ext-ejb/classes...

and in ext-ejb/classes/portal-ext.properties add the right setting (from my earlier post).
Paperboy -, geändert vor 17 Jahren.

RE: Overriding ServicePreAction.java

Junior Member Beiträge: 25 Beitrittsdatum: 17.08.06 Neueste Beiträge
Thanks for clearing this up emoticon

One of the reasons we wanted to do this is because we fear that we have to extend alot of classes in order to set new variables for Velocity templates.

By just "overriding" the classes we could rewrite ServicePreAction.java and VelocityVariables.java to get them to collect and set the new variables.

In this way it would be enough for us to extend ThemeDisplay to hold the new data and cast this object into NewThemeDisplay in our "overriden" VelocityVariables.java.

This would simplify things a bit.

When we try to extend these classes we need to identify each class in the chain in order to set the new variables and get them visible for the templates.

Right now we have identified three classes that needs to be extended in order to find, set and read the variables needed.

These are:
ThemeDisplay.java
ThemeUtil.java
VelocityVariables.java

We extend ThemeDisplay and use this in our new class defineRootLayouts that is called after ServicePreAction.java. ( portal-ext.properties )

Then we extend VelocityVariables. But in order to get these changes visible we need to also extend ThemeUtil to call insertVariables in our new NewVelocityVariables.java.

But here it stops. I cannot see which class calls the insertVM in ThemeUtil.java so the chain is obviously not completed and therefore my extended classes won't be called.

Now I fear that I'm missing something completely logical here. But right now I can't seem to get these new variables visible for the velocity templates without having to extend all of the classes in the chain. And I can't even find all the classes that makes up the chain.
thumbnail
David García González, geändert vor 12 Jahren.

RE: Overriding ServicePreAction.java

Regular Member Beiträge: 127 Beitrittsdatum: 14.07.09 Neueste Beiträge
Hi, In Liferay 6 Wich could be the better option: a hook or an ext plugin?

NOTE: I have created a new class that inherits the original ServicePreAction and then I will override only the method I wanted to implement, in this case, the method servicePre.

Thanks.
Balavardhi Raju, geändert vor 8 Jahren.

RE: Overriding ServicePreAction.java

New Member Beiträge: 2 Beitrittsdatum: 15.01.14 Neueste Beiträge
David García González:
Hi, In Liferay 6 Wich could be the better option: a hook or an ext plugin?

NOTE: I have created a new class that inherits the original ServicePreAction and then I will override only the method I wanted to implement, in this case, the method servicePre.

Thanks.


Hi David ,

I am tring to override ServicePreAction using hooks. Please could you provide steps to override ServicePreAction using hooks in liferay 6.2.

Thanks in advance emoticon
Allan Chan Tan, geändert vor 17 Jahren.

RE: Overriding ServicePreAction.java

New Member Beiträge: 12 Beitrittsdatum: 02.12.06 Neueste Beiträge
Got this working fine... emoticon

Just curious, PreServiceAction is executed on all request and there is a considerable amount of codes building the displayTheme (e.g. createURLs,etc.)

Is there any performance analysis done on this? Would it be more efficient if the URLS are just stored in session and not reset on every request?