Ákos Gábriel 11 Years Ago "DLFileEntry (the entity used to store documents of Documents & Media) has the DLFileEntry"Service is missing at the end I guess.Thanks for the useful article again! Please sign in to reply. Reply as... Cancel Jorge Ferrer Ákos Gábriel 11 Years Ago Fixed. Thanks Ákos. I'm glad you liked it. Please sign in to reply. Reply as... Cancel
Jorge Ferrer Ákos Gábriel 11 Years Ago Fixed. Thanks Ákos. I'm glad you liked it. Please sign in to reply. Reply as... Cancel
Remis Baima 11 Years Ago Amazing post!Finally we have a great overview of the LR Architecture in one single place. I mean: your presentation of LR Architecture in the European Symposium with these blog posts :-).It would be great it this topics were also integrated in the LR Development Guide: http://www.liferay.com/documentation/liferay-portal/6.1/developmentThis would help a lot new developers (I know that it would have helped me a lot 2 years ago when I started with LR :-). Please sign in to reply. Reply as... Cancel Jorge Ferrer Remis Baima 11 Years Ago Thanks Remis!That's exactly my plan. Once I finish the blog series I'll work with Jim Hinkey, the main author of the Dev Guide to incorporate the content in the next version. Please sign in to reply. Reply as... Cancel
Jorge Ferrer Remis Baima 11 Years Ago Thanks Remis!That's exactly my plan. Once I finish the blog series I'll work with Jim Hinkey, the main author of the Dev Guide to incorporate the content in the next version. Please sign in to reply. Reply as... Cancel
Dave Weitzel 11 Years Ago If you are looking for suggestions for next one I think an explanation of the URL Filtering system and how/ the order of filters is applied, which ones can safely be disabled for performance and which ones never should be would be useful if it isn't covered elsewhere of course. Please sign in to reply. Reply as... Cancel
Alain Dresse 11 Years Ago Thank you for these posts. They definitely help structure.Could you please explain why the return types of the local services is so strict? What are the consequences of deviating from this in user defined services ? Please sign in to reply. Reply as... Cancel David H Nebinger Alain Dresse 11 Years Ago Well, there is a 4th type, a primitive (or the object equivalents).The reason for the strictness is the CLP layer. ServiceBuilder creates a shim layer so calls are successful over the class loader boundary between different web applications (your plugins are separate wars and have their own class loader).ServiceBuilder, however, only knows about the types defined in the service.xml file. It has no visibility over other types, no idea if they are appropriately serializable, etc.There are two ways to use non-DB based entities as return types: 1) the return types must be defined at a global scope (put your classes in a jar and push the jar to the app container's global library, i.e. lib/ext in Tomcat). 2) There's a suggestion here http://www.liferay.com/community/forums/-/message_boards/message/12095602 that would seem to allow for a regular entity definition that might not actually get persisted (as long as you didn't invoke one of the standard CRUD methods). Please sign in to reply. Reply as... Cancel Jorge Ferrer David H Nebinger 11 Years Ago @Dave Thanks for the suggestion, I do have some slides that cover URL handling but that will be several posts from now @Alain, what I'm describing are the conventions we follow at Liferay. We follow them because we think having strict conventions makes it significantly easier to maintain the code for a product this large. Additionally, as David says, these conventions can also be leveraged by our own tools such as Service Builder to do some work for us. You don't need to follow the same conventions (I guess most people won't), but if you use Service Builder you will get benefits from following some of them.@David, good catch on the 4th type, I'll add it to the post Please sign in to reply. Reply as... Cancel Alain Dresse David H Nebinger 11 Years Ago Thanks David. Certainly helps a lot.I had initially understood the restriction as being "the entity for which the service is defined". If I understand your answer correctly, I should read the restriction as "the entities defined by ServiceBuilder, i.e. DB based entities".Not yet clear to me however if the restriction refers to entities in THE currently processed service.xml or if it extends to portal entities (Users, Organizations, ...) and entities defined in service.xml in other wars. Please sign in to reply. Reply as... Cancel
David H Nebinger Alain Dresse 11 Years Ago Well, there is a 4th type, a primitive (or the object equivalents).The reason for the strictness is the CLP layer. ServiceBuilder creates a shim layer so calls are successful over the class loader boundary between different web applications (your plugins are separate wars and have their own class loader).ServiceBuilder, however, only knows about the types defined in the service.xml file. It has no visibility over other types, no idea if they are appropriately serializable, etc.There are two ways to use non-DB based entities as return types: 1) the return types must be defined at a global scope (put your classes in a jar and push the jar to the app container's global library, i.e. lib/ext in Tomcat). 2) There's a suggestion here http://www.liferay.com/community/forums/-/message_boards/message/12095602 that would seem to allow for a regular entity definition that might not actually get persisted (as long as you didn't invoke one of the standard CRUD methods). Please sign in to reply. Reply as... Cancel Jorge Ferrer David H Nebinger 11 Years Ago @Dave Thanks for the suggestion, I do have some slides that cover URL handling but that will be several posts from now @Alain, what I'm describing are the conventions we follow at Liferay. We follow them because we think having strict conventions makes it significantly easier to maintain the code for a product this large. Additionally, as David says, these conventions can also be leveraged by our own tools such as Service Builder to do some work for us. You don't need to follow the same conventions (I guess most people won't), but if you use Service Builder you will get benefits from following some of them.@David, good catch on the 4th type, I'll add it to the post Please sign in to reply. Reply as... Cancel Alain Dresse David H Nebinger 11 Years Ago Thanks David. Certainly helps a lot.I had initially understood the restriction as being "the entity for which the service is defined". If I understand your answer correctly, I should read the restriction as "the entities defined by ServiceBuilder, i.e. DB based entities".Not yet clear to me however if the restriction refers to entities in THE currently processed service.xml or if it extends to portal entities (Users, Organizations, ...) and entities defined in service.xml in other wars. Please sign in to reply. Reply as... Cancel
Jorge Ferrer David H Nebinger 11 Years Ago @Dave Thanks for the suggestion, I do have some slides that cover URL handling but that will be several posts from now @Alain, what I'm describing are the conventions we follow at Liferay. We follow them because we think having strict conventions makes it significantly easier to maintain the code for a product this large. Additionally, as David says, these conventions can also be leveraged by our own tools such as Service Builder to do some work for us. You don't need to follow the same conventions (I guess most people won't), but if you use Service Builder you will get benefits from following some of them.@David, good catch on the 4th type, I'll add it to the post Please sign in to reply. Reply as... Cancel
Alain Dresse David H Nebinger 11 Years Ago Thanks David. Certainly helps a lot.I had initially understood the restriction as being "the entity for which the service is defined". If I understand your answer correctly, I should read the restriction as "the entities defined by ServiceBuilder, i.e. DB based entities".Not yet clear to me however if the restriction refers to entities in THE currently processed service.xml or if it extends to portal entities (Users, Organizations, ...) and entities defined in service.xml in other wars. Please sign in to reply. Reply as... Cancel
Andrea Gentili 11 Years Ago As I can read in development documentation, Liferay web services API support only basic authentication. Is it possible to enforce authentication policy? Thanks in advance Please sign in to reply. Reply as... Cancel Jorge Ferrer Andrea Gentili 11 Years Ago Hi Andrea,If you are accessing the web services API through an unsecure channel we recommend you to use HTTPS to protect your credentials.For next version we are also adding Oauth as an alternative authentication option for web services. Please sign in to reply. Reply as... Cancel David H Nebinger Jorge Ferrer 11 Years Ago @Alain, other entities are supported within the same class loader using the @reference object.... But the limitation here is the 'same class loader' thing. Your entities are in one class loader, the portal's entities are in the portal's class loader, and other SB-based plugins will be in their own class loaders...Here you're kind of stuck returning PKs for the entities that need to be pulled in and use those PKs to fetch them manually. Please sign in to reply. Reply as... Cancel Andrea Gentili David H Nebinger 11 Years Ago Hi Jorge,which Oauth versione (1.0 or 2.0) will be supported as option for web service authentication?Thanks in advance,Andrea. Please sign in to reply. Reply as... Cancel Jorge Ferrer Andrea Gentili 11 Years Ago Right now I think it's 1.0.Oauth 2.0 is more of a framework than a protocol. Please sign in to reply. Reply as... Cancel
Jorge Ferrer Andrea Gentili 11 Years Ago Hi Andrea,If you are accessing the web services API through an unsecure channel we recommend you to use HTTPS to protect your credentials.For next version we are also adding Oauth as an alternative authentication option for web services. Please sign in to reply. Reply as... Cancel David H Nebinger Jorge Ferrer 11 Years Ago @Alain, other entities are supported within the same class loader using the @reference object.... But the limitation here is the 'same class loader' thing. Your entities are in one class loader, the portal's entities are in the portal's class loader, and other SB-based plugins will be in their own class loaders...Here you're kind of stuck returning PKs for the entities that need to be pulled in and use those PKs to fetch them manually. Please sign in to reply. Reply as... Cancel Andrea Gentili David H Nebinger 11 Years Ago Hi Jorge,which Oauth versione (1.0 or 2.0) will be supported as option for web service authentication?Thanks in advance,Andrea. Please sign in to reply. Reply as... Cancel Jorge Ferrer Andrea Gentili 11 Years Ago Right now I think it's 1.0.Oauth 2.0 is more of a framework than a protocol. Please sign in to reply. Reply as... Cancel
David H Nebinger Jorge Ferrer 11 Years Ago @Alain, other entities are supported within the same class loader using the @reference object.... But the limitation here is the 'same class loader' thing. Your entities are in one class loader, the portal's entities are in the portal's class loader, and other SB-based plugins will be in their own class loaders...Here you're kind of stuck returning PKs for the entities that need to be pulled in and use those PKs to fetch them manually. Please sign in to reply. Reply as... Cancel Andrea Gentili David H Nebinger 11 Years Ago Hi Jorge,which Oauth versione (1.0 or 2.0) will be supported as option for web service authentication?Thanks in advance,Andrea. Please sign in to reply. Reply as... Cancel Jorge Ferrer Andrea Gentili 11 Years Ago Right now I think it's 1.0.Oauth 2.0 is more of a framework than a protocol. Please sign in to reply. Reply as... Cancel
Andrea Gentili David H Nebinger 11 Years Ago Hi Jorge,which Oauth versione (1.0 or 2.0) will be supported as option for web service authentication?Thanks in advance,Andrea. Please sign in to reply. Reply as... Cancel Jorge Ferrer Andrea Gentili 11 Years Ago Right now I think it's 1.0.Oauth 2.0 is more of a framework than a protocol. Please sign in to reply. Reply as... Cancel
Jorge Ferrer Andrea Gentili 11 Years Ago Right now I think it's 1.0.Oauth 2.0 is more of a framework than a protocol. Please sign in to reply. Reply as... Cancel
sushil patidar 10 Years Ago Hi Jorge , Nice explanation of the liferay service architecture. But service methods are also executed using <entity>LocalServiceClp. Would you please also elaborate the motive of <entity>LocalServiceClp generated by service builder.Thanks Please sign in to reply. Reply as... Cancel
sushil patidar 10 Years Ago Hi Jorge , Nice explanation of the liferay service architecture. But service methods are also executed using <entity>LocalServiceClp. Would you please also elaborate the motive of <entity>LocalServiceClp generated by service builder.Thanks Please sign in to reply. Reply as... Cancel Jorge Ferrer sushil patidar 10 Years Ago Hi Sushil,<entity>LocalServiceClp can be used to invoke services defined and implemented in one plugin from another plugin. This class is autogenerated to handle the classloading manipulation necessary to do this, since the default classloading mechanisms of J2EE does not allow for it.Another way of achieving the same and one in which we are investing for 6.2 and future versions is using OSGi. Please sign in to reply. Reply as... Cancel sushil patidar Jorge Ferrer 10 Years Ago Hi Jorge, Thanks for quick response. Whether it is possible to use OSGI in earlier versions(LR6 ,LR6.1) also ? . Please sign in to reply. Reply as... Cancel Jorge Ferrer sushil patidar 10 Years Ago Liferay's Module Framework, which allows developing OSGi modules to extend Liferay, is only available since 6.2. I guess nothing prevents you from using OSGi on your own, but I guess it would be much more work. Please sign in to reply. Reply as... Cancel
Jorge Ferrer sushil patidar 10 Years Ago Hi Sushil,<entity>LocalServiceClp can be used to invoke services defined and implemented in one plugin from another plugin. This class is autogenerated to handle the classloading manipulation necessary to do this, since the default classloading mechanisms of J2EE does not allow for it.Another way of achieving the same and one in which we are investing for 6.2 and future versions is using OSGi. Please sign in to reply. Reply as... Cancel sushil patidar Jorge Ferrer 10 Years Ago Hi Jorge, Thanks for quick response. Whether it is possible to use OSGI in earlier versions(LR6 ,LR6.1) also ? . Please sign in to reply. Reply as... Cancel Jorge Ferrer sushil patidar 10 Years Ago Liferay's Module Framework, which allows developing OSGi modules to extend Liferay, is only available since 6.2. I guess nothing prevents you from using OSGi on your own, but I guess it would be much more work. Please sign in to reply. Reply as... Cancel
sushil patidar Jorge Ferrer 10 Years Ago Hi Jorge, Thanks for quick response. Whether it is possible to use OSGI in earlier versions(LR6 ,LR6.1) also ? . Please sign in to reply. Reply as... Cancel Jorge Ferrer sushil patidar 10 Years Ago Liferay's Module Framework, which allows developing OSGi modules to extend Liferay, is only available since 6.2. I guess nothing prevents you from using OSGi on your own, but I guess it would be much more work. Please sign in to reply. Reply as... Cancel
Jorge Ferrer sushil patidar 10 Years Ago Liferay's Module Framework, which allows developing OSGi modules to extend Liferay, is only available since 6.2. I guess nothing prevents you from using OSGi on your own, but I guess it would be much more work. Please sign in to reply. Reply as... Cancel