Trustin Lee wrote:
On 2/3/07, John E. Conlon <[EMAIL PROTECTED]> wrote:
Trustin,
Below are the OSGi related entries generated for the mina-core and added
to jar's manifest.mf . Note the Export-Package and the Import-Package
entries. These two metadata entries along with the Bundle-SymbolicName,
and the Bundle-Version are used by the OSGi runtime to create a
classloader matrix that wires the Mina-Core bundle to its dependencies
and as a dependency for other bundles.
The mina-core bundle manifest below specifies to the OSGi runtime to
export of all the packages in mina-core to the outside world, import the
slf4j package and also import all the exported packages as well. The
latter may seem unwanted but in an OSGi runtime one may have multiple
mina-core bundles installed. To quote -Richard Hall, Apache Felix.
" Yes, that is intended because it allows those packages to be
substitutable with other providers. If your bundle only exported them,
then it would always get them from itself, even in cases where there was
another provider already in use. This would then limit interoperability,
because your bundle would not be able to interact with bundles using the
other provider's packages. You can explicitly tell the plugin to not
import an exported package if you do not want this behavior. "
Also notice the 'uses' attribute for the exported packages. The 'uses'
metadata gives additional hints for wiring the classloader matrix
between bundles. Perhaps you may find this metadata useful to you in
your refactoring the cyclic dependencies out of mina?
The OSGi classloader matrix offers a continuation of the same idea of
Java encapsulation taken to a package level -> private, default, public,
and now Export-Package. With OSGi we can encapsulate as much as
possible inside the module, exposing only as exportable the packages
with classes needed by our mina-core user bundles.
I see. You are a great OSGi teacher. Thanks for quick-start
education. :)
I already identified cyclic dependencies using JDepends.
So the first thing you can help me with is to identify all the packages
that we should specify as private to the plugin. Meaning what packages
do we not want to offer to the outside world. These private packages
would contain internal classes that are only used within the mina-core.
In other words, internal classes are those that would never be inherited
or appear in a method signature by a class in a bundle other than the
mina-core.
Because I am going to restructure the current package structure, I can't
tell which packages will become private yet.
Makes perfect sense. The good news is, that with module encapsulation
you now have a new encapsulation construct to consider taking advantage
of in the new design.
The packages are mixed up now
and private and public classes sometimes exist together.
And that is reflected by all the packages being exported now by the plugin.
And I have a few questions.
1) Can't we control the access in a class-level instead of a
package-level?
2) Does class access modifier (e.g. class PackagePrivateClass) work
correctly in OSGi?
Yes to #2. This is Java after all, so all the class access modifiers
work as expected package(aka default), private, public and protected.
The new aspect OSGi offers for us at this point is an intelligent
container that wires our dependencies. I call it the OSGi 'classloader
matrix';-)
No to #1. The wiring instructions (metadata) are oriented for matching
bundle packages.
If the answer of the second question is 'yes', then we could
restructure the
packages and make package-private classes have appropriate access
modifier (
i.e. (package)), rather than prohibiting access to the whole classes of a
certain package.
Yes that can be done and we can just export everything. But I think you
will find it more useful to move what changes behind stable interfaces,
factories, utilities that are in exported packages. All implementations
can be moved to private packages that are not exported. Developers
using Mina can then build their Mina infrastructures on stable
interfaces/factories/utilities that are offered in the exported
packages. Packages with classes they care about are accessible things
they don't - aren't. Tightens up the docs, lessens the learning curve
and moves us away from module(aka jar) development time coupling. We can
rev our private packages release to release without impact, because now
we are decoupled at the module/jar level and loosely coupled at the
package level. (Did I mention we can add version and version-range
attributes to our imports and export metadata to insure only what we or
our users is getting what we require?)
Maven and Ivy provides the dependency matrix for developers at dev time
between modules. With OSGi we can now push this dependency coupling
down to the package level and out to the deploy/run time.
For now, users should have no access to *.support, but this will change
after restructuring.
I will commit my plug-in changes to mina-core. As you move forward with
the redesign we can tune the plugin to hide our private packages. (If
you elect to use private packages. ) Later on if we want, we can
gradually add more metadata to tighten up our export and imports to
achieve a higher degree of deploy and runtime agility.
cheers,
John
