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