Hi Marina,
I'll give you a partial explanation and then take an educated guess at
the second part of the answer.
First, the partial explanation, initOrUpdateLogging() updates the
logging values for a log. There are two logs we are interested in.
1. The default log
2. The session log
You will seen each place initOrUpdateLogging() is called, it is called
for each of those logs. I guess that means your update will not
necessarily in that specific method, but it will be where that method is
called.
Now, the educated guess (the original implementer of this feature will
be available next week to confirm or deny what I say here):
I believe we make calls to initOrUpdateLogging() both in predeploy and
deploy because we have always had the goal of allowing application
servers to do all the predeployment work ,serialize it in some way and
then do the deployment work later (or over and over again). When we
have implemented a feature like that, making these calls in both places
will make logging more flexible. (i.e. you will be able to configure it
for the predeployment step, and then later, when you actually deploy you
will be able to change the values.)
-Tom
Marina Vatkina wrote:
>Tom,
>
>To change initOrUpdateLogging() I need answers to Q2.2.
>
>thanks,
>-marina
>
>Tom Ware wrote:
>
>
>>Hi Marina,
>>
>> I think we need to investigate solving the logging issue without moving
>>the whole updateServerSession method.
>>
>> The reason I say that is that updateServerSession() occurs in the
>>deploy method by design. We intentionally do not create a server
>>session until deploy is called. (Notice deploy is not called until a
>>ServerSession is required by the EntityManagerFactory) Update
>>ServerSession provides a number of important updates that should only be
>>done when the session is created.
>>
>> Is it possible to make achange in the initOrUpdateLogging() call to
>>first change the default log to the appropriate log prior to all other
>>changes? There is an abstractSessionLog.setLog() method that can be
>>used to set the default session log. A call to that method should
>>result in logging going to the specified log.
>>
>> Here are some answers to a couple of your questions:
>>
>>1. Protected Methods - We realize that in traditional applications only
>>methods that are actually used in a protected manner should be set as
>>protected. Since TopLink is a library that people may want to extend,
>>we provide protected (rather than private) methods as a way of allowing
>>them to do that.
>>2. getServerSession()- It looks like this method can be removed. The
>>ServerSession aquisition logic has been moved to EntityManagerFactoryImpl
>>
>>-Tom
>>
>>Marina Vatkina wrote:
>>
>>
>>
>>>Team,
>>>
>>>The following solution solves the logger integration problem (all
>>>changes are
>>>made to EntityManagerSetupImpl):
>>>
>>>1. Modify updateServerPlatform() and move the lines
>>>
>>>
>>>if(!session.getLogin().shouldUseExternalTransactionController()) {
>>> serverPlatform.disableJTA();
>>> }
>>>to be after updateLogins(m) as there was a comment
>>>"update ServerPlatform must be called after updateLogins - to set
>>>correct useJTA flag"
>>>
>>>2. Add updateServerPlatform(predeployProperties) after the second call
>>>to initOrUpdateLogging() in predeploy.
>>>Q2.1: can it be done earlier that that?
>>>Q2.2: Why is this method executed at least 4 times (twice in predeploy()
>>>plus twice via updateServerSession(), which comments say can happen
>>>more than once)?
>>>
>>>3. I left call to updateServerPlatform() (modified as in #1) from
>>>updateServerSession() as I don't fully understand the reason of
>>>calling it from
>>>there.
>>>Q3.1: Should I just remove it?
>>>
>>>Other questions:
>>>a) Why do we have protected methods in this class that are not called
>>>by any
>>>other class?
>>>
>>>b) What is the purpose of method getServerSession(Map) in
>>>EntityManagerSetupImpl
>>>that is not called by any other code? Can I remove it (I commented it
>>>out and
>>>clean compile had no complains)?
>>>
>>>The changed class is attached (with commented out
>>>getServerSession(Map) method).
>>>
>>>thanks,
>>>-marina
>>>
>>>
>>>
>>>
--
Tom Ware
Principal Software Engineer
Oracle Canada Inc.
Direct: (613) 783-4598
Email: tom.ware_at_oracle.com