From: Marina Vatkina <Marina.Vatkina_at_Sun.COM>
Date: Thu, 19 Oct 2006 10:35:52 -0700

Hi Wonseok,

Thanks for catching this!

I don't think '.' will affect anything as even if the LogMgr reads it as
sub-logger namespace, either 'oracle.toplink.essentials' has a level, or
all of the long name altogether, which means that nothing in between should
matter. Right?

Thanks for RFE.

Tom, any comments from your side?

thanks,
-marina

Wonseok Kim wrote:
> Hi Marina,
>
> I think the 'deploymentCount' should not be decreased if it is just
> predeployment state.
>
> protected void cleanUpSessionManager() {
> deploymentCount--;
> if(deploymentCount > 0) {
> return;
> }
> state = STATE_UNDEPLOYED;
> removeSessionFromGlobalSessionManager();
> }
>
> How about doing like below?
> if(state == STATE_DEPLOYED){
> deploymentCount--;
> }
>
> One more question about the logger name. It's a trivial issue, but is it
> okay if a session name contains dot(".") like below?
>
> file:/home/works/my.tests/toplink-essentials-annotation-model-tests.jar-default
>
>
> Others look good.
>
> FYI, I filed an RFE issue for category-specific logging level.
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=1338
> <https://glassfish.dev.java.net/issues/show_bug.cgi?id=1338>
>
> Cheers,
> - Wonseok
>
> On 10/19/06, *Marina Vatkina* <Marina.Vatkina_at_sun.com
> <mailto:Marina.Vatkina_at_sun.com>> wrote:
>
> Hi Tom,
>
> The problem was not in EntityManagerSetupImpl.undeploy() (though the
> final
> change was made there as well), but in EMFImpl.close() that didn't have
> a serverSession set, unless the deploy is executed, so it wasn't
> calling
> undeploy at all.
>
> The solution:
> a) Removing 'if(serverSession != null)' around setupImpl.undeploy() call
> allows to always proceed (serverSession is now created in predeploy).
> b) Changing the condition in undeploy from 'if(state !=
> STATE_DEPLOYED)' to
> 'if(session == null)' for not going further, solves the rest.
>
> Unit tests all pass with the above changes. I also ran verifier with
> my example.
>
> The above changes still don't address a) issue 1333 (I need more
> info, but let's
> take it to another thread), and b) setting session name in the map
> *and* using
> javaagent (let's discuss that scenario further on that new thread),
> but if you
> are ok, I'd rather check in the current changes.
>
> All changes are attached.
>
> thanks,
> -marina
>
> Tom Ware wrote:
> > Hi Marina,
> >
> > I believe people will use JavaLog on SE. This will be particularly
> > common with people deploying to non-JPA compliant servers. (
> e.g. Tom Cat)
> >
> > Have you had a look at the code in:
> EntityManagerSetupImpl.undeploy()
> > for your issues with redeployment. It seems like the changes you are
> > making will result in a session existing before it used to
> (before the
> > EntityManagerFactory in in the DEPLOYED state). In the undeploy
> method,
> > we are only cleaning up if the EMF is in DEPLOYED state. You may
> have
> > to write some code to allow clean up to work properly in states
> other
> > than DEPLOYED.
> >
> > -Tom
> >
> > Marina Vatkina wrote:
> >
> >> Hi Tom,
> >>
> >> I need to look into that code path more, but by default JavaLog
> is not
> >> used in SE.
> >> It can be a problem if somebody calls createEntityManagerFactory()
> >> directly in EE, but how often that can be? I'm not saying we
> shouldn't
> >> address that, but should it block the current changes to go in?
> >>
> >> My other urgent concern is that with the changes that I'm ready
> to check
> >> in, redeploy on GF fails if there was no appclient run
> in-between because
> >> after the PU load into the server, there is no emf.close() call.
> >>
> >> Let me know what do you think.
> >>
> >> thanks,
> >> -marina
> >>
> >> Tom Ware wrote:
> >>
> >>
> >>> Hi Marina,
> >>>
> >>> The map will not work in SE. The reason is that predeploy is
> called
> >>> before createEntityManagerFactory() on all persistence units on the
> >>> classpath. When createEntityManagerFactory(String, Map) is
> called,
> >>> the map is stored on the factory that is created. It is then used
> >>> when deploy is called in the getServerSession() method. In this
> >>> situation, none of the logging properties will be properly
> dealt with.
> >>>
> >>> -Tom
> >>>
> >>> Marina Vatkina wrote:
> >>>
> >>>
> >>>
> >>>> Tom,
> >>>>
> >>>> Map should work, right? It's merged with the PU, and used in
> predeploy.
> >>>> With my latest fix for Wonseok's item #2 noted below, the
> session name
> >>>> should be used as-is (if somebody reminds me how to use
> JavaLog in SE,
> >>>> I can test it). In EE, the only way to specify session name
> will be in
> >>>> the persistence.xml - I can test this before I check in my
> changes).
> >>>>
> >>>> The thing that won't work, is changing the session name, *and*
> using
> >>>> JavaLog - DefaultSessionLog is not affected at all by my changes.
> >>>>
> >>>> HTH,
> >>>> -marina
> >>>>
> >>>> Tom Ware wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> First of all, I appologize for noticing this so late in the
> cycle.
> >>>>>
> >>>>> I am a little more concerned about this one than the category
> >>>>> property support issue. The reason is: In SE we need this
> support
> >>>>> in order for a session name specified in the Map argument to
> >>>>> createEntityManagerFactory(name, map) to work.
> >>>>>
> >>>>> If it is resolved later, I would prefer it if later is
> "immediately
> >>>>> after the check-in of this change".
> >>>>>
> >>>>> -Tom
> >>>>>
> >>>>> Marina Vatkina wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Hi Tom,
> >>>>>>
> >>>>>> This is one of 2 things to be resolved later (the other being
> >>>>>> support for
> >>>>>> category-specific log level). Do you mind?
> >>>>>>
> >>>>>>
> >>>>>> Tom Ware wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> Hi Marina,
> >>>>>>>
> >>>>>>> I just noticed another potential issue. Maybe you can
> dispel my
> >>>>>>> concern.
> >>>>>>>
> >>>>>>> In deploy() we call
> updateServerSession(). updateServerSession()
> >>>>>>> potentially changes the session name. When it changes the
> >>>>>>> session name, It looks like we should be dealing with the
> loggers
> >>>>>>> after the session name change. Also, I am wondering if we need
> >>>>>>> to do anything about the logging namespace.
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> What do you mean by this last question?
> >>>>>>
> >>>>>> thanks,
> >>>>>> -marina
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> -Tom
> >>>>>>>
> >>>>>>> Tom Ware wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> Sounds good Marina. If those are the only changes, I do not
> >>>>>>>> think there is a need for further review.
> >>>>>>>>
> >>>>>>>> -Tom
> >>>>>>>>
> >>>>>>>> Marina Vatkina 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>
> >>>>>>>>>>> <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
> <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.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>
> >>>
>
>
>