You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Geoff Soutter <ge...@whitewolf.com.au> on 2000/07/26 12:04:42 UTC
[catalina] build.xml bugs?
Hi there
looks like the current build.xml/catalina.bat is broken
when you try and start it, it doesn't have access to the XmlMapper.
looks to me as if the fix is to extend the build.xml to include jasper.jar
to include utils/** rather than just utils/*, but I'm only guessing.
also, I think the readme could be more clear about where jaxp is expected to
be installed ;-)
cheers
Geoff
Re: [CATALINA] last checkin broke MemoryRealm? [was Re: [catalina]
build.xml bugs?]
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Geoff Soutter wrote:
> thanks all.
>
> hope you don't mind me simply reporting bugs rather than fixing them myself,
> I'm kinda busy at the moment ... :-)
>
That's OK, we'll forgive you *this* time :-)
> geoff
>
Craig
Re: [CATALINA] last checkin broke MemoryRealm? [was Re: [catalina] build.xml bugs?]
Posted by Geoff Soutter <ge...@whitewolf.com.au>.
thanks all.
hope you don't mind me simply reporting bugs rather than fixing them myself,
I'm kinda busy at the moment ... :-)
geoff
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: <to...@jakarta.apache.org>
Sent: Thursday, July 27, 2000 11:27 AM
Subject: Re: [CATALINA] last checkin broke MemoryRealm? [was Re: [catalina]
build.xml bugs?]
> > Yah, just ran into this myself as well. I'm investigating, and should
be
> able
> > to fix it shortly.
>
> Ok, I've fixed it.
>
> Remy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
Re: [CATALINA] last checkin broke MemoryRealm? [was Re: [catalina] build.xml bugs?]
Posted by Remy Maucherat <re...@apache.org>.
> Yah, just ran into this myself as well. I'm investigating, and should be
able
> to fix it shortly.
Ok, I've fixed it.
Remy
Re: [CATALINA] last checkin broke MemoryRealm? [was Re: [catalina]
build.xml bugs?]
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Geoff Soutter wrote:
> Hi Craig
>
> > I suspect this problem is related to your previous problem building
> > Tomcat
> > itself. If that job doesn't complete correctly, Catalina won't build
> > correctly
> > either. (I just did clean builds of both and they worked for me, and
> > both
> > executed).
>
> I created a new dir, checked out tomcat into it, and now it builds ok, and I
> can get catalina to build too using the updated build stuff. However, when I
> try and run catalina, it gets into what appears to be an endless loop during
> the startup.
>
Yah, just ran into this myself as well. I'm investigating, and should be able
to fix it shortly.
Craig
[CATALINA] last checkin broke MemoryRealm? [was Re: [catalina] build.xml bugs?]
Posted by Geoff Soutter <ge...@whitewolf.com.au>.
Hi Craig
> I suspect this problem is related to your previous problem building
> Tomcat
> itself. If that job doesn't complete correctly, Catalina won't build
> correctly
> either. (I just did clean builds of both and they worked for me, and
> both
> executed).
I created a new dir, checked out tomcat into it, and now it builds ok, and I
can get catalina to build too using the updated build stuff. However, when I
try and run catalina, it gets into what appears to be an endless loop during
the startup.
heres an example thread dump
D:\apps\jakarta\latest\build\catalina>bin\catalina run
Using BOOT PATH:
.\bin\bootstrap.jar;d:\apps\jdk\130\jre\lib\i18n.jar;d:\apps\jdk\130\jre\lib
\rt.jar;d:\apps\jdk\130\lib\tools.jar
Using CLASSPATH: .\dummy;.\lib\jasper.jar;.\lib\servlet.jar
Full thread dump:
"Signal Dispatcher" daemon prio=10 tid=0x768610 nid=0x129 waiting on monitor
[0..0]
"Finalizer" daemon prio=9 tid=0x765060 nid=0xb1 waiting on monitor
[0x8d8f000..0x8d8fdc8]
at java.lang.Object.wait(Native Method)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:108)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:123)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:162)
"Reference Handler" daemon prio=10 tid=0x765d10 nid=0xea waiting on monitor
[0x8d4f000..0x8d4fdc8]
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:420)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:110)
"main" prio=5 tid=0x7619a0 nid=0xe9 runnable [0x6f000..0x6fc3c]
at java.lang.String.indexOf(String.java:1330)
at java.lang.String.indexOf(String.java:1274)
at org.apache.tomcat.realm.MemoryRealm.addUser(MemoryRealm.java:340)
at
org.apache.tomcat.realm.MemoryRealmUserAction.start(MemoryRealm.java:644)
at
org.apache.tomcat.util.xml.XmlMapper.matchStart(XmlMapper.java:384)
at
org.apache.tomcat.util.xml.XmlMapper.startElement(XmlMapper.java:81)
at com.sun.xml.parser.Parser.maybeElement(Parser.java:1391)
at com.sun.xml.parser.Parser.content(Parser.java:1499)
at com.sun.xml.parser.Parser.maybeElement(Parser.java:1400)
at com.sun.xml.parser.Parser.parseInternal(Parser.java:492)
at com.sun.xml.parser.Parser.parse(Parser.java:284)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:155)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:126)
at org.apache.tomcat.util.xml.XmlMapper.readXml(XmlMapper.java:214)
at org.apache.tomcat.realm.MemoryRealm.start(MemoryRealm.java:488)
at
org.apache.tomcat.core.ContainerBase.start(ContainerBase.java:1105)
at
org.apache.tomcat.core.StandardServer.start(StandardServer.java:440)
at org.apache.tomcat.startup.Catalina.start(Catalina.java:517)
at org.apache.tomcat.startup.Catalina.execute(Catalina.java:488)
at org.apache.tomcat.startup.Catalina.process(Catalina.java:160)
at java.lang.reflect.Method.invoke(Native Method)
at org.apache.tomcat.startup.Bootstrap.main(Bootstrap.java:138)
"VM Thread" prio=5 tid=0x764f90 nid=0xb4 runnable
"VM Periodic Task Thread" prio=10 tid=0x767010 nid=0xa4 waiting on monitor
Full thread dump:
and then I did it a few seconds later...
"Signal Dispatcher" daemon prio=10 tid=0x768610 nid=0x129 waiting on monitor
[0..0]
"Finalizer" daemon prio=9 tid=0x765060 nid=0xb1 waiting on monitor
[0x8d8f000..0x8d8fdc8]
at java.lang.Object.wait(Native Method)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:108)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:123)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:162)
"Reference Handler" daemon prio=10 tid=0x765d10 nid=0xea waiting on monitor
[0x8d4f000..0x8d4fdc8]
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:420)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:110)
"main" prio=5 tid=0x7619a0 nid=0xe9 runnable [0x6f000..0x6fc3c]
at org.apache.tomcat.realm.MemoryRealm.addUser(MemoryRealm.java:344)
at
org.apache.tomcat.realm.MemoryRealmUserAction.start(MemoryRealm.java:644)
at
org.apache.tomcat.util.xml.XmlMapper.matchStart(XmlMapper.java:384)
at
org.apache.tomcat.util.xml.XmlMapper.startElement(XmlMapper.java:81)
at com.sun.xml.parser.Parser.maybeElement(Parser.java:1391)
at com.sun.xml.parser.Parser.content(Parser.java:1499)
at com.sun.xml.parser.Parser.maybeElement(Parser.java:1400)
at com.sun.xml.parser.Parser.parseInternal(Parser.java:492)
at com.sun.xml.parser.Parser.parse(Parser.java:284)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:155)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:126)
at org.apache.tomcat.util.xml.XmlMapper.readXml(XmlMapper.java:214)
at org.apache.tomcat.realm.MemoryRealm.start(MemoryRealm.java:488)
at
org.apache.tomcat.core.ContainerBase.start(ContainerBase.java:1105)
at
org.apache.tomcat.core.StandardServer.start(StandardServer.java:440)
at org.apache.tomcat.startup.Catalina.start(Catalina.java:517)
at org.apache.tomcat.startup.Catalina.execute(Catalina.java:488)
at org.apache.tomcat.startup.Catalina.process(Catalina.java:160)
at java.lang.reflect.Method.invoke(Native Method)
at org.apache.tomcat.startup.Bootstrap.main(Bootstrap.java:138)
"VM Thread" prio=5 tid=0x764f90 nid=0xb4 runnable
"VM Periodic Task Thread" prio=10 tid=0x767010 nid=0xa4 waiting on monitor
Full thread dump:
looks like its having a problem with the XML parsing again. I'm using
JAXP1.01 and the JAXP parser...
I had the same behaviour under JDK 1.2.2 as well
I noticed that your very last checkin updated this file as well... so I'm
guessing it needed a bit more testing :-) Or maybe the same cosmic rays that
caused my gremlins last night are affecting you too :-)
> >
> > also, I think the readme could be more clear about where jaxp is
expected to
> > be installed ;-)
> >
>
> I just updated the Catalina README to reflect the current instructions.
thanks
geoff
Re: [Catalina] Re: WebDAV, DefaultServlet and Resources
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
See interspersed.
Remy Maucherat wrote:
> > Remy Maucherat wrote:
> >
> > > Hi,
> > >
> > > I'd like to discuss here some features and enhancements I plan to make
> in
> > > Catalina.
> > >
> > > * WebDAV support
> > >
> > > A servlet will provide WebDAV level 2 capabilities. It can be seen as a
> > > merge between the DefaultServlet and a simplified version of the
> > > WebdavServlet from the Slide project (and cleared of Slide dependencies,
> of
> > > course). This servlet could be designed to use the filesystem directly.
> > > Instead, for additional flexibility and abstraction, I plan to use the
> > > Resources interface (well, an extended version of it, since there are no
> > > write methods in that interface as of now - see below).
> > >
> >
> > The goal should be that the default servlet, in whatever form, should work
> > whether the underlying document storage is a filesystem, a WAR file, BLOB
> > objects in a database -- all abstracted by the Resources interface in
> Catalina
> > so that the servlet itself need not know or care the underlying
> persistence
> > mechanism.
>
> With the extensions proposed below, we'll be able to switch to Resources.
Cool.
>
>
> > > * DefaultServlet
> > >
> > > DefaultServlet will be modified to also use the Resources interface. If
> > > performance turns out to be good enough, I suggest completely removing
> any
> > > direct filesystem access. Some additions will be needed to Resources,
> > > though, like the possibility to access directories through the
> interface, or
> > > just retrieving the content length of a resource, when it's known.
> > >
> >
> > You will want to check out the enhancements I added to today to the
> Resources
> > implementation classes, which (among other things) support the
> configurable
> > caching that is currently in the default servlet. That way, the caching
> > benefits will accrue to any application that uses
> > ServletContext.getResourceAsStream(), not just the default servlet's
> support for
> > caching static files. Two initial implementations are included -- one
> that runs
> > out of the filesystem (which is all that Tomcat 3.x supports), and one
> that runs
> > from a JAR file, which can be either local or remote (courtesy of the JAR
> file
> > URLStreamHandler built into the JDK).
>
> I saw that. Slide does just that too (it has caching at the storage
> abstraction layer).
> BTW, should I add a WAR unziping feature to
> StandardContext.setWorkDirectory() (just like Tomcat 3.x does), or will WAR
> files be accessed through Resources (which might be slower) ?
>
There is a WAR file unzipper in Catalina already (it is in
org.apache.tomcat.startup.HostConfig) that does the same trick that Tomcat 3.2
does -- or at least it's supposed to. I haven't tested this extensively yet.
For access speed, it's not clear to me that JAR file access would be slower
(after the first time a resource is retrieved) if you are doing aggressive
caching. Lots of the web apps I've seen have relatively small amounts of
resource content (just the source JSP pages and a few images, plus maybe a
little static HTML) and the tradeoff of memory occupancy versus access speed
seems like quite a good one.
In addition, the JAR file URL handler lets you do an interesting trick -- you
can refer to a JAR file on a remote server by setting your docBase to:
jar:http://www.foo.com/bar/baz.jar
Of course, you *definitely* want caching if you do something like this :-).
>
> > Extra stuff that is known to the underlying Resources implementation, can
> be
> > made available as well. Of course, any servlet that depends on this stuff
> will
> > be specific to this implementation.
>
> If the functions below are added, it will be ok.
>
> > > * Resources
> > >
> > > Right now, the interface provides the following functions :
> > > - String getMimeType(String file)
> > > - String getRealPath(String path)
> > > - URL getResource(String path)
> > > - InputStream getResourceAsStream(String path)
> > >
> >
> > and getResourceModified() to return the last modified timestamp of the
> specified
> > resource.
>
> Right. It was on my list, but I just forgot to write it down.
>
> > > I think the following methods should be added for support in
> DefaultServlet,
> > > with the same level of functionality as standard filesystem :
> > > - long getResourceLength(String path)
> > > Returns -1 if unknown, 0 if no content (directory ...), or the content
> > > length of the resource otherwise
> > > - boolean isCollection(String path)
> > > Returns true if the resource denoted by the given path is the functional
> > > equivalent of a directory
> > > - String[] getCollectionMembers(String path)
> > > Returns the list of the paths of the resources which are member of the
> > > collection denoted by the given path. null if the resource is not a
> > > collection
> >
> > This seems reasonable. Any practical implementation of the Resources
> interface
> > will know all of the above things, so it should be straightforward to
> expose
> > them.
>
> Yep. It's needed for porting the DefaultServlet to Resources.
>
Sounds like appropriate things to expose through the Resources interface.
>
> > One thing that is not visible (somewhat to my surprise) is any notion of
> > "created timestamp" through any of the Java APIs. I hope there is nothing
> in
> > WebDAV that critically requires this.
>
> I forgot that one, and indeed it's needed. We can add the function and let
> the implementation return whatever it wants (like the last modified date
> ...).
>
OK
>
> > > WebDAV requires write access :
> > > - boolean setResource(String path, InputStream content)
> > > Write a resource. Return false if the content was not written if the
> given
> > > path denotes a collection of if no parent collection exists for this
> > > resource.
> > > - boolean createCollection(String path)
> > > Creates a new empty collection. isCollection(path) would return true
> after
> > > making that call. The call returns false if a resource already exist, or
> if
> > > additional intermediate collections need to be created before.
> > > - void deleteResource(String path)
> > > Deletes the resource denoted by the path. Only "normal" resources and
> empty
> > > dirs can be deleted, etc, etc ...
> >
> > While we don't have to wait for a Tomcat-specific WebDAV implementation,
> some
> > mechanism to deal with writeable resources is being discussed in the
> context of
> > Servlet 2.3.
>
> Of course, if compatibility to the spec ends up being a requirement, it will
> have to be implemented on top of the filesystem.
>
> Remy
>
Craig
[Catalina] Re: WebDAV, DefaultServlet and Resources
Posted by Remy Maucherat <re...@apache.org>.
> Remy Maucherat wrote:
>
> > Hi,
> >
> > I'd like to discuss here some features and enhancements I plan to make
in
> > Catalina.
> >
> > * WebDAV support
> >
> > A servlet will provide WebDAV level 2 capabilities. It can be seen as a
> > merge between the DefaultServlet and a simplified version of the
> > WebdavServlet from the Slide project (and cleared of Slide dependencies,
of
> > course). This servlet could be designed to use the filesystem directly.
> > Instead, for additional flexibility and abstraction, I plan to use the
> > Resources interface (well, an extended version of it, since there are no
> > write methods in that interface as of now - see below).
> >
>
> The goal should be that the default servlet, in whatever form, should work
> whether the underlying document storage is a filesystem, a WAR file, BLOB
> objects in a database -- all abstracted by the Resources interface in
Catalina
> so that the servlet itself need not know or care the underlying
persistence
> mechanism.
With the extensions proposed below, we'll be able to switch to Resources.
> > * DefaultServlet
> >
> > DefaultServlet will be modified to also use the Resources interface. If
> > performance turns out to be good enough, I suggest completely removing
any
> > direct filesystem access. Some additions will be needed to Resources,
> > though, like the possibility to access directories through the
interface, or
> > just retrieving the content length of a resource, when it's known.
> >
>
> You will want to check out the enhancements I added to today to the
Resources
> implementation classes, which (among other things) support the
configurable
> caching that is currently in the default servlet. That way, the caching
> benefits will accrue to any application that uses
> ServletContext.getResourceAsStream(), not just the default servlet's
support for
> caching static files. Two initial implementations are included -- one
that runs
> out of the filesystem (which is all that Tomcat 3.x supports), and one
that runs
> from a JAR file, which can be either local or remote (courtesy of the JAR
file
> URLStreamHandler built into the JDK).
I saw that. Slide does just that too (it has caching at the storage
abstraction layer).
BTW, should I add a WAR unziping feature to
StandardContext.setWorkDirectory() (just like Tomcat 3.x does), or will WAR
files be accessed through Resources (which might be slower) ?
> Extra stuff that is known to the underlying Resources implementation, can
be
> made available as well. Of course, any servlet that depends on this stuff
will
> be specific to this implementation.
If the functions below are added, it will be ok.
> > * Resources
> >
> > Right now, the interface provides the following functions :
> > - String getMimeType(String file)
> > - String getRealPath(String path)
> > - URL getResource(String path)
> > - InputStream getResourceAsStream(String path)
> >
>
> and getResourceModified() to return the last modified timestamp of the
specified
> resource.
Right. It was on my list, but I just forgot to write it down.
> > I think the following methods should be added for support in
DefaultServlet,
> > with the same level of functionality as standard filesystem :
> > - long getResourceLength(String path)
> > Returns -1 if unknown, 0 if no content (directory ...), or the content
> > length of the resource otherwise
> > - boolean isCollection(String path)
> > Returns true if the resource denoted by the given path is the functional
> > equivalent of a directory
> > - String[] getCollectionMembers(String path)
> > Returns the list of the paths of the resources which are member of the
> > collection denoted by the given path. null if the resource is not a
> > collection
>
> This seems reasonable. Any practical implementation of the Resources
interface
> will know all of the above things, so it should be straightforward to
expose
> them.
Yep. It's needed for porting the DefaultServlet to Resources.
> One thing that is not visible (somewhat to my surprise) is any notion of
> "created timestamp" through any of the Java APIs. I hope there is nothing
in
> WebDAV that critically requires this.
I forgot that one, and indeed it's needed. We can add the function and let
the implementation return whatever it wants (like the last modified date
...).
> > WebDAV requires write access :
> > - boolean setResource(String path, InputStream content)
> > Write a resource. Return false if the content was not written if the
given
> > path denotes a collection of if no parent collection exists for this
> > resource.
> > - boolean createCollection(String path)
> > Creates a new empty collection. isCollection(path) would return true
after
> > making that call. The call returns false if a resource already exist, or
if
> > additional intermediate collections need to be created before.
> > - void deleteResource(String path)
> > Deletes the resource denoted by the path. Only "normal" resources and
empty
> > dirs can be deleted, etc, etc ...
>
> While we don't have to wait for a Tomcat-specific WebDAV implementation,
some
> mechanism to deal with writeable resources is being discussed in the
context of
> Servlet 2.3.
Of course, if compatibility to the spec ends up being a requirement, it will
have to be implemented on top of the filesystem.
Remy
Re: WebDAV, DefaultServlet and Resources
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Remy Maucherat wrote:
> Hi,
>
> I'd like to discuss here some features and enhancements I plan to make in
> Catalina.
>
> * WebDAV support
>
> A servlet will provide WebDAV level 2 capabilities. It can be seen as a
> merge between the DefaultServlet and a simplified version of the
> WebdavServlet from the Slide project (and cleared of Slide dependencies, of
> course). This servlet could be designed to use the filesystem directly.
> Instead, for additional flexibility and abstraction, I plan to use the
> Resources interface (well, an extended version of it, since there are no
> write methods in that interface as of now - see below).
>
The goal should be that the default servlet, in whatever form, should work
whether the underlying document storage is a filesystem, a WAR file, BLOB
objects in a database -- all abstracted by the Resources interface in Catalina
so that the servlet itself need not know or care the underlying persistence
mechanism.
>
> * DefaultServlet
>
> DefaultServlet will be modified to also use the Resources interface. If
> performance turns out to be good enough, I suggest completely removing any
> direct filesystem access. Some additions will be needed to Resources,
> though, like the possibility to access directories through the interface, or
> just retrieving the content length of a resource, when it's known.
>
You will want to check out the enhancements I added to today to the Resources
implementation classes, which (among other things) support the configurable
caching that is currently in the default servlet. That way, the caching
benefits will accrue to any application that uses
ServletContext.getResourceAsStream(), not just the default servlet's support for
caching static files. Two initial implementations are included -- one that runs
out of the filesystem (which is all that Tomcat 3.x supports), and one that runs
from a JAR file, which can be either local or remote (courtesy of the JAR file
URLStreamHandler built into the JDK).
Extra stuff that is known to the underlying Resources implementation, can be
made available as well. Of course, any servlet that depends on this stuff will
be specific to this implementation.
>
> * Resources
>
> Right now, the interface provides the following functions :
> - String getMimeType(String file)
> - String getRealPath(String path)
> - URL getResource(String path)
> - InputStream getResourceAsStream(String path)
>
and getResourceModified() to return the last modified timestamp of the specified
resource.
>
> I think the following methods should be added for support in DefaultServlet,
> with the same level of functionality as standard filesystem :
> - long getResourceLength(String path)
> Returns -1 if unknown, 0 if no content (directory ...), or the content
> length of the resource otherwise
> - boolean isCollection(String path)
> Returns true if the resource denoted by the given path is the functional
> equivalent of a directory
> - String[] getCollectionMembers(String path)
> Returns the list of the paths of the resources which are member of the
> collection denoted by the given path. null if the resource is not a
> collection
>
This seems reasonable. Any practical implementation of the Resources interface
will know all of the above things, so it should be straightforward to expose
them.
One thing that is not visible (somewhat to my surprise) is any notion of
"created timestamp" through any of the Java APIs. I hope there is nothing in
WebDAV that critically requires this.
>
> WebDAV requires write access :
> - boolean setResource(String path, InputStream content)
> Write a resource. Return false if the content was not written if the given
> path denotes a collection of if no parent collection exists for this
> resource.
> - boolean createCollection(String path)
> Creates a new empty collection. isCollection(path) would return true after
> making that call. The call returns false if a resource already exist, or if
> additional intermediate collections need to be created before.
> - void deleteResource(String path)
> Deletes the resource denoted by the path. Only "normal" resources and empty
> dirs can be deleted, etc, etc ...
>
While we don't have to wait for a Tomcat-specific WebDAV implementation, some
mechanism to deal with writeable resources is being discussed in the context of
Servlet 2.3.
>
> Feel free to give me some feedback on these plans.
>
> Remy
>
Craig McClanahan
WebDAV, DefaultServlet and Resources
Posted by Remy Maucherat <re...@apache.org>.
Hi,
I'd like to discuss here some features and enhancements I plan to make in
Catalina.
* WebDAV support
A servlet will provide WebDAV level 2 capabilities. It can be seen as a
merge between the DefaultServlet and a simplified version of the
WebdavServlet from the Slide project (and cleared of Slide dependencies, of
course). This servlet could be designed to use the filesystem directly.
Instead, for additional flexibility and abstraction, I plan to use the
Resources interface (well, an extended version of it, since there are no
write methods in that interface as of now - see below).
* DefaultServlet
DefaultServlet will be modified to also use the Resources interface. If
performance turns out to be good enough, I suggest completely removing any
direct filesystem access. Some additions will be needed to Resources,
though, like the possibility to access directories through the interface, or
just retrieving the content length of a resource, when it's known.
* Resources
Right now, the interface provides the following functions :
- String getMimeType(String file)
- String getRealPath(String path)
- URL getResource(String path)
- InputStream getResourceAsStream(String path)
I think the following methods should be added for support in DefaultServlet,
with the same level of functionality as standard filesystem :
- long getResourceLength(String path)
Returns -1 if unknown, 0 if no content (directory ...), or the content
length of the resource otherwise
- boolean isCollection(String path)
Returns true if the resource denoted by the given path is the functional
equivalent of a directory
- String[] getCollectionMembers(String path)
Returns the list of the paths of the resources which are member of the
collection denoted by the given path. null if the resource is not a
collection
WebDAV requires write access :
- boolean setResource(String path, InputStream content)
Write a resource. Return false if the content was not written if the given
path denotes a collection of if no parent collection exists for this
resource.
- boolean createCollection(String path)
Creates a new empty collection. isCollection(path) would return true after
making that call. The call returns false if a resource already exist, or if
additional intermediate collections need to be created before.
- void deleteResource(String path)
Deletes the resource denoted by the path. Only "normal" resources and empty
dirs can be deleted, etc, etc ...
Feel free to give me some feedback on these plans.
Remy
Re: [catalina] build.xml bugs?
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Geoff Soutter wrote:
> Hi there
>
> looks like the current build.xml/catalina.bat is broken
>
> when you try and start it, it doesn't have access to the XmlMapper.
>
> looks to me as if the fix is to extend the build.xml to include jasper.jar
> to include utils/** rather than just utils/*, but I'm only guessing.
>
I'm specific about the "*" because Jasper itself does not need anything
in the
subdirectories -- in particular, Jasper does not use XmlMapper to read
XML
files.
I suspect this problem is related to your previous problem building
Tomcat
itself. If that job doesn't complete correctly, Catalina won't build
correctly
either. (I just did clean builds of both and they worked for me, and
both
executed).
>
> also, I think the readme could be more clear about where jaxp is expected to
> be installed ;-)
>
I just updated the Catalina README to reflect the current instructions.
>
> cheers
>
> Geoff
>
Craig
Re: [catalina] build.xml bugs?
Posted by Remy Maucherat <re...@apache.org>.
> Hi there
>
> looks like the current build.xml/catalina.bat is broken
>
> when you try and start it, it doesn't have access to the XmlMapper.
Actually, what happens is that the class loader doesn't load XmlMapper,
because it can't find JAXP. Drop JAXP and the implementing parser in the lib
subdirectory and it will work.
> looks to me as if the fix is to extend the build.xml to include jasper.jar
> to include utils/** rather than just utils/*, but I'm only guessing.
>
> also, I think the readme could be more clear about where jaxp is expected
to
> be installed ;-)
True :-)
Remy