Could anyone remove me from this list? I already unsubscribed but I continue to receive the emails.
Thank you. On Wed, Feb 1, 2017 at 11:32 AM, "Michał Kłeczek (XPro Sp. z o. o.)" < michal.klec...@xpro.biz> wrote: > Rant aside... > > This is what I am saying all along... Bundles are not good candidates for > codebase annotations. > For exactly the reason you describe: bundles represent a template that may > produce different wirings. > > But to recreate an object graph you need the _wiring_ - not the template. > > And this is also why any kind of statically (ie. at bundle build time) > locking of the dependencies is not going to work either. > The ImplementationDetailServiceProxy runtime dependencies are not yet > known when creating the bundle manifest > since its interface to be useful must be resolved in each client > environment differently (or all parties in the distributed system > must share the same versions of the code - which makes the whole point of > OSGI moot) > > The only way I can see around this is not to treat jar files downloaded > dynamically as bundles > but rather create fake bundles from them and generate artificial manifests > based on information in the stream. > Kind of an ugly hack really... > > The situation might change if OSGI defined a way to provide bundle > manifest not as a statically prepared MANIFEST.MF > inside the jar file but as separate piece of information provided > dynamically at runtime. > > A little rant now... > > This container centric view is IMHO quite restricting. > There is no reason why resolution of code dependencies (aka preparing the > wiring) > must be done by the particular container where the client software is > executed. > It might as well be done somewhere else (ie. in the service provider > environment) > and sent to the client already prepared for execution. > > OSGI way is not the only way. > > I do not find any particular problem with downloading data together with > the code that manipulates this data. > I am doing it very often when viewing tens (if not more) of web sites > daily. > Haven't found any major issues with that - quite the opposite - it seems > like this is a pretty damn good way of doing things. > > End of rant... > > Thanks, > Michal > > Niclas Hedhman wrote: > >> As I think you know, the whole purpose of OSGi is to NOT tie the >> resolution >> to Bundles, but to explicitly Exported (with versions) packages. If people >> screw up and don't declare the Import/Export package meta data correctly, >> then ordinary OSGi may fail just as spectacularly. The difference being >> that Java serialization is slightly more sensitive to class changes than >> the code itself, and that was an issue from the start. "Back then" it was >> quickly realized that "long-term" storage of serialized state was a bad >> idea, but "long-term" is relative to code releases and with highly >> distributed systems, this is now a reality in networked applications as >> well as storing serialized objects to disk. With that in mind, one should >> seriously reconsider the status of Java Serialization in one's >> application, >> realize that every serialized class, incl possible exceptions, is a >> published API and needs to be treated as such, just as a REST API, SOAP >> interface or HTTP itself. Sorry for the rant... >> >> Back to OSGi; even if you really need to tie a class to a particular >> bundle, you can do that with attributes and the 'mandatory' directive. >> >> Cheers >> Niclas >> >> On Wed, Feb 1, 2017 at 3:29 AM, Michał Kłeczek<michal.klec...@xpro.biz> >> wrote: >> >> Unfortunately it is >>> >> > -- [image: cid:image016.png@01CD59E4.99704620] Sergio Gomes | Senior Software Developer Fedelta Point of Sale | Australia Phone +61 1300 652 029 Fax +61 3 9642 1265 Web www.fedeltapos.com
