This link has been bookmarked by 4 people . It was first bookmarked on 12 Jan 2009, by Lubos Pochman.
-
21 Apr 09
-
tracking services and managing all the aspects of what to do when services come and go is nasty
-
To be honest - I'd never even think about starting an OSGi project without using Spring DM.
-
OSGi's versioning concept (as a side effect ...) makes a first step of bringing the enforcement of architectural constraints to the developer's daily life by definining export and import packages
-
You typically end up in a situation where you constantly tweak your modules build specifications (that creates your manifest) and spread absolutely counter-intuitive dependencies across your whole system.
-
you cannot go on without a strong and automated integration testing suite that incorporates OSGi (another thing that Spring DM supports).
-
First of all - before considering OSGi I would really check if I have the ultimate requirement to exchange bundles at runtime without shutting down the system
-
I do not want my objects to be bound to a runtime environment such as OSGI - therefore I unit-test my classes with the standard Java runtime environment (and hence with the default class loader).
-
As most of the frameworks, they only work well if used with POJOs solely. Same goes for OSGi,
-
increased overhead of explicitly managing third party library dependencies.
-
Any technology which provides productivity barriers will be resisted
-
modularity is crucial for these huge software systems. Or for example LinkedIn where over 800 bundles provide the functionality for this very cool website.
-
"low-hanging-fruits" of the OSGi mindset:
- Use bundle-scoped micro-services (e.g. by just structuring my software into
bundles and exporting/importing to/from a service registry)
- Give developers what makes life easier for them (e.g. classpath scanning,
automatic startup of bundles if they are on the classpath etc.)
- BUT: Heavily constrain the developer at build-time (like OSGi does - but
e.g. through the use of Classycle or similiar tools)
- BUT: Loosely constrain the developer at runtime (bundles can only get objects
they are intended to get, e.g. through service lookups)
- AND: put all these things into relation with existing best practices (e.g.
Spring DM like IOC, AOP, etc...) -
ClassLoaders mix two responsabilities:
1) Load the class (and have a chance to instrument it at load-time)
2) Define the visibility on other classes loaded in the JVM (e.g. via ClassLoader hierarchies. -
Ideally, the concepts of class loading and visibility should be orthogonal. Java should maybe evolve in this direction, by integrating the bundle concept into the JVM for dealing with visibility rules (in a way like .NET assemblies) and let the classloader only deal with class loading.
-
-
15 Jan 09
-
12 Jan 09
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.