Karl Pauls 12 Years Ago Interesting. Did you try to use PojoSR as a framework for Arkadiko (0.1.6 provides a Framework Factory)? The benefit would be that you don't have to worry about classloaders but can just put your bundles together with your jars on the classpath. Would be interesting to see whether it works. Please sign in to reply. Reply as... Cancel Ray Augé Karl Pauls 12 Years Ago First off, welcome to Liferay.com Paul! It's good to have you!Second, I didn't try that but it's an excellent idea! I will certainly give it a try as it sounds like a very interesting idea!Also, since I have your attention, perhaps you had already considered this, but perhaps not; that is the notion of using PojoSR as clever test harness for OSGi bundles. (I realize it's much more than that) As you know testing OSGi bundles can sometimes present difficulty for some developers. It occurred to me that PojoSR could avoid a lot of that difficulty by allowing developers to quickly build up test plans with dependent modules outside of a full OSGi runtime.Lastly, the next thing I'm going to be experimenting with is the possibility for Arkadiko to support resolving dependencies ("locating" services) from within the OSGi framework to satisfy the bean dependencies in spring without having an implementation existing on the spring side. Currently dependencies still needs to be satisfied on the spring side, which later could get overridden by an OSGi services. I'd like to solve that so code can finally and completely be moved from the spring side to the OSGi side.Anyway, Thanks for stopping by! Please sign in to reply. Reply as... Cancel Kamesh Sampath Ray Augé 12 Years Ago Ray,I just have a few questions here, 1. when you say that Arkadiko exposes all the beans as Services, don't you think we are violating the fundamental concept of OSGi the "modularity" by exposing all he stuff of the jar to external world ?2. How does version of the classes taken care by Arkadiko ? Lets taken an example i have 1.0.0 version of Bean called "MyBean" already deployed as Spring beans and now i deploy 2.0.0 of the same bean called "MyBean" .. Please excuse me if my questions are very basic, its just for my understanding Please sign in to reply. Reply as... Cancel Ray Augé Kamesh Sampath 12 Years Ago - Edited First, Spring knows nothing of versioning since it's plain java! Therefore there is no way that two versions can be in play, within spring. Second, you have to export the interfaces you want to load from OSGi via the system bundle, and so again the version is known and so only a matching version can be used.Within OSGi you can have multiple versions, within spring, there can be only one!I think this is still reasonable trade off considering that you get the benefit of the dynamic nature of OSGi which is already far more flexible than what spring alone can offer. Please sign in to reply. Reply as... Cancel Ray Augé Ray Augé 12 Years Ago - Edited That was an answer to the second question.This is the answer to the first one:To begin there is absolutely no way to get Liferay to a modular design in one shot! Not only would it break everything for backward compatibility but the gap between releases would have to be too big, Liferay would lose to much momentum and all interest would be lost.The WHOLE POINT of Arkadiko is to address that specific case where the code is so large than it has to be redesigned incrementally. When faced with that fact, there is little incentive to actually want to start migrating to OSGi at all. The cost may be too high. BUT if we form a partnership with the OSGi framework, and we expose the services that we have (which is the bulk of what developers need from Liferay) then we can begin to form a working model where developers can write plugins fully based in OSGi, and gain from it's benefits while slowly Liferay takes reorganizes. That would still be no change to developer code... since you don't care which bundles expose what.. you only care that something is exposed or not. This is the beauty and simplicity of Arkadiko, exposing as much as possible to OSGi NOW, while giving ourselves time to restructure it all. Please sign in to reply. Reply as... Cancel
Ray Augé Karl Pauls 12 Years Ago First off, welcome to Liferay.com Paul! It's good to have you!Second, I didn't try that but it's an excellent idea! I will certainly give it a try as it sounds like a very interesting idea!Also, since I have your attention, perhaps you had already considered this, but perhaps not; that is the notion of using PojoSR as clever test harness for OSGi bundles. (I realize it's much more than that) As you know testing OSGi bundles can sometimes present difficulty for some developers. It occurred to me that PojoSR could avoid a lot of that difficulty by allowing developers to quickly build up test plans with dependent modules outside of a full OSGi runtime.Lastly, the next thing I'm going to be experimenting with is the possibility for Arkadiko to support resolving dependencies ("locating" services) from within the OSGi framework to satisfy the bean dependencies in spring without having an implementation existing on the spring side. Currently dependencies still needs to be satisfied on the spring side, which later could get overridden by an OSGi services. I'd like to solve that so code can finally and completely be moved from the spring side to the OSGi side.Anyway, Thanks for stopping by! Please sign in to reply. Reply as... Cancel Kamesh Sampath Ray Augé 12 Years Ago Ray,I just have a few questions here, 1. when you say that Arkadiko exposes all the beans as Services, don't you think we are violating the fundamental concept of OSGi the "modularity" by exposing all he stuff of the jar to external world ?2. How does version of the classes taken care by Arkadiko ? Lets taken an example i have 1.0.0 version of Bean called "MyBean" already deployed as Spring beans and now i deploy 2.0.0 of the same bean called "MyBean" .. Please excuse me if my questions are very basic, its just for my understanding Please sign in to reply. Reply as... Cancel Ray Augé Kamesh Sampath 12 Years Ago - Edited First, Spring knows nothing of versioning since it's plain java! Therefore there is no way that two versions can be in play, within spring. Second, you have to export the interfaces you want to load from OSGi via the system bundle, and so again the version is known and so only a matching version can be used.Within OSGi you can have multiple versions, within spring, there can be only one!I think this is still reasonable trade off considering that you get the benefit of the dynamic nature of OSGi which is already far more flexible than what spring alone can offer. Please sign in to reply. Reply as... Cancel Ray Augé Ray Augé 12 Years Ago - Edited That was an answer to the second question.This is the answer to the first one:To begin there is absolutely no way to get Liferay to a modular design in one shot! Not only would it break everything for backward compatibility but the gap between releases would have to be too big, Liferay would lose to much momentum and all interest would be lost.The WHOLE POINT of Arkadiko is to address that specific case where the code is so large than it has to be redesigned incrementally. When faced with that fact, there is little incentive to actually want to start migrating to OSGi at all. The cost may be too high. BUT if we form a partnership with the OSGi framework, and we expose the services that we have (which is the bulk of what developers need from Liferay) then we can begin to form a working model where developers can write plugins fully based in OSGi, and gain from it's benefits while slowly Liferay takes reorganizes. That would still be no change to developer code... since you don't care which bundles expose what.. you only care that something is exposed or not. This is the beauty and simplicity of Arkadiko, exposing as much as possible to OSGi NOW, while giving ourselves time to restructure it all. Please sign in to reply. Reply as... Cancel
Kamesh Sampath Ray Augé 12 Years Ago Ray,I just have a few questions here, 1. when you say that Arkadiko exposes all the beans as Services, don't you think we are violating the fundamental concept of OSGi the "modularity" by exposing all he stuff of the jar to external world ?2. How does version of the classes taken care by Arkadiko ? Lets taken an example i have 1.0.0 version of Bean called "MyBean" already deployed as Spring beans and now i deploy 2.0.0 of the same bean called "MyBean" .. Please excuse me if my questions are very basic, its just for my understanding Please sign in to reply. Reply as... Cancel Ray Augé Kamesh Sampath 12 Years Ago - Edited First, Spring knows nothing of versioning since it's plain java! Therefore there is no way that two versions can be in play, within spring. Second, you have to export the interfaces you want to load from OSGi via the system bundle, and so again the version is known and so only a matching version can be used.Within OSGi you can have multiple versions, within spring, there can be only one!I think this is still reasonable trade off considering that you get the benefit of the dynamic nature of OSGi which is already far more flexible than what spring alone can offer. Please sign in to reply. Reply as... Cancel Ray Augé Ray Augé 12 Years Ago - Edited That was an answer to the second question.This is the answer to the first one:To begin there is absolutely no way to get Liferay to a modular design in one shot! Not only would it break everything for backward compatibility but the gap between releases would have to be too big, Liferay would lose to much momentum and all interest would be lost.The WHOLE POINT of Arkadiko is to address that specific case where the code is so large than it has to be redesigned incrementally. When faced with that fact, there is little incentive to actually want to start migrating to OSGi at all. The cost may be too high. BUT if we form a partnership with the OSGi framework, and we expose the services that we have (which is the bulk of what developers need from Liferay) then we can begin to form a working model where developers can write plugins fully based in OSGi, and gain from it's benefits while slowly Liferay takes reorganizes. That would still be no change to developer code... since you don't care which bundles expose what.. you only care that something is exposed or not. This is the beauty and simplicity of Arkadiko, exposing as much as possible to OSGi NOW, while giving ourselves time to restructure it all. Please sign in to reply. Reply as... Cancel
Ray Augé Kamesh Sampath 12 Years Ago - Edited First, Spring knows nothing of versioning since it's plain java! Therefore there is no way that two versions can be in play, within spring. Second, you have to export the interfaces you want to load from OSGi via the system bundle, and so again the version is known and so only a matching version can be used.Within OSGi you can have multiple versions, within spring, there can be only one!I think this is still reasonable trade off considering that you get the benefit of the dynamic nature of OSGi which is already far more flexible than what spring alone can offer. Please sign in to reply. Reply as... Cancel Ray Augé Ray Augé 12 Years Ago - Edited That was an answer to the second question.This is the answer to the first one:To begin there is absolutely no way to get Liferay to a modular design in one shot! Not only would it break everything for backward compatibility but the gap between releases would have to be too big, Liferay would lose to much momentum and all interest would be lost.The WHOLE POINT of Arkadiko is to address that specific case where the code is so large than it has to be redesigned incrementally. When faced with that fact, there is little incentive to actually want to start migrating to OSGi at all. The cost may be too high. BUT if we form a partnership with the OSGi framework, and we expose the services that we have (which is the bulk of what developers need from Liferay) then we can begin to form a working model where developers can write plugins fully based in OSGi, and gain from it's benefits while slowly Liferay takes reorganizes. That would still be no change to developer code... since you don't care which bundles expose what.. you only care that something is exposed or not. This is the beauty and simplicity of Arkadiko, exposing as much as possible to OSGi NOW, while giving ourselves time to restructure it all. Please sign in to reply. Reply as... Cancel
Ray Augé Ray Augé 12 Years Ago - Edited That was an answer to the second question.This is the answer to the first one:To begin there is absolutely no way to get Liferay to a modular design in one shot! Not only would it break everything for backward compatibility but the gap between releases would have to be too big, Liferay would lose to much momentum and all interest would be lost.The WHOLE POINT of Arkadiko is to address that specific case where the code is so large than it has to be redesigned incrementally. When faced with that fact, there is little incentive to actually want to start migrating to OSGi at all. The cost may be too high. BUT if we form a partnership with the OSGi framework, and we expose the services that we have (which is the bulk of what developers need from Liferay) then we can begin to form a working model where developers can write plugins fully based in OSGi, and gain from it's benefits while slowly Liferay takes reorganizes. That would still be no change to developer code... since you don't care which bundles expose what.. you only care that something is exposed or not. This is the beauty and simplicity of Arkadiko, exposing as much as possible to OSGi NOW, while giving ourselves time to restructure it all. Please sign in to reply. Reply as... Cancel