Sampsa Sohlman Il y a 14 années Good article.I have found out that many utils can be called in from "portal-impl" using com.liferay.portal.kernel.util.PortalClassInvoker. Good example how to do this is com.liferay.portal.kernel.util.PropsUtil, which is delegating calls to com.liferay.portal.util.PropsUtil. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Jakub Liska Sampsa Sohlman Il y a 13 années Hey,so the kernel.util.PropsUtil via " PortalClassInvoker.invoke() > PortalClassLoaderUtil.getClassLoader() " gets liferayPortalClassloader for a moment just to load util.PropsUtil and call methods on it ? I'm not sure I'f I get it, why wouldn't we then just get the liferayPortalClassloader from PortalClassLoaderUtil and load whatever class we'd wanted ? Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Sampsa Sohlman Jakub Liska Il y a 13 années Hi JakubIf all applications would run under same classloader there would be class version conflicts. Then you could safely use only classes provided by liferay and when they upgrade their libs you should too. You would loose modularity. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Jakub Liska Sampsa Sohlman Il y a 13 années I understand this fact, what I meant was: why this way of loading classes from root liferay context by LiferayPortalClassloader isn't used for 3rd party portlets, instead of using LiferayPortalClassloader as a primary (and the only one) classloader. Because usually when people do it, they just need to load a few classes from portal context, which could be easily done the way you described. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Jakub Liska Sampsa Sohlman Il y a 13 années I forgot considering the fact, that using another classloader (portal) is very restricted as to what we are calling, because the living object instances would have to be serialized and instantiated again in local context to be used. That's why portlets need to use Portal classloader if they want to use portal-impl classes. Is this the point ? In this case, could you please explain more specifically what did you mean by the first comment ? Thanks Sampsa Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Sampsa Sohlman Jakub Liska Il y a 13 années You are on correct track. PropsUtil is very simple case because parameter and return classes are globally available. If I recall correct (might be mistaking at this point) - if the return values are interfaces which are availabe at portal-service.jar (and older portal-kernel.jar), you should be return those too with PortalClassInvoker.Liferay has also more complex cross classloader features and instead of serializing objects they are using java's Proxy object feature. Look example BeanLocatorImpl. Hooks have been implemented by using Proxy objects. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Jakub Liska Sampsa Sohlman Il y a 13 années Hey,so the kernel.util.PropsUtil via " PortalClassInvoker.invoke() > PortalClassLoaderUtil.getClassLoader() " gets liferayPortalClassloader for a moment just to load util.PropsUtil and call methods on it ? I'm not sure I'f I get it, why wouldn't we then just get the liferayPortalClassloader from PortalClassLoaderUtil and load whatever class we'd wanted ? Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Sampsa Sohlman Jakub Liska Il y a 13 années Hi JakubIf all applications would run under same classloader there would be class version conflicts. Then you could safely use only classes provided by liferay and when they upgrade their libs you should too. You would loose modularity. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Jakub Liska Sampsa Sohlman Il y a 13 années I understand this fact, what I meant was: why this way of loading classes from root liferay context by LiferayPortalClassloader isn't used for 3rd party portlets, instead of using LiferayPortalClassloader as a primary (and the only one) classloader. Because usually when people do it, they just need to load a few classes from portal context, which could be easily done the way you described. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Jakub Liska Sampsa Sohlman Il y a 13 années I forgot considering the fact, that using another classloader (portal) is very restricted as to what we are calling, because the living object instances would have to be serialized and instantiated again in local context to be used. That's why portlets need to use Portal classloader if they want to use portal-impl classes. Is this the point ? In this case, could you please explain more specifically what did you mean by the first comment ? Thanks Sampsa Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Sampsa Sohlman Jakub Liska Il y a 13 années You are on correct track. PropsUtil is very simple case because parameter and return classes are globally available. If I recall correct (might be mistaking at this point) - if the return values are interfaces which are availabe at portal-service.jar (and older portal-kernel.jar), you should be return those too with PortalClassInvoker.Liferay has also more complex cross classloader features and instead of serializing objects they are using java's Proxy object feature. Look example BeanLocatorImpl. Hooks have been implemented by using Proxy objects. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Sampsa Sohlman Jakub Liska Il y a 13 années Hi JakubIf all applications would run under same classloader there would be class version conflicts. Then you could safely use only classes provided by liferay and when they upgrade their libs you should too. You would loose modularity. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Jakub Liska Sampsa Sohlman Il y a 13 années I understand this fact, what I meant was: why this way of loading classes from root liferay context by LiferayPortalClassloader isn't used for 3rd party portlets, instead of using LiferayPortalClassloader as a primary (and the only one) classloader. Because usually when people do it, they just need to load a few classes from portal context, which could be easily done the way you described. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Jakub Liska Sampsa Sohlman Il y a 13 années I forgot considering the fact, that using another classloader (portal) is very restricted as to what we are calling, because the living object instances would have to be serialized and instantiated again in local context to be used. That's why portlets need to use Portal classloader if they want to use portal-impl classes. Is this the point ? In this case, could you please explain more specifically what did you mean by the first comment ? Thanks Sampsa Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Sampsa Sohlman Jakub Liska Il y a 13 années You are on correct track. PropsUtil is very simple case because parameter and return classes are globally available. If I recall correct (might be mistaking at this point) - if the return values are interfaces which are availabe at portal-service.jar (and older portal-kernel.jar), you should be return those too with PortalClassInvoker.Liferay has also more complex cross classloader features and instead of serializing objects they are using java's Proxy object feature. Look example BeanLocatorImpl. Hooks have been implemented by using Proxy objects. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Jakub Liska Sampsa Sohlman Il y a 13 années I understand this fact, what I meant was: why this way of loading classes from root liferay context by LiferayPortalClassloader isn't used for 3rd party portlets, instead of using LiferayPortalClassloader as a primary (and the only one) classloader. Because usually when people do it, they just need to load a few classes from portal context, which could be easily done the way you described. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Jakub Liska Sampsa Sohlman Il y a 13 années I forgot considering the fact, that using another classloader (portal) is very restricted as to what we are calling, because the living object instances would have to be serialized and instantiated again in local context to be used. That's why portlets need to use Portal classloader if they want to use portal-impl classes. Is this the point ? In this case, could you please explain more specifically what did you mean by the first comment ? Thanks Sampsa Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Sampsa Sohlman Jakub Liska Il y a 13 années You are on correct track. PropsUtil is very simple case because parameter and return classes are globally available. If I recall correct (might be mistaking at this point) - if the return values are interfaces which are availabe at portal-service.jar (and older portal-kernel.jar), you should be return those too with PortalClassInvoker.Liferay has also more complex cross classloader features and instead of serializing objects they are using java's Proxy object feature. Look example BeanLocatorImpl. Hooks have been implemented by using Proxy objects. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Sampsa Sohlman Jakub Liska Il y a 13 années You are on correct track. PropsUtil is very simple case because parameter and return classes are globally available. If I recall correct (might be mistaking at this point) - if the return values are interfaces which are availabe at portal-service.jar (and older portal-kernel.jar), you should be return those too with PortalClassInvoker.Liferay has also more complex cross classloader features and instead of serializing objects they are using java's Proxy object feature. Look example BeanLocatorImpl. Hooks have been implemented by using Proxy objects. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Ismael Ferrer Il y a 14 années The link to the wiki article is broken. The correct URL ishttp://www.liferay.com/community/wiki/-/wiki/Main/Liferay+modules+communication Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Juan Fernández Ismael Ferrer Il y a 14 années Fixed! Thanks Ismael Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Juan Fernández Ismael Ferrer Il y a 14 années Fixed! Thanks Ismael Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Jonas Yuan Il y a 14 années Nice feature! Thank you, Juan.It would be nice that you could add a practical example for CLP. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Juan Fernández Jonas Yuan Il y a 14 années Hi Jonas: thanks for your comment.You have a wiki article I created explaining how to use CLP communication here: http://www.liferay.com/community/wiki/-/wiki/Main/Using+Class+Loader+Proxy+classes+to+share+plugins+services Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Juan Fernández Jonas Yuan Il y a 14 années Hi Jonas: thanks for your comment.You have a wiki article I created explaining how to use CLP communication here: http://www.liferay.com/community/wiki/-/wiki/Main/Using+Class+Loader+Proxy+classes+to+share+plugins+services Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Bavithra Rajendran Il y a 13 années Sir, article is very good and wiki link explained as how to use CLP communication. Thanks for the diagram as it made very easier to understand Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Nidhi Singh Il y a 13 années Thanks Juan for informative blog Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Balu Sasidharan Il y a 13 années Hi Juan, You were helping me out for some previous issues .Thanks for all your help Please help me out in this .I have one more problem decribed belowI have a web application and I changed it as a portlet by adding the required filesNow I want use the com.liferay.model.impl.UserImpl class in my WebApp.When I used it I'm getting ClassNot found Exception.I added portal-impl.jar entry into liferay-plugin-package.prpeties file and started tomcat . Still I'm getting the same Exception.I have tried severel methods to get rid of this problem ,But none of them seems to work.I don't know where I'm going wrong? Its been 7 days I stuck with this problem.Please help me out I'm very much in need Thanks Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Balu Sasidharan Balu Sasidharan Il y a 13 années Sorry for posting the query here.I'm really desperate with this problem.I couldn't find a solution Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Binh Le Balu Sasidharan Il y a 13 années @Balu Sasidharan:I believe you should check your classpath. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Balu Sasidharan Balu Sasidharan Il y a 13 années Sorry for posting the query here.I'm really desperate with this problem.I couldn't find a solution Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Binh Le Balu Sasidharan Il y a 13 années @Balu Sasidharan:I believe you should check your classpath. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Binh Le Balu Sasidharan Il y a 13 années @Balu Sasidharan:I believe you should check your classpath. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler