Tom,
I need to look at that more, as redeploying now causes an exception (Sahoo, I do
not have your latest changes - this is the previous night snapshot):
Exception [TOPLINK-28009] (Oracle TopLink Essentials - 9.1 (Build non promoted:
10/16/2006)): oracle.toplink.essentials.exceptions.EntityManagerSetupException
Exception Description: Attempted to redeploy a session named
file:/faith4/gf/publish/glassfish/domains/domain1/applications/j2ee-apps/ex1-ee/entities.jar-pu1
without closing it.
at
oracle.toplink.essentials.internal.ejb.cmp3.EntityManagerSetupImpl.addSessionToGlobalSessionManager(EntityManagerSetupImpl.java:246)
at
oracle.toplink.essentials.internal.ejb.cmp3.EntityManagerSetupImpl.setServerSessionName(EntityManagerSetupImpl.java:776)
at
oracle.toplink.essentials.internal.ejb.cmp3.EntityManagerSetupImpl.predeploy(EntityManagerSetupImpl.java:465)
at
oracle.toplink.essentials.ejb.cmp3.EntityManagerFactoryProvider.createContainerEntityManagerFactory(EntityManagerFactoryProvider.java:152)
-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.
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>
>> >>>
>> >>>
>>
>>
>>