[jboss-as7-dev] Modules and hidden packages

[Brian Stansberry]

On 4/2/13 11:40 AM, David M. Lloyd wrote:
> The grim fact is that our logging ID scheme in the AS project is simply
> not sustainable.  We have to change it or we will start running into
> major problems, especially as we fork and branch things over time, and
> even more so as we move towards finer-grained components and start
> phasing components in and out.  The rename gives us an opportunity to do
> so in a way that *is* sustainable.
>
> We will not break any existing searches/KB keys, and it would be easy
> enough (essential really) to provide a one-time, one-way mapping from
> existing codes to future codes (the reverse would be impossible of
> course, and undesirable in any case) which would be easy to publish.
>

Beyond "essentially really", I'd say required as part of the change, and 
no change patch related to this is accepted unless this is part of it. 
Then we are getting somewhere. If it's a task to do later it won't get 
done, or it will become a crap task that some poor unlucky soul is stuck 
with.

I also think any logging id conversion should be an AS 9 task. We don't 
have the bandwidth now.

> It's painful, and awkward, but I believe this is something we must do,
> so we should be sure to do it right.
>
> On 04/02/2013 11:14 AM, Brian Stansberry wrote:
>> Our logging IDs are already in the wild and are keys to knowledge base
>> entries and google results. Is changing these a case where we are
>> imposing pain on users in order to solve our own internal process problems?
>>
>> On 4/2/13 10:47 AM, David M. Lloyd wrote:
>>> There is a mechanism in JBoss Modules to support packages which are not
>>> visible to consumers of a module.  The idea is to come up with an easy
>>> convention so that we can put module-private APIs and classes in one
>>> place that is visible from multiple packages, without exposing or
>>> documenting these packages.
>>>
>>> Until 1.2, the only way available to do this for statically defined
>>> modules was to add an export filter in your module.xml via the <exports>
>>> element to exclude the specific package directories that are hidden.
>>>
>>> Starting in 1.2, you can also create a series of packages whose first
>>> segment is "_private".  These packages will automatically be excluded
>>> from the exported paths list.
>>>
>>> What I'd like to propose is:
>>>
>>> 1) For any given module, all generated JavaDoc should exclude packages
>>> under the _private hierarchy.
>>> 2) For any module which does i18n logging, all logging messages should
>>> be consolidated in one or more (but preferably one) interface(s) stored
>>> in a public _private.org.yourproject.YourInterface.
>>> 3) Once the new name is announced, I think we should break up our main
>>> logging IDs into per-subsystem categories.  For example, "XXEE" for EE,
>>> "XXEJB" for EJB, etc., each with their own numerical space and message
>>> interface.  These two changes should put an end to our log message ID
>>> fragmentation problems and give us a (one-time only!) chance to clean up
>>> this mess.
>>> 4) Projects that wish to exploit this mechanism can do so, noting that
>>> they should use "_private.org.yourproject" as a package prefix instead
>>> of just putting things directly under "_private" (to avoid conflicts
>>> when JARs are used on a flat class path).
>>>
>>> Flame on!
>>>
>>
>>
>
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat