Jeanfrancois Arcand wrote:
> Salut,
>
> Sahoo wrote:
>> We are currently exporting every package, which is not desirable. The
>> attached zip file contains a file called bundles.xml, which lists
>> packages being exported by each module. Please take some time to
>> analyze your module and come up with the appropriate package list. It
>> does not give a good picture of modularity when we have so many
>> packages exported. If we can reduce the number of exported packages,
>> the system will not only boot faster, it will also run a lot faster.
>
> Hum..can you elaborate why we will run faster if we reduce the number
> of exported package? Is it because of our classloader architecture?
OSGi f/w controls class loading of implementation classes. It uses
package based wiring and each exporter-importer pair is known as a wire.
If there are less number of exported packages, there are automatically
less number of wires for the framework to establish. That's just the set
up cost, then comes the cost of searching. If there are less number of
wires, then there are less places to search for class dependencies.
Thanks,
Sahoo
>
> Thanks
>
> -- Jeanfrancois
>
>
>
> This is in
>> addition to improving the overall design of the modules.
>>
>> To identify the packages to be exported, you may like to use
>> wires.xml file in the same zip file to get an idea of current package
>> dependencies. Copy wires.xml and wires.xsl into the same folder and
>> open wires.xml in any XSL aware editor (like firefox). If you see a
>> package is imported only by the module that exports it, then that's
>> likely to be removed from exported package list. Please note, this
>> may not always be true, so use your own judgment. I am hoping that
>> this should reduce the total number of exported packages drastically.
>> Then we need to take the second step which is to identify the real
>> module boundaries as per the module's design goals. The two steps can
>> be done as one or more check-ins.
>>
>> Once you have identified correct set of exported package names,
>> please *update* pom.xml of your module. We are investigating the
>> possibility of adding some package level annotation to automatically
>> generate this list during build, but until then when you add or
>> remove any package, please also update the pom.xml.
>>
>> You may be tempted to ask why we are currently exporting every
>> package. Well, without knowing what each module does, I had little
>> choice but to export all the packages. It's not that big a problem
>> when every module owner takes care of their individual modules.
>>
>> Thanks,
>> Sahoo
>>
>>
>> ------------------------------------------------------------------------
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>