First of all, I appologize for noticing this so late in the cycle.
I am a little more concerned about this one than the category property
support issue. The reason is: In SE we need this support in order for a
session name specified in the Map argument to
createEntityManagerFactory(name, map) to work.
If it is resolved later, I would prefer it if later is "immediately
after the check-in of this change".
-Tom
Marina Vatkina wrote:
>Hi Tom,
>
>This is one of 2 things to be resolved later (the other being support for
>category-specific log level). Do you mind?
>
>
>Tom Ware wrote:
>
>
>>Hi Marina,
>>
>> I just noticed another potential issue. Maybe you can dispel my concern.
>>
>> In deploy() we call updateServerSession(). updateServerSession()
>>potentially changes the session name. When it changes the session name,
>>It looks like we should be dealing with the loggers after the session
>>name change. Also, I am wondering if we need to do anything about the
>>logging namespace.
>>
>>
>
>What do you mean by this last question?
>
>thanks,
>-marina
>
>
>
>>-Tom
>>
>>Tom Ware wrote:
>>
>>
>>
>>>Sounds good Marina. If those are the only changes, I do not think
>>>there is a need for further review.
>>>
>>>-Tom
>>>
>>>Marina Vatkina wrote:
>>>
>>>
>>>
>>>
>>>
>>>>Tom, Wonseok,
>>>>
>>>>I did #1, and to address #2 in Wonseok's list, I moved the following
>>>>lines
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> session.setName(name);
>>>>> addSessionToGlobalSessionManager();
>>>>>
>>>>>
>>>>>
>>>>outside the 'if(name == null)' block.
>>>>
>>>>Do you want to see the final code?
>>>>
>>>>thanks,
>>>>-marina
>>>>
>>>>Tom Ware wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Hi Marina,
>>>>>
>>>>>In general, I think the code looks good.
>>>>>
>>>>>A couple comments below related to Wonsoek's earlier comments:
>>>>>
>>>>>
>>>>>Wonseok Kim wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Marina,
>>>>>>Some comments...
>>>>>>
>>>>>>1. Could you update the default level with INFO in
>>>>>>PropertiesHandler.LoggingLevelProp class?
>>>>>>
>>>>>> protected static class LoggingLevelProp extends Prop {
>>>>>> LoggingLevelProp() {
>>>>>> super(TopLinkProperties.LOGGING_LEVEL,
>>>>>>Level.CONFIG.getName());
>>>>>>
>>>>>>Also this should be updated in the TopLink JPA documentation.
>>>>>>http://www.oracle.com/technology/products/ias/toplink/jpa/resources/toplink-jpa-extensions.html#TopLinkLogging
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>I agree.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>2. If a user specify the toplink.session-name property, your code
>>>>>>will use the default namespace("
>>>>>>oracle.toplink.essentials.default"). I think it should be
>>>>>>considered in setServerSessionName().
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>This is important. The user specified name should definitely be
>>>>>considered.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>3. I would like to know there is a resolution about the level for a
>>>>>>specific category. DefaultSessionLog doesn't support this. JavaLog
>>>>>>supports this but it is not easy to set the level by a user -
>>>>>>should know the generated session name(long and location dependent).
>>>>>>It would be very useful if a user can set the level of 'sql'
>>>>>>category to see only the generated SQLs. Another property like
>>>>>>"toplink.logging.level.<category>" can be an option for this. Is
>>>>>>there any idea?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>We should definitely add an issue to ensure the categories work.
>>>>>
>>>>>-Tom
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Others look good to me.
>>>>>>
>>>>>>Thanks,
>>>>>>- Wonseok
>>>>>>
>>>>>>On 10/17/06, *Marina Vatkina* <Marina.Vatkina_at_sun.com
>>>>>><mailto:Marina.Vatkina_at_sun.com>> wrote:
>>>>>>
>>>>>> Tom, Wonseok, Mitesh,
>>>>>>
>>>>>> Please review the changes. They combine the discussions in this
>>>>>> thread
>>>>>> and CONFIG log messages in the (short) other.
>>>>>>
>>>>>> thanks,
>>>>>> -marina
>>>>>>
>>>>>> Tom Ware wrote On 10/16/06 13:55,:
>>>>>> >
>>>>>> > Marina Vatkina wrote:
>>>>>> >
>>>>>> >
>>>>>> >>Hi Tom,
>>>>>> >>
>>>>>> >>Tom Ware wrote On 10/16/06 07:09,:
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>>Hi Marina,
>>>>>> >>>
>>>>>> >>> Lets not add the separate property for now and continue to set
>>>>>> both
>>>>>> >>>loggers at initialization time. I think the issue with the
>>>>>> default
>>>>>> >>>logger being set by each persistence unit is one that will have
>>>>>> a fairly
>>>>>> >>>low impact on users.
>>>>>> >>>
>>>>>> >>>
>>>>>> >>
>>>>>> >>RI agree. With the only exception that its name is "...default".
>>>>>> >>
>>>>>> >>But before I finalize my changes, I have one more question: all
>>>>>> the changes
>>>>>> >>to the logger names are being done in the JavaLog class which
>>>>>> means that
>>>>>> >>they have no affect on SE loggers unless the users specify the
>>>>>> new option
>>>>>> >>added by Wonseok. But you are concerned about the session name.
>>>>>> So how does
>>>>>> >>the user-specified session name come into the picture?
>>>>>> >>
>>>>>> >>
>>>>>> >
>>>>>> > As long as the session has the correct name at the time we
>>>>>> initialize
>>>>>> > the loggers, it should not matter whether the use has specified
>>>>>>the
>>>>>> > session name or we have defaulted it.
>>>>>> >
>>>>>> >
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>> Perhaps we should enter an enhancement that says something like:
>>>>>> >>>Currently the Default logger is used for some of the initial
>>>>>>setup
>>>>>> >>>messages in JPA. Changing the logging level in JPA affects the
>>>>>> logging
>>>>>> >>>level of the default logger and therefore potentially affects
>>>>>> users of
>>>>>> >>>the default logger outside of the persistence unit. TopLink
>>>>>> should be
>>>>>> >>>enhanced to allow persistence units to log messages before the
>>>>>> session
>>>>>> >>>is available at all the available levels without having the log
>>>>>> level
>>>>>> >>>for the persistence unit affect future users of the default log.
>>>>>> >>>
>>>>>> >>>
>>>>>> >>
>>>>>> >>We have an IT that says that AbstractSessionLog is being
>>>>>> constantly changed:
>>>>>> >> https://glassfish.dev.java.net/issues/show_bug.cgi?id=1113. Do
>>>>>> you want to
>>>>>> >>change that one, or file another? Feel free to do either one.
>>>>>> >>
>>>>>> >>
>>>>>> >
>>>>>> > That one looks fine.
>>>>>> >
>>>>>> > -Tom
>>>>>> >
>>>>>> >
>>>>>> >>thanks,
>>>>>> >>-marina
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>>-Tom
>>>>>> >>>
>>>>>> >>>Marina Vatkina wrote:
>>>>>> >>>
>>>>>> >>>
>>>>>> >>>
>>>>>> >>>
>>>>>> >>>
>>>>>> >>>>Hi Tom,
>>>>>> >>>>
>>>>>> >>>>This is not a problem. Do you want to be able to set the
>>>>>> default logger
>>>>>> >>>>level from a separate PU property (if yes, in all envs or Java
>>>>>> SE only)?
>>>>>> >>>>
>>>>>> >>>>thanks,
>>>>>> >>>>-marina
>>>>>> >>>>
>>>>>> >>>>Tom Ware wrote:
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>>>Hi Marina,
>>>>>> >>>>>
>>>>>> >>>>>How about the following:
>>>>>> >>>>>
>>>>>> >>>>>1. Change the namespace for the default logger to
>>>>>> >>>>>"oracle.toplink.essentials.default".
>>>>>> >>>>>2. Change the namespace for the session loggers to
>>>>>> >>>>>"oracle.toplink.essentials.session.<sessionName>
>>>>>> >>>>>
>>>>>> >>>>>That way we can avoid a clash between the default logger and
>>>>>>the
>>>>>> >>>>>session loggers.
>>>>>> >>>>>
>>>>>> >>>>>What do you think?
>>>>>> >>>>>-Tom
>>>>>> >>>>>
>>>>>> >>>>>Marina Vatkina wrote:
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>>>Hi Tom,
>>>>>> >>>>>>
>>>>>> >>>>>>What behavior would you like to see (keeping in mind that
>>>>>> >>>>>>AbstractSessionLog
>>>>>> >>>>>>doesn't have a name, and is used only for a limited
>>>>>> pre-session-creation
>>>>>> >>>>>>configuration).
>>>>>> >>>>>>
>>>>>> >>>>>>BTW, now that we create a session and name it at the time we
>>>>>> create
>>>>>> >>>>>>the loggers,
>>>>>> >>>>>>can we get rid of the AbstractSessionLog instance altogether?
>>>>>> >>>>>>
>>>>>> >>>>>>thanks,
>>>>>> >>>>>>-marina
>>>>>> >>>>>>
>>>>>> >>>>>>Tom Ware wrote:
>>>>>> >>>>>>
>>>>>> >>>>>>
>>>>>> >>>>>>
>>>>>> >>>>>>
>>>>>> >>>>>>
>>>>>> >>>>>>
>>>>>> >>>>>>
>>>>>> >>>>>>
>>>>>> >>>>>>>Hi Marina,
>>>>>> >>>>>>>
>>>>>> >>>>>>>The reason I am concerned (and the reason I am slow getting
>>>>>> back to
>>>>>> >>>>>>>you) is that all of the following make it so there is a
>>>>>> session name
>>>>>> >>>>>>>is a "reserved word" since the namespace for a session is
>>>>>> >>>>>>>oracle.toplink.essentials.<sessionName>
>>>>>> >>>>>>>
>>>>>> >>>>>>>- oracle.toplink.essentials.default
>>>>>> >>>>>>>- oracle.toplink.essentials.default-logger
>>>>>> >>>>>>>- oracle.toplink.essentials.non-session
>>>>>> >>>>>>>
>>>>>> >>>>>>>I am trying to figure out if there is a reasonable way to
>>>>>> solve this
>>>>>> >>>>>>>problem and avoid having a session name that behaves
>>>>>> differently (no
>>>>>> >>>>>>>matter how obscure the name ends up being). In addition, I
>>>>>> am hoping
>>>>>> >>>>>>>to keep the name spaces so they are intuitive.
>>>>>> >>>>>>>
>>>>>> >>>>>>>-Tom
>>>>>> >>>>>>>
>>>>>> >>>>>>>Marina Vatkina wrote:
>>>>>> >>>>>>>
>>>>>> >>>>>>>
>>>>>> >>>>>>>
>>>>>> >>>>>>>
>>>>>> >>>>>>>
>>>>>> >>>>>>>
>>>>>> >>>>>>>
>>>>>> >>>>>>>
>>>>>> >>>>>>>
>>>>>> >>>>>>>>Tom,
>>>>>> >>>>>>>>
>>>>>> >>>>>>>>One more thought: may be we should assign
>>>>>> AbstractSessionLog namespace
>>>>>> >>>>>>>>called oracle.toplink.essentials.non-session or something
>>>>>> to that
>>>>>> >>>>>>>>extent?
>>>>>> >>>>>>>>It's not a default logger, and a different name will
>>>>>> clarify a lot
>>>>>> >>>>>>>>of confusion.
>>>>>> >>>>>>>>
>>>>>> >>>>>>>>thanks,
>>>>>> >>>>>>>>-marina
>>>>>> >>>>>>>>
>>>>>> >>>>>>>>Marina Vatkina wrote:
>>>>>> >>>>>>>>
>>>>>> >>>>>>>>
>>>>>> >>>>>>>>
>>>>>> >>>>>>>>
>>>>>> >>>>>>>>
>>>>>> >>>>>>>>
>>>>>> >>>>>>>>
>>>>>> >>>>>>>>
>>>>>> >>>>>>>>
>>>>>> >>>>>>>>
>>>>>> >>>>>>>>>Hi Tom,
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>Tom Ware wrote:
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>>Hi Marina,
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>Comments inline.
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>Marina Vatkina wrote:
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>>Hi Tom,
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>About the name (your other email) - we can use
>>>>>> something else
>>>>>> >>>>>>>>>>>other than
>>>>>> >>>>>>>>>>>"default", or we can document that a session named
>>>>>> "default" will
>>>>>> >>>>>>>>>>>have
>>>>>> >>>>>>>>>>>the same log level as the default logger (whether
>>>>>> explicitly
>>>>>> >>>>>>>>>>>specified
>>>>>> >>>>>>>>>>>or not).
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>I have a strong preference towards a solution that does
>>>>>> not not
>>>>>> >>>>>>>>>>make any potential session names into "reserved words"
>>>>>> and will
>>>>>> >>>>>>>>>>required some convincing that a solution that makes any
>>>>>> session
>>>>>> >>>>>>>>>>name into a "reserved word" is the only reasonable way
>>>>>> forward.
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>No problem. Worth discussing ;)
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>>>Here are my thoughts about the options:
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>Tom Ware wrote:
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>>I am still brainstorming for ideas. So far here's all
>>>>>> I have
>>>>>> >>>>>>>>>>>>come up with.
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>1. Do not change the namespace
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>We know it causes all types of problems if PU
>>>>>> properties apply to
>>>>>> >>>>>>>>>>>the AbstractSessionLog.
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>That's why I am trying to figure out an alternate way of
>>>>>> dealing
>>>>>> >>>>>>>>>>with the default logger stored on AbstractSessionLog.
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>>2. Add a property that allows the default TopLink
>>>>>> logging level
>>>>>> >>>>>>>>>>>>to be set. ( toplink.logging.level.default or
>>>>>> something like that).
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>Do you mean for the AbstractSessionLog to ignore the
>>>>>> current
>>>>>> >>>>>>>>>>>toplink.logging.level specified in a PU and use the
>>>>>> default unless
>>>>>> >>>>>>>>>>>explicitly specified by the
>>>>>>toplink.logging.level.default?
>>>>>> >>>>>>>>>>>Can be an option.
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>Your interpretation of my suggestion is correct. I am
>>>>>> open to
>>>>>> >>>>>>>>>>other suggestions as well.
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>>3. Document the new property as the only way to
>>>>>>change the
>>>>>> >>>>>>>>>>>>logging level for pre-session-creation configuration
>>>>>> (i.e.the
>>>>>> >>>>>>>>>>>>only way to change the logging level of the default
>>>>>> logger on
>>>>>> >>>>>>>>>>>>AbstractSessionLog). Also, document the fact that
>>>>>> setting the
>>>>>> >>>>>>>>>>>>value of this property in any persistence unit could
>>>>>> affect
>>>>>> >>>>>>>>>>>>other persistence units and will override any parent
>>>>>> logging
>>>>>> >>>>>>>>>>>>setting.
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>No, it shouldn't override the parent, i.e.
>>>>>> >>>>>>>>>>>toplink.logging.level.default
>>>>>> >>>>>>>>>>>will not affect
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>>>>>>>>toplink.logging.level.<very-long-constructed-session-name>.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>This was the reason to add its own name to the default
>>>>>> logger.
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>First, in case my phrasing was not clear, by "override
>>>>>> the parent"
>>>>>> >>>>>>>>>>I simply mean using that property to specify the logging
>>>>>> level for
>>>>>> >>>>>>>>>>"oracle.toplink.essentials" - not changing the logging
>>>>>> level on
>>>>>> >>>>>>>>>>the parent logger.
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>" oracle.toplink.essentials" is the parent logger for all
>>>>>> other
>>>>>> >>>>>>>>>loggers.
>>>>>> >>>>>>>>>The goal is to never set the level on that particular
>>>>>> logger from any
>>>>>> >>>>>>>>>of the PU properties.
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>>Assuming my initial phrasing was adequately understood,
>>>>>> I am not
>>>>>> >>>>>>>>>>sure I understand what you are saying here. If someone
>>>>>> specifies
>>>>>> >>>>>>>>>>toplink.logging.level.default, they are explicitly
>>>>>>setting a
>>>>>> >>>>>>>>>>logging level. Why shouldn't that set the level for
>>>>>> >>>>>>>>>>" oracle.toplink.essentials"?
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>Setting the level for "oracle.toplink.essentials"
>>>>>> explicitly breaks GF
>>>>>> >>>>>>>>>integration, as it will not be possible to reset it to
>>>>>> defaults
>>>>>> >>>>>>>>>dynamically:
>>>>>> >>>>>>>>>the default value is not set on
>>>>>> "oracle.toplink.essentials" - it's
>>>>>> >>>>>>>>>a property
>>>>>> >>>>>>>>>that is not present for the defaults, but by Java logging
>>>>>> defaults,
>>>>>> >>>>>>>>>i.e.
>>>>>> >>>>>>>>>"" logger in our case.
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>The one strange thing this setting does is
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>>it potentially has side effects for the next user of the
>>>>>> default
>>>>>> >>>>>>>>>>log. This setting is one that is likely to be only used
>>>>>> while
>>>>>> >>>>>>>>>>debugging (and infrequently, even then) due to the fact
>>>>>> that there
>>>>>> >>>>>>>>>>are very few messages at a more granular level that
>>>>>> INFO(the
>>>>>> >>>>>>>>>>default) that are written to the default logger. As a
>>>>>> result, I
>>>>>> >>>>>>>>>>am willing to live with that side effect as long as we
>>>>>> adequately
>>>>>> >>>>>>>>>>document it.
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>What if we change the setting to
>>>>>> toplink.logging.level.config or
>>>>>> >>>>>>>>>> toplink.logging.level.default-logger, and ensure it
>>>>>> does not have
>>>>>> >>>>>>>>>>any effect on the session loggers.
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>Yes, we can have toplink.logging.level.default-logger
>>>>>> mapped to the
>>>>>> >>>>>>>>>"oracle.toplink.essentials.default-logger" namespace,
>>>>>> which will
>>>>>> >>>>>>>>>not affect
>>>>>> >>>>>>>>>any session loggers, but will use the same global
>>>>>> defaults if not
>>>>>> >>>>>>>>>set explicitly.
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>>4. Only use the existing property (
>>>>>> toplink.logging.level) to set
>>>>>> >>>>>>>>>>>>the level of the session's log.
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>This will require a redeploy to apply a change, and
>>>>>> doesn't solve
>>>>>> >>>>>>>>>>>the
>>>>>> >>>>>>>>>>>problem of having separate log levels for separate PUs.
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>What conditions cause us to need a redeploy for a change?
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>If a user once specified a toplink.logging.level in the
>>>>>> >>>>>>>>>persistence.xml,
>>>>>> >>>>>>>>>they can't just remove that property to get the defaults.
>>>>>> They need to
>>>>>> >>>>>>>>>redeploy either way if they change persistence.xml, but
>>>>>> they'll
>>>>>> >>>>>>>>>need to
>>>>>> >>>>>>>>>either reset it to INFO, or restart the server after the
>>>>>> redeploy
>>>>>> >>>>>>>>>to get
>>>>>> >>>>>>>>>the defaults.
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>>If toplink.logging.level sets only the level of the
>>>>>> sessions log.
>>>>>> >>>>>>>>>>(i.e. for session "session1", only the logger in namespace
>>>>>> >>>>>>>>>>"oracle.toplink.essentials.session1" is affected),
>>>>>> doesn't this
>>>>>> >>>>>>>>>>solve the problem of having separate log levels for
>>>>>> separate PUs?
>>>>>> >>>>>>>>>>Please forgive me if I am being missing something obvious.
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>Yes. It does. I think we now go in circles around the
>>>>>> following
>>>>>> >>>>>>>>>proposal:
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>1. Existing toplink.logging.level property to affect only
>>>>>> session
>>>>>> >>>>>>>>>loggers.
>>>>>> >>>>>>>>>2. Introduce toplink.logging.level.default-logger
>>>>>> property that
>>>>>> >>>>>>>>>will affect
>>>>>> >>>>>>>>>AbstractSessionLog only and will be global for all PUs in
>>>>>> this VM.
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>As we didn't discuss the categories behavior so far,
>>>>>> >>>>>>>>>3. It's not possible to choose for a user a separate log
>>>>>> level for
>>>>>> >>>>>>>>>separate
>>>>>> >>>>>>>>>category.
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>Do you agree?
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>thanks,
>>>>>> >>>>>>>>>-marina
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>>-Tom
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>>I haven't completely thought it out, but figured I
>>>>>> pass on the
>>>>>> >>>>>>>>>>>>idea to start the discussion.
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>yes, let's sort it out (and document the result).
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>thanks,
>>>>>> >>>>>>>>>>>-marina
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>>-Tom
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>Tom Ware wrote:
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>Hi Marina,
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>Thanks for the lesson:)
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>As far as changing the namespace for the default
>>>>>> logger to
>>>>>> >>>>>>>>>>>>>"oracle.toplink.essentials.default", I have a
>>>>>> concern. Isn't
>>>>>> >>>>>>>>>>>>>this the same namespace as a session called
>>>>>> "default"? I
>>>>>> >>>>>>>>>>>>>believe this could cause problems.
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>I still need to do some thinking about the issue of
>>>>>> how we deal
>>>>>> >>>>>>>>>>>>>with the logging level of the default Logger. It
>>>>>> seems to me
>>>>>> >>>>>>>>>>>>>to potentially be an issue regardless of what we do
>>>>>> about this
>>>>>> >>>>>>>>>>>>>bug. I'll let you know what I come up with.
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>I think Wonsoek has replied to your question about
>>>>>> the default
>>>>>> >>>>>>>>>>>>>logging levels. Please let me know if you have
>>>>>> additional
>>>>>> >>>>>>>>>>>>>questions.
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>-Tom
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>Marina Vatkina wrote:
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>Tom, Wonseok,
>>>>>> >>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>Yes, I should've extracted the relevant portion into
>>>>>> >>>>>>>>>>>>>>setServerSessionName
>>>>>> >>>>>>>>>>>>>>(don't know why I missed half of the code :( - sorry
>>>>>> about that).
>>>>>> >>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>Yes, it should be ".default".
>>>>>> >>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>The categories are appended to each name space, and
>>>>>> I'm not
>>>>>> >>>>>>>>>>>>>>sure the categories
>>>>>> >>>>>>>>>>>>>>are implemented correctly now in the JavaLog if
>>>>>>they are
>>>>>> >>>>>>>>>>>>>>expected to be
>>>>>> >>>>>>>>>>>>>>specified by the user. But let's discuss this
>>>>>> further, and see
>>>>>> >>>>>>>>>>>>>>where is the
>>>>>> >>>>>>>>>>>>>>right solution.
>>>>>> >>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>Here is the problem that I'm trying to solve.
>>>>>> >>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>Java loggers use parent's level if it is not
>>>>>> explicitly set,
>>>>>> >>>>>>>>>>>>>>but use its own
>>>>>> >>>>>>>>>>>>>>level otherwise. There is no way to unset a level,
>>>>>> once it's
>>>>>> >>>>>>>>>>>>>>set explicitly.
>>>>>> >>>>>>>>>>>>>>The namespace is registered with the LogMgr in the
>>>>>> VM, which
>>>>>> >>>>>>>>>>>>>>means that as long
>>>>>> >>>>>>>>>>>>>>as you use the same name, you are getting the same
>>>>>> Java logger
>>>>>> >>>>>>>>>>>>>>instance.
>>>>>> >>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>Now, if a log level is specified in a
>>>>>> persistence.xml as a
>>>>>> >>>>>>>>>>>>>>property, we do set
>>>>>> >>>>>>>>>>>>>>it currently on the default logger by processing
>>>>>> >>>>>>>>>>>>>>AbstractSessionLog in
>>>>>> >>>>>>>>>>>>>>initOrUpdateLogging (which without ".default" equals
>>>>>> to the
>>>>>> >>>>>>>>>>>>>>overall TopLink namespace of "
>>>>>> oracle.toplink.essentials") ,
>>>>>> >>>>>>>>>>>>>>i.e. any other PU after that will
>>>>>> >>>>>>>>>>>>>>use that level (if it doesn't specify it
>>>>>> explicitly), or will
>>>>>> >>>>>>>>>>>>>>override it again
>>>>>> >>>>>>>>>>>>>>with its own setting if it is different. Which means
>>>>>> that 2
>>>>>> >>>>>>>>>>>>>>PUs can't have 2
>>>>>> >>>>>>>>>>>>>>different logging levels.
>>>>>> >>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>Adding ".default" will give AbstractSessionLog it's
>>>>>>own
>>>>>> >>>>>>>>>>>>>>sub-space.
>>>>>> >>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>Setting the ServerSession name much earlier, gives
>>>>>> each PU
>>>>>> >>>>>>>>>>>>>>it's own sub-space.
>>>>>> >>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>Now the subcategories (I had never tested, how would
>>>>>> it work
>>>>>> >>>>>>>>>>>>>>in GF): the
>>>>>> >>>>>>>>>>>>>>current code constructs the corresponding namespace
>>>>>>as:
>>>>>> >>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>sessionNameSpace = DEFAULT_TOPLINK_NAMESPACE + "." +
>>>>>> sessionName;
>>>>>> >>>>>>>>>>>>>>String loggerNameSpace = sessionNameSpace + "." +
>>>>>> loggerCategory;
>>>>>> >>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>It might be better to have it as
>>>>>> >>>>>>>>>>>>>>DEFAULT_TOPLINK_NAMESPACE + "." + loggerCategory +
>>>>>> sessionName;
>>>>>> >>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>Right?
>>>>>> >>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>I need to think more about changing the session name
>>>>>> - we
>>>>>> >>>>>>>>>>>>>>can't unregister
>>>>>> >>>>>>>>>>>>>>a logger from a LogMgr, so changing a name will mean
>>>>>> creating
>>>>>> >>>>>>>>>>>>>>new loggers,
>>>>>> >>>>>>>>>>>>>>right?
>>>>>> >>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>Tom, about the new useParentLevel() - will it be OFF
>>>>>> or INFO
>>>>>> >>>>>>>>>>>>>>by default,
>>>>>> >>>>>>>>>>>>>>if you don't specify the level in SE? Can you check?
>>>>>> >>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>thanks,
>>>>>> >>>>>>>>>>>>>>-marina
>>>>>> >>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>Tom Ware wrote:
>>>>>> >>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>Marina and Wonsoek,
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>- Can you explain a bit more why you need to append
>>>>>> >>>>>>>>>>>>>>>".default" to the default log namespace. How will
>>>>>> this work
>>>>>> >>>>>>>>>>>>>>>in conjuction with the logger categories? How
>>>>>> exactly is the
>>>>>> >>>>>>>>>>>>>>>current namespace causing issues? Will users have
>>>>>> to now
>>>>>> >>>>>>>>>>>>>>>specify ".default" on all their categories? ( e.g.
>>>>>> >>>>>>>>>>>>>>>oracle.toplink.essentials.default.sql) To me, this
>>>>>> seems a
>>>>>> >>>>>>>>>>>>>>>bit less intuitive than being able to set the
>>>>>> logging levels
>>>>>> >>>>>>>>>>>>>>>without the "default".
>>>>>> >>>>>>>>>>>>>>>- BTW: Assuming we can sort out the "default", I
>>>>>> think the
>>>>>> >>>>>>>>>>>>>>>namespace is currently missing a dot. It looks
>>>>>> like it is
>>>>>> >>>>>>>>>>>>>>>oracle.toplink.essentialsdefault.
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>Additional comments inline:
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>Wonseok Kim wrote:
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>Hi Marina,
>>>>>> >>>>>>>>>>>>>>>>comments in line...
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>On 10/12/06, *Marina Vatkina* <
>>>>>> Marina.Vatkina_at_sun.com <mailto:Marina.Vatkina_at_sun.com>
>>>>>> >>>>>>>>>>>>>>>><mailto:Marina.Vatkina_at_sun.com
>>>>>> <mailto:Marina.Vatkina_at_sun.com>>> wrote:
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>Tom, Wonseok,
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>Please review the changes.
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>Major points are described below in the IT note.
>>>>>> Other diffs:
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>a) renamed initServerSession() to
>>>>>> setServerSessionName(),
>>>>>> >>>>>>>>>>>>>>>>removed
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>from it the
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>call to assignCMP3Policy(), and changed the
>>>>>> javadoc comments as
>>>>>> >>>>>>>>>>>>>>>>they didn't
>>>>>> >>>>>>>>>>>>>>>>reflect the actual things happening in the method
>>>>>> anyway;
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>b) changed to call assignCMP3Policy() directly in
>>>>>> place of the
>>>>>> >>>>>>>>>>>>>>>>previous
>>>>>> >>>>>>>>>>>>>>>>initServerSession() call;
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>c) moved the call to setServerSessionName() to the
>>>>>> beginning of
>>>>>> >>>>>>>>>>>>>>>>predeploy (see
>>>>>> >>>>>>>>>>>>>>>>the reason #3 below).
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>Tom, do you see any problem with registering the
>>>>>> session by
>>>>>> >>>>>>>>>>>>>>>>name
>>>>>> >>>>>>>>>>>>>>>>so early? I
>>>>>> >>>>>>>>>>>>>>>>couldn't find any code in the
>>>>>> EntityManagerSetupImpl that would
>>>>>> >>>>>>>>>>>>>>>>suggest that
>>>>>> >>>>>>>>>>>>>>>>it can be.
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>1. Original initServerSession() does another
>>>>>> things. Those
>>>>>> >>>>>>>>>>>>>>>>calls session.getDescriptors() but this is filled in
>>>>>> >>>>>>>>>>>>>>>>predeploy phase. Therefore I think this should not
>>>>>> be called
>>>>>> >>>>>>>>>>>>>>>>before predeploy finishes.
>>>>>> >>>>>>>>>>>>>>>>How about making a new method "initSessionName()" by
>>>>>> >>>>>>>>>>>>>>>>extracting only the following code?
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>// use default session name if none is provided
>>>>>> >>>>>>>>>>>>>>>>String name =
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>>>>>>>>>>>>>EntityManagerFactoryProvider.getConfigPropertyAsString(TopLinkProperties.SESSION_NAME
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>> ,
>>>>>> >>>>>>>>>>>>>>>>m);
>>>>>> >>>>>>>>>>>>>>>>if(name == null) {
>>>>>> >>>>>>>>>>>>>>>> if (
>>>>>> persistenceUnitInfo.getPersistenceUnitRootUrl()
>>>>>> >>>>>>>>>>>>>>>>!= null){
>>>>>> >>>>>>>>>>>>>>>> name =
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> persistenceUnitInfo.getPersistenceUnitRootUrl().toString() +
>>>>>> >>>>>>>>>>>>>>>>"-" + persistenceUnitInfo.getPersistenceUnitName();
>>>>>> >>>>>>>>>>>>>>>> } else {
>>>>>> >>>>>>>>>>>>>>>> name =
>>>>>> persistenceUnitInfo.getPersistenceUnitName();
>>>>>> >>>>>>>>>>>>>>>> }
>>>>>> >>>>>>>>>>>>>>>> session.setName(name);
>>>>>> >>>>>>>>>>>>>>>>// session.log(SessionLog.FINEST,
>>>>>> >>>>>>>>>>>>>>>>SessionLog.PROPERTIES , "property_value_default",
>>>>>>new
>>>>>> >>>>>>>>>>>>>>>>Object[]{TopLinkProperties.SESSION_NAME , name});
>>>>>> >>>>>>>>>>>>>>>> addSessionToGlobalSessionManager();
>>>>>> >>>>>>>>>>>>>>>>}
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>I think Wonsoek's suggestion is a good one. Let's
>>>>>> only move
>>>>>> >>>>>>>>>>>>>>>the session name initialization code, and not the
>>>>>>other
>>>>>> >>>>>>>>>>>>>>>code. The initServerSession() method does more than
>>>>>> >>>>>>>>>>>>>>>initialize the name.
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>2. (To Tom) Is it safe to call
>>>>>> >>>>>>>>>>>>>>>>addSessionToGlobalSessionManager() in this early
>>>>>> step (with
>>>>>> >>>>>>>>>>>>>>>>uninitialized session)?
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>There is really one issue with this call we should
>>>>>> resolve.
>>>>>> >>>>>>>>>>>>>>>Details in the next item.
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>3. What if SESSION_NAME is set by user explicitly?
>>>>>> Now
>>>>>> >>>>>>>>>>>>>>>>user-specified name is set later by
>>>>>> updateSessionName()
>>>>>> >>>>>>>>>>>>>>>>which is called from updateServerSession() in
>>>>>> deploy phase.
>>>>>> >>>>>>>>>>>>>>>>I think we need to set this user-specified name in
>>>>>> >>>>>>>>>>>>>>>>"initSessionName()" also. But current code appears
>>>>>> to allow
>>>>>> >>>>>>>>>>>>>>>>changing session name in deploy(). Then should
>>>>>> logger should
>>>>>> >>>>>>>>>>>>>>>>change? I'm confused.
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>When we are integrated with the Server, I
>>>>>> believe, predeploy
>>>>>> >>>>>>>>>>>>>>>and deploy will be called with the same properties
>>>>>>and
>>>>>> >>>>>>>>>>>>>>>therefore, the call to updateSessionName() should
>>>>>> result in
>>>>>> >>>>>>>>>>>>>>>the same name as the call to initSessionName().
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>In SE, the predeploy occurs before the call to
>>>>>> >>>>>>>>>>>>>>>createEntityManagerFactory(name, properties) and
>>>>>> the deploy
>>>>>> >>>>>>>>>>>>>>>occurs after. The properties specified in the
>>>>>> argument to
>>>>>> >>>>>>>>>>>>>>>createEntityManagerFactory() that method need to be
>>>>>> >>>>>>>>>>>>>>>considered. That is why the call is made in deploy
>>>>>> as well.
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>As a result of this, there is an issue we have to
>>>>>> resolve in
>>>>>> >>>>>>>>>>>>>>>SE if we are calling
>>>>>> addSessionToGlobalSessionManager()
>>>>>> >>>>>>>>>>>>>>>before the deploy phase.
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>- What happens if we initialize with a session
>>>>>> name, and the
>>>>>> >>>>>>>>>>>>>>>call to createEntityManagerFactory() has a
>>>>>> different name.
>>>>>> >>>>>>>>>>>>>>>In this case, we cannot simply change the session
>>>>>>name
>>>>>> >>>>>>>>>>>>>>>because sessions are hashed in SessionManager based
>>>>>> on their
>>>>>> >>>>>>>>>>>>>>>name, so changing the name of the session will
>>>>>> result in
>>>>>> >>>>>>>>>>>>>>>lookup problems.
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>4. (To Tom) This is another concern but related to
>>>>>> #3. What
>>>>>> >>>>>>>>>>>>>>>>is the behaviour of session name property? If I
>>>>>> specify the
>>>>>> >>>>>>>>>>>>>>>>same session name of two applications or two
>>>>>> persistence
>>>>>> >>>>>>>>>>>>>>>>units, could I share ServerSession? But it doesn't
>>>>>> seem to
>>>>>> >>>>>>>>>>>>>>>>do it, because in
>>>>>> EntityManagerSetupImpl.predeploy() session
>>>>>> >>>>>>>>>>>>>>>>is always newly created like below regardless of
>>>>>> the session
>>>>>> >>>>>>>>>>>>>>>>name.
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>session = new ServerSession(...);
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>If session name property has no effect in JPA, I
>>>>>> think it
>>>>>> >>>>>>>>>>>>>>>>should be removed and then there will be no
>>>>>> confusion in #3.
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>Session name is used to store the session we use on
>>>>>> the
>>>>>> >>>>>>>>>>>>>>>SessionManager. We expect the session name to be
>>>>>> unique. If
>>>>>> >>>>>>>>>>>>>>>it is not, an exception will be thrown when the
>>>>>> session is
>>>>>> >>>>>>>>>>>>>>>added to the SessionManager. Take a look at the
>>>>>> >>>>>>>>>>>>>>>addSessionToGlobalSessionManager() method.
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>d) I added an api to the SessionLog to allow for
>>>>>> #1 below.
>>>>>> >>>>>>>>>>>>>>>>Another
>>>>>> >>>>>>>>>>>>>>>>option would
>>>>>> >>>>>>>>>>>>>>>>be to check for the log level being OFF, but it's
>>>>>> more time
>>>>>> >>>>>>>>>>>>>>>>consuming to go up
>>>>>> >>>>>>>>>>>>>>>>the logging chain every time.
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>Then in Java SE, the default level of JavaLogger
>>>>>> becomes
>>>>>> >>>>>>>>>>>>>>>>INFO while CONFIG is a default for DefaultLogger.
>>>>>> It appears
>>>>>> >>>>>>>>>>>>>>>>to be inconsistent for the default level. I don't
>>>>>> know why
>>>>>> >>>>>>>>>>>>>>>>the default level has been CONFIG for TopLink
>>>>>> logger, how
>>>>>> >>>>>>>>>>>>>>>>about changing it to INFO consistently. Then we
>>>>>> don't need
>>>>>> >>>>>>>>>>>>>>>>to set default level explicitly and to introduce
>>>>>> new method
>>>>>> >>>>>>>>>>>>>>>>"userParentLevel()" to SessionLog interface.
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>protected void initOrUpdateLogging(boolean init,
>>>>>> Map m,
>>>>>> >>>>>>>>>>>>>>>>SessionLog log) {
>>>>>> >>>>>>>>>>>>>>>>String logLevelString =
>>>>>> >>>>>>>>>>>>>>>>PropertiesHandler.getPropertyValueLogDebug
>>>>>> >>>>>>>>>>>>>>>>( TopLinkProperties.LOGGING_LEVEL, m, session);
>>>>>> >>>>>>>>>>>>>>>>// Don't need to set default level. It will
>>>>>>follow the
>>>>>> >>>>>>>>>>>>>>>>default level policy of the logger. INFO for
>>>>>> >>>>>>>>>>>>>>>>DefaultSessionLog. Parent logger's level(INFO
>>>>>> normally) for
>>>>>> >>>>>>>>>>>>>>>>JavaLog.
>>>>>> >>>>>>>>>>>>>>>>/*
>>>>>> >>>>>>>>>>>>>>>>if(logLevelString == null && init) {
>>>>>> >>>>>>>>>>>>>>>> logLevelString =
>>>>>> >>>>>>>>>>>>>>>>
>>>>>>
>>>>>>PropertiesHandler.getDefaultPropertyValueLogDebug(TopLinkProperties.LOGGING_LEVEL,
>>>>>>
>>>>>> >>>>>>>>>>>>>>>>session);
>>>>>> >>>>>>>>>>>>>>>>}
>>>>>> >>>>>>>>>>>>>>>>*/
>>>>>> >>>>>>>>>>>>>>>>if (logLevelString != null) {
>>>>>> >>>>>>>>>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>>>>>>>>>>>>>log.setLevel(AbstractSessionLog.translateStringToLoggingLevel(logLevelString));
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>}
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>I just talked to our product manager and we agree
>>>>>>that
>>>>>> >>>>>>>>>>>>>>>changing the JPA default to be the same as the
>>>>>>default
>>>>>> >>>>>>>>>>>>>>>logger. (INFO) Does that remove the need for the
>>>>>> >>>>>>>>>>>>>>>useParentLevel() method?
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>If we make this change, I think we should change
>>>>>> the logging
>>>>>> >>>>>>>>>>>>>>>in translateOldProperties and warnOldProperties to
>>>>>> INFO.
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>-Tom
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>Regards
>>>>>> >>>>>>>>>>>>>>>>- Wonseok
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>Let me know if you see any problems with the
>>>>>>proposed
>>>>>> >>>>>>>>>>>>>>>>changes. I
>>>>>> >>>>>>>>>>>>>>>>tested with
>>>>>> >>>>>>>>>>>>>>>>2 PUs being deployed, one with the explicit log
>>>>>> level, and
>>>>>> >>>>>>>>>>>>>>>>another
>>>>>> >>>>>>>>>>>>>>>>without it.
>>>>>> >>>>>>>>>>>>>>>>I also tested dynamic change of the log levels,
>>>>>> and server
>>>>>> >>>>>>>>>>>>>>>>restart. All seem
>>>>>> >>>>>>>>>>>>>>>>to work correctly.
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>thanks,
>>>>>> >>>>>>>>>>>>>>>>-marina
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>-------- Original Message --------
>>>>>> >>>>>>>>>>>>>>>>Subject: [Issue 1107] Logger defined by a
>>>>>> property doesn't
>>>>>> >>>>>>>>>>>>>>>>work
>>>>>> >>>>>>>>>>>>>>>>Date: Thu, 12 Oct 2006 01:56:44 +0000
>>>>>> >>>>>>>>>>>>>>>>From: mvatkina_at_dev.java.net
>>>>>> <mailto:mvatkina_at_dev.java.net> <mailto:mvatkina_at_dev.java.net
>>>>>> <mailto:mvatkina_at_dev.java.net>>
>>>>>> >>>>>>>>>>>>>>>>To: mvatkina_at_dev.java.net
>>>>>> <mailto:mvatkina_at_dev.java.net> <mailto:mvatkina_at_dev.java.net
>>>>>> <mailto:mvatkina_at_dev.java.net>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=1107
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>User mvatkina changed the following:
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>> What |Old
>>>>>>value |New value
>>>>>> >>>>>>>>>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>>>>>>>>>>>>>================================================================================
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>>Status|NEW |STARTED
>>>>>> >>>>>>>>>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>>>>>>>>>>>>>--------------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>------- Additional comments from
>>>>>> mvatkina_at_dev.java.net <mailto:mvatkina_at_dev.java.net>
>>>>>> >>>>>>>>>>>>>>>><mailto: mvatkina_at_dev.java.net
>>>>>> <mailto:mvatkina_at_dev.java.net>> Thu Oct 12 01:56:44 +0000
>>>>>> >>>>>>>>>>>>>>>>2006 -------
>>>>>> >>>>>>>>>>>>>>>>There are apparently several issues to address -
>>>>>> >>>>>>>>>>>>>>>>1.Do not set log level explicitly if not specified
>>>>>> in the
>>>>>> >>>>>>>>>>>>>>>>properties - use the
>>>>>> >>>>>>>>>>>>>>>>parent logger's level (set by the container)
>>>>>>instead.
>>>>>> >>>>>>>>>>>>>>>>2. The default logger namespace should be a child
>>>>>> of TopLink
>>>>>> >>>>>>>>>>>>>>>>namespace, e.g.
>>>>>> >>>>>>>>>>>>>>>>" oracle.toplink.essentials.default", otherwise
>>>>>> >>>>>>>>>>>>>>>>AbstractSessionLog
>>>>>> >>>>>>>>>>>>>>>>will set the
>>>>>> >>>>>>>>>>>>>>>>explicit level for all TopLink loggers (overriding
>>>>>> the
>>>>>> >>>>>>>>>>>>>>>>container
>>>>>> >>>>>>>>>>>>>>>>settings) in
>>>>>> >>>>>>>>>>>>>>>>the VM on the first PU with the specified log level.
>>>>>> >>>>>>>>>>>>>>>>3. ServerSession name must be set prior to
>>>>>>setting the
>>>>>> >>>>>>>>>>>>>>>>logger for
>>>>>> >>>>>>>>>>>>>>>>that session,
>>>>>> >>>>>>>>>>>>>>>>otherwise the logger is registered as the default
>>>>>> logger,
>>>>>> >>>>>>>>>>>>>>>>and its
>>>>>> >>>>>>>>>>>>>>>>level will
>>>>>> >>>>>>>>>>>>>>>>apply to all PUs in this VM.
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>A note: the problem that can't be solved so far is
>>>>>> switching
>>>>>> >>>>>>>>>>>>>>>>between explicitly
>>>>>> >>>>>>>>>>>>>>>>specified log level for a PU and the defalt app
>>>>>> server level
>>>>>> >>>>>>>>>>>>>>>>for
>>>>>> >>>>>>>>>>>>>>>>this namespace.
>>>>>> >>>>>>>>>>>>>>>>As there is no way to unset log level after it's
>>>>>> set, the only
>>>>>> >>>>>>>>>>>>>>>>work around will
>>>>>> >>>>>>>>>>>>>>>>be to change the property value or restart the
>>>>>>server.
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>
>>>>>> >>>
>>>>>> >>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>
>>>
>>>
>>>
>>>