Hi Sahoo,
This seems to be the container issue, as it happens only if I redeploy without
executing a client in between the deploys. Looks like EMF.close() is not called
in that case. Can you check?
thanks,
-marina
Marina Vatkina wrote:
> 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.
>>> >>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>
>>> >>>>>>>>>>
>>> >>>>>>>>>>
>>> >>>>>>>>>>
>>> >>>>>>>>>>
>>> >>>>>>>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>
>>> >>>
>>> >>>
>>>
>>>
>>>