Ákos Gábriel 11年 前 "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! 投票するためにはログインが必要です。 次として送信する: キャンセル Jorge Ferrer Ákos Gábriel 11年 前 Fixed. Thanks Ákos. I'm glad you liked it. 投票するためにはログインが必要です。 次として送信する: キャンセル
Jorge Ferrer Ákos Gábriel 11年 前 Fixed. Thanks Ákos. I'm glad you liked it. 投票するためにはログインが必要です。 次として送信する: キャンセル
Remis Baima 11年 前 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 :-). 投票するためにはログインが必要です。 次として送信する: キャンセル Jorge Ferrer Remis Baima 11年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル
Jorge Ferrer Remis Baima 11年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル
Dave Weitzel 11年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル
Alain Dresse 11年 前 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 ? 投票するためにはログインが必要です。 次として送信する: キャンセル David H Nebinger Alain Dresse 11年 前 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). 投票するためにはログインが必要です。 次として送信する: キャンセル Jorge Ferrer David H Nebinger 11年 前 @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 投票するためにはログインが必要です。 次として送信する: キャンセル Alain Dresse David H Nebinger 11年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル
David H Nebinger Alain Dresse 11年 前 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). 投票するためにはログインが必要です。 次として送信する: キャンセル Jorge Ferrer David H Nebinger 11年 前 @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 投票するためにはログインが必要です。 次として送信する: キャンセル Alain Dresse David H Nebinger 11年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル
Jorge Ferrer David H Nebinger 11年 前 @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 投票するためにはログインが必要です。 次として送信する: キャンセル
Alain Dresse David H Nebinger 11年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル
Andrea Gentili 11年 前 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 投票するためにはログインが必要です。 次として送信する: キャンセル Jorge Ferrer Andrea Gentili 11年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル David H Nebinger Jorge Ferrer 11年 前 @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. 投票するためにはログインが必要です。 次として送信する: キャンセル Andrea Gentili David H Nebinger 11年 前 Hi Jorge,which Oauth versione (1.0 or 2.0) will be supported as option for web service authentication?Thanks in advance,Andrea. 投票するためにはログインが必要です。 次として送信する: キャンセル Jorge Ferrer Andrea Gentili 11年 前 Right now I think it's 1.0.Oauth 2.0 is more of a framework than a protocol. 投票するためにはログインが必要です。 次として送信する: キャンセル
Jorge Ferrer Andrea Gentili 11年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル David H Nebinger Jorge Ferrer 11年 前 @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. 投票するためにはログインが必要です。 次として送信する: キャンセル Andrea Gentili David H Nebinger 11年 前 Hi Jorge,which Oauth versione (1.0 or 2.0) will be supported as option for web service authentication?Thanks in advance,Andrea. 投票するためにはログインが必要です。 次として送信する: キャンセル Jorge Ferrer Andrea Gentili 11年 前 Right now I think it's 1.0.Oauth 2.0 is more of a framework than a protocol. 投票するためにはログインが必要です。 次として送信する: キャンセル
David H Nebinger Jorge Ferrer 11年 前 @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. 投票するためにはログインが必要です。 次として送信する: キャンセル Andrea Gentili David H Nebinger 11年 前 Hi Jorge,which Oauth versione (1.0 or 2.0) will be supported as option for web service authentication?Thanks in advance,Andrea. 投票するためにはログインが必要です。 次として送信する: キャンセル Jorge Ferrer Andrea Gentili 11年 前 Right now I think it's 1.0.Oauth 2.0 is more of a framework than a protocol. 投票するためにはログインが必要です。 次として送信する: キャンセル
Andrea Gentili David H Nebinger 11年 前 Hi Jorge,which Oauth versione (1.0 or 2.0) will be supported as option for web service authentication?Thanks in advance,Andrea. 投票するためにはログインが必要です。 次として送信する: キャンセル Jorge Ferrer Andrea Gentili 11年 前 Right now I think it's 1.0.Oauth 2.0 is more of a framework than a protocol. 投票するためにはログインが必要です。 次として送信する: キャンセル
Jorge Ferrer Andrea Gentili 11年 前 Right now I think it's 1.0.Oauth 2.0 is more of a framework than a protocol. 投票するためにはログインが必要です。 次として送信する: キャンセル
sushil patidar 10年 前 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 投票するためにはログインが必要です。 次として送信する: キャンセル
sushil patidar 10年 前 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 投票するためにはログインが必要です。 次として送信する: キャンセル Jorge Ferrer sushil patidar 10年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル sushil patidar Jorge Ferrer 10年 前 Hi Jorge, Thanks for quick response. Whether it is possible to use OSGI in earlier versions(LR6 ,LR6.1) also ? . 投票するためにはログインが必要です。 次として送信する: キャンセル Jorge Ferrer sushil patidar 10年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル
Jorge Ferrer sushil patidar 10年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル sushil patidar Jorge Ferrer 10年 前 Hi Jorge, Thanks for quick response. Whether it is possible to use OSGI in earlier versions(LR6 ,LR6.1) also ? . 投票するためにはログインが必要です。 次として送信する: キャンセル Jorge Ferrer sushil patidar 10年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル
sushil patidar Jorge Ferrer 10年 前 Hi Jorge, Thanks for quick response. Whether it is possible to use OSGI in earlier versions(LR6 ,LR6.1) also ? . 投票するためにはログインが必要です。 次として送信する: キャンセル Jorge Ferrer sushil patidar 10年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル
Jorge Ferrer sushil patidar 10年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル