[PROPOSAL] Use javac as an load-from-context-classloadr compiler (was: Classloader when Tomcat is embedded + save)
Hello Matthias and All! 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. mecc Class org.eclipse.jdt.internal.compiler.Compiler in combination with mecc org.apache.cocoon.components.language.programming.java.EclipseJavaCompiler mecc provide a load-from-context-classloader compiler, independent of the mecc filesystem. The latter can be easily turned into an ant CompilerAdapter. mecc I've once briefly browsed the javac source, that one couldn't even easily mecc be adapted. What if we: Create a special classloader. Teach this classloader not to delegate loading of java.io to its parent classloader. Load java.io except for File, FileInputStream, FileOutputStream directly from rt.jar. Load our own implementations of File, FileInputStream, FileOutputStream to create own own virtual fs. Load tools.jar with this classloader too. This way we may fool javac and use it as an in-process load-from-context-classloader compiler. We may use for instance a ThreadLocal variable to short-circuit our in-house reiplementations of File* to the classloader and a sink accepting compiled classes. The only question I have: does sun licsense allow us to legimately do this? Anton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Classloader when Tomcat is embedded + save
Remy Maucherat wrote: The implementation of the feature had little to do with the StandardServer class itself. It should really be a separate helper class (no more hacks, sorry ;-) ). Well, I can do the helper class, but I have some questions. The helper class will be for the method storeConfig() or for storeServer() ? Because the name of the config file will remain the same name in the same place. But it's true that the helper class must allow the best flexibility so it would be for storeConfig. So, the Helper class can be on the form StoreConfigHelper with a constructor which take a Server Object. so the storeConfig() method of StandardServer will call : storeConfigHelper.store(server) All the stuff concerning exceptions, persistables, skippables could be in this helper class. Or it can be arguments for the constructor of the helper class. StandardServer will also have a method for setting the helper class. So there is a need of an interface. My next question is : Can we authorize the default StoreConfigHelper class to be extended and by allowing the fact that storeListener, storeContext, etc will be protected and not private. Or if we have only choice by implementing a class of the StoreConfigHelper interface. My last question is about the name and the package of these classes. The helper class must go on the util package or stay in the core package. The interface must go on root package where there are a lot of interfaces ? Do you have advice for the name of these classes or architecture for this helper class. Regards, Florent Florent BENOIT wrote: 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. The implementation of the feature had little to do with the StandardServer class itself. It should really be a separate helper class (no more hacks, sorry ;-) ). 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]
Re: Classloader when Tomcat is embedded + save
Florent BENOIT wrote: 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. The implementation of the feature had little to do with the StandardServer class itself. It should really be a separate helper class (no more hacks, sorry ;-) ). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Classloader when Tomcat is embedded + save
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.
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.
I can understand that this is not your priority but it can be a good
feature when we embed Tomcat. Thanks.
Best regards,
Florent.
ObjectWeb JOnAS server
http://jonas.objectweb.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Classloader when Tomcat is embedded + save
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]
Re: Classloader when Tomcat is embedded + save
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. Class org.eclipse.jdt.internal.compiler.Compiler in combination with org.apache.cocoon.components.language.programming.java.EclipseJavaCompiler provide a load-from-context-classloader compiler, independent of the filesystem. The latter can be easily turned into an ant CompilerAdapter. I've once briefly browsed the javac source, that one couldn't even easily be adapted. Matthias -- Matthias Ernst Software Engineer CoreMedia - Smart Content Technology - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
