Thanks for the link. I followed some of the further reading links and ended up at http://www.javageeks.com/Papers/ClassForName/ClassForName.pdf.
On page 14, I found the following: "Using Thread.getContextClassLoader relies on the Thread's context ClassLoader to be appropriately set. What if the Thread's current context ClassLoader isn't the one expected, but is instead set by an arbitrary third-party package (like RMI or JNDI)? In fact, there's not much you can do to prevent this...." I wonder if this is the problem since the SessionFactoryStub is sitting in JNDI. If that's the case, I bet the way to fix it is to pass the class loader of the EJB to the SessionFactoryStub before it opens a session. Sounds kind of ugly... It seems like we are trying to create a system wide resource that is tied to single EJB jar file. If some other EJB tries to use it, it won't work. Wouldn't it be better to just let the EJB handle this internally? If we still want a JNDI factory built in an MBean, I would suggest building it in the MBean at startup before we bind it to JNDI and require that all the classes and mappings be loaded into the server's context loader on startup. Thoughts? Regards, John -----Original Message----- From: Christian Meunier [mailto:[EMAIL PROTECTED] Sent: Thursday, August 08, 2002 10:47 AM To: Urberg, John; Gavin_King/[EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [Hibernate-devel] RE: JMX/JBoss In case it could help http://kb.atlassian.com/content/atlassian/howto/classloaders.jsp Chris ----- Original Message ----- From: "Urberg, John" <[EMAIL PROTECTED]> To: <Gavin_King/[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, August 08, 2002 4:04 PM Subject: RE: [Hibernate-devel] RE: JMX/JBoss > > Damn! I really don't understand why the following line wouldn't > > work: > > > > ds.storeResource( > > resources[i], Thread.currentThread().getContextClassLoader() > > ); > > > >( in SessionFactoryStub.getImpl() ). Have I got it totally wrong, > > or isn't Thread.currentThread.getContextClassLoader() meant to get > > the classloader used by the calling EJB? Perhaps I'm > > hallucinating... > > I often feel that way when confronted with class loaders. I don't know much > about them yet, so I can't be much help there. > > >> The only way I can see making this MBean useful is if users put all >> > their mapped classes and mappings in the server's classpath. Then > >> they can put them all in one mapping or split them up and it won't > >> matter because the MBean and SessionFactoryStub will have access > >> to them. > > I should always test it out before I make pronounciations! I tried my > little example with the jar files containing the mapping files in Jboss's > lib/ext directory (which get loaded when JBoss starts up). I got the same > exception as I did when it was in the EJB jar file. The SesstionFactory > stub could not find it. When I moved the creation of the SessionFactory > completely into a class in my jar file, everything worked a.o.k. (This last > version is what I'm doing in my application) > > My original attempt created the session factory in the MBean at startup. I > had the domain classes in jboss's lib/ext directory and the MBean seemed to > find them ok. Unless someone has some classloader answers for you, this > will probably be the only way to do it. > > Regards, > John > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Hibernate-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/hibernate-devel > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
