Tomáš Polešovský 12 Years Ago Whohoo! Nice!Ray, is this correct URL to see the modifications? https://github.com/rotty3000/liferay-portal/compare/master...OSGiThank you.-- tom Please sign in to reply. Reply as... Cancel
Szymon Gołębiewski 12 Years Ago As a guy that prepares and sells solutions based on Liferay I want to ask what do we gonna get from "Liferay+OSGi"? Please sign in to reply. Reply as... Cancel
jelmer kuperus 12 Years Ago hey ray, could you make your images viewable for guests. I am getting a permission error now Please sign in to reply. Reply as... Cancel Ray Augé jelmer kuperus 12 Years Ago @Tomáš, yes it is!@Szymon, my primary goal is to eliminate the dependency on j2ee/servlet specs and app server behaviors for support of hot deploy plugins. Basically, if Liferay could be a plain war, with no global scope interactions/changes needed, it would be better for everyone. OSGi can give us that and more.@ jelmer, Sorry, should be fixed now! Please sign in to reply. Reply as... Cancel Ravindra Kanchikare Ray Augé 12 Years Ago Does Liferay+OSGi helps us to deploy Liferay in Goggle app engine ? Please sign in to reply. Reply as... Cancel Ray Augé Ravindra Kanchikare 12 Years Ago - Edited Not immediately, but eventually it would make it more feasible to attempt it. There are a number of restrictions that Liferay would have to overcome, naturally the one I mentioned is one of the toughest, the global classloader dependency for plugins.But even after than is solved, we still need to address: "an app cannot spawn threads, write data to the local file system or make arbitrary network connections", but besides this, and by far the most difficult task would be the persistence tier, which for Liferay is heavily customized hibernate/SQL. App Engine only provides JDO and JPA, which we don't yet support either of. Please sign in to reply. Reply as... Cancel Jonas Yuan Ray Augé 12 Years Ago Very nice! Thanks, Ray. Please sign in to reply. Reply as... Cancel Ray Augé Jonas Yuan 12 Years Ago I just published the liferay-plugins OSGi branch with a few plugins to test out some of the features, such as http bridge support and example, service wrapper example, spring dm example, and blueprint example.https://github.com/rotty3000/liferay-plugins/tree/OSGi Please sign in to reply. Reply as... Cancel
Ray Augé jelmer kuperus 12 Years Ago @Tomáš, yes it is!@Szymon, my primary goal is to eliminate the dependency on j2ee/servlet specs and app server behaviors for support of hot deploy plugins. Basically, if Liferay could be a plain war, with no global scope interactions/changes needed, it would be better for everyone. OSGi can give us that and more.@ jelmer, Sorry, should be fixed now! Please sign in to reply. Reply as... Cancel Ravindra Kanchikare Ray Augé 12 Years Ago Does Liferay+OSGi helps us to deploy Liferay in Goggle app engine ? Please sign in to reply. Reply as... Cancel Ray Augé Ravindra Kanchikare 12 Years Ago - Edited Not immediately, but eventually it would make it more feasible to attempt it. There are a number of restrictions that Liferay would have to overcome, naturally the one I mentioned is one of the toughest, the global classloader dependency for plugins.But even after than is solved, we still need to address: "an app cannot spawn threads, write data to the local file system or make arbitrary network connections", but besides this, and by far the most difficult task would be the persistence tier, which for Liferay is heavily customized hibernate/SQL. App Engine only provides JDO and JPA, which we don't yet support either of. Please sign in to reply. Reply as... Cancel Jonas Yuan Ray Augé 12 Years Ago Very nice! Thanks, Ray. Please sign in to reply. Reply as... Cancel Ray Augé Jonas Yuan 12 Years Ago I just published the liferay-plugins OSGi branch with a few plugins to test out some of the features, such as http bridge support and example, service wrapper example, spring dm example, and blueprint example.https://github.com/rotty3000/liferay-plugins/tree/OSGi Please sign in to reply. Reply as... Cancel
Ravindra Kanchikare Ray Augé 12 Years Ago Does Liferay+OSGi helps us to deploy Liferay in Goggle app engine ? Please sign in to reply. Reply as... Cancel Ray Augé Ravindra Kanchikare 12 Years Ago - Edited Not immediately, but eventually it would make it more feasible to attempt it. There are a number of restrictions that Liferay would have to overcome, naturally the one I mentioned is one of the toughest, the global classloader dependency for plugins.But even after than is solved, we still need to address: "an app cannot spawn threads, write data to the local file system or make arbitrary network connections", but besides this, and by far the most difficult task would be the persistence tier, which for Liferay is heavily customized hibernate/SQL. App Engine only provides JDO and JPA, which we don't yet support either of. Please sign in to reply. Reply as... Cancel Jonas Yuan Ray Augé 12 Years Ago Very nice! Thanks, Ray. Please sign in to reply. Reply as... Cancel Ray Augé Jonas Yuan 12 Years Ago I just published the liferay-plugins OSGi branch with a few plugins to test out some of the features, such as http bridge support and example, service wrapper example, spring dm example, and blueprint example.https://github.com/rotty3000/liferay-plugins/tree/OSGi Please sign in to reply. Reply as... Cancel
Ray Augé Ravindra Kanchikare 12 Years Ago - Edited Not immediately, but eventually it would make it more feasible to attempt it. There are a number of restrictions that Liferay would have to overcome, naturally the one I mentioned is one of the toughest, the global classloader dependency for plugins.But even after than is solved, we still need to address: "an app cannot spawn threads, write data to the local file system or make arbitrary network connections", but besides this, and by far the most difficult task would be the persistence tier, which for Liferay is heavily customized hibernate/SQL. App Engine only provides JDO and JPA, which we don't yet support either of. Please sign in to reply. Reply as... Cancel Jonas Yuan Ray Augé 12 Years Ago Very nice! Thanks, Ray. Please sign in to reply. Reply as... Cancel Ray Augé Jonas Yuan 12 Years Ago I just published the liferay-plugins OSGi branch with a few plugins to test out some of the features, such as http bridge support and example, service wrapper example, spring dm example, and blueprint example.https://github.com/rotty3000/liferay-plugins/tree/OSGi Please sign in to reply. Reply as... Cancel
Jonas Yuan Ray Augé 12 Years Ago Very nice! Thanks, Ray. Please sign in to reply. Reply as... Cancel Ray Augé Jonas Yuan 12 Years Ago I just published the liferay-plugins OSGi branch with a few plugins to test out some of the features, such as http bridge support and example, service wrapper example, spring dm example, and blueprint example.https://github.com/rotty3000/liferay-plugins/tree/OSGi Please sign in to reply. Reply as... Cancel
Ray Augé Jonas Yuan 12 Years Ago I just published the liferay-plugins OSGi branch with a few plugins to test out some of the features, such as http bridge support and example, service wrapper example, spring dm example, and blueprint example.https://github.com/rotty3000/liferay-plugins/tree/OSGi Please sign in to reply. Reply as... Cancel
Sampsa Sohlman 12 Years Ago Truly interesting, I have to take a look. Brian Chan did mention OSGi development direction and reasons behind it year ago at European Symposium and now we see where you are going.Good work. Please sign in to reply. Reply as... Cancel
Tomáš Polešovský 12 Years Ago Ray, how deep do you want to go with the extensibility? Have you thought about loading/overriding/adding Struts+Tiles configs/classes, servlet filters, exposing portlets services ... also from the OSGi context - where it could be redefined by a custom module.And another idea - querying services/pojos in the OSGi context based on the current context in the portal (companyId/name, groupId/name) ? Please sign in to reply. Reply as... Cancel Jakub Liska Tomáš Polešovský 12 Years Ago Ray, how is this going to reflect on ServiceBuilder ? In regards to the notion of 2 non-related spring contexts (portlet / portal) that use different classloaders - SpringUtil.loadContext() for loading context from spring.configs locations is ok for testing Portal only, but for testing both Portlet services that implicitly use Portal services ... it is not so trivial. This is actually third time I'm doing that, I did it every time differently, learning from past mistakes... Please sign in to reply. Reply as... Cancel Ray Augé Jakub Liska 12 Years Ago At least from my perspective the model does not change from the current model one iota in the first generations. I also don't see a reason to change it since the OSGi blueprint spec is virtually a one to one mapping of what we're currently doing, except in standardized way. Please sign in to reply. Reply as... Cancel
Jakub Liska Tomáš Polešovský 12 Years Ago Ray, how is this going to reflect on ServiceBuilder ? In regards to the notion of 2 non-related spring contexts (portlet / portal) that use different classloaders - SpringUtil.loadContext() for loading context from spring.configs locations is ok for testing Portal only, but for testing both Portlet services that implicitly use Portal services ... it is not so trivial. This is actually third time I'm doing that, I did it every time differently, learning from past mistakes... Please sign in to reply. Reply as... Cancel Ray Augé Jakub Liska 12 Years Ago At least from my perspective the model does not change from the current model one iota in the first generations. I also don't see a reason to change it since the OSGi blueprint spec is virtually a one to one mapping of what we're currently doing, except in standardized way. Please sign in to reply. Reply as... Cancel
Ray Augé Jakub Liska 12 Years Ago At least from my perspective the model does not change from the current model one iota in the first generations. I also don't see a reason to change it since the OSGi blueprint spec is virtually a one to one mapping of what we're currently doing, except in standardized way. Please sign in to reply. Reply as... Cancel
Jack Bakker 12 Years Ago - Edited be interesting also ? for Vaadin portlets if UI modules could be added/removed on the flyhttp://vaadin.com/wiki/-/wiki/Main/Creating%20a%20Modular%20Vaadin%20Application%20with%20OSGi Please sign in to reply. Reply as... Cancel Ray Augé Jack Bakker 12 Years Ago Yup! I don't see any reason why they couldn't. I'm still working on the request handling delegation model (which will heavily factor in when working with third party libs like this). Right now the behavior is pretty raw but I figure it won't be more than a month or two (working on this only part time at the present) and I'll have that sorted out. Please sign in to reply. Reply as... Cancel jelmer kuperus Ray Augé 12 Years Ago os-chi-i ? Please sign in to reply. Reply as... Cancel Ray Augé jelmer kuperus 12 Years Ago ;) (can't wait for comment moderation workflow) Please sign in to reply. Reply as... Cancel
Ray Augé Jack Bakker 12 Years Ago Yup! I don't see any reason why they couldn't. I'm still working on the request handling delegation model (which will heavily factor in when working with third party libs like this). Right now the behavior is pretty raw but I figure it won't be more than a month or two (working on this only part time at the present) and I'll have that sorted out. Please sign in to reply. Reply as... Cancel jelmer kuperus Ray Augé 12 Years Ago os-chi-i ? Please sign in to reply. Reply as... Cancel Ray Augé jelmer kuperus 12 Years Ago ;) (can't wait for comment moderation workflow) Please sign in to reply. Reply as... Cancel
jelmer kuperus Ray Augé 12 Years Ago os-chi-i ? Please sign in to reply. Reply as... Cancel Ray Augé jelmer kuperus 12 Years Ago ;) (can't wait for comment moderation workflow) Please sign in to reply. Reply as... Cancel
Ray Augé jelmer kuperus 12 Years Ago ;) (can't wait for comment moderation workflow) Please sign in to reply. Reply as... Cancel
Amarjeet Singh 12 Years Ago I cloned git://github.com/rotty3000/liferay-portal.git locally and after a successful build and starting the server, I still do NOT see the OSGi Admin in the control panel. Is there something else I need to do in order to see this in action?Thanks! Please sign in to reply. Reply as... Cancel Ray Augé Amarjeet Singh 12 Years Ago You need to use the OSGi branch on my fork It should be in your clone if you pulled all the branches (which I think is typically the default).That branch is a little old about 2-3 weeks, but it's still very functional. Please sign in to reply. Reply as... Cancel
Ray Augé Amarjeet Singh 12 Years Ago You need to use the OSGi branch on my fork It should be in your clone if you pulled all the branches (which I think is typically the default).That branch is a little old about 2-3 weeks, but it's still very functional. Please sign in to reply. Reply as... Cancel
Kamesh Sampath 12 Years Ago just a clarification, i dont see any equinox jars or any other OSGi supported framework jars in the web-inf/lib of the Liferay OSGi server that i build from your github repo. is the bnd.jar the one which does the provisioning of bundles ? Can you please explain how bundles are processed and which jars are key for it ? just to understand the core architecture of it. Please sign in to reply. Reply as... Cancel Ray Augé Kamesh Sampath 12 Years Ago - Edited Liferay ships with equinox.jar that will appear in the WEB-INF/lib folder. This jar provides both the osgi apis as well as the equinox implementation. You could just as easily change this jar for Felix or Knopflerfish, or any OSGi implementation that supports the Framework API, as well as the BundleStartLevel API.You will find in portal.properties under the ## OSGi heading properties related to the configuration of the framework.I would like to stick with pure OSGi APIs in order for it to be possible to maintain this implementation agnostic support. It currently is, and should remain possible to swap out the OSGi implementation for any that support the OSGi 4.3 or higher standard.Deployment of OSGi bundles is implemented in two ways currently. You can drop bundles into the standard deploy folder and an OSGiAutoDeployListener which will identify bundles and install them (this is in trunk already) OR you can upload them directly via the OSGi Admin portlet if you have my OSGi branch (since this portlet is not in trunk).On portal startup, Liferay's OSGiServiceUtil class will dynamically locate and load the first Framework implementation it finds in its classpath. When initializing the Framework it will use the properties defined in portal(-ext).properties to setup it's environment. The interaction between the portal and Framework will continue to be controlled completely through this class, such as install/update/remove/start/stop/adjust run levels, etc.The BND jar is only used for handling of OSGi header parsing in two places a) during build time for the portal core, and b) during auto deploy to check if a plugin is an OSGi bundle. Please sign in to reply. Reply as... Cancel
Ray Augé Kamesh Sampath 12 Years Ago - Edited Liferay ships with equinox.jar that will appear in the WEB-INF/lib folder. This jar provides both the osgi apis as well as the equinox implementation. You could just as easily change this jar for Felix or Knopflerfish, or any OSGi implementation that supports the Framework API, as well as the BundleStartLevel API.You will find in portal.properties under the ## OSGi heading properties related to the configuration of the framework.I would like to stick with pure OSGi APIs in order for it to be possible to maintain this implementation agnostic support. It currently is, and should remain possible to swap out the OSGi implementation for any that support the OSGi 4.3 or higher standard.Deployment of OSGi bundles is implemented in two ways currently. You can drop bundles into the standard deploy folder and an OSGiAutoDeployListener which will identify bundles and install them (this is in trunk already) OR you can upload them directly via the OSGi Admin portlet if you have my OSGi branch (since this portlet is not in trunk).On portal startup, Liferay's OSGiServiceUtil class will dynamically locate and load the first Framework implementation it finds in its classpath. When initializing the Framework it will use the properties defined in portal(-ext).properties to setup it's environment. The interaction between the portal and Framework will continue to be controlled completely through this class, such as install/update/remove/start/stop/adjust run levels, etc.The BND jar is only used for handling of OSGi header parsing in two places a) during build time for the portal core, and b) during auto deploy to check if a plugin is an OSGi bundle. Please sign in to reply. Reply as... Cancel
Jevon Wright 12 Years Ago I'm so happy to see OSGi integration with Liferay, even in alpha stages. I'd love to see Liferay itself split into separate OSGi bundles but I'd imagine that's years and years away. Please sign in to reply. Reply as... Cancel Ray Augé Jevon Wright 12 Years Ago Thanks for your feedback Jevon!I should have some OSGi related content coming out very soon! I hope you find it interesting and ideally useful. Please sign in to reply. Reply as... Cancel Cristiano Gavião Ray Augé 12 Years Ago Hi Ray,Could you give me an updated status of our branch ? it is stable? it is sync with 6.1 version?I've been working in a vaadin + osgi + tycho product a couple of months. After reading your article, I think that integrating liferay could be a nice path to follow...regards,Cristiano Please sign in to reply. Reply as... Cancel Ray Augé Cristiano Gavião 12 Years Ago I'll be updating all this info in the next week(s) as we're starting the next dec cycle which contains some OSGi work. I'll keep you all posted.Thanks. Please sign in to reply. Reply as... Cancel
Ray Augé Jevon Wright 12 Years Ago Thanks for your feedback Jevon!I should have some OSGi related content coming out very soon! I hope you find it interesting and ideally useful. Please sign in to reply. Reply as... Cancel Cristiano Gavião Ray Augé 12 Years Ago Hi Ray,Could you give me an updated status of our branch ? it is stable? it is sync with 6.1 version?I've been working in a vaadin + osgi + tycho product a couple of months. After reading your article, I think that integrating liferay could be a nice path to follow...regards,Cristiano Please sign in to reply. Reply as... Cancel Ray Augé Cristiano Gavião 12 Years Ago I'll be updating all this info in the next week(s) as we're starting the next dec cycle which contains some OSGi work. I'll keep you all posted.Thanks. Please sign in to reply. Reply as... Cancel
Cristiano Gavião Ray Augé 12 Years Ago Hi Ray,Could you give me an updated status of our branch ? it is stable? it is sync with 6.1 version?I've been working in a vaadin + osgi + tycho product a couple of months. After reading your article, I think that integrating liferay could be a nice path to follow...regards,Cristiano Please sign in to reply. Reply as... Cancel Ray Augé Cristiano Gavião 12 Years Ago I'll be updating all this info in the next week(s) as we're starting the next dec cycle which contains some OSGi work. I'll keep you all posted.Thanks. Please sign in to reply. Reply as... Cancel
Ray Augé Cristiano Gavião 12 Years Ago I'll be updating all this info in the next week(s) as we're starting the next dec cycle which contains some OSGi work. I'll keep you all posted.Thanks. Please sign in to reply. Reply as... Cancel