thanks for responding i did not mean to seem petulant but it was obvious my were not getting past all the other important issues the list memebers have been dealing with of late.... I have been lurking for a while :-)
As to why the current thead contexts class loader was not able to load axis classes in dynamo, to tell you the truth it was a bit suprising to me also, but since presumably the classes which provide the web service are deployed along with the AxisServlet class. calling new SomeAxisClass().getClass().getClassloader() should resonably be able to access both axis classes and web service provider classes in a wide variety opf servlet containers since they are in the same set of jar files/ear file/war file. is this not the case in jrun. how do calls to new foo() work if it were not the case? Dynamo uses jmx mbeans for a number of other subsystems. could this provide an explanation? ----- Original Message ----- From: "Glen Daniels" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, January 31, 2002 5:17 PM Subject: RE: Could we please take a second and discuss AxisClassloader (3rd attempt) > > Hi Matt: > > Sorry about the delay in getting back to you! > > You raise an interesting point, and one which has certainly come up before in various guises. > > From the perspective of a JRun developer, your trick won't work, because JRun loads Axis with a "server-wide" classloader which is higher up the tree than the webapp classloader (which is the one you want). > > Could you explain how things work in Dynamo so that the current thread classloader in a servlet invocation does NOT have access to the WEB-INF classes? > > (isn't there some servlet 2.3 standard way of getting at the webapp classloader?) > > --Glen > > > -----Original Message----- > > From: Matt Bowersox [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, January 31, 2002 4:55 PM > > To: [EMAIL PROTECTED] > > Subject: Could we please take a second and discuss > > AxisClassloader (3rd > > attempt) > > > > > > I have attempted to engage the list on this issue on two > > seperate occasions > > and have recived no feedback. The implementation decisions made in the > > design of this class completely breaks axis on ATG dynamo ( > > a certified > > j2ee app server) and possibly other vendor's products. > > > > ps. sorry if the obtuse numeric email address in some of my > > prior messages > > is confusing, I am sometimes trapped behind our clients > > firewalls and it > > can do weird things to email addresses. > > please respond to the list or the [EMAIL PROTECTED] > > addresses for > > personal correspondances. > > > > ----- Original Message ----- > > From: <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Monday, January 28, 2002 2:12 PM > > Subject: possible bug > > > > > > > From: Matthew Bowersox > > > > > > The axis classloader is based on a parent classloader > > derived from the > > > thread context. I suspect that the assumption that the > > classloader derived > > > from the thread context should be able to load the j2ee web > > container > > > classes for axis is false. This behavior breaks axis on > > the atg dynamo > > > version 5.5 application server. I patched AxisClassLoader > > by having it > > > instantiate a class in an axis package, then calling getClass > > > ().getClassloader() on this axis packaged class as a way to > > ensure gaining > > > refererence to the j2ee application classloader. the servlet spec is > > > somewhat fuzzy in this regard. it manadates a sperate > > clasloader for each > > > j2ee app but does not specify the required mechanism to > > gain a reference > > to > > > it. and certainly does not prescribe that the current > > thread object use > > > the same classlaoder as it is quite conceivable that the > > thread object be > > > part of the application server proper not a particular web > > container. > > > > > > thoughts? > > > > > > > > > Matt Bowersox > > > > > > > > > > > >
