Tomáš Polešovský Il y a 12 années Whohoo! Nice!Ray, is this correct URL to see the modifications? https://github.com/rotty3000/liferay-portal/compare/master...OSGiThank you.-- tom Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Szymon Gołębiewski Il y a 12 années As a guy that prepares and sells solutions based on Liferay I want to ask what do we gonna get from "Liferay+OSGi"? Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
jelmer kuperus Il y a 12 années hey ray, could you make your images viewable for guests. I am getting a permission error now Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Ray Augé jelmer kuperus Il y a 12 années @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! Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Ravindra Kanchikare Ray Augé Il y a 12 années Does Liferay+OSGi helps us to deploy Liferay in Goggle app engine ? Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Ray Augé Ravindra Kanchikare Il y a 12 années - Edité 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. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Jonas Yuan Ray Augé Il y a 12 années Very nice! Thanks, Ray. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Ray Augé Jonas Yuan Il y a 12 années 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 Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Ray Augé jelmer kuperus Il y a 12 années @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! Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Ravindra Kanchikare Ray Augé Il y a 12 années Does Liferay+OSGi helps us to deploy Liferay in Goggle app engine ? Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Ray Augé Ravindra Kanchikare Il y a 12 années - Edité 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. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Jonas Yuan Ray Augé Il y a 12 années Very nice! Thanks, Ray. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Ray Augé Jonas Yuan Il y a 12 années 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 Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Ravindra Kanchikare Ray Augé Il y a 12 années Does Liferay+OSGi helps us to deploy Liferay in Goggle app engine ? Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Ray Augé Ravindra Kanchikare Il y a 12 années - Edité 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. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Jonas Yuan Ray Augé Il y a 12 années Very nice! Thanks, Ray. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Ray Augé Jonas Yuan Il y a 12 années 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 Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Ray Augé Ravindra Kanchikare Il y a 12 années - Edité 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. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Jonas Yuan Ray Augé Il y a 12 années Very nice! Thanks, Ray. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Ray Augé Jonas Yuan Il y a 12 années 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 Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Jonas Yuan Ray Augé Il y a 12 années Very nice! Thanks, Ray. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Ray Augé Jonas Yuan Il y a 12 années 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 Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Ray Augé Jonas Yuan Il y a 12 années 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 Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Sampsa Sohlman Il y a 12 années 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. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Tomáš Polešovský Il y a 12 années 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) ? Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Jakub Liska Tomáš Polešovský Il y a 12 années 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... Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Ray Augé Jakub Liska Il y a 12 années 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. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Jakub Liska Tomáš Polešovský Il y a 12 années 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... Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Ray Augé Jakub Liska Il y a 12 années 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. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Ray Augé Jakub Liska Il y a 12 années 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. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Jack Bakker Il y a 12 années - Edité 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 Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Ray Augé Jack Bakker Il y a 12 années 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. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler jelmer kuperus Ray Augé Il y a 12 années os-chi-i ? Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Ray Augé jelmer kuperus Il y a 12 années ;) (can't wait for comment moderation workflow) Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Ray Augé Jack Bakker Il y a 12 années 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. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler jelmer kuperus Ray Augé Il y a 12 années os-chi-i ? Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Ray Augé jelmer kuperus Il y a 12 années ;) (can't wait for comment moderation workflow) Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
jelmer kuperus Ray Augé Il y a 12 années os-chi-i ? Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Ray Augé jelmer kuperus Il y a 12 années ;) (can't wait for comment moderation workflow) Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Ray Augé jelmer kuperus Il y a 12 années ;) (can't wait for comment moderation workflow) Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Amarjeet Singh Il y a 12 années 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! Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Ray Augé Amarjeet Singh Il y a 12 années 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. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Ray Augé Amarjeet Singh Il y a 12 années 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. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Kamesh Sampath Il y a 12 années 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. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Ray Augé Kamesh Sampath Il y a 12 années - Edité 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. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Ray Augé Kamesh Sampath Il y a 12 années - Edité 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. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Jevon Wright Il y a 12 années 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. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Ray Augé Jevon Wright Il y a 12 années 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. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Cristiano Gavião Ray Augé Il y a 12 années 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 Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Ray Augé Cristiano Gavião Il y a 12 années 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. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Ray Augé Jevon Wright Il y a 12 années 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. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Cristiano Gavião Ray Augé Il y a 12 années 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 Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Ray Augé Cristiano Gavião Il y a 12 années 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. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Cristiano Gavião Ray Augé Il y a 12 années 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 Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Ray Augé Cristiano Gavião Il y a 12 années 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. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Ray Augé Cristiano Gavião Il y a 12 années 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. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler