2014-12-09 11:53 GMT+02:00 Mark Thomas <ma...@apache.org>: > > 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.
Yep > > 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. Thanks > Mark > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org >
