Extending LDAPUserImporter ???

[Sunit Chatterjee, modificado 6 Anos atrás.]

Hi,

Can anyone give me some pointers on how to extend LDAPUserImporter?

Use Case:
1. There are few actions that we want to take on User object and its associated data once an LDAP user is imported in liferay.
2. We want to pass on the newly created User and the data read from LDAP Server, to a custom service class that populates associated custom data for every user.

The only way I could think of is
1. Extend com.liferay.portal.security.ldap.internal.exportimport.LDAPUserImporterImpl, and override the method - importUser
2. In the overridden method, I first call "super.importUser()", and then pass on the LDAP data to my custom service class that populates the user's associated data.

The only problem I faced with this approach is that I am not able to extend LDAPUserImporterImpl, probably because this may be an internal class which is not exposed.

Is there any other way to handle this use case.

Thanks
Sunit

[Andrew Jardine, modificado 6 Anos atrás.]

Hi Sunit,

Frustrating I know. There have been several occasions to date where I have hit a wall where I am staring at a class that, in my mind, should be exported rather than hidden.

It's not pretty, and sucks for upgrade path, but you could "clone" (fancy way of saying copy and paste lol) the existing class, make your changes, and give it a higher service ranking.

Alternatively, depending on your version, EXT plugins are back -- so you could always go that route as well.

[David H Nebinger, modificado 6 Anos atrás.]

Don't forget my blog post for how to expose an otherwise private package...

https://web.liferay.com/web/user.26526/blog/-/blogs/fixing-module-package-access-modifiers

[Sunit Chatterjee, modificado 6 Anos atrás.]

Thanks a ton, David and Andrew.

I will try out both the suggestions (Exposing private packages and using Ext Plugins)

Sunit

[Andrew Jardine, modificado 6 Anos atrás.]

I had forgotten about this post! I was thinking about it, but I was actually thinking about another one -- the one you did with the message boards where there were 1000 caveats and things to track (well, not 1000, but a dozen anyway ) so I wasn't sure that it was the best option.

But thanks for adding this link -- good refresher and I am not refactoring something to expose the Login Portlet constants to eliminate my hard coded portlet id.

[Sunit Chatterjee, modificado 6 Anos atrás.]

Just want to give an update, that I was able to solve my use case with the approach of modifying the package export of OSGI bundles. It worked like a charm. Although I faced few hiccups, but they were more due to my inexperience with liferay and OSGI.

But it was a great learning experience for me, so thank you very much.

I think this will solve my other use case also where I need to extend Liferay's implementation of Elastic search - https://web.liferay.com/community/forums/-/message_boards/message/94275487

Thanks
Sunit