Hi Marina,
How do I recreate this issue?
-Tom
Marina Vatkina wrote:
>Tom, Wonseok,
>
>Yes, it solves the 1st part of problem (and I like the solution), but
>unfortunately there is more to it (unless it happens only in my environment):
>the logging when integrated, can't resolve message keys and the log messages
>are printed as a list of arguments, and the keys instead.
>
>Wonseok, do you see the same problem?
>
>Tom, any idea?
>
>thanks,
>-marina
>
>Tom Ware wrote:
>
>
>>Hi Wonseok,
>>
>> Thanks for taking a deeper look at this issue. This solution seems
>>good to me. It appears to resolve all the issues.
>> Marina, what do you think?
>>
>>-Tom
>>
>>Wonseok Kim wrote:
>>
>>
>>
>>>Hi Tom, Marina
>>>
>>>I'm investigating this issue too. Tom's patch has another problem
>>>besides Marina's comment.
>>>
>>>session is not initialized before getServerPlatform(). So the
>>>serverPlatform is created with null session. This causes following
>>>exception when creating EntityManager(in ServerSession's deploy phase).
>>>
>>>-----
>>>Caused by: java.lang.NullPointerException
>>> at
>>>oracle.toplink.essentials.platform.server.ServerPlatformBase.initializeExternalTransactio
>>>nController(ServerPlatformBase.java:213)
>>> at
>>>oracle.toplink.essentials.internal.sessions.DatabaseSessionImpl.preConnectDatasource(Data
>>>baseSessionImpl.java:664)
>>> at
>>>oracle.toplink.essentials.internal.sessions.DatabaseSessionImpl.loginAndDetectDatasource(
>>>DatabaseSessionImpl.java:534)
>>> at
>>>oracle.toplink.essentials.ejb.cmp3.EntityManagerFactoryProvider.login(EntityManagerFactor
>>>yProvider.java:180)
>>> at
>>>oracle.toplink.essentials.internal.ejb.cmp3.EntityManagerSetupImpl.deploy(EntityManagerSe
>>>tupImpl.java:230)
>>> at
>>>oracle.toplink.essentials.internal.ejb.cmp3.base.EntityManagerFactoryImpl.getServerSessio
>>>n(EntityManagerFactoryImpl.java:78)
>>> at
>>>oracle.toplink.essentials.internal.ejb.cmp3.base.EntityManagerFactoryImpl.createEntityMan
>>>agerImpl(EntityManagerFactoryImpl.java:113)
>>> at
>>>oracle.toplink.essentials.internal.ejb.cmp3.EntityManagerFactoryImpl.createEntityManager(
>>>EntityManagerFactoryImpl.java:84)
>>> at
>>>com.sun.enterprise.util.EntityManagerWrapper._getDelegate(EntityManagerWrapper.java:166)
>>>
>>> at com.sun.enterprise.util.EntityManagerWrapper.createQuery
>>>(EntityManagerWrapper.java:271)
>>> at
>>>hellojpa.ProductManagerBean.removeAllProducts(ProductManagerBean.java:58)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at
>>>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>
>>> at
>>>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>
>>> at java.lang.reflect.Method.invoke (Method.java:585)
>>> at
>>>com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.j
>>>ava:1050)
>>> at
>>>com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:165)
>>> at
>>>com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2788)
>>>
>>> at
>>>com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:3870)
>>> at
>>>com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke
>>>(EJBLocalObjectInvocationHan dler.java:184)
>>> ... 31 more
>>>-----
>>>
>>>I have a solution for this problem (including Marina's comment). May I
>>>provide a patch for this?
>>>
>>>See below diff (from Tom's patch). I also attached full source and
>>>diff from cvs.
>>>In summary, this do two things.
>>>
>>>1. translateOldProperties() is done before getServerPlatform() without
>>>logging. logging is done separately by another new method
>>>warnOldProperties() after logger is set.
>>>2. session is created before getServerPlatform()
>>>
>>>EntityManagerFactoryProvider.java 2006-09-06 10:16: 20.000000000 +0900
>>>***************
>>>*** 77,85 ****
>>> public static final String DEFAULT_DDL_GENERATION_MODE =
>>>DDL_SQL_SCRIPT_GENERATION;
>>> // TEMPORARY - WILL BE REMOVED.
>>>! // The two variables below are used to warn users about
>>>deprecated property name and suggest the valid name.
>>> // TEMPORARY the old property names will be translated to the
>>>new ones and processed.
>>>- public static final String DEPRECATED_TARGET_SERVER =
>>>"toplink.server.platform.class.name
>>><http://toplink.server.platform.class.name>";
>>> protected static final String oldPropertyNames[][] = {
>>> {TopLinkProperties.JDBC_WRITE_CONNECTIONS_MAX,
>>>"toplink.max-write-connections"},
>>> {TopLinkProperties.JDBC_WRITE_CONNECTIONS_MIN , "to
>>>plink.min-write-connections"},
>>>--- 77,84 ----
>>> public static final String DEFAULT_DDL_GENERATION_MODE =
>>>DDL_SQL_SCRIPT_GENERATION;
>>> // TEMPORARY - WILL BE REMOVED.
>>>! // Used to warn users about deprecated property name and suggest
>>>the valid name.
>>> // TEMPORARY the old property names will be translated to the
>>>new ones and processed.
>>> protected static final String oldPropertyNames[][] = {
>>> {TopLinkProperties.JDBC_WRITE_CONNECTIONS_MAX, "
>>>toplink.max-write-connections"},
>>> {TopLinkProperties.JDBC_WRITE_CONNECTIONS_MIN,
>>>"toplink.min-write-connections"},
>>>***************
>>>*** 87,93 ****
>>> {TopLinkProperties.JDBC_READ_CONNECTIONS_MIN ,
>>>"toplink.min-read-connections"},
>>> {TopLinkProperties.JDBC_BIND_PARAMETERS,
>>>"toplink.bind-all-parameters"},
>>> {TopLinkProperties.TARGET_DATABASE, "
>>>toplink.platform.class.name <http://toplink.platform.class.name>"},
>>>! {TopLinkProperties.TARGET_SERVER, DEPRECATED_TARGET_SERVER},
>>> {TopLinkProperties.CACHE_SIZE_DEFAULT, "toplink.cache.defau
>>>lt-size"}
>>> };
>>>
>>>--- 86,92 ----
>>> {TopLinkProperties.JDBC_READ_CONNECTIONS_MIN,
>>>"toplink.min-read-connections"},
>>> {TopLinkProperties.JDBC_BIND_PARAMETERS,
>>>"toplink.bind-all-parameters"},
>>> {TopLinkProperties.TARGET_DATABASE,
>>>"toplink.platform.class.name <http://toplink.platform.class.name>"},
>>>! {TopLinkProperties.TARGET_SERVER, "
>>>toplink.server.platform.class.name
>>><http://toplink.server.platform.class.name>"},
>>> {TopLinkProperties.CACHE_SIZE_DEFAULT,
>>>"toplink.cache.default-size"}
>>> };
>>>
>>>***************
>>>*** 370,378 ****
>>> for(int i=0; i < oldPropertyNames.length; i++) {
>>> Object value =
>>>getConfigPropertyAsString(oldPropertyNames[i][1], m);
>>> if(value != null) {
>>>! session.log(SessionLog.CONFIG,
>>>SessionLog.TRANSACTION , "deprecated_property", oldPropertyNames[i]);
>>> m.put(oldPropertyNames[i][0], value);
>>> }
>>> }
>>> }
>>> }
>>>--- 369,387 ----
>>> for(int i=0; i < oldPropertyNames.length; i++) {
>>> Object value = getConfigPropertyAsString(oldProper
>>>tyNames[i][1], m);
>>> if(value != null) {
>>>! if(session != null)
>>>! session.log(SessionLog.CONFIG,
>>>SessionLog.TRANSACTION, "deprecated_property", oldPropertyNames[i]);
>>> m.put(oldPropertyNames[i][0], value);
>>> }
>>> }
>>> }
>>>+
>>>+ public static void warnOldProperties(Map m, AbstractSession
>>>session) {
>>>+ for(int i=0; i < oldPropertyNames.length; i++) {
>>>+ Object value = m.get(oldPropertyNames[i][1]);
>>>+ if(value != null) {
>>>+ session.log(SessionLog.CONFIG,
>>>SessionLog.TRANSACTION, "deprecated_property", oldPropertyNames[i]);
>>>+ }
>>>+ }
>>>+ }
>>> }
>>>
>>>EntityManagerSetupImpl.java 2006-09-06 13:35:28.000000000 +0900
>>>***************
>>>*** 311,323 ****
>>> protected ServerPlatform getServerPlatform(Map m) {
>>> String serverPlatformClassName =
>>>(String)PropertiesHandler.getPropertyValueLogDebug(TopLinkProperties.TARGET_SERVER
>>>, m, session);
>>> if (serverPlatformClassName == null) {
>>>! // TEMPORARY: Check the old platform name. This will be
>>>removed when the deprecated properties are actually removed
>>>! // Note: We are not printing config message here. We
>>>are relying on the warning occuring later in the code path where the
>>>! // properties are translated.
>>>! serverPlatformClassName =
>>>(String)PropertiesHandler.getPropertyValueLog
>>>Debug(EntityManagerFactoryProvider.DEPRECATED_TARGET_SERVER, m, session);
>>>! if (serverPlatformClassName == null) {
>>>! return null;
>>>! }
>>> }
>>>
>>> ServerPlatform serverPlatform = null;
>>>--- 311,317 ----
>>> protected ServerPlatform getServerPlatform(Map m) {
>>> String serverPlatformClassName =
>>>(String)PropertiesHandler.getPropertyValueLogDebug(
>>>TopLinkProperties.TARGET_SERVER, m, session);
>>> if (serverPlatformClassName == null) {
>>>! return null;
>>> }
>>>
>>> ServerPlatform serverPlatform = null;
>>>***************
>>>*** 458,481 ****
>>> ClassLoader privateClassLoader =
>>>persistenceUnitInfo.getNewTempClassLoader();
>>> predeployProperties =
>>>EntityManagerFactoryProvider.mergeMaps(extendedProperties,
>>>persistenceUnitInfo.getProperties());
>>>
>>>! ServerPlatform serverPlatform =
>>>getServerPlatform(predeployProperties);
>>> if (serverPlatform != null){
>>> AbstractSessionLog.setLog (serverPlatform.get
>>>ServerLog());
>>> }
>>>! //Bug5389828. Update the logging settings for the
>>>singleton logger.
>>> initOrUpdateLogging(true, predeployProperties,
>>>AbstractSessionLog.getLog());
>>> // build a list of entities the persistence unit represented
>>>by this EntityManagerSetupImpl will use
>>> Collection entities = buildEntityList(persistenceUnitInfo,
>>>privateClassLoader);
>>>
>>>- session = new ServerSession(new Project(new DatabaseLogin()));
>>>-
>>> if (serverPlatform != null){
>>> session.setSessionLog(serverPlatform.getServerLog());
>>> session.setServerPlatform(serverPlatform);
>>> }
>>>
>>>!
>>>EntityManagerFactoryProvider.translateOldProperties(predeployProperties,
>>>session);
>>> initOrUpdateLogging(true, predeployProperties,
>>>session.getSessionLog());
>>> session.getPlatform().setConversionManager(new
>>>EJB30ConversionManager());
>>> --- 452,480 ----
>>> ClassLoader privateClassLoader =
>>>persistenceUnitInfo.getNewTempClass
>>>Loader();
>>> predeployProperties =
>>>EntityManagerFactoryProvider.mergeMaps(extendedProperties,
>>>persistenceUnitInfo.getProperties ());
>>>
>>>! // translate old properties
>>>! // this should be done before using properties (i.e.
>>>ServerPlatform)
>>>!
>>>EntityManagerFactoryProvider.translateOldProperties(predeployProperties,
>>>null);
>>>!
>>>! // create server session (it should be done before
>>>initializing ServerPlatform)
>>>! session = new ServerSession(new Project(new DatabaseLogin()));
>>>!
>>>! ServerPlatform serverPlatform =
>>>getServerPlatform(predeployProperties);
>>> if (serverPlatform != null){
>>> AbstractSessionLog.setLog (serverPlatform.getServerLog());
>>> }
>>>!
>>> //Bug5389828. Update the logging settings for the singleton
>>>logger.
>>> initOrUpdateLogging(true, predeployProperties,
>>>AbstractSessionLog.getLog());
>>> // build a list of entities the persistence unit represented
>>>by this EntityManagerSetupImpl will use
>>> Collection
>>>entities = buildEntityList(persistenceUnitInfo, privateClassLoader);
>>>
>>> if (serverPlatform != null){
>>> session.setSessionLog(serverPlatform.getServerLog());
>>> session.setServerPlatform(serverPlatform);
>>> }
>>>
>>>!
>>>EntityManagerFactoryProvider.warnOldProperties(predeployProperties,
>>>session);
>>> initOrUpdateLogging(true, predeployProperties,
>>>session.getSessionLog());
>>> session.getPlatform().setConversionManager(new
>>>EJB30ConversionManager());
>>> Thanks
>>>- Wonseok
>>>I
>>>
>>>On 9/6/06, *Marina Vatkina* <Marina.Vatkina_at_sun.com
>>><mailto:Marina.Vatkina_at_sun.com>> wrote:
>>>
>>> Hi Tom,
>>>
>>> No, this doesn't work as PropertiesHandler doesn't know about the old
>>> (deprecated) name and returns null as for unknown property. Should
>>> I now
>>> add the old name to the PropertiesHandler as well? This seems like
>>> a wrong
>>> idea for handling something that you want to deprecate...
>>>
>>> thanks,
>>> -marina
>>>
>>> Tom Ware wrote:
>>> > Hi Marina,
>>> >
>>> > The initial bug was that the logging that occurs in
>>> > buildEntityList(persistenceUnitInfo, privateClassLoader) was not
>>> > affected by the logging settings.
>>> >
>>> > I am attaching some suggested changes - most are based on your
>>> initial
>>> > fix. Admittedly, there are a couple of pieces that are somewhat
>>> hacky.
>>> >
>>> > 1. The way we deal with the fact that ServerPlatform could come
>>> from one
>>> > of the deprecated properties
>>> > 2. Only the non-deprecated properties will affect the logging that
>>> > occurs in buildEntityListt(persistenceUnitInfo, privateClassLoader)
>>> >
>>> > These changes are just a suggestion and totally open to alternate
>>> > changes, and I have not done much testing, but figured I pass on my
>>> > thoughts.
>>> >
>>> > -Tom
>>> >
>>> >
>>> > Marina Vatkina wrote:
>>> >
>>> >> Hi Tom,
>>> >>
>>> >> Tom Ware wrote:
>>> >>
>>> >>
>>> >>> Hi Marina,
>>> >>>
>>> >>> I think there still may be a couple of issues:
>>> >>>
>>> >>> 1. Doesn't updateServerPlatform() replace the logger with the
>>> server
>>> >>> one?
>>> >>
>>> >>
>>> >> Yes.
>>> >>
>>> >> If so, don't we lose the settings from the initOfUpdateLogging()
>>> >>
>>> >>
>>> >>> calls that occur before update updateServerPlatform()?
>>> >>>
>>> >>
>>> >>
>>> >> We propagate the setting in setNewLog:
>>> >>
>>> >> newLog.setLevel(session.getSessionLog().getLevel());
>>> >>
>>> >> newLog.setShouldPrintDate
>>> (session.getSessionLog().shouldPrintDate());
>>> >>
>>> >>
>>>
>>>newLog.setShouldPrintThread(session.getSessionLog().shouldPrintThread());
>>> >>
>>> >>
>>>
>>>newLog.setShouldPrintSession(session.getSessionLog().shouldPrintSession());
>>>
>>>
>>> >>
>>> >>
>>> >>
>>>
>>>newLog.setShouldLogExceptionStackTrace(session.getSessionLog().shouldLogExceptionStackTrace());
>>>
>>> >>
>>> >>
>>> >> session.setSessionLog(newLog);
>>> >>
>>> >>
>>> >> But(!) we are doing it anyway even now, just a bit later.
>>> >>
>>> >> We cannot do
>>> >>
>>> >>
>>> >>> that because it will reopen the bug that initially causes us to
>>> >>> change where our logging settings are set.
>>> >>>
>>> >>
>>> >>
>>> >> What was that bug about?
>>> >>
>>> >>
>>> >>
>>> >>> 2. In my mind, this bug is not fixed until all logging
>>> messages go to
>>> >>> the correct place. If the default log is not set on
>>> >>> AbstractSessionLog, that is not done. Can we not, make a call to
>>> >>> AbstractSessionLog.setLog() with the correct log?
>>> >>>
>>> >>
>>> >>
>>> >> Here is the problem:
>>> >> EntityManagerFactoryProvider.translateOldProperties needs a
>>> logger, and
>>> >> we can't get the correct server platform without prior
>>> translation (blame
>>> >> those who decided to invent new names :().
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>> As a result of these two concerns, I think there is some work
>>> to do.
>>> >>> Perhaps a solution could be to break up the
>>> updateServerPlatform in
>>> >>> to two methods. 1 - get the serverPlatform instance, 2 - set
>>> it on
>>> >>> the session. If you do that, the first method could be called
>>> before
>>> >>> the first initOrUpdateLogging call, and the instance derived
>>> from it
>>> >>> could to set the correct logger both on the session and on the
>>> >>> AbstractSesssionLog at the appropriate time.
>>> >>>
>>> >>
>>> >>
>>> >> OK. Let's discuss it further.
>>> >>
>>> >>
>>> >>> -Tom
>>> >>>
>>> >>> Marina Vatkina wrote:
>>> >>>
>>> >>>
>>> >>>
>>> >>>> Hi Tom,
>>> >>>>
>>> >>>> Tom Ware wrote:
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>> Hi Marina,
>>> >>>>>
>>> >>>>> First of all, sorry for the confusion.
>>> >>>>>
>>> >>>>>
>>> >>>>
>>> >>>> No problem. Good think I asked ;)
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>> Now a question: Are we also adding some code that sets the
>>> default
>>> >>>>> log? I am surprised I do not see any code that influences
>>> >>>>> AbstractSessionLog's default log. Don't we need to logging
>>>from
>>> >>>>> AbstractSessionLog.getLog () to be logged to the correct place?
>>> >>>>>
>>> >>>>>
>>> >>>>
>>> >>>> Yes, I'd like to understand the whole initOrUpdateLogging()
>>>story
>>> >>>> myself.
>>> >>>>
>>> >>>> Do you see a problem if I file a separate issue for that and
>>> check
>>> >>>> in my changes now?
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>> Aside from that, I think moving the updateServerPlatform
>>> call and
>>> >>>>> chaning the location of the JTA initialization will be fine.
>>> >>>>>
>>> >>>>> ServerPlatform should not change in the middle of a run, so
>>> I think
>>> >>>>> removing the call to this method in updateServerSession
>>> should be
>>> >>>>> fine.
>>> >>>>>
>>> >>>>>
>>> >>>>
>>> >>>> OK.
>>> >>>>
>>> >>>> thanks,
>>> >>>> -marina
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>> -Tom
>>> >>>>>
>>> >>>>>
>>> >>>>> Marina Vatkina wrote:
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>> 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
>>> >>>>>>>>>>
>>> >>>>>>>>>>
>>> >>>>>>>>>>
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>
>>> >>>
>>>
>>>
>>>
>>>
>>>