Wonseok,
Yes, I also thought that this is the case, but I then I realized that
EntityManagerSetupImpl.undeploy is not called at all (print statement
is a fool-proof method ;)).
Let's see what Sahoo thinks.
thanks,
-marina
Wonseok Kim wrote:
> Marina,
>
> I think this occurs because
> EntityManagerSetupImpl.removeSessionFromGlobalSessionManager() is not
> called.
> With your change, session is added to SessionManager at predeployment
> time, but below undeploy() code calls cleanUpSessionManager() which
> calls removeSessionFromGlobalSessionManager() only if it is deployed.
> I think you need to solve this problem also.
>
> public synchronized void undeploy() {
> if(state != STATE_DEPLOYED) {
> return;
> }
> session.log(SessionLog.FINEST, SessionLog.PROPERTIES ,
> "undeploy_begin", new
> Object[]{getPersistenceUnitInfo().getPersistenceUnitName(), state,
> deploymentCount});
> try {
> cleanUpSessionManager();
> } finally {
> session.log(SessionLog.FINEST, SessionLog.PROPERTIES,
> "undeploy_end", new
> Object[]{getPersistenceUnitInfo().getPersistenceUnitName(), state,
> deploymentCount});
> if(state == STATE_UNDEPLOYED) {
> session = null;
> }
> }
>
> Thanks
> - Wonseok
>
> On 10/18/06, *Marina Vatkina* < Marina.Vatkina_at_sun.com
> <mailto:Marina.Vatkina_at_sun.com>> wrote:
>
> 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>
> >>> <mailto: 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>>
> >>> >>>>>>>>>>>>>>>><mailto: 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>> <mailto: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>> <mailto: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>>
> >>> >>>>>>>>>>>>>>>><mailto: 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.
> >>> >>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>
> >>> >>>>>>>>>>
> >>> >>>>>>>>>>
> >>> >>>>>>>>>>
> >>> >>>>>>>>>>
> >>> >>>>>>>>>>
> >>> >>>>>>>>>>
> >>> >>>>>
> >>> >>>>>
> >>> >>>>>
> >>> >>>>>
> >>> >>>>>
> >>> >>>
> >>> >>>
> >>> >>>
> >>>
> >>>
> >>>
>
>