Thank you Peter! That's all I really hoping to hear.
- Ray On Tue, Apr 2, 2013 at 3:06 AM, Peter Kriens <[email protected]> wrote: > An embedded framework is similar to PojoSR and I it will work since you > never take a big step, you can adjust your strategy along the way. I think > PojoSR will give you an advantage since all developers can now take > advantage of OSGi without worrying about class loading. If you are service > centric already you can even try both: PojoSR for the old code and an > embedded framework for the new code. It is not that hard to make sure both > sides see the same services. > > Anyway, speed is a matter of risk and effort. Not sure either approach is > faster or slower only that big bangs tend to fail. > > Kind regards, > > Peter Kriens > > On 1 apr. 2013, at 16:54, Raymond Auge wrote: > > Thanks for your response Peter. I really appreciate it. > > I follow your logic above, it makes complete sense. > > However, I'd like to argue that this process has a limit of scale. Take > for instance the Websphere migration to OSGi (I'm extrapolating from Graham > Charters talk at Eclipse/OSGiCon). I don't think it could ever have > included the PojoSR step. Nor could it have succeeded, I believe, without > an early access to the real OSGi framework (in order for the engineers to > learn and immediately benefit from it). > > If I'm wrong, I'm hoping he'll correct me. > > My point is that I'm not really convinced (excluding the services first > step of course) that migrating a truly complex application can suffer the > process above. In our case, taking that approach would literally mean years > for us to get to OSGi. We'd be mired in the gap between services first > (which in our case we luckily already have) and an actual set of bundles > running in osgi for an eternity and I'm sure misery would quickly set in > among our team members. > > I think our project fits more with the Websphere case than with any > project that could conceivably be re-architected in more or less a single > development cycle. > > We have several criteria: > > 1) we have to retain backward compatibility for our own plugin APIs and > lifecycle (which uses the host app server's webapp support) > 2) we can't repackage our app as a pure OSGi runtime with a set of bundles > (it's a web app, and has to run in app servers) without losing significant > extensibility feature set we currently support. > 3) "super bundle" approach is out of the question (it would break > literally thousands of features) > 4) we can't assume an osgi runtime exists outside one we bootstrap > ourselves (we run in websphere, weblogic - jetty, tomcat (everything in > between) > 5) it will likely take 4-5 years to fully migrate our application to OSGi > 5.1) we cannot have dual development streams supporting both the legacy > and the new architecture > 5.2) we must release new versions of our product in that time > > I have spoken to many of the esteemed OSGi experts who came to OSGiCon, > however I have sensed trepidation when discussing our situation and > approach. Perhaps few have considered the position such as the one we're in > (except again Websphere) because of the types of recommendations I have > been given (except by the odd few). > > I'm hoping for some measure of validation that taking the approach of > starting with an embedded framework container with the goal of evolving our > application in small bits gradually over time is not a completely > bone-headed plan. > > In fact, I've started a small project, which I am hoping to leverage, > which will allow parts of our application which are spring based (but > outside osgi) to leverage OSGi services without actually being aware that > they are doing so (akin to PojoSR, except backed by a real OSGi framework). > I'm currently also considering taking a similar approach for other > "component"-like frameworks in order to allow those to consume OSGi > services without actually being aware of it, like struts. > > The project is called Arkadiko > (https://github.com/rotty3000/arkadiko/blob/master/README.md)<https://github.com/rotty3000/arkadiko/blob/master/README.md>and > it actually talks about the above concerns. It's a work in progress. > > I'd be quite pleased if the experts here could comment more on our > approach. > > Sincerely, > - Ray > > > On Mon, Apr 1, 2013 at 4:48 AM, Peter Kriens <[email protected]>wrote: > >> A very good way to get started with OSGi is services first. Start with >> PojoSR and then move your code to services. Since PojoSR == OSGi - >> classloader isolation it will not break your code and is completely >> unintrusive. Once you're there, you can test the app, move something to a >> bundle with services, test, repeat ad. hopefully not infinitum. Notice that >> bundles work, DS works, Config Admin works, etc. Limits are no class loader >> isolation, so no dynamic install/uninstall/update and side by side >> versioning. Start/stop, resource loading, etc. all work. >> >> Once the application is broken in bundles that way you can try to run it >> with isolation. Since you do not need class loader hacks for the >> intermodule communication (services fulfill that role) remaining problems >> should be manageable. >> >> That said, the greatest problem is that there are too few enterprise >> libraries that are really modular, uncoupled, and highly cohesive. Many >> popular libraries drag in the kitchen sink. >> >> Kind regards, >> >> Peter Kriens >> >> >> >> On 29 mrt. 2013, at 16:56, Raymond Auge wrote: >> >> [This was going to be a response to the DS vs Blueprint thread.. but got >> too long] >> >> Re: DS vs Blueprint? >> >> What about complex concerns like providing aop on thousands of services? >> >> Speaking to David Bosschaert briefly about this at osgi con, he suggested >> two options, service interception (via service listener I believe) and/or >> asm/weaving/etc (David correct me if I'm wrong here). >> >> Which of DS or Blueprint lends itself better with these concerns? >> >> It would seem to me that DS lends itself better when development is on >> "new" components while Blueprint seems more "integrate-able" with already >> established, non-osgi, components. >> >> This brings me to my main topic and a comment I have after all the >> fantastic talks from the convention is that the vast majority of >> application of osgi (except of course for Graham's talk exploring the >> history of Websphere's evolution to osgi) seems focused on new development. >> Meanwhile it's evident that a key osgi value for many ( again demonstrated >> by both the websphere and eclipse cases) is in taking a complex system and >> migrating it to a modular architecture and osgi. >> >> I think this is where a lot of developers hit a wall. We can't just start >> from scratch. Secondly, by nature of having arrived at the osgi >> "conclusion", the issue was quite obviously that complexity already existed. >> >> At the OSGi BoF, it was asked "what could the osgi community do to help >> make it easier for new developers". >> >> It would be extremely valuable to have several demonstrations of taking >> some non-osgi application containing at least some degree of complexity and >> transforming that to an osgi-ified one with insight into the decisions and >> best practices. >> >> i.e. o(sgi)petstore is fine and dandy, there are plenty of those (Tim >> Ward demonstrated ~120) but what I really would benefit from is a jpetstore >> -> opetstore migration. >> >> In an effort to make some of that experience available to the general >> public, David also suggested that it would be great for Liferay to publish >> it's experience, and so I think I may do just that. The caveat being of >> course that as "new" osgi-ers we will likely show that we made some wrong >> decisions. However, I feel emboldened by Graham's admittance of IBM having >> made mistakes along the road. If IBM can do that, surely we can do that too. >> >> It was a great pleasure meeting many of you. >> >> Sincerely, >> Ray >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> >> >> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> > > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > <http://twitter.com/#!/rotty3000> | Senior Software Architect | *Liferay, > Inc.* <http://www.liferay.com/> <https://twitter.com/#!/liferay> > > --- > 24-25 October 2012 |* Liferay **Spain Symposium* | > liferay.com/spain2012<http://www.liferay.com/spain2012> > 16 November 2012 |* Liferay **Italy Symposium* | > liferay.com/italy2012<http://www.liferay.com/italy2012> > > > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> <http://twitter.com/#!/rotty3000> | Senior Software Architect | *Liferay, Inc.* <http://www.liferay.com> <https://twitter.com/#!/liferay> --- 24-25 October 2012 |* Liferay **Spain Symposium* | liferay.com/spain2012<http://www.liferay.com/spain2012> 16 November 2012 |* Liferay **Italy Symposium* | liferay.com/italy2012<http://www.liferay.com/italy2012>
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
