tag:blogger.com,1999:blog-18772002.post6493782025869564450..comments2023-12-06T19:00:46.094+00:00Comments on OSGi Blog: OSGi's RoleJürgen Alberthttp://www.blogger.com/profile/02725834158183495837noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-18772002.post-59381022565827273652011-03-04T14:05:33.464+00:002011-03-04T14:05:33.464+00:00It will require some redesign but it is oh so nice...It will require some redesign but it is oh so nice if you can always rely on OSGi to be there ...<br /><br />And it is not that hard to make many of the support libraries work on OSGi as well as on the dreaded classpath.Peter Krienshttps://www.blogger.com/profile/11373850803487010328noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-22427627755228266092011-03-04T13:09:45.200+00:002011-03-04T13:09:45.200+00:00That sounds interesting as we could remove abstrac...That sounds interesting as we could remove abstractions or "di framework" classes that are necessary to run in several environments. The problem for us is that for example CXF is only a small part in a bigger application. So your suggestion could work for the inner plumbing of cxf and camel as long as it not visible on the outside. There we have to be flexible to fit into what the Christian Schneiderhttps://www.blogger.com/profile/15483626935577725409noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-61267079231914353302011-03-04T10:04:47.117+00:002011-03-04T10:04:47.117+00:00@Christian: Not sure you understood me. What I am ...@Christian: Not sure you understood me. What I am advising is just include a framework in your code. If you're running inside OSGi, use that framework. If you're deployed in a WAR or on the classpath, just start your own Felix ... <br /><br />OSGi is not like a big bloated app server ... it is just a (small) dependency that can make your life a lot better.Peter Krienshttps://www.blogger.com/profile/11373850803487010328noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-47349460006693974492011-03-03T23:38:05.071+00:002011-03-03T23:38:05.071+00:00The problem is that we create frameworks that peop...The problem is that we create frameworks that people use for many different things. As there are many people that do not use OSGi we can not fully concentrate on it. If you are writing an application then it is easier. You simply decide for one plumbing and go with it. In a framework that needs plumbing but wants to fit in the environment of an application it is not that easy.Christian Schneiderhttps://www.blogger.com/profile/15483626935577725409noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-1854727137940373442011-03-03T13:07:07.683+00:002011-03-03T13:07:07.683+00:00Well, not using the OSGi API because you want to r...Well, not using the OSGi API because you want to run outside OSGi just means you're gone have to reinvent the wheel.<br /><br />I actually never understood the argument to not couple to OSGi when you're in its domain: application plumbing. <br /><br />Felix is around 400k, which is a minute dependency nowadays. Using non-OSGi code with OSGi code is a breeze with the launching API, and Peter Krienshttps://www.blogger.com/profile/11373850803487010328noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-49508155062487415902011-03-03T07:05:37.480+00:002011-03-03T07:05:37.480+00:00Hi Peter,
I work as a framework developer (Apache ...Hi Peter,<br />I work as a framework developer (Apache CXF and Apache Camel). The problem is that our domain is not so much the plumbing but we still do it and to some extend have to do it.<br /><br />The problem is that CXF and Camel have to work with or without spring and inside or outside osgi. Doe you have an idea what a good strategy is to separate the real framework from the plumbing? I Christian Schneiderhttps://www.blogger.com/profile/15483626935577725409noreply@blogger.com