Vlákno názorů k článku OpenHAB a jeho instalace na Raspberry Pi od Andrej Ramašeuski - ano, start trva nekolik minut. pozdejsi odezva je...
-
Ondra Satai NekolaZlatý podporovatelV Jave bych problem nevidel. Ale ze dneska nekdo dobrovolne pouzije OSGI mne trochu znervoznuje.
-
Ondra Satai NekolaZlatý podporovatel
Nepamatuju si, ze bych videl (podotykam, ze dost) zkusene programatory tak nadavat, jako kdyz jim prislo pod ruku OSGi. Kdo z nich mel predchozi znalost Corby, tak to dost srovnaval. Mne to nastesti minulo, ale ten krik mucenych neslo ze sousednich kanclu preslechnout.
Ve zkratce se jejich zkusenosti dost podobaly http://tuhrig.de/when-modularity-comes-down-to-osgi/ Vsechno nakonec resit slo (protoze ono nakonec vsechno resit jde), ale byl to nehorazny opruz. -
Ondra Satai NekolaZlatý podporovatel
s trochou nadsazky to kdosi nazval OSGi = leaking abstraction factory pattern
-
To je dost slabý argument. Znám peprné stížnosti směřované na maven a přesto to je užitečný a široce používaný nástroj.
A ten odkazovaný článek neříká nic jiného, než: OSGi řeší komplikovaně problém, který nemá v běžném runtime vůbec řešení (kooperace dvou tříd různé verze). Vás napadá, jak kooperaci dvou verzí tříd řešit snáze, než de fakto napsat nějaký adaptér?
-
Ondra Satai NekolaZlatý podporovatel
Presne tak, to, co s classloadery delaji nemuze skoncit dobre. IMO je daleko lepsi nesnazit se kombinovat nevyhody distribuovanych a napevno vazanych systemu a proste tohle nedelat, vzdat to a nutit programatora to resit explicitne.
-
Ale cožpak to nenutí programátora řešit situaci explicitně? Z toho článku jsem pochopil, že to musí programátor explicitně vyřešit (popsat pomocí xml) a OSGi mu k tomu pouze poskytuje zastřešující rámec:
To solve this problem in OSGi you would write a service with an interface in package B and C, describe it in XML and wire it in package A. You would expose those services explicitly and create bunch of XML (...)
Jinak džungli classlodearů si dokážu představit (ono stačí mít někde v classpath dvě různá jar a pak se problém leckdy dost těžko hledá). Nicméně s OSGi nemám naprosto žádnou zkušenost, takže nedokážu posoudit, zda to je v OSGi o tolik horší...
-
Ondra Satai NekolaZlatý podporovatel
Jak si reknes "jdu delat aplikacni server", tak samozrejme v Jave classloadovat musis jak o zivot. O tom zadna.
-
sid (neregistrovaný)
ano, tak ako chces rozumne integrovat nejaky modul ktory neni uplne trivialny a pouziva dalsie jar subory? nemozes predsa niekomu povedat ze ty pouzivas nejake starsie verzie nejakych beznych veci z apache-commons a ze kazdy ma zostat na tej verzii ked napr potrebuje novsie veci. Ak pravda modulom nemyslis nieco na sposob nejakej trivalnosti ktora z principu nepotrebuje ziadne externe jar.
-
Sid (neregistrovaný)
Takze o tom v skratke hovno viete ale je to informacia "jedna pani povedala". To co ste poslali je typicky bullshit ako ked niekto porovnava dva jazyky a vytrhne nieco z kontextu a zacne kricat, ze toto nejde. Je uplne samozrejme, ze tento priklad nemoze fungovat a preco. To, ze to niekoho prekvapuje je pre zmenu prekvapujuce pre mna.
Ak by ste vytykali OSGI problem s tym, ze dost kniznic neobsahuje OSGI informacie (momentalne uz trocha lepsie) alebo problemy ktore vznikaju ked kniznice pouzivaju class loading vo vlastnej rezii tak by som aj mohol suhlasit. Ale pre projekty ktore pouzivaju nejaky druh modularity potrebuje nieco ako OSGI. A OSGI ma vyhodu, ze zaprve je to aspon nejako standardizovane a za druhe ze je viac implementacii. Tiez si mozete pomoct niecim ako Apache Karaf a viac menej mate zaklad app serveru v instantnom baleni.Podla mna ale hlavny problem s OSGI je ten, ze vacsina programatorov prasi normalny kod a co potom ked naraz sa dostanu do levelu kde sluzby mozu dynamicky sa registrovat/odregistrovat (ok da sa to obist trocha cez Blueprint alebo iPOJO), potrebuju separovat sluzby a nie bastlit kod cez 5 levelov krizom krazom. Lahsie je nadavat na framework ako priznat si, ze sa treba aj cosi naucit a zlozitejsie problemy vyzaduju aj zlozitejsie riesenia.
ČLÁNKY DO MAILU