Re: [2.2] Classloading
I made some updates to the class loading stuff. The paranoid servlet is now working again (at least for me). One problem was a class cast exception as somehow the servlet.jar is copied into WEB-INF/lib. So there seems to be a faulty pom somewhere! I don't have a clue right now how to find the pom which is causing this. So I exclude the packages java.** and javax.servlet.** from paranoid classpath loading, which makes sense anyway. The per sitemap classloading is now in again, but I didn't test it yet; I won't test it before next week. Now, it seems that Spring is using the ThreadContext classloader for instantiating new beans, so as we set this class loader it should work...however I think we have problems with the Cocoon: protocol here. If one sitemap is using the cocoon: protocol which refers to a different sitemap with a different classloader we have to switch the thread context class loader! (This switching is currently done for several other components and is required due to the nature of the sax streams). I more and more come to the conclusion that we should not directly stream if the cocoon: protocol is used. There are too many things which might differ between two sitemaps and we have to set/restore them for each and every sax event. So buffering creates a much safer environment here (of course with the cost of loosing a little performance). Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Classloading
Reinhard Poetz wrote: I haven't looked at your deployer tool and I only briefly looked at the maven war plugin some time ago, but couldn't we just extend the plugin (like you do) and move the jar files from WEB-INF/lib to whatever directory we want after the original code is finished building the webapp. So this would be a simple post processor. hmmm, that would be easy but I'm not sure if we should really do this. If the ParanoidClassloader is not used, the developer has to take care that he configures the cocoon-deployer-plugin correctly too. Yes, true. What about extending the deployer (or creating another plugin) which by default rewrites the web.xml and adds all required wrappers (paranoid servlet etc.) and also moves the jars to a different directory? With a plugin-configuration this can be turned off. (We don't need this for b1) Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Classloading
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 19 May 2006, Carsten Ziegeler wrote: Date: Fri, 19 May 2006 09:18:26 +0200 From: Carsten Ziegeler [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: Cocoon-Dev dev@cocoon.apache.org Subject: [2.2] Classloading Reinhard already started the discussion on readding per sitemap classloading which I think is a good idea. I'll try to add the code over the weekend again. But I think we should go one step further: Let's always use the paranoid class loader for the whole webapp. I started a discussion about this a long time ago and I think noone disagreed at that time (haven't searched in the archives). I hope this is still the case. Now, my idea is to solve all class path related problems (xml apis, rhino, commons-logging) with this. I suggest that we: a) move the paranoid class loader code (3 classes without additional dependencies) to the core-webapp block. It doesn't make sense to make this code an own block. b) Configure this as the default (I already did this and it worked on my machine - as it didn't work on Reinhards he commented it out. We have to find out what went wrong). c) Change the deployer tool to *not* put all jars in WEB-INF/lib and classes in WEB-INF/classes. I think we should only put the paranoid servlet and classloader class into WEB-INF/lib and everything else goes into a different directory to hide these classes from the usual application container classpath. It doesn't make sense to add all these jars to the webapp classpath although they are not used at all. So we put them into an own directory, let's they WEB-INF/cocoon-lib and the paranoid class loader loads everything from there. How does this work if one has added ServletFilters or a top level Spring applicationContext? Does he has to take care of it's own to deploy the necessary jars at the right place? Do we need to clone the maven webapp-plugin (the one creating a war/webapp structure)? At the first glance it doesn't seem so easy to me - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEbXTPLNdJvZjjVZARAikiAJ90sMJ3HlV038W1nHHqhF64jVnXSACgpbvs C3MIBJcLWkEvALEh/DXsBRE= =Wkfg -END PGP SIGNATURE-
Re: [2.2] Classloading
Giacomo Pati wrote: How does this work if one has added ServletFilters or a top level Spring applicationContext? Does he has to take care of it's own to deploy the necessary jars at the right place? Hmm, good question. Do we need to clone the maven webapp-plugin (the one creating a war/webapp structure)? No, I think/hope that we can do this in our deployer tool. At the first glance it doesn't seem so easy to me Yes, you're right. Now I see two solutions (perhaps there are more?): a) We forget about the paranoid class loading completly as this causes too much problems with other servlets or filters defined in the webapp. This would require to rely on the application server when it comes to class loading. b) We require that every servlet and filter use our paranoid class loader. We could achieve this by wrapping our ParanoidServlet and our ParanoidFilter class around the real servlet/filter in the web.xml. So all you have to do is a little bit more configuration in web.xml. Instead of directly configuring your servlet/filter you configure the wrapper and give your class as a parameter. Together with the deployer tool everything else should be transparent. I would try to go for b) Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Classloading
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 19 May 2006, Carsten Ziegeler wrote: Date: Fri, 19 May 2006 09:46:10 +0200 From: Carsten Ziegeler [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [2.2] Classloading Giacomo Pati wrote: How does this work if one has added ServletFilters or a top level Spring applicationContext? Does he has to take care of it's own to deploy the necessary jars at the right place? Hmm, good question. Do we need to clone the maven webapp-plugin (the one creating a war/webapp structure)? No, I think/hope that we can do this in our deployer tool. Not sure we can (Reinhard?) At the first glance it doesn't seem so easy to me Yes, you're right. Now I see two solutions (perhaps there are more?): a) We forget about the paranoid class loading completly as this causes too much problems with other servlets or filters defined in the webapp. This would require to rely on the application server when it comes to class loading. b) We require that every servlet and filter use our paranoid class loader. We could achieve this by wrapping our ParanoidServlet and our ParanoidFilter class around the real servlet/filter in the web.xml. So all you have to do is a little bit more configuration in web.xml. Instead of directly configuring your servlet/filter you configure the wrapper and give your class as a parameter. Together with the deployer tool everything else should be transparent. I would try to go for b) b) might work, but since you want it to be the default ClassLoader I expect problems users forgot about wrapping their stuff in web.xml. - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEbXx4LNdJvZjjVZARAm06AKDy+im44BQGReqTkvb3/95zI9iv0ACg5HeF 5lEmkhjGegX+9cVFHRzesJI= =T6+R -END PGP SIGNATURE-
Re: [2.2] Classloading
Giacomo Pati wrote: b) might work, but since you want it to be the default ClassLoader I expect problems users forgot about wrapping their stuff in web.xml. Yes, that's true - but apart from that what do you think about the idea? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Classloading
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 19 May 2006, Carsten Ziegeler wrote: Date: Fri, 19 May 2006 10:37:01 +0200 From: Carsten Ziegeler [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [2.2] Classloading Giacomo Pati wrote: b) might work, but since you want it to be the default ClassLoader I expect problems users forgot about wrapping their stuff in web.xml. Yes, that's true - but apart from that what do you think about the idea? The web.xml in 2.2 is in the responsability of the developer (it was not so in 2.1 where you've build from the source and had to patch it to have a reproducable and automated build). And because of that I'd say go for b) :-) - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEbYT3LNdJvZjjVZARAsSdAKDw8t2VdUc88ZR57EHTqwRka3SQ7wCgx6vi G1rwpVZC7w6bHWWfsY7fPjQ= =hzTs -END PGP SIGNATURE-
Re: [2.2] Classloading
Carsten Ziegeler skrev: Giacomo Pati wrote: b) might work, but since you want it to be the default ClassLoader I expect problems users forgot about wrapping their stuff in web.xml. Yes, that's true - but apart from that what do you think about the idea? As, we want to make Cocoon less monolithic and easier to use together with other web frameworks, it seem like a step in the wrong direction to require all servlets and filters to be wrapped and use non-standard classloading. I don't remember what classloading problems we have, could you give some background or a link to the previous discussion you referred to, so that I can create a more informed opinion about the issue. /Daniel
Re: [2.2] Classloading
Daniel Fagerstrom wrote: Carsten Ziegeler skrev: Giacomo Pati wrote: b) might work, but since you want it to be the default ClassLoader I expect problems users forgot about wrapping their stuff in web.xml. Yes, that's true - but apart from that what do you think about the idea? As, we want to make Cocoon less monolithic and easier to use together with other web frameworks, it seem like a step in the wrong direction to require all servlets and filters to be wrapped and use non-standard classloading. I don't remember what classloading problems we have, could you give some background or a link to the previous discussion you referred to, so that I can create a more informed opinion about the issue. There are several problems, for example Rhino, Xerces and Xalan which usually are already in the classpath of the app server. Now, Cocoon requires specific versions of these jars and if the app server comes with different (possibly incompatible) versions, then you have problems. And updating the jars of the app server is a no-go. And the paranoid class loader is the only solution which works reliable. Other problems occur with logging when for example the app server uses the same logging frameworks but with a different configuration. Now, you *can* use Cocoon without the paranoid class loader, but I would like to make it the default and common practice. If you don't need this for your own app, you can change it and simply not configure the wrappers. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Classloading
Carsten Ziegeler skrev: Daniel Fagerstrom wrote: Carsten Ziegeler skrev: Giacomo Pati wrote: b) might work, but since you want it to be the default ClassLoader I expect problems users forgot about wrapping their stuff in web.xml. Yes, that's true - but apart from that what do you think about the idea? As, we want to make Cocoon less monolithic and easier to use together with other web frameworks, it seem like a step in the wrong direction to require all servlets and filters to be wrapped and use non-standard classloading. I don't remember what classloading problems we have, could you give some background or a link to the previous discussion you referred to, so that I can create a more informed opinion about the issue. There are several problems, for example Rhino, Xerces and Xalan which usually are already in the classpath of the app server. Now, Cocoon requires specific versions of these jars and if the app server comes with different (possibly incompatible) versions, then you have problems. And updating the jars of the app server is a no-go. And the paranoid class loader is the only solution which works reliable. Other problems occur with logging when for example the app server uses the same logging frameworks but with a different configuration. Now, you *can* use Cocoon without the paranoid class loader, but I would like to make it the default and common practice. If you don't need this for your own app, you can change it and simply not configure the wrappers. Seem reasonable. Then I don't have any problem with having the paranoid classloader as default. /Daniel
Re: [2.2] Classloading
Reinhard Poetz schrieb: Giacomo Pati wrote: Hmm, good question. Do we need to clone the maven webapp-plugin (the one creating a war/webapp structure)? No, I think/hope that we can do this in our deployer tool. Not sure we can (Reinhard?) The cocoon-deployer-maven-plugin *extends* the maven-war-plugin as good as possible[1]. We only have to upgrade the dependency in the POM whenever we want to use a new maven-war-plugin. The only disadvantage of this is that implementing Carsten's idea c) Change the deployer tool to *not* put all jars in WEB-INF/lib and classes in WEB-INF/classes. would lead to a lot of code duplication as we would have to build the web application ourselves. So I'm -1 on this as at least I don't want to maintain this fork. Ok, are you -1 on the whole classloading idea or just on point c)? I haven't looked at your deployer tool and I only briefly looked at the maven war plugin some time ago, but couldn't we just extend the plugin (like you do) and move the jar files from WEB-INF/lib to whatever directory we want after the original code is finished building the webapp. So this would be a simple post processor. WDYT? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Classloading
Carsten Ziegeler wrote:
Reinhard Poetz schrieb:
Giacomo Pati wrote:
Hmm, good question.
Do we need to clone the maven webapp-plugin (the one creating a
war/webapp structure)?
No, I think/hope that we can do this in our deployer tool.
Not sure we can (Reinhard?)
The cocoon-deployer-maven-plugin *extends* the maven-war-plugin as good as
possible[1]. We only have to upgrade the dependency in the POM whenever we want
to use a new maven-war-plugin.
The only disadvantage of this is that implementing Carsten's idea c) Change the
deployer tool to *not* put all jars in WEB-INF/lib and classes in
WEB-INF/classes. would lead to a lot of code duplication as we would have to
build the web application ourselves. So I'm -1 on this as at least I don't want
to maintain this fork.
Ok, are you -1 on the whole classloading idea or just on point c)?
only point c)
except we find some way so that we don't have to reinvent the maven-war-plugin
I
haven't looked at your deployer tool and I only briefly looked at the
maven war plugin some time ago, but couldn't we just extend the plugin
(like you do) and move the jar files from WEB-INF/lib to whatever
directory we want after the original code is finished building the
webapp. So this would be a simple post processor.
hmmm, that would be easy but I'm not sure if we should really do this. If the
ParanoidClassloader is not used, the developer has to take care that he
configures the cocoon-deployer-plugin correctly too.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
