Tom,
Map should work, right? It's merged with the PU, and used in predeploy.
With my latest fix for Wonseok's item #2 noted below, the session name
should be used as-is (if somebody reminds me how to use JavaLog in SE,
I can test it). In EE, the only way to specify session name will be in
the persistence.xml - I can test this before I check in my changes).
The thing that won't work, is changing the session name, *and* using
JavaLog - DefaultSessionLog is not affected at all by my changes.
HTH,
-marina
Tom Ware wrote:
> 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.
>>>>>>> >>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>
>>>>>>> >>>>>>>>>>
>>>>>>> >>>>>>>>>>
>>>>>>> >>>>>>>>>>
>>>>>>> >>>>>>>>>>
>>>>>>> >>>>>>>>>>
>>>>>>> >>>>>
>>>>>>> >>>>>
>>>>>>> >>>>>
>>>>>>> >>>>>
>>>>>>> >>>>>
>>>>>>> >>>
>>>>>>> >>>
>>>>>>> >>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>