> This is going to cause other problems. What if I have two wars that > uses struts and each have a different version of the same action class > because they are different releases of the same web application. If a > struts.jar is referred to by a war manifest is should be only loaded > by the servlet container class loader. That it is at the war level is > just a packaging choice to avoid duplication of the jar in the wars.
So how do you recommend this be fixed? The servlet containers do not appear to utilize the Class-Path entry of the war's manifest. I could create a URLClassLoader that loads the war, the WEB-INF/classes and lib, and all manifest entries. It's parent classloader would be a UnifiedClassLoader (perhaps the current thread's context loader?). > This again comes back to the fact that the packaging structure should > not be the sole dictator of the class loading heirarchy. I agree. I think each deployment type should be able to dictate what url's to expose to the UnifiedClassLoader, and which to keep privately within child URLClassLoaders. A simple hacked solution would be to remove the createClassLoaders from DepoymentInfo, and place that responsibility in the init methods of SubDeployer (with SubDeployerSupport providing the default implementation). I have been looking into a Deployer refactoring anyway... I'll put some time into it this weekend, and present a list of requirements / proposed design for discussion. -Larry > Scott Stark > Chief Technology Officer > JBoss Group, LLC > xxxxxxxxxxxxxxxxxxxxxxxx > ----- Original Message ----- > From: "Larry Sanderson" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, April 19, 2002 8:42 AM > Subject: Re: [JBoss-dev] [ jboss-Bugs-544848 ] EAR Deployments don't work > > > > > I'm also running into a problem that may be related > > > to this. I have a .war (or the .war embedded in a .ear > > > properly referenced in application.xml ... > > > > > OK - A few questions. From where are you accessing this resource (i.e. > the location of the directory or jar file where the accessing class lives). > Is it in your WEB-INF/lib, WEB-INF/classes, sitting next to the war file? > I'm going to assume that it is in the WEB-INF/lib directory, since the only > change I made since RC1 would affect nested archives (usually located in > WEB-INF/lib). > > > > Second question... Have you ever tried this scenario with 3.0 beta, prior > to RC1? I am interested to know if that worked. From what I can tell from > the class history, I don't think this would have worked, but I may be > mistaken. > > > > A brief explanation of the classloader hierarchy: > > JBoss has a custom ClassLoader called the UnifiedClassLoader. > ClassLoaders normally have a parent-child hierarchy, such that a child > ClassLoader can "see" all classes loaded by the parent, but the parent > cannot "see" those classes loaded by the child. The UnifiedClassLoader > throws that concept out the window. Any class loaded by a UnifiedClassLoader > can "see" every other class loaded by another UnifiedClassLoader, regardless > of the parent child relationship. > > > > My original changes (in the RC1 release): > > The problem with war files is that Jetty and Tomcat use their own > Classloaders to load up the war file. (This includes the lib and classes > directories within WEB-INF). Since they are not using the > UnifiedClassLoader, all of JBoss's normal classes can not see any of the > files within the web archive. So, if struts.jar was located "next to" the > war file, it would be loaded by JBoss and the UnifiedClassLoader, and when > it came time to access your struts Actions (within your war file's lib or > classes directories), it would get a ClassNotFoundException. This was the > original problem on this thread. > > > > My most recent change: > > Since all classes need to be able to see each other, the obvious solution > is to use the UnifiedClassLoader to load all classes. The "fix" I put in > since RC1 was released was to use the UnifiedClassLoader on all nested > deployable archives. This is (I think) exactly the way things were done > prior to my work. The only problem is that it left out the WEB-INF/classes > directory. > > > > The fix: > > I just need to load WEB-INF/classes with a UnifiedClassLoader and your > problem should be solved. This is a fairly simple fix, and I will get it in > today. I need to create some test cases to check all this, but that will > have to wait for the weekend (Is it Friday already?) > > > > Sorry for the confusion. > > > > -Larry > > > > * * * > > > > View thread online: > http://jboss.org/forums/thread.jsp?forum=66&thread=13076 > > > > _______________________________________________ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
