I made some progress.
I ended up creating a custom UIAccountPortlet with custom UIAccountForm to initialize a custom UIUserProfileInputSet. You can easily add new field and new categories (business profile1, business profile2 and etc.) in your custom UIUserProfileInputSet. This part is fairly straight forward.
Then I tried to use the same approach to UIOrganizationPortlet so that I can view the custom user profile data when selecting a user from the user organization panel (instead of the standard UIAccountForm). I created custom UIOrganizationPortlet, UIUserManagement, UIUserInfo to initialize custom UIUserProfileInputSet. It turns out that my custom UIOrganizationPortlet (not the same class name) can not reference the class UIUserManagement (I just use this class as an example. I did craete my own version, but eventually it uses UIUserList or some other classes) or any other classes bundled in the exoadmin.war.
I read the GateIn kernel doc and extension doc. I thought all those classes from varias webapps would be in a unified classpath as declared in the gatein/conf/configuration.xml. Am I missing something?
I know I can just recreate all referenced class in exoadmin.war or just bundle my custom portlet related stuff inside exoadmin. But it seems like I should be just somehow use the classes in exoadmin. Could someone with better understanding of GateIn class loading provide some hint?
I did run into same troubles:
Kent Xu schrieb:
Is there a nicer way for doing so? I mean, what do I need if I would like to provide different categories for different roles?
The unified class loader is for loading resource only. So class defined in exoadmin.war is not visible to class from your custom UIOrganization..
I'm facing the same problem as you infact . I see that the UserProfile provides method setAttribute()/ getAttribute(), so there 's no limitation in extending the persistent fields. For the custom UIAccountPortlet portlet that i'm coding, i add a portlet preference, giving the list of attributes to be displayed
Kent Xu schrieb:
what I did to work around this limitation is repackaging required class files into own Maven artifact:
* extract war
* copy classes from WEB-INF/classes to appropriate folder
I did use Maven Ant Plugin for that case. That's not really nice, but it's straight forward and limits the amount of files I need to touch.