On 09/12/2014 07:10, Violeta Georgieva wrote: > Hi Mark, > > 2014-12-09 1:17 GMT+02:00 Mark Thomas <ma...@apache.org>: >> >> On 08/12/2014 09:04, violet...@apache.org wrote: >>> Author: violetagg >>> Date: Mon Dec 8 09:04:56 2014 >>> New Revision: 1643766 >>> >>> URL: http://svn.apache.org/r1643766 >>> Log: >>> Extract several "protected" methods in order to make StandardRoot > easier for extending. >>> >>> Modified: >>> tomcat/trunk/java/org/apache/catalina/webresources/StandardRoot.java >>> >>> Modified: > tomcat/trunk/java/org/apache/catalina/webresources/StandardRoot.java >>> URL: > http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/webresources/StandardRoot.java?rev=1643766&r1=1643765&r2=1643766&view=diff >>> > ============================================================================== >>> --- > tomcat/trunk/java/org/apache/catalina/webresources/StandardRoot.java > (original) >>> +++ > tomcat/trunk/java/org/apache/catalina/webresources/StandardRoot.java Mon > Dec 8 09:04:56 2014 >>> @@ -457,6 +457,10 @@ public class StandardRoot extends Lifecy >>> return postResources.toArray(new WebResourceSet[0]); >>> } >>> >>> + protected WebResourceSet[] getClassResources() { >>> + return classResources.toArray(new WebResourceSet[0]); >>> + } >>> + >>> @Override >>> public void setAllowLinking(boolean allowLinking) { >>> this.allowLinking = allowLinking; >> >> What is the use case for this one? classResources was intended to be >> internal to StandardRoot. >> >>> @@ -633,9 +637,7 @@ public class StandardRoot extends Lifecy >>> >>> cacheJmxName = register(cache, getObjectNameKeyProperties() + > ",name=Cache"); >>> >>> - // Ensure support for jar:war:file:/ URLs will be available > (required >>> - // for resource JARs in packed WAR files). >>> - TomcatURLStreamHandlerFactory.register(); >>> + registerURLStreamHandlerFactory(); >>> >>> if (context == null) { >>> throw new IllegalStateException( >>> @@ -649,29 +651,17 @@ public class StandardRoot extends Lifecy >>> } >>> } >>> >>> + protected void registerURLStreamHandlerFactory() { >>> + // Ensure support for jar:war:file:/ URLs will be available > (required >>> + // for resource JARs in packed WAR files). >>> + TomcatURLStreamHandlerFactory.register(); >>> + } >>> + >> >> I can see the use case for these two. +1. >> >> >>> @Override >>> protected void startInternal() throws LifecycleException { >>> - String docBase = context.getDocBase(); >>> - >>> mainResources.clear(); >>> >>> - if (docBase == null) { >>> - main = new EmptyResourceSet(this); >>> - } else { >>> - File f = new File(docBase); >>> - if (!f.isAbsolute()) { >>> - f = new > File(((Host)context.getParent()).getAppBaseFile(), f.getPath()); >>> - } >>> - if (f.isDirectory()) { >>> - main = new DirResourceSet(this, "/", > f.getAbsolutePath(), "/"); >>> - } else if(f.isFile() && docBase.endsWith(".war")) { >>> - main = new JarResourceSet(this, "/", > f.getAbsolutePath(), "/"); >>> - } else { >>> - throw new IllegalArgumentException( >>> - sm.getString("standardRoot.startInvalidMain", >>> - f.getAbsolutePath())); >>> - } >>> - } >>> + main = createMainResourceSet(); >>> >>> mainResources.add(main); >>> >>> @@ -694,6 +684,31 @@ public class StandardRoot extends Lifecy >>> setState(LifecycleState.STARTING); >>> } >>> >>> + protected WebResourceSet createMainResourceSet() { >>> + String docBase = context.getDocBase(); >>> + >>> + WebResourceSet mainResourceSet; >>> + if (docBase == null) { >>> + mainResourceSet = new EmptyResourceSet(this); >>> + } else { >>> + File f = new File(docBase); >>> + if (!f.isAbsolute()) { >>> + f = new > File(((Host)context.getParent()).getAppBaseFile(), f.getPath()); >>> + } >>> + if (f.isDirectory()) { >>> + mainResourceSet = new DirResourceSet(this, "/", > f.getAbsolutePath(), "/"); >>> + } else if(f.isFile() && docBase.endsWith(".war")) { >>> + mainResourceSet = new JarResourceSet(this, "/", > f.getAbsolutePath(), "/"); >>> + } else { >>> + throw new IllegalArgumentException( >>> + sm.getString("standardRoot.startInvalidMain", >>> + f.getAbsolutePath())); >>> + } >>> + } >>> + >>> + return mainResourceSet; >>> + } >>> + >> >> I'm curious about the use case for this too. > > In OSGi environment it is hard to use the > DirResourceSet/FileResourceSet/JarResourceSet/JarWarResourceSet > implementations they all are based on the fact that one can work with files > directly. > In OSGi environment one can use only URLs/OSGi API to access bundle and > bundle entries. (there are hacks that one can use if one wants to use files > but then the implementation will become dependent on the OSGi framework and > its internal implementation) > The war archive is hidden and every bundle entry (file in the war archive) > can be accessed via *bundleentry* URL protocol.
I assume you are implementing a BundleResourceSet or something similar then. > 1) I'm extending the StandardRoot as almost of the implementation is > relevant for OSGi use case also and I'm overriding createMainResourceSet in > order to provide my own implementation of the main WebResourceSet. OK. If you need a non-file system based main resource set then you need to do something along these lines. > 2) Also one cannot register URLStreamHandlerFactory like in Tomcat but one > needs to register an OSGi service that will provide this functionality. Yes. No objections here at all. > 3) In OSGi environment one can declare that wants to have something in the > classpath also via *Bundle-ClassPath* header in the MANIFEST.mf file. > > I need these two methods getClassResources()/addClassResources because I > need to provide my own implementation for createWebResourceSet methods. > If you don't want classResources to be exposed than I have to think about > how to separate createWebResourceSet in order to provide my implementation > of the WebResourceSet/WebResource. > > What do you think? I'm wondering if WebResourceRoot needs some tweaks. The createWebResourceSet() methods are beginning to look like utility methods for file system based resources that don't belong in the interface. I think I'll add a TODO marker for now. There are other things I need to focus on. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
