Sampsa Sohlman 14 Anos atrás 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. Por favor, autentique-se para votar. Responda como... Cancelar Jakub Liska Sampsa Sohlman 13 Anos atrás 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 ? Por favor, autentique-se para votar. Responda como... Cancelar Sampsa Sohlman Jakub Liska 13 Anos atrás 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. Por favor, autentique-se para votar. Responda como... Cancelar Jakub Liska Sampsa Sohlman 13 Anos atrás 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. Por favor, autentique-se para votar. Responda como... Cancelar Jakub Liska Sampsa Sohlman 13 Anos atrás 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 Por favor, autentique-se para votar. Responda como... Cancelar Sampsa Sohlman Jakub Liska 13 Anos atrás 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. Por favor, autentique-se para votar. Responda como... Cancelar
Jakub Liska Sampsa Sohlman 13 Anos atrás 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 ? Por favor, autentique-se para votar. Responda como... Cancelar Sampsa Sohlman Jakub Liska 13 Anos atrás 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. Por favor, autentique-se para votar. Responda como... Cancelar Jakub Liska Sampsa Sohlman 13 Anos atrás 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. Por favor, autentique-se para votar. Responda como... Cancelar Jakub Liska Sampsa Sohlman 13 Anos atrás 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 Por favor, autentique-se para votar. Responda como... Cancelar Sampsa Sohlman Jakub Liska 13 Anos atrás 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. Por favor, autentique-se para votar. Responda como... Cancelar
Sampsa Sohlman Jakub Liska 13 Anos atrás 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. Por favor, autentique-se para votar. Responda como... Cancelar Jakub Liska Sampsa Sohlman 13 Anos atrás 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. Por favor, autentique-se para votar. Responda como... Cancelar Jakub Liska Sampsa Sohlman 13 Anos atrás 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 Por favor, autentique-se para votar. Responda como... Cancelar Sampsa Sohlman Jakub Liska 13 Anos atrás 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. Por favor, autentique-se para votar. Responda como... Cancelar
Jakub Liska Sampsa Sohlman 13 Anos atrás 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. Por favor, autentique-se para votar. Responda como... Cancelar
Jakub Liska Sampsa Sohlman 13 Anos atrás 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 Por favor, autentique-se para votar. Responda como... Cancelar Sampsa Sohlman Jakub Liska 13 Anos atrás 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. Por favor, autentique-se para votar. Responda como... Cancelar
Sampsa Sohlman Jakub Liska 13 Anos atrás 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. Por favor, autentique-se para votar. Responda como... Cancelar
Ismael Ferrer 14 Anos atrás The link to the wiki article is broken. The correct URL ishttp://www.liferay.com/community/wiki/-/wiki/Main/Liferay+modules+communication Por favor, autentique-se para votar. Responda como... Cancelar Juan Fernández Ismael Ferrer 14 Anos atrás Fixed! Thanks Ismael Por favor, autentique-se para votar. Responda como... Cancelar
Juan Fernández Ismael Ferrer 14 Anos atrás Fixed! Thanks Ismael Por favor, autentique-se para votar. Responda como... Cancelar
Jonas Yuan 14 Anos atrás Nice feature! Thank you, Juan.It would be nice that you could add a practical example for CLP. Por favor, autentique-se para votar. Responda como... Cancelar Juan Fernández Jonas Yuan 14 Anos atrás 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 Por favor, autentique-se para votar. Responda como... Cancelar
Juan Fernández Jonas Yuan 14 Anos atrás 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 Por favor, autentique-se para votar. Responda como... Cancelar
Bavithra Rajendran 13 Anos atrás 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 Por favor, autentique-se para votar. Responda como... Cancelar
Nidhi Singh 13 Anos atrás Thanks Juan for informative blog Por favor, autentique-se para votar. Responda como... Cancelar
Balu Sasidharan 13 Anos atrás 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 Por favor, autentique-se para votar. Responda como... Cancelar Balu Sasidharan Balu Sasidharan 13 Anos atrás Sorry for posting the query here.I'm really desperate with this problem.I couldn't find a solution Por favor, autentique-se para votar. Responda como... Cancelar Binh Le Balu Sasidharan 13 Anos atrás @Balu Sasidharan:I believe you should check your classpath. Por favor, autentique-se para votar. Responda como... Cancelar
Balu Sasidharan Balu Sasidharan 13 Anos atrás Sorry for posting the query here.I'm really desperate with this problem.I couldn't find a solution Por favor, autentique-se para votar. Responda como... Cancelar Binh Le Balu Sasidharan 13 Anos atrás @Balu Sasidharan:I believe you should check your classpath. Por favor, autentique-se para votar. Responda como... Cancelar
Binh Le Balu Sasidharan 13 Anos atrás @Balu Sasidharan:I believe you should check your classpath. Por favor, autentique-se para votar. Responda como... Cancelar