Dimitris Menounos 7年 前 Are OSGi based portlets are compatible with the portlet standard?And if we want to stay with the standard approach (no osgi api and packaging), how do we access the various services?Thank you 投票するためにはログインが必要です。 次として送信する: キャンセル David H Nebinger Dimitris Menounos 7年 前 - 編集済み So OSGi portlet modules do not have a portlet.xml file, instead the values are set using the OSGi annotation on the portlet class so, technically, they do not adhere to the letter of the specification. But in all other ways, they do adhere to the spec.Liferay still has the Util classes that provide static access to service instances. Even when you do your own LR7 SB modules, you still end up with an API jar that has the static Util classes. So in legacy mode, your service access methods are the same.Note that when your in this legacy mode, your war files get dropped into the Liferay deploy folder and Liferay will actually rebundle these as WABs and deploy them within the OSGi framework as if you have a "pure" OSGi portlet.While this is supported, I would encourage you to keep this method only for your existing projects; if you are starting a new project, you will be much better served by picking up the new ways of developing portlets.I mean, I have no inside information, but would you want to guess if legacy wars will be supported under LR 7.1 or LR 8 or 9 or ...? Maybe they will, I really don't know. I can't see Liferay moving backwards off of OSGi, however. 投票するためにはログインが必要です。 次として送信する: キャンセル Dimitris Menounos David H Nebinger 7年 前 I understand that OSGi offers certain advantages, especially for the developers of the platform. However from the view of the developer of applications, OSGi brings in added complexity and some important disadvantages I might say.Firstly, it creates a separate container from the application server. That, makes it an alien environment with respect to the application server and as such stands in the way of the builtin provided JEE services. For example. Can we use the application server CDI services? or the EJB services? Can we use the application server provided transaction management? the application server AOP functionalities? the application server ORM functionalities? I haven't delved much into LR 7 yet, but I guess that that the answer is no.Even from the perspective of configuration and packaging, I believe that being compliant with the standards is something crucially important for some organizations. The idea that a future Liferay version could drop the support for standards based portlet development is very worrisome at least. 投票するためにはログインが必要です。 次として送信する: キャンセル David H Nebinger Dimitris Menounos 7年 前 The problem, though, is that the java specifications say nothing about JEE; they don't even require an application container for that matter. The portlet spec talks about it's own requests and responses, it's own session management, etc. The fact that Liferay and others have built their portlet standard compliant container on a regular JEE server is an implementation detail left to the implementors, but it is not a requirement from the portlet specifications themselves.So the joining of the portlet spec and JEE services is not a requirement, and I don't believe you'll find any commitment from Liferay to ever support or sanction or leverage JEE services in any documentation in the last 5 years or so.The last time JEE was supported was back under versions 4 (and possibly 5) where the Liferay EE lines were leveraging some J2EE facilities, but that was before the explosion of Hibernate, Spring, Spring Security, etc. that offered similar functionality w/o the J2EE application containers. From 6.0 on, Liferay has been dependent upon only a container implementing the Java Servlet and Java Server Pages specifications.All of those things said, the OSGi container is running within the Liferay web application that can be deployed to a JEE container. So all of the OSGi code is still under the Liferay web application. Can it therefore leverage the JEE facilities mentioned? Possibly, it make take some research and some glue to make it happen, but I can't say it can't be done. 投票するためにはログインが必要です。 次として送信する: キャンセル
David H Nebinger Dimitris Menounos 7年 前 - 編集済み So OSGi portlet modules do not have a portlet.xml file, instead the values are set using the OSGi annotation on the portlet class so, technically, they do not adhere to the letter of the specification. But in all other ways, they do adhere to the spec.Liferay still has the Util classes that provide static access to service instances. Even when you do your own LR7 SB modules, you still end up with an API jar that has the static Util classes. So in legacy mode, your service access methods are the same.Note that when your in this legacy mode, your war files get dropped into the Liferay deploy folder and Liferay will actually rebundle these as WABs and deploy them within the OSGi framework as if you have a "pure" OSGi portlet.While this is supported, I would encourage you to keep this method only for your existing projects; if you are starting a new project, you will be much better served by picking up the new ways of developing portlets.I mean, I have no inside information, but would you want to guess if legacy wars will be supported under LR 7.1 or LR 8 or 9 or ...? Maybe they will, I really don't know. I can't see Liferay moving backwards off of OSGi, however. 投票するためにはログインが必要です。 次として送信する: キャンセル Dimitris Menounos David H Nebinger 7年 前 I understand that OSGi offers certain advantages, especially for the developers of the platform. However from the view of the developer of applications, OSGi brings in added complexity and some important disadvantages I might say.Firstly, it creates a separate container from the application server. That, makes it an alien environment with respect to the application server and as such stands in the way of the builtin provided JEE services. For example. Can we use the application server CDI services? or the EJB services? Can we use the application server provided transaction management? the application server AOP functionalities? the application server ORM functionalities? I haven't delved much into LR 7 yet, but I guess that that the answer is no.Even from the perspective of configuration and packaging, I believe that being compliant with the standards is something crucially important for some organizations. The idea that a future Liferay version could drop the support for standards based portlet development is very worrisome at least. 投票するためにはログインが必要です。 次として送信する: キャンセル David H Nebinger Dimitris Menounos 7年 前 The problem, though, is that the java specifications say nothing about JEE; they don't even require an application container for that matter. The portlet spec talks about it's own requests and responses, it's own session management, etc. The fact that Liferay and others have built their portlet standard compliant container on a regular JEE server is an implementation detail left to the implementors, but it is not a requirement from the portlet specifications themselves.So the joining of the portlet spec and JEE services is not a requirement, and I don't believe you'll find any commitment from Liferay to ever support or sanction or leverage JEE services in any documentation in the last 5 years or so.The last time JEE was supported was back under versions 4 (and possibly 5) where the Liferay EE lines were leveraging some J2EE facilities, but that was before the explosion of Hibernate, Spring, Spring Security, etc. that offered similar functionality w/o the J2EE application containers. From 6.0 on, Liferay has been dependent upon only a container implementing the Java Servlet and Java Server Pages specifications.All of those things said, the OSGi container is running within the Liferay web application that can be deployed to a JEE container. So all of the OSGi code is still under the Liferay web application. Can it therefore leverage the JEE facilities mentioned? Possibly, it make take some research and some glue to make it happen, but I can't say it can't be done. 投票するためにはログインが必要です。 次として送信する: キャンセル
Dimitris Menounos David H Nebinger 7年 前 I understand that OSGi offers certain advantages, especially for the developers of the platform. However from the view of the developer of applications, OSGi brings in added complexity and some important disadvantages I might say.Firstly, it creates a separate container from the application server. That, makes it an alien environment with respect to the application server and as such stands in the way of the builtin provided JEE services. For example. Can we use the application server CDI services? or the EJB services? Can we use the application server provided transaction management? the application server AOP functionalities? the application server ORM functionalities? I haven't delved much into LR 7 yet, but I guess that that the answer is no.Even from the perspective of configuration and packaging, I believe that being compliant with the standards is something crucially important for some organizations. The idea that a future Liferay version could drop the support for standards based portlet development is very worrisome at least. 投票するためにはログインが必要です。 次として送信する: キャンセル David H Nebinger Dimitris Menounos 7年 前 The problem, though, is that the java specifications say nothing about JEE; they don't even require an application container for that matter. The portlet spec talks about it's own requests and responses, it's own session management, etc. The fact that Liferay and others have built their portlet standard compliant container on a regular JEE server is an implementation detail left to the implementors, but it is not a requirement from the portlet specifications themselves.So the joining of the portlet spec and JEE services is not a requirement, and I don't believe you'll find any commitment from Liferay to ever support or sanction or leverage JEE services in any documentation in the last 5 years or so.The last time JEE was supported was back under versions 4 (and possibly 5) where the Liferay EE lines were leveraging some J2EE facilities, but that was before the explosion of Hibernate, Spring, Spring Security, etc. that offered similar functionality w/o the J2EE application containers. From 6.0 on, Liferay has been dependent upon only a container implementing the Java Servlet and Java Server Pages specifications.All of those things said, the OSGi container is running within the Liferay web application that can be deployed to a JEE container. So all of the OSGi code is still under the Liferay web application. Can it therefore leverage the JEE facilities mentioned? Possibly, it make take some research and some glue to make it happen, but I can't say it can't be done. 投票するためにはログインが必要です。 次として送信する: キャンセル
David H Nebinger Dimitris Menounos 7年 前 The problem, though, is that the java specifications say nothing about JEE; they don't even require an application container for that matter. The portlet spec talks about it's own requests and responses, it's own session management, etc. The fact that Liferay and others have built their portlet standard compliant container on a regular JEE server is an implementation detail left to the implementors, but it is not a requirement from the portlet specifications themselves.So the joining of the portlet spec and JEE services is not a requirement, and I don't believe you'll find any commitment from Liferay to ever support or sanction or leverage JEE services in any documentation in the last 5 years or so.The last time JEE was supported was back under versions 4 (and possibly 5) where the Liferay EE lines were leveraging some J2EE facilities, but that was before the explosion of Hibernate, Spring, Spring Security, etc. that offered similar functionality w/o the J2EE application containers. From 6.0 on, Liferay has been dependent upon only a container implementing the Java Servlet and Java Server Pages specifications.All of those things said, the OSGi container is running within the Liferay web application that can be deployed to a JEE container. So all of the OSGi code is still under the Liferay web application. Can it therefore leverage the JEE facilities mentioned? Possibly, it make take some research and some glue to make it happen, but I can't say it can't be done. 投票するためにはログインが必要です。 次として送信する: キャンセル
Evan Thomas 7年 前 Thanks for providing these tutorials. As a complete newbie not just to liferay but the whole portal world there are many technologies I need to learn simultaneously. This tutorial has helped make some of the things mentioned in the official LR documentation concrete and this will help bootstrap into the rest of the stack. 投票するためにはログインが必要です。 次として送信する: キャンセル
Roberto Javier Aguirre 6年 前 I added a second portlet but i cant see it on menu inside of new category 投票するためにはログインが必要です。 次として送信する: キャンセル