All right, i spent a lot of time in this and now the only thing that comes as a
clean solution for this in my mind is to get rid of the static block in
TCPropertisImpl and accessing the TCProperties by having a singleton object.
I'll have to dig around the code to actually figure out how to do it, but as it
would be having a big impact on the existing code so i thought of having
people's opinion on this.
So what do you guys think of this? Any suggestions/comments/observations would
be more than welcomed :)
raghu
----- Original Message -----
From: "Geert Bevin" <[EMAIL PROTECTED]>
To: "Raghvendra Singh" <[EMAIL PROTECTED]>
Cc: "Saravanan Subbiah" <[EMAIL PROTECTED]>, "dev-internal" <[EMAIL PROTECTED]>
Sent: Wednesday, June 11, 2008 12:28:03 AM GMT -08:00 US/Canada Pacific
Subject: Re: [Dev-internal] initialization of TCPropertiesImpl
BootJarTool is where you wanna start looking, more specifically the
generateJar method.
Hope this helps,
Geert
On 11 Jun 2008, at 09:07, Raghvendra Singh wrote:
> I'll try the first solution out, but need a little heads up on how
> to do it, i mean how do i add TCPropertiesImpl to the boot jar?
>
> ----- Original Message -----
> From: "Geert Bevin" <[EMAIL PROTECTED]>
> To: "Raghvendra Singh" <[EMAIL PROTECTED]>
> Cc: "Saravanan Subbiah" <[EMAIL PROTECTED]>, "dev-
> internal" <[EMAIL PROTECTED]>
> Sent: Tuesday, June 10, 2008 11:55:02 PM GMT -08:00 US/Canada Pacific
> Subject: Re: [Dev-internal] initialization of TCPropertiesImpl
>
>
> On 11 Jun 2008, at 20:11, Raghvendra Singh wrote:
>
>> So till now there are two possible solutions
>>
>> 1. make TCPropertiesImpl the part of boot jar.
>
> Well, there's maybe a problem with that, if the TCPropertiesImpl are
> needed while generating the bootjar there might be some recursive
> dependency. Not sure, this needs some investigation.
>
>> 2. Get the TCProperties via jmx.
>>
>> Is there any more solutions in you guys mind...
>
> You could play around with classloader magic to try to retrieve the
> classloader that loading TCPropertiesImpl (ie. get access to the
> tcLoader field of ClassProcessorHelper, but that feels quite icky to
> me ;-)
>
>> raghu
>>
>> Geert Bevin wrote:
>>> This stacktrace is from the bootjartool which is used to create the
>>> bootjar. Since you now made the L1 config manager depend on
>>> TCProperties, this is loaded when the bootjartool is used. The
>>> script dso-java executes this once, before executing the main
>>> program. These are 2 seperate java processes.
>>>
>>> TCProperties is in the bootjar, but TCPropertiesImpl isn't, so that
>>> might be the reason. Also the dedicated URLClassLoader instance
>>> that is created in ClassProcessorHelper has no parent classloader
>>> at all, so it really is isolated.
>>>
>>> On 11 Jun 2008, at 19:49, Raghvendra Singh wrote:
>>>
>>>> Following is the stack trace where TCProperties gets initialized
>>>> in the
>>>> boot jar.
>>>>
>>>> at
>>>> com.tc.properties.TCPropertiesImpl.<clinit>(TCPropertiesImpl.java:
>>>> 56)
>>>> at
>>>> com
>>>> .tc
>>>> .config
>>>> .schema
>>>> .setup
>>>> .StandardL1TVSConfigurationSetupManager
>>>> .overwriteTcPropertiesFromConfig
>>>> (StandardL1TVSConfigurationSetupManager.java:103)
>>>> at
>>>> com
>>>> .tc
>>>> .config
>>>> .schema
>>>> .setup
>>>> .StandardL1TVSConfigurationSetupManager
>>>> .<init>(StandardL1TVSConfigurationSetupManager.java:69)
>>>> at
>>>> com
>>>> .tc
>>>> .config
>>>> .schema
>>>> .setup
>>>> .StandardTVSConfigurationSetupManagerFactory
>>>> .createL1TVSConfigurationSetupManager
>>>> (StandardTVSConfigurationSetupManagerFactory.java:185)
>>>> at com.tc.object.tools.BootJarTool.main(BootJarTool.java:2496)
>>>>
>>>> The interesting thing is that the class loaders for all the stack
>>>> traces
>>>> i sent (this one and the two i sent in my earlier mail) are
>>>> different.
>>>> Any idea why is that happening.
>>>>
>>>> raghu
>>>>
>>>> Raghvendra Singh wrote:
>>>>> Actually it does stay in boot jar, i have seen stack traces which
>>>>> points
>>>>> that it gets initialized in the bootjar itself. The question is
>>>>> that if
>>>>> it stays in bootjar then why it gets initialized more number of
>>>>> times,
>>>>> once while starting the L1 and another in the application itself?
>>>>>
>>>>> Saravanan Subbiah wrote:
>>>>>
>>>>>> I thought TCProperties stayed in the bootjar ? Well if it didnt,
>>>>>> adding it will load in system classloader and will only be
>>>>>> loaded once.
>>>>>>
>>>>>> Geert Bevin wrote:
>>>>>>
>>>>>>> Hi Raghu,
>>>>>>>
>>>>>>> Terracotta creates its own instance of URLClassLoader and sets
>>>>>>> up
>>>>>>> the classpath for the jars that make up the Terracotta
>>>>>>> client. I
>>>>>>> think it does that to cleanly isolate any of the classes that
>>>>>>> are
>>>>>>> used inside the L1 logic from the classes that are used in the
>>>>>>> real
>>>>>>> application. Without doing that, there could easily be clashes
>>>>>>> when
>>>>>>> an application uses the same libraries as we do. See the
>>>>>>> tcLoader
>>>>>>> field in ClassProcessorHelper.
>>>>>>> (can someone please confirm all of this, I'm just relaying info
>>>>>>> that
>>>>>>> I deducted over time)
>>>>>>>
>>>>>>> So, your application will actually load its own instance of
>>>>>>> TCPropertiesImpl. As for testing it, I can't immediately think
>>>>>>> of an
>>>>>>> easy way to do so. My guess would be that we should maybe allow
>>>>>>> the
>>>>>>> TCProperties to be accessed through JMX (which doesn't seem to
>>>>>>> be
>>>>>>> the case currently). Then you could retrieve the TCProperties
>>>>>>> that
>>>>>>> are in use from the client app.
>>>>>>>
>>>>>>> Hope this helps,
>>>>>>>
>>>>>>> Geert
>>>>>>>
>>>>>>> On 10 Jun 2008, at 14:35, Raghvendra Singh wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Hi All
>>>>>>>>
>>>>>>>> I am trying to write a system test for a new feature in which
>>>>>>>> if there
>>>>>>>> is any tc-property provided in tc-config file then it would get
>>>>>>>> overwritten for both L1 and L2. The way i have implemented is
>>>>>>>> it
>>>>>>>> that in
>>>>>>>> constructor of StandardL1TVSConfigurationSetupManager and
>>>>>>>> StandardL2TVSConfigurationSetupManager we instantiate
>>>>>>>> TCPropertiesImpl.INSTANCE by calling
>>>>>>>> TCPropertiesImpl.getProperties()
>>>>>>>> and then i overwrite the properties that i get from tc-config.
>>>>>>>> This
>>>>>>>> step
>>>>>>>> works fine. The call stack for this is as below
>>>>>>>>
>>>>>>>> at
>>>>>>>> com
>>>>>>>> .tc
>>>>>>>> .properties.TCPropertiesImpl.<clinit>(TCPropertiesImpl.java:
>>>>>>>> 56)
>>>>>>>> at
>>>>>>>> com .tc .config .schema .setup
>>>>>>>> .StandardL1TVSConfigurationSetupManager
>>>>>>>> .overwriteTcPropertiesFromConfig
>>>>>>>> (StandardL1TVSConfigurationSetupManager.java:103)
>>>>>>>> at
>>>>>>>> com .tc .config .schema .setup
>>>>>>>> .StandardL1TVSConfigurationSetupManager
>>>>>>>> .<init>(StandardL1TVSConfigurationSetupManager.java:69)
>>>>>>>> at
>>>>>>>> com .tc .config .schema .setup
>>>>>>>> .StandardTVSConfigurationSetupManagerFactory
>>>>>>>> .createL1TVSConfigurationSetupManager
>>>>>>>> (StandardTVSConfigurationSetupManagerFactory.java:197)
>>>>>>>> at
>>>>>>>> com .tc .object .bytecode
>>>>>>>> .hook
>>>>>>>> .impl.DSOContextImpl.getGlobalConfigHelper(DSOContextImpl.java:
>>>>>>>> 194)
>>>>>>>> at
>>>>>>>> com .tc .object .bytecode
>>>>>>>> .hook
>>>>>>>> .impl.DSOContextImpl.createGlobalContext(DSOContextImpl.java:
>>>>>>>> 62)
>>>>>>>> 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 .tc .object .bytecode .hook .impl
>>>>>>>> .ClassProcessorHelper
>>>>>>>> .createGlobalContext(ClassProcessorHelper.java:
>>>>>>>> 635)
>>>>>>>> at
>>>>>>>> com .tc .object .bytecode
>>>>>>>> .hook.impl.ClassProcessorHelper.init(ClassProcessorHelper.java:
>>>>>>>> 423)
>>>>>>>> at
>>>>>>>> com .tc .object .bytecode .hook .impl .ClassProcessorHelper
>>>>>>>> .systemLoaderInitialized(ClassProcessorHelper.java:829)
>>>>>>>> at
>>>>>>>> java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:
>>>>>>>> 1382)
>>>>>>>> at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:
>>>>>>>> 1341)
>>>>>>>>
>>>>>>>>
>>>>>>>> Now to verify whether i the tc-properties have been
>>>>>>>> overwritten or
>>>>>>>> not,
>>>>>>>> i just try to get the tc-properties in the application's main
>>>>>>>> method and
>>>>>>>> check whether they are overwritten or not. Ideally i should get
>>>>>>>> TCPropertiesImpl.INSTANCE object directly without its getting
>>>>>>>> instantiated again as it has been initialized once before. But
>>>>>>>> the
>>>>>>>> surprising thing is that instead of getting the previously
>>>>>>>> initialized
>>>>>>>> TCPropertiesImpl.INSTANCE object, it instantiate the object
>>>>>>>> again by
>>>>>>>> calling the constructor of TCPropertiesImpl().
>>>>>>>>
>>>>>>>> Note that i am not running the test using the test framework,
>>>>>>>> instead it
>>>>>>>> is just a simple class which i execute using dso-java.sh. The
>>>>>>>> class
>>>>>>>> is below
>>>>>>>>
>>>>>>>> public static class Client {
>>>>>>>>
>>>>>>>> public static void main(String args[]) {
>>>>>>>> Client client = new Client();
>>>>>>>> client.execute();
>>>>>>>> synchronized (obj) {
>>>>>>>> obj.notify();
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>> private void execute() {
>>>>>>>> TCProperties tcProps = TCPropertiesImpl.getProperties();
>>>>>>>> System.out.println(TCPropertiesConsts.L1_CACHEMANAGER_ENABLED
>>>>>>>> + ":
>>>>>>>> " +
>>>>>>>> tcProps
>>>>>>>> .getProperty(TCPropertiesConsts.L1_CACHEMANAGER_ENABLED));
>>>>>>>>
>>>>>>>> System
>>>>>>>> .out.println(TCPropertiesConsts.L1_LOGGING_MAX_LOGFILE_SIZE
>>>>>>>> + ": " +
>>>>>>>> tcProps
>>>>>>>> .getProperty(TCPropertiesConsts.L1_LOGGING_MAX_LOGFILE_SIZE));
>>>>>>>> System.out.println("test passed");
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> The call stack for the initialization of
>>>>>>>> TCPropertiesImpl.INSTANCE
>>>>>>>> (which shouldn't have been initialized again at the first
>>>>>>>> place) is
>>>>>>>> below
>>>>>>>>
>>>>>>>> at
>>>>>>>> com
>>>>>>>> .tc.properties.TCPropertiesImpl.<clinit>(TCPropertiesImpl.java:
>>>>>>>> 56)
>>>>>>>> at
>>>>>>>> com.tctest.Client.execute(TcPropertiesOverWriteTestApp.java:94)
>>>>>>>> at com.tctest.Client.main(TcPropertiesOverWriteTestApp.java:87)
>>>>>>>>
>>>>>>>> I debugged it a little more and found out that the class
>>>>>>>> loaders for
>>>>>>>> both of the call stacks are different. This is what i fail to
>>>>>>>> understand. Why there are two class loaders for one process
>>>>>>>> that we
>>>>>>>> start using dso-java.sh. And if there is a reason behind it
>>>>>>>> then
>>>>>>>> how can
>>>>>>>> i be able to write this test. I would very much appreciate any
>>>>>>>> kind of
>>>>>>>> help here.
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> raghu
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Dev-internal mailing list
>>>>>>>> [EMAIL PROTECTED]
>>>>>>>> http://mail.terracottatech.com/mailman/listinfo/dev-internal
>>>>>>>>
>>>>>>> --
>>>>>>> Geert Bevin
>>>>>>> Terracotta - http://www.terracotta.org
>>>>>>> Uwyn "Use what you need" - http://uwyn.com
>>>>>>> RIFE Java application framework - http://rifers.org
>>>>>>> Music and words - http://gbevin.com
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Dev-internal mailing list
>>>>>>> [EMAIL PROTECTED]
>>>>>>> http://mail.terracottatech.com/mailman/listinfo/dev-internal
>>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Dev-internal mailing list
>>>>> [EMAIL PROTECTED]
>>>>> http://mail.terracottatech.com/mailman/listinfo/dev-internal
>>>>>
>>>>
>>>> _______________________________________________
>>>> Dev-internal mailing list
>>>> [EMAIL PROTECTED]
>>>> http://mail.terracottatech.com/mailman/listinfo/dev-internal
>>>
>>> --
>>> Geert Bevin
>>> Terracotta - http://www.terracotta.org
>>> Uwyn "Use what you need" - http://uwyn.com
>>> RIFE Java application framework - http://rifers.org
>>> Music and words - http://gbevin.com
>>>
>>
>
> --
> Geert Bevin
> Terracotta - http://www.terracotta.org
> Uwyn "Use what you need" - http://uwyn.com
> RIFE Java application framework - http://rifers.org
> Music and words - http://gbevin.com
>
--
Geert Bevin
Terracotta - http://www.terracotta.org
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com
_______________________________________________
tc-dev mailing list
tc-dev@lists.terracotta.org
http://lists.terracotta.org/mailman/listinfo/tc-dev
