Learning to Ignore OSGi

8/3/2019 Learning to Ignore OSGi

1/126

January 25, 2011 Richard S. Hall

Learning to Ignore OSGi


2/126


Modularity

This presentation is notabout modularity

It assumes we all know what modularity is andagree it is a good thing

If you feel otherwise please leave or stop reading

This presentation is about using OSGi as ameans to achieve modularity


3/126


The reality


4/126


The reality

I asked a developer on a 250-plus bundle OSGiproject, How much have you read aboutOSGi? The answer?


5/126


The reality


I've neverread any OSGi documentation at all.


6/126


The reality


I've neverread any OSGi documentation at all. Clearly, this can't be the approach of the

average corporate developer, can it?


7/126January 25, 2011 Richard S. Hall

The reality


I've neverread any OSGi documentation at all. Clearly, this can't be the approach of the

average corporate developer, can it?

Shortly after the above, I read the following on anOSGi-oriented mailing list:I represent the mainstream corporate developerwho only wants to consume OSGibut notunderstand it.



Reality check

We have people who think they can use atechnology in projects (or even base projects onit) with little or no understanding of it



Reality check


This seems like it has a debatable valueproposition, but...



Reality check


This seems like it has a debatable valueproposition, but...

Ok, fine, this presentation will help you learn toignore OSGi...



The first step

The first step in learning to ignore OSGi is...



The first step

The first step in learning to ignore OSGi is...

Accept the fact thatyou can'tcompletely

ignore OSGi!

Accept the fact thatyou can'tcompletely

ignore OSGi!



Why?



Why?

Java

Your application



Why?

Java

OSGi framework

Your application

OSGi adds a layer to enforce modularity

by limitingtype visibility



Say, What?

To clarify, let's review howtype visibility is handled instandard Java...



Say, What?

Class path

rt.jart.jar bar.jarar.jar baz.jaraz.jar foo.jaroo.jar zoo.jaroo.jar



Say, What?

Besides its own types,which types are visible to your

application?

Class path


Yourourapp.jarpp.jar



Say, What?

All public types on theclass path are visible...

Class path





Say, What?

All public types on theclass path are visible...

not very modular.

Class path





Say, What?

How does OSGi impact this?

Class path





Say, What?

OSGi onlyallows yourapplication to see public types

in java.* packages.

Class path


Yourourapp.jarpp.jarYourourapp.jarpp.jar

OSGi



Say, What?

Noteven javax.* typesare visible!!!

Class path



OSGi



Say, What?

Why does OSGi do this?!

Class path



OSGi


25/126


Say, What?

Global type visibility makes itdifficult to know your code'strue dependencies and to

control what it actually sees.

Class path



OSGi


26/126


What about legacy code?


27/126



foo.ja

r

foo.jarbaz.jaraz.jar

bar.j

ar

bar.jar


28/126



Ok, not really,but sort of...

there is no magicOSGi pixie dust!

foo.ja

r

foo.jarbaz.jaraz.jar

bar.j

ar

bar.jar


29/126



The MuleSoft fallacy

http://blogs.mulesoft.org/osgi-no-thanks/

To paraphrase (not a quote):

OSGi provides little value and is too complex asdemonstrated by our failed attempt to make modularityinvisible when porting our huge legacy system to it withover 150 third-party JARs.

There is no free lunch Modularity has to be considered at all levels

and will be visible

Porting huge legacy systems to another platform

is complex. Period.


30/126



Legacy code is written under a different mentalmodel that no longer works in OSGi

@deprecatedglobal public type visibility

Legacy code must be examined on a case-by-case basis

Does the code just provide types?

Does it make assumptions about type visibility?(i.e., use class loaders orClass.forName())

If so, it likely won't work


31/126


That's not all!

Currently, we've only discussed which typesyour application can see

What about the flip side which types from

your application can be seen by other code?


32/126


That's not all!


If your public classes are these cookies


33/126


That's not all!


If your public classes are these cookiesthen everyone can see all yourcookies in a standard JAR file...


34/126


That's not all!



again, not very modular.


35/126


That's not all!


How does OSGi impact this?




36/126


That's not all!


In OSGi, no one sees any of your cookies.Nothing!

bundleundle.jarjar




37/126


That's not all!


Why does OSGi do this?!bundleundle

.jarjar




38/126


That's not all!


Because it is impossible to protect yourcode's implementation details if you

always expose everything.

bundleundle.jarjar




39/126


JAR file comparison summary

StandardJAR file

OSGiJAR file

Class path type visibility

for internal code

All public

types

Only public

java.* typesApplication type visibilityfor external code

All publictypes

Nothing


40/126


JAR file comparison summary

StandardJAR file

OSGiJAR file

Class path type visibility

for internal code

All public

types

Only public

java.* typesApplication type visibilityfor external code

All publictypes

Nothing

Do these differences seem minor enough to ignore?


41/126


Wait a minute!

You must be thinking

What a gyp!

I thought we were going to learn how to ignore

OSGi?


42/126


Wait a minute!

You must be thinking

What a gyp!

I thought we were going to learn how to ignore

OSGi?

There's a lot you can ignore, but typevisibility isn't one of them...

However, if you change your mental model tooperate under these new rules, you'll no longerhave to think about them

And your JAR files will stillwork as standard JAR files


43/126


A lot left to ignore

Java

OSGi framework

Your application

Expand focus


44/126



Security

Module

Lifecycle

Service

OSGi framework isconceptually layered


45/126



Security

Module

Lifecycle

Service

You can ignore

security...wealways do


46/126



Security

Module

Lifecycle

Service

Handles typevisibility, so youcan't ignore this


47/126



Security

Module

Lifecycle

Service

Maybe you canignore this


48/126



Security

Module

Lifecycle

Service

You can ignorethis, although youlose a decouplingmechanism


49/126



Security

Module

Lifecycle

ServiceBasically, all OSGiAPI is from thesetwo layers, so we

can pretty muchignore it all


50/126



Security

Module

Lifecycle

Service Ironically, theseare the thinnest

layers


51/126


What about lifecycle?


52/126



StandardJAR file

OSGiJAR file

Class path type visibilityfor internal code All publictypes Only publicjava.* types

Application type visibilityfor external code

All publictypes

Nothing

Lifetime of JAR file Same asJVM Can comeand go

Another JAR file difference...


53/126



You can ignore lifecycle if your code doesn't doanything that may live on after it

i.e., have things that need to be cleaned up

Such as active threads, open files, open ports, etc.


54/126



You can ignore lifecycle if your code doesn't doanything that may live on after it

i.e., have things that need to be cleaned up

Such as active threads, open files, open ports, etc. If you do have such issues, then...

Your code has explicit lifecycle requirements andmust implement a bundle activator

i.e., provide start and stop callbacks

Your code must not create or use long-livedresources unless it has been started and not after ithas been stopped


55/126



If you're concerned about not being able toignore the OSGi lifecycle API...

Dirty little secret...

You don't need to use the OSGi lifecycle API It's possible to create your own lifecycle layer

And ultimately your own service-like layer

However, the same sort of rules ultimately stillapply, they'll just be enforced by you

And even then, your lifecycle layer will still need to beimplemented using OSGi API


56/126


Revisiting legacy code

For legacy code, the two biggest obstacleswhen moving to OSGi are assumptions about

Global type visibility

Static lifecycle


57/126


End of story?

bundleundle.jarjar


58/126


End of story?

bundleundle.jarjar

No!A JAR file that can't see anything andno one can see into isn't very useful!


59/126


Sharing cookies

bundleundle.jarjar If you have some types you want toshare with other code, you need someway to expose them...


60/126


Sharing cookies

...OSGi allows you to exportallpublic types in a Java package.

bundleundle.jarjar


61/126


Sharing cookies

This gives you controlover your code'simplementation details, since you only

expose what you want to external code.bundleundle

.jarjar


62/126


Sharing cookies

You must explicitly list all packagesyou wish to share in your JARmanifest

Export-Package:

org.foo.p1,org.foo.p2bundleundle.jarjar


63/126


Sharing cookies


Export-Package:

org.foo.p1; version=1.0,org.foo.p2; version=1.1

You should actually specify packageversions

bundleundle.jarjar


64/126


Sharing cookies


Export-Package:



Only the types in these listedpackages are shared

You should keep this list short

Unlisted packages are hiddenimplementation details

bundleundle.jarjar


65/126


Sharing cookies


Export-Package:



Only the types in these listedpackages are shared

You should keep this list short

Unlisted packages are hiddenimplementation details

Since tools can help generate thissyntax, you can potentially ignore it...but it is probably better to understand

it for debugging purposes.

bundleundle.jarjar


66/126


Gimme your cookies

bundleundle.jarjar By default, your code only sees types injava.* packages, so you'll almost certainlyneed some way to ask for more...


67/126


Gimme your cookies

...OSGi allows you to importrequiredtypes in other Java packages notcontained in your JAR file.

bundleundle.jarjar


68/126


Gimme your cookies

This gives you controlover what externaltypes your code sees at execution time.bundleundle.jarjar


69/126


Gimme your cookies

You must explicitly list all requiredexternal packages (except java.*packages) in your JAR manifest

Import-Package:

org.foo.p1,org.foo.p2bundleundle.jarjar


70/126


Gimme your cookies


Import-Package:

org.foo.p1; version=[1.0,2.0),

org.foo.p2; version=[1.1,2.0)

With meaningful version ranges

bundleundle.jarjar


71/126


Gimme your cookies


Import-Package:

org.foo.p1; version=[1.0,2.0),

org.foo.p2; version=[1.1,2.0)


Only the external types in theselisted packages are visibleinternally, in addition to internal andjava.* types

bundleundle.jarjar


72/126


Gimme your cookies


Import-Package:

org.foo.p1; version=[1.0,2.0),org.foo.p2; version=[1.1,2.0)


Only the external types in theselisted packages are visibleinternally, in addition to internal andjava.* types

bundleundle.jarjar

Tools can again help here and generate

much of this using byte-code analysis,but you'll still need to review it.


73/126


JAR + metadata != module

Once you've added export and importmetadata to your JAR files, youbasically have a module

Albeit, maybe not a very meaningful one


74/126





Modules are not stalagmites, theydon't just form, they are a designprimitive

Just like classes

You need to think hard about

What you put into a module

What you expose from a module

What you expose to a module


75/126





Modules are not stalagmites, theydon't just form, they are a designprimitive

Just like classes

You need to think hard about

What you put into a module

What you expose from a module

What you expose to a module

Maximize cohesion,minimize coupling!


76/126


OSGi at execution time

Even if we ignore everything else, once we have somemodules, they still need to run in an OSGi framework

This is easily accomplished with most OSGi frameworks

But what is actually happening?

b2.jar2.jarb1.jar1.jar


77/126



The framework resolves module dependencies Resolving dependencies involves matching exported

packages to imported packages to ensure type consistency

A module can't be used if its dependencies aren't satisfied



78/126



The framework enforces module boundaries Ensuring that only exported packages are exposed and only

imported packages are visible

Each module gets a class loader to enforce isolation


OSGi i i


79/126



After dependency resolution, OSGi gets out of the way It's just class loader delegation and application code

execution after that


U d t di h d


80/126


Understanding search order

OSGi class loading search order is strict andconsistent, at a high level it is as follows

U d t di h d


81/126




Boot delegate java.* packages, fail if not found

U d t di h d


82/126





Delegate imported packages to exporter classloaders, fail if not found

U d t di h d


83/126





Delegate imported packages to exporter classloaders, fail if not found

Search internal content, fail if not found

U d t di h d


84/126



Taking into account all OSGi features, it's a little morecomplicated, but still strict and consistent

U d t di h d


85/126





U d t di h d


86/126





Delegate imported packages to exporter class loaders, fail if

not found

U d t di h d


87/126






not found Delegate to required bundle class loaders, do not fail if not

found

U d t di h d


88/126







found

Search internal content, do not fail if not found

U d t di h d


89/126







found


Attempt to dynamically import if package is not required orexported, if successful

Delegate to exporter class loader

Treat as a normal import for subsequent load requests



90/126







found


Attempt to dynamically import if package is not required orexported, if successful

Delegate to exporter class loader

Treat as a normal import for subsequent load requests

Fail

When things go wrong


91/126


When things go wrong...

Unresolved constraints In Felix you might see something like this:

org.osgi.framework.BundleException:

Unresolved constraint in bundle importer

[5]: Unable to resolve 5.0: missingrequirement [5.0] package;

(&(package=exporter)

(version>=1.0.0)(!(version>=2.0.0)))



92/126







(&(package=exporter)(version>=1.0.0)(!(version>=2.0.0)))

Questions to ask yourself:Is there a provider of the missing package?



93/126







(&(package=exporter)

(version>=1.0.0)(!(version>=2.0.0)))

Questions to ask yourself:Do import attributes match the exported

package's attributes?



94/126



Unresolved constraints It could also be a transitive dependency




(&(package=exporter)(version>=1.0.0)(!(version>=2.0.0))) [caused by: Unable to

resolve 6.0: missing requirement [6.0]

package; (&(package=transitive)(version>=1.0.0))]

It complains about not being able toresolve exporter package...



95/126



Unresolved constraints It could also be a transitive dependency




(&(package=exporter)(version>=1.0.0)(!

(version>=2.0.0))) [caused by: Unable toresolve 6.0: missing requirement [6.0]

package; (&(package=transitive)(version>=1.0.0))]

But actually, exporter was found,

but its provider has a dependency ontransitive that couldn't be satisfied.



96/126



Constraint violations In Felix you might see something like this:


Constraint violation for package 'bar'

when resolving module 7.0 between existingimport 6.0.bar BLAMED ON [[7.0] package;

(&(package=bar)(version>=1.0.0)(!

(version>=2.0.0)))] and uses constraint

5.0.bar BLAMED ON [[7.0] package;

(&(package=exporter1.foo)(version>=1.0.0)(!(version>=2.0.0)))]



97/126






when resolvingmodule 7.0 between existingimport 6.0.bar BLAMED ON [[7.0] package;(&(package=bar)(version>=1.0.0)(!

(version>=2.0.0)))] and uses constraint5.0.bar BLAMED ON [[7.0] package;


Here, module 7.0 (aka bundle 7) isexposed to two versions of package

bar from modules 5.0 and 6.0

(aka bundles 5 and 6).



98/126







(&(package=bar)(version>=1.0.0)(!(version>=2.0.0)))] and uses constraint5.0.bar BLAMED ON [[7.0] package;


Questions to ask yourself:Are the involved bundles' import constraints

accurate/specific enough?



99/126









Questions to ask yourself:Have you deployed unnecessary providers

of the conflicting package?



100/126









Questions to ask yourself:Were dependencies resolved incrementally

(i.e., incremental bundle deployment)?



101/126



Constraint violations It could also be a transitive constraint

org.osgi.Framework.BundleException:






(&(package=exporter2.woz)(version>=1.0.0)(!(version>=2.0.0))), [6.0] package;

(&(package=exporter3.boz)(version>=1.0.0)

(!(version>=2.0.0)))]


102/126



103/126










(&(package=exporter2.woz)(version>=1.0.0)(!(version>=2.0.0))), [6.0] package;(&(package=exporter3.boz)(version>=1.0.0)(!(version>=2.0.0)))]

To clarify, this is the chain of imports that

led to the constraint violation.



104/126






when resolvingmodule 8.0 between existingimport 5.0.bar BLAMED ON [[8.0] package;




(&(package=exporter2.woz)(version>=1.0.0)(!(version>=2.0.0))), [6.0] package;(&(package=exporter3.boz)(version>=1.0.0)

(!(version>=2.0.0)))]

So, here module 8.0 imports

exporter2.woz from module 6.0...



105/126










(&(package=exporter2.woz)(version>=1.0.0)(!(version>=2.0.0))), [6.0] package;(&(package=exporter3.boz)(version>=1.0.0)(!(version>=2.0.0)))]

Who imports exporter3.boz from module 7.0,

which apparently has a uses contraint on bar.



106/126



ClassNotFoundException In Felix you might see something like this:

java.lang.ClassNotFoundException:

exporter.Exporter not found by importer [5]

at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(

ModuleImpl.java:787)

at org.apache.felix.framework.

ModuleImpl.access$400(ModuleImpl.java:71)

at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(Modu

leImpl.java:1768)

... 36 more



107/126











leImpl.java:1768)

... 36 moreQuestions to ask yourself:Is the class in question supposed to be

in the bundle or imported?



108/126











leImpl.java:1768)

... 36 moreQuestions to ask yourself:If it's a bundle class, does the bundle

actually contain the class?



109/126











leImpl.java:1768)

... 36 moreQuestions to ask yourself:If it's an imported class, does the bundle

actually import the package?



110/126











leImpl.java:1768)

... 36 moreQuestions to ask yourself:If it does import the package, does the

exporting bundle actually contain the class?



111/126



NoClassDefError In Felix you might see something like this:

java.lang.NoClassDefFoundError:

exporter/Other

at exporter.Exporter.(Exporter.java:7)at importer.Importer.start(Importer.java:10)

at org.apache.felix.framework.util.

SecureAction.startActivator

(SecureAction.java:629)

at org.apache.felix.framework.Felix.activateBundle(Felix.java:1827)

... 32 more



112/126





exporter/Other






... 32 moreQuestions to ask yourself:

The same types of questions as withclass not found exceptions...



113/126





exporter/Other






... 32 more

The tricky part is that the class in questionis not directly relevant to you...



114/126





exporter/Other

at exporter.Exporter.(Exporter.java:7)at importer.Importer.start(Importer.java:10)at org.apache.felix.framework.util.




... 32 moreHere, the Importer was creatingExporter, but the failure is for

Other, which Importer might

know nothing about...



115/126





exporter/Other






... 32 moreThis means means the issue is likely inthe bundle containing Exporter, not

the bundle containing Importer.

Poking around


116/126


Poking around

Use the Gogo shell to see what's going on lb to list installed bundles

headers to view a bundle's manifest main

headers inspect p[ackage] c[apability] to view a

bundle's exported packages with wiring

inspect p[ackage] r[equirement] to view

a bundle's imported packages with wiring which to try to load a class from a bundle and

see from where it comes

How to load classes?


117/126



Generally speaking Your modules should notneed to explicitly load

classes

Normal, on-demand, implicit class loading as yourcode executes should be sufficient



118/126



Generally speaking Your modules should notneed to explicitly load

classes

Normal, on-demand, implicit class loading as yourcode executes should be sufficient

But, what if this isn't sufficient?

What if your code needs to dynamically load a

class?



119/126



First things first Don't use Class.forName()

The resulting class is cached in the defining AND theinitiating class loader

Subsequent requests from the initiating class loader will alwaysreturn the same class, which is not usually what you want

Inhibits garbage collection

Yes, the JavaDocs tell you to useClass.forName(), but still don't

One of the main arguments forClass.forName() is

that it handles array types, but OSGi class loaders shouldhandle this too via ClassLoader.loadClass()


120/126



121/126


o to oad c asses

If no client is involved, then some options are If you know it will always be the same class at

execution time, you just don't know which one, usedynamic imports

e.g., maybe the class is set via a configuration property

Search installed bundles and useBundle.loadClass()

a la the extender pattern


122/126

Conclusions


123/126


Conclusions


124/126


When using OSGi you must unlearn the globaltype visibility assumption

OSGi provides strict and explicit type visibility rulesto give control back to you

Conclusions


125/126


When using OSGi you must unlearn the globaltype visibility assumption

OSGi provides strict and explicit type visibility rulesto give control back to you

If you change your mindset, then your code willwork well with (or without) OSGi...

...and then you can begin to ignore it

If you want all the details...


126/126

y

Get this book - http://www.manning.com/hall/

Documents

Learning to Ignore OSGi