Looks good to me.
I sent an another mail regarding undeployment problem. Please see it.
Thanks
-Wonseok
On 10/18/06, Marina Vatkina <Marina.Vatkina_at_sun.com> 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.
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>
> >> >>>
> >> >>>
> >>
> >>
> >>
>