Salut,
Sahoo wrote:
> 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.
OK Thanks for the explanation :-) I need to do the same exercise with
Grizzly standalone then :-)
A+
-- Jeanfrancois
>
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>