Marina,
I recognoized the problem before, but even before I apply this patch log
messages were printed like that (in latest cvs workspace). So I didn't think
it's a side effect of this patch.
[#|2006-09-06T12:11:
11.231+0900|FINER|sun-appserver-ee9.1|oracle.toplink.essentials.defaultsessionname.connection|_ThreadID=15
;_ThreadName=httpWorkerThread-8080-0;ClassName=null;MethodName=null;_RequestID=a3b93262-642f-4be8-845d-afb0ba923494;|client_acquired|#]
[#|2006-09-06T12:11:
11.231+0900|FINER|sun-appserver-ee9.1|oracle.toplink.essentials.defaultsessionname.transaction|_ThreadID=15
;_ThreadName=httpWorkerThread-8080-0;ClassName=null;MethodName=null;STATUS_ACTIVE;_RequestID=a3b93262-642f-4be8-845d-afb0ba923494;|TX_bind|#]
[#|2006-09-06T12:11:
11.231+0900|FINER|sun-appserver-ee9.1|oracle.toplink.essentials.defaultsessionname.transaction|_ThreadID=15
;_ThreadName=httpWorkerThread-8080-0;ClassName=null;MethodName=null;STATUS_ACTIVE;_RequestID=a3b93262-642f-4be8-845d-afb0ba923494;|TX_bind|#]
[#|2006-09-06T12:11:
11.231+0900|FINEST|sun-appserver-ee9.1|oracle.toplink.essentials.defaultsessionname.transaction|_ThreadID=15;_ThreadName=httpWorkerThread-8080-0;ClassName=null;MethodName=null;Product[productId=5,
price=22.0, description=Chrome
Fish];_RequestID=a3b93262-642f-4be8-845d-afb0ba923494;|merge_clone_with_references|#]
When I debug JavaLog.internalLog(), SessionLogEntry's shouldTranslate is
true, so ResourceBundle is set properly.
if (entry.shouldTranslate()) {
String bundleName;
ResourceBundle resourceBundle;
if (entry.getLevel() > FINE) {
bundleName = LOGGING_LOCALIZATION_STRING;
resourceBundle = new LoggingLocalizationResource();
} else {
bundleName = TRACE_LOCALIZATION_STRING;
resourceBundle = new TraceLocalizationResource();
}
lr.setResourceBundleName(bundleName);
lr.setResourceBundle(resourceBundle);
}
I don't know why this resource bundle is not used in formatting in
GlassFish.
When I use JavaLog by configuring my JavaLoggerServerPlatform[1] in Java SE,
the messages are translated correctly. In this case JRE default
ConsoleHandler and SimpleFormatter are used.
Sep 7, 2006 9:24:45 AM
oracle.toplink.essentials.defaultsessionname.connection
FINER: client acquired
Sep 7, 2006 9:24:45 AM oracle.toplink.essentials.defaultsessionname.query
FINEST: Execute query DoesExistQuery()
Sep 7, 2006 9:24:45 AM
oracle.toplink.essentials.defaultsessionname.transaction
FINEST: register_new_for_persist
Sep 7, 2006 9:24:45 AM
oracle.toplink.essentials.defaultsessionname.transaction
FINER: begin transaction
Sep 7, 2006 9:24:45 AM oracle.toplink.essentials.defaultsessionname.query
FINEST: Execute query DataModifyQuery()
Sep 7, 2006 9:24:45 AM oracle.toplink.essentials.defaultsessionname.sql
FINE: UPDATE SEQUENCE SET SEQ_COUNT = SEQ_COUNT + ? WHERE SEQ_NAME = ?
bind => [50, SEQ_GEN_TABLE]
Do you know which Formatter is used in GlassFish?
[1]
http://weblogs.java.net/blog/guruwons/archive/2006/09/toplink_essenti.html
- Wonseok
On 9/7/06, Marina Vatkina <Marina.Vatkina_at_sun.com> 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
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>
> >> >>>
> >>
> >>
> >>
>