On 26 Dec 2011, at 09:50, S B <sbl...@gmail.com> wrote: > On Sat, Dec 24, 2011 at 6:29 PM, Pid <p...@pidster.com> wrote: > >> On 23/12/2011 04:57, S B wrote: >>> On Thu, Dec 22, 2011 at 8:49 PM, Pid <p...@pidster.com> wrote: >>> >>>> On 22/12/2011 10:34, Konstantin Kolinko wrote: >>>>> 2011/12/20 S B <sbl...@gmail.com>: >>>>>> Hi, >>>>>> >>>>>> I created and deployed an MBean in my tomcat. It uses datasource to >>>> connect >>>>>> to DB. >>>>>> >>>>>> My questions is: >>>>>> >>>>>> When I create InitialContext() inside MBean's constructor and pass the >>>>>> envContext to DBManager class to lookup datasource it works fine. >>>> However >>>>>> when I create InitialContext() in DBManager class, it fails. >>>>> >>>>> IIRC what InitialContext() sees as its environment highly depends on >>>>> what classloader is active. That is TCCL = >>>>> Thread.getContextClassLoader(). >>>>> >>>>> So while it is run from within web application your TCCL = your >>>>> webapp's classloader. >>>>> >>>>> When it is invoked from jconsole it might be a separate Thread, not >>>>> related to your web application. >>>> >>>> >>>> Like he ^^^ said. :) >>>> >>>> >>>> p >>>> >>>> >>>> -- >>>> >>>> [key:62590808] >>>> >>>> >>> Hi Pid/Konstantin, >>> >>> yes you are right. I just verified it. When it is invoked from jconsole, >>> the classloader is: sun.misc.Launcher$AppClassLoader@61e63e3d >>> and when it is run within a web application the clasloader is >>> WebAppClassloader. >>> >>> So, how can I force it to use webapp classloader during new >>> InitialContext() while invoking from jconsole >>> One possible way is to reuse the initialContext created during server >>> startup. (pass it as param during invocation from jconsole). >>> >>> Is there a smarter way ?? >> >> I am a bit concerned about how you are registering the bean inside the >> bean's own constructor. I am not clear on how you are subsequently >> unregistering that bean, before the reloading operation - and I am not >> at all clear what the purpose of reloading is anyway. >> >> Is there a reason that the MBean itself needs to be recreated? >> >> Bear in mind that you are attempting to re-initialise the MBean, while >> you are still using it. This does not seem like a good idea to me. >> >> I would suggest that you either have a separate Manager MBean that does >> the reloading, or just have the reload method call the actual code on >> the DB, without re-initialising the bean. >> >> >> p >> >> >> -- >> >> [key:62590808] >> >> > Hi, > > un-registering of mbean doesn't happen until servlet's destroy method is > called. > Actually, registration of bean happen only once, ie during server startup. > This time mbean's constructor is called and it is registered with MBean > server. > (I was wrong earlier when I said, constructor is called on each invocation > of reload() method from jconsole. sorry about that. i was lill confused.) > > MBean is never re-created. It is created only once and registered only once. > > actual flow is: > > click reload() on jconsole gui. > *it causes constructor of MBeanImpl to run. (verified from logs.)* -- *Wrong. > pls disregard this statement.* > calls reload() defined in MBeanImpl. > calls DBManager.reload() > inside DBManager.reload() it fails at InitialContext initContext = new > InitialContext(); > the exception is - javax.naming.NoInitialContextException: Cannot > instantiate class: org.apache.naming.java.javaURLContextFactory [Root > exception is java.lang.ClassNotFoundException: > org.apache.naming.java.javaURLContextFactory]
OK, but what is the purpose of DBManager.reload()? p --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
