Dimitris Menounos 7 Years Ago 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 Please sign in to reply. Reply as... Cancel David H Nebinger Dimitris Menounos 7 Years Ago - Edited 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. Please sign in to reply. Reply as... Cancel Dimitris Menounos David H Nebinger 7 Years Ago 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. Please sign in to reply. Reply as... Cancel David H Nebinger Dimitris Menounos 7 Years Ago 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. Please sign in to reply. Reply as... Cancel
David H Nebinger Dimitris Menounos 7 Years Ago - Edited 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. Please sign in to reply. Reply as... Cancel Dimitris Menounos David H Nebinger 7 Years Ago 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. Please sign in to reply. Reply as... Cancel David H Nebinger Dimitris Menounos 7 Years Ago 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. Please sign in to reply. Reply as... Cancel
Dimitris Menounos David H Nebinger 7 Years Ago 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. Please sign in to reply. Reply as... Cancel David H Nebinger Dimitris Menounos 7 Years Ago 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. Please sign in to reply. Reply as... Cancel
David H Nebinger Dimitris Menounos 7 Years Ago 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. Please sign in to reply. Reply as... Cancel
Evan Thomas 7 Years Ago 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. Please sign in to reply. Reply as... Cancel
Roberto Javier Aguirre 6 Years Ago I added a second portlet but i cant see it on menu inside of new category Please sign in to reply. Reply as... Cancel