Hi Georg, Sure, Turbine is component based. But my question would then be how much overhead would OSGi bring to the core? Because to me, running an OSGi container within a Servlet container, sounds like running Virtualization on top of a Virtualized Environment. I am wondering if that is really worth the effort. Or if we will going to experience the same drawbacks as virtualization on top of virtualization faces which are: High Network Latency, Higher Complexity, Steep Learning Curve, Very hard to trace errors, etc.
Buddy > On 24.09.2015, at 13:01, Georg Kallidis <gkalli...@cedis.fu-berlin.de> wrote: > > Hi Jürgen, > > good point, which is what I asked myself ;-) I think it is about > transparency... > > One reason may be is to get class loading better done - step by step. Some > good points are mentioned here: http://www.infoq.com/news/2011/10/pojosr. > This does not mean necessarily OSGi at a whole, but at least it it is one > part within this context (there is an example to use PojoSR in a Servlet > context). OSGi is a good reference and is supported in many useful > apllications, eg. Apache Karaf (Apache Felix based) and Apache Ace. > Considering the latter, if deployment is an issue, then OSGi matters IMO. > > - Turbine is a component model as is OSGi. We should then at least point > out, why using Turbine is better and NOT OSGi ;-) > > Best regards, Georg > > > > > Von: Jürgen Hoffmann <hoffm...@ellumination.de> > An: Turbine Developers List <dev@turbine.apache.org> > Datum: 24.09.2015 11:10 > Betreff: Re: [DISCUSS] OSGI in Turbine 4 Final > > > > Hi Georg, > > Yes, this discussion was way back in time. I am still wondering, why you > would like to run a Web Application inside an OSGi Container. Turbine > needs a servlet container to run. I know others are using fulcrum > components outside the context of a web application, but that was always > hard for me to understand/follow as I think there are better options > available in these cases than to use Turbine. > > So my question is, what benefits would a developer have to have a web > application framework directly deployable into an OSGi container in favor > of a servlet container? > > Again, this depicts my personal opinion and should by no means stop > discussion! And by my prejudice I guess you already figured that my > knowledge about OSGi is pretty slim :) > > Buddy > >> On 24.09.2015, at 10:03, Georg Kallidis <gkalli...@cedis.fu-berlin.de> > wrote: >> >> Hi all! >> to restart an older discussion (What happens after M1?) I have some more > >> (naive) questions about this. >> Should Turbine support/be runnable in a OSGI container? >> Should this become a main focus of the next release? >> -> Create a new JIRA issue (feature request)! >> >> Some more questions, which came into my mind are: >> - What would be the Proof of Concept for OSGI support? E.g. deploying > into >> Apache Karaf (light weight OSGI)? >> - Configuration is up to now done using Yaafi component. Could >> Turbine/Yaafi/Avalon Container include a Service Registry? >> E.g. something like http://wiki.osgi.org/wiki/PojoSR, >> https://code.google.com/p/pojosr/wiki/Usage)? Dow e need support for >> Declarative Services/ Blueprint OSGI? Would it more easy to use these >> standards instead? >> - Refactoring: Do we need more than one Turbine bundle? E.g. expose an >> interface bundle and an implementation bundle? Some pPackage refactoring > >> may be required at least. >> - Classloading: Cft. to > http://wiki.osgi.org/wiki/Avoid_Classloader_Hacks >> ). There is an interesting discussion about class loading issues: >> http://www.mail-archive.com/users@felix.apache.org/msg05231.html. >> Class.forName classloading should be checked >> - Do we need Servicemix OSGI-enabled packages for dependencies? >> More helpful Infos, especially for Fulcrum Components: >> https://wiki.apache.org/commons/CommonsOsgi, >> https://issues.apache.org/jira/browse/COMMONSSITE-23, and > commons-logging >> is a special case.. >> >> Best regards, Georg >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@turbine.apache.org >> For additional commands, e-mail: dev-h...@turbine.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@turbine.apache.org > For additional commands, e-mail: dev-h...@turbine.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@turbine.apache.org > For additional commands, e-mail: dev-h...@turbine.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@turbine.apache.org For additional commands, e-mail: dev-h...@turbine.apache.org
