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.
-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.
>>>> >>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>
>>>> >>>>>>>>>>
>>>> >>>>>>>>>>
>>>> >>>>>>>>>>
>>>> >>>>>>>>>>
>>>> >>>>>>>>>>
>>>> >>>>>>>>>>
>>>> >>>>>
>>>> >>>>>
>>>> >>>>>
>>>> >>>>>
>>>> >>>>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>
>
>
>
--
Tom Ware
Principal Software Engineer
Oracle Canada Inc.
Direct: (613) 783-4598
Email: tom.ware_at_oracle.com