Hi Marina,
Andrei has sent some comments.
-Tom
Marina Vatkina wrote:
>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.
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>
>> >>>
>>
>>
>>
>>
>>