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. The packages are mixed up now and private and public classes sometimes exist together. 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? 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. For now, users should have no access to *.support, but this will change after restructuring. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
