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.
>>>>> >>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>>
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>
>>
>>
>>
>>
>