EXT Plugin Advice

[Andew Jardine, modifié il y a 9 années.]

Hi Guys,

First off -- I know. "Don't use an EXT plugin". Unfortuantely the nature of the beast I am wrestling with requires it -- or at least I think it does, if there is some other trick that I am not aware of, I am all ears.

My situation --
I need to make a customization to the, brace yourself, the PortalImpl class. In particular I need to modify exactly ONE method in this class to augment the logic with some cutom stuff. At first I was simpy copying this class, and making my change. I'm suffering through some issues at runtime with this approach, but that is another matter altogether. The bigger issue is, as we all know, upgrades. I just updated today to 6.2 EE SP11 and found that one of the changes was a change to the PortalImpl class. I don't know how often it changes but this is ofcourse the heartache of the update. As far as I can make out -- I have a couple of options for how to proceed, but I am looking for advice from you guys out there.

1. Do as I am, override the PortalImpl class adding my logic and just go through the motions as we upgrade to newer versions.

2. I am toying with the idea of adding a CustomPortalImpl class that extends the PortalImpl and then update the spring mapping to reference the CustomPortalImpl in place of the PortalImpl. I think I only have to worry about references in two files for this -- though I am not sure of the pain with this approach in upgrades.

I am seriosuly considering #2 mostly because it would mean any changes made to the PortalImpl class moving forward I should be able to "inherit" leaving me only to have to worry about changes, if ever made, to the spring bean files that reference the PortalImpl class. I'd love to hear what you guys think or might suggest though.

Thoughts?

[David H Nebinger, modifié il y a 9 années.]

#2 is definitely the way to go. Extend PortalImpl and use updates to META-INF/service-builder-spring.xml and META-INF/util-spring.xml to use your extension class over the default PortalImpl

Also you're probably going to want to include a META-INF/portal-log4j-ext.xml file to define the logger for your extension class. There's a specific logger entry for com.liferay.portal.util.PortalImpl at INFO level by default, so you may want to define a category for your class to keep a similar logging level.

[Andew Jardine, modifié il y a 9 années.]

Hey David,

Thanks for the guidance . A follow on question. Should I be updating the two xml files as part of the EXT plugin? or can I use something like the spring.configs property to update just the two bean definitions I need to update?

(excellent point for the portal-log4j -- I had forgotten about that one)

[David H Nebinger, modifié il y a 9 années.]

The two uses inject a blind instance of PortalImpl, they're actually embedded bean tags, i.e.

<property name="portalImpl"><bean class="com.liferay.portal.util.PortalImpl" /></property>

So it's not a normal Spring replace, you have to do the containing beans (I think they're PortalUtil and some other SB class I don't remember). You should be able to use spring configs to override the containing beans.

[Andew Jardine, modifié il y a 9 années.]

Just to make sure I understand -- I can see that in the portal source (for example util-spring.xml) we have the definition

	<bean id="com.liferay.portal.util.PortalUtil" class="com.liferay.portal.util.PortalUtil">
		<property name="portal">
			<bean class="com.liferay.portal.util.PortalImpl" />
		</property>
	</bean>

.. and I should be able to use ext-spring.xml with this --

	<bean id="com.liferay.portal.util.PortalUtil" class="com.liferay.portal.util.PortalUtil">
		<property name="portal">
			<bean class="com.liferay.portal.util.CustomPortalImpl" />
		</property>
	</bean>

Rinse and repeat for service-builder-spirng.xml and porta-log4j.xml. Does that sound right?

(Normally I would just try it before asking all these questions, but EXTs are such a pain to purge and start over )

[Jan Geißler, modifié il y a 9 années.]

Rinse and repeat. You are correct as far as I can see.

[Andew Jardine, modifié il y a 9 années.]

Hi Jan,

Ok last question. As part of my EXT plugin I have created an additional service builder entity (as you know from the other thread on this). So that generated code has given me an ext-spring.xml in my ext-impl/src folder. Should I do my bean overrides in there? or would it be a better practice to place them into a separate ext-spring.xml file somewhere else on the classpath?

I am leaning towards using the file in the EXT plugin to keep all the extension/override stuff in the same place. Thoughts?

[Jan Geißler, modifié il y a 9 années.]

Andew Jardine:

I am leaning towards using the file in the EXT plugin to keep all the extension/override stuff in the same place. Thoughts?

Me too. Keep all in the same place, and I don't even know if you wouldn't run in troubles if you have another spring-ext.xml....

[Olaf Kock, modifié il y a 9 années.]

I'm not adding more information to the thread, just wanted to comment on two small items:

Andew Jardine:

First off -- I know. "Don't use an EXT plugin". Unfortuantely the nature of the beast I am wrestling with requires it -- or at least I think it does, if there is some other trick that I am not aware of, I am all ears.

I like to phrase it differently: "You do not want to use EXT". If you can come up with an alternative, that alternative is most likely the best solution. If you can't think of an alternative, try harder. You did well by asking here. If - after trying harder - you still can't come up with a solution, EXT might be the solution for you.

When you have decided for EXT you should still maximize its maintainability. And you seem to do this right.

Andew Jardine:

Ok last question. As part of my EXT plugin I have created an additional service builder entity (as you know from the other thread on this).

I didn't check that other thread (missing link, hint hint), but wanted to let you know that new entities are unsupported in ext. If you get them to work but run into problems later, the correct answer is "told you so". My advice, for this reason, is to keep your custom entity in a separate hook. If you need to make it available on the global classpath (so that your ext can use it) - so be it. I hope that your overridden PortalImpl does not rely on the custom entity - this seems to be very intrusive...

Other than that: Good job checking here first and going this way. This approach has my blessing for implementing ext.

[Andew Jardine, modifié il y a 9 années.]

Hi Olaf --

Sorry, I figured everyone would come here from the other thread hahah -- https://www.liferay.com/community/forums/-/message_boards/message/51296227

I am in fact doing what you say I should not. My custom PortalImpl has a dependency on the new service. That's why I wanted to put it into the EXT plugin so that when you deploy the plugin, you know for sure that the service is there.

When you say it doesn't work anymore, do you mean you can do it (as I have done) but at runtime Liferay won't load the services (ie: it won't actually work even if it looks like it is)? Or do you mean -- you really should not do it as in a best practice?

[Olaf Kock, modifié il y a 9 années.]

I'm not sure how it behaves. Officially it's stated that "new service builder entities are not supported in ext". For this reason I've never tried them. They might work, or they might break. Or they might break with the next update. Or at full moon. Not sure, but you might figure out...

You can check if deploying them in a hook and placing the my-service.jar in global classpath works. It probably will, unless it's already being used before the hook is deployed.

[David H Nebinger, modifié il y a 9 années.]

With the two being tightly coupled you are probably better served keeping them together, although there are a lot of messages from Liferay saying that service in EXT is deprecated and should be avoided, but we've been through that in the other thread

[Olaf Kock, modifié il y a 9 années.]

Fine for me - just don't come wining when you discover that it doesn't work (in a future update) any more.

That being said, while adding new entities might have an argument for it, adding methods/fields to an existing entity or service is definitely a no-go: This will change the API and must not be done.

I'm assuming that you're not attempting this, just add it here for people who come along later and take this thread as justification to do so.

[Andew Jardine, modifié il y a 9 années.]

Alright -- update on progress.

I was able to add my custom service.xml file and then using the right arguments generate the service entites and such. I did as was recommended here and added the portal-log4j-ext as well as the custom bean mapping. Everything looked good. An then I deployed .

I did this on a clean 6.2 EE SP11 install with a fresh database etc to make sure that it was as vanilla as it gets to start. After a few hours of rebuilds and do overs I just can't get rid of some really whacky errors that are showing up. Some of them were complaints in the Role_ table (?!??!!) about a duplicate column id, others some exceptions about the JournalArticle (of which there are none anyway -- didn't look closely, maybe this was the issue). Regardless, it just doesn't seem to like my war.

So on to the alternate approach which, I agree Olaf is not ideal (EXT dependency on a external service project) but right now in order to accomplish our requirement we've hacked the VirtualHost database table which I believe to be worse.

I'll update this thread with my results when I have some more news. Thanks again for your help on this guys.

[Andew Jardine, modifié il y a 9 années.]

Hey Guys,

I'm stuck on something and not sure how to work out where the problem is. I have created a new maven EXT project. In it I have added just two things, both in the ext-impl module. The first is my CustomPortalImpl class (under the src/main/java folder) with the appropriate package of com.liferay.portal.util. The second, under src/main/resources inside a META-INF folder, an ext-spring.xml file with the content as listed above in this thread.

In my CustomPortalImpl class I have just added a logging statement to validate that the right overridden class and method are being used and in my portal-log4j-ext.xml, which I have placed where I usually leave it (inside TOMCAT_HOME/webapps/ROOT/WEB-INF/classes/META-INF) I have added the appender with an INFO level.

I am not seeing my logging statements (and I know I should be seeing PILES of them since the getPortalURL method is called for just about every url that is created for a page). I suspect that it is because my ext-spring,xml file is not being loaded, but I am not sure how to check this.

Any hints?

EDIT:
I cna't seem to get this working with a maven project, but I have managed to get it going with ANT. In the ANT version I simply added a META-INF folder to the root src folder and then in there put the ext-spring.xml. Everything works well. Now on to the external service definition.

Is it just me or do EXT plugins via maven have some issues to be worked out still?