Remy Maucherat wrote:
> Well, I think in the complex cases, you should probably use StandardContext.setCompilerClasspath. I'm willing to remove that check, though.
> Of course, it's good to remember that this code exists only because of the lack of a good in memory compiler. This could change.
Yes, I could use setCompilerClasspath() method, but, in order to retrieve the classpath (to give to setCompilerClasspath()), I have to use a similar method than setClassPath() of the class WebappLoader. So the code is duplicated only for changing the number of layer. So it would be great if the 3 is going to be removed.
If this value (3) is not removed, it could become a parameter like for setCompilerClasspath() on StandardContext.
StandardContext.setCompilerClassPathLayers(int layers). If it's null, it uses 3, else it uses the number which is set.
So, this value can be adjusted by the application server in different cases.
In ear case, this number will be greater than in a standalone war file as the number of classloader is increased.
But, it will result in the same case that if this 3 parameter is definitively removed because it will stop at the last URLClassloader found.
For the saving feature :
> That feature is thought out for standalone mode. It's hard to predict what are the components which should be saved, and which should not.
> Now if you want to refactor the save-to-xml code to a separate class (and allow configuring that class, of course), then I'm waiting for your patch :)
There is no problem for doing a contribution. But maybe I have to use the skippable mechanism already defined in StandardServer.
So, by adding a public method addSkippable(String classname) (and maybe a removeSkippable(String)) and by adding the isSkippable() mechanism in the storeContext like for storeListener()
I think that addSkippable(String classname) is better than setSkippables(string skippables) as we don't have to know the existing skippables.
These methods will not be called in standalone mode but can be useful in the embedded mode.
If you agree with this, I can propose a patch for the current catalina 5.x cvs.
Regards,
Florent
Remy Maucherat wrote:
Florent BENOIT wrote:
Hello,
When we embed Tomcat in an application server, we have the following problem that we must "patch".
It would be good if in the Tomcat 5.x branch, this will be fixed.
The problem :
It's about the setClassPath() method of the class WebappLoader of the package org.apache.catalina.loader.
This is the following code :
int layers = 0; int n = 0; while ((layers < 3) && (loader != null)) {
So, the classpath is set to 3 level.
When JOnAS is embedded, several URL Classloader can be parent classloader and not set to 3 levels.
So, for example if we have an application server classloader, ear classloader, ejb classloader, web classloader, etc.
The final classpath has some missing jars which can be found on a layer >= 3.
So, please, if you can :
- remove this test on this value (only testing (loader != null) and we stop when it's not anymore an URLClassLoader
- or that we can configure this value by a system property or anything else.
It will make a better integration of the Tomcat product, without having to set the right classpath with the same method but without the number 3.
Well, I think in the complex cases, you should probably use StandardContext.setCompilerClasspath. I'm willing to remove that check, though.
Of course, it's good to remember that this code exists only because of the lack of a good in memory compiler. This could change.
Another request is if the save action to the server.xml file could not saved some configurable parameters.
For example, in a j2ee application server, some contexts are created at the runtime, but we don't want that these contexts will be stored on the server.xml as their path are sometimes dynamic, temporary, etc.
So if we could add/remove/configure the actions of the save() method, it would be great for a better integration.
That feature is thought out for standalone mode. It's hard to predict what are the components which should be saved, and which should not.
Now if you want to refactor the save-to-xml code to a separate class (and allow configuring that class, of course), then I'm waiting for your patch :)
Remy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
