Hi Tom,
I think (I don't know why I didn't notice it right away) that there is
some disconnect here ;).
I didn't change updateServerSession. I added a call to updateServerPlatform
from predeploy() *and* modified that (updateServerPlatform) method not to
set JTA flag. Setting JTA flag is called explicitly from updateServerSession
after updateLogins() call.
Now, all updateServerPlatform is doing, is loading the class, then sets
session.setServerPlatform(serverPlatform), and sets the log. I can't set
the log without loading the platform class. Now,
a) how harmful is session.setServerPlatform(serverPlatform) call?
b) can server platform change in the middle of the run? If yes, what would
it mean? If no, then I can make another change, and completely remove call
to this method from updateServerSession.
What is wrong with this solution? (Apart that I'm still not sure we are not
wasting time on multiple calls to initOrUpdateLogging() - but that can wait).
thanks,
-marina
Tom Ware wrote:
> 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
>>>>
>>>>
>>>>
>
>