that's a good point I will update the engineering guide.
Tim Quinn wrote:
> Jerome Dochez wrote:
>> Tim Quinn wrote:
>>> Hi.
>>>
>>> Perhaps this has already been answered, but if so I have forgotten
>>> and have not found a relevant message.
>>>
>>> When we move a LogStrings.properties file into a module, if the
>>> package where the file resides has not already been listed in the
>>> module's osgi.bundle file, do we need to add that package to
>>> osgi.bundle's -exportcontents expression?
>>>
>>> If we don't how will the LogDomains find it when it looks for it?
>>>
>> it falls back to the case whether or not all the code using that
>> logger instance resides in the same module or not. If not, you need
>> to add it the export-list. Put it another way : if any Class
>> instances you pass to the getLogger API all come from the bundle
>> containing the properties, you have nothing to do.
> Ah, I got it now. So by following your suggested approach 2.2 from
> your earlier message - in which the calls to LogDomains.getLogger
> always pass a class that is in the same module as the
> LogStrings.properties - I can leave osgi.bundle alone.
>
> Are you planning to publish those notes somewhere on the v3
> engineering wiki pages? If so you might say that if engineers pass
> classes that are NOT in the same module as LogStrings.properties then
> they will need to revise osgi.bundle.
>
> Thanks.
>
> - Tim
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>