----- Original Message -----
From: "Santiago Gala" <[EMAIL PROTECTED]>
To: "JetSpeed" <[EMAIL PROTECTED]>
Sent: Tuesday, November 21, 2000 12:17 PM
Subject: Re: Possible bugs with isLocal and "file://"
>
>
> Stephan Hesmer wrote:
>
> > There is possibly a new bug in Jetspeed, due to the changes to
EngineContext
> > and JetspeedServlet.
> >
> > The new getResource function in EngineContext returns an url to a
resource
> > on the server, which is normally local. For example:
> > It returns
"file:D:\jakarta-tomcat\webapps\ROOT/content/psml/default.psml"
> > for "/content/psml/default.psml"
> >
> > This causes several problems:
> > * the RSS portlet is not running anymore (in my case the Jetspeed
portlet),
> > and
> > * the url is not considered as local from Jetspeed (Jetspeed it looking
for
> > "file://")
> >
>
> Yes. Yesterday we noticed this bug and we are reserching it.
>
> >
> > While changing and testing it on my PC, I discovered several code
pieces,
> > which do not make sense or I simply do not understand:
> > * PortletFactory
> > //make sure that no one tries to instantiate a portlet with a
file
> > URL
> > if ( pc.getURL() != null && pc.getURL().indexOf( "file://" ) ==
0 )
> > {
> > String message = "Local URLs not served through HTTP to
prevent
> > security holes: " + pc.getURL();
> > Log.error( message );
> > throw new PortletException( message );
> > }
> > ok, before modifying EngineContext a local URL was represented by
> > "http://localhost:port/..." . But now, it is something like
"file:D:/....".
> > So, do we have luck that we are asking here for "file://" ? Surely, we
can
> > not rely on that information, because other servers than Tomcat could
return
> > "file://".
>
> In our copy, only Jetspeed.rss gets problems. The "remote" ones are
handled
> allright. I will look at differences WRT cvs to check for changes.
>
> >
> > On the other side, we will get a problem when fixing this code... nearly
> > every portlet is rejected and therefore not displayed
> >
> > * JetspeedDiskCache
> > //attempt to see if the user didn't specify a URL if they didn't
> > then
> > //assume it is localhost with the servlet port
> > if ( DiskCacheUtils.isLocal( url ) &&
> > url.indexOf("file://") == -1 ) {
> > Why do we ask here for isLocal and forbid "file://" ? Someone who knows
this
> > code better than me?
> >
> > * DiskCacheUtils
> > In this file you can find the isLocal function, which asks for
"file://"....
> > do I have to say anymore?
> >
> > There are some other files which are affected, but they are quite
simple.
> >
> > I think, that Jetspeed needs to recognize this type of URL (file:D:/...)
as
> > local, and therefore we have to change the files I mentioned above. Does
> > anybody know who wrote or modified the files or who is working on the
> > isLocal stuff?
>
> I am, thanks. We tried to deprecate file:/ URLs some time ago because they
> caused lots of problems dealing with the different jdk versions/servlet
> containers.
>
> To my understanding, file:D: is not a legal url, neither file:/D: is. A
file url
> is:
>
> file://server/path. When it is local, it is file:///path.
>
> An absolute path under windows is: /D:/... (See jdk documentation)
>
> So, a legal windows file url would be file:///D:/...
I played a little with urls myself. If you create an URL like file:///D:/...
with the class URL, it will be truncated to file:/D:/... . Some other
problems occured, if you are using file://D:/.. - this is accepted by the
URL class, but will break Jetspeed later.
> This fact has made lots of problems around, hence why we tried to forbid
file
> urls from the system. This way, you can use http: URLs, and server the
documents
> from anywhere in the internet, for instance having a farm of machines take
> "local" content from a content server.
>
> I am investigating this issue and will report when I find something.
>
> We are also also breaking Cocoon Portlets, so that if you recompile any
Cocoon
> portlet, it will not work anymore.
Perhaps this is interesting for you:
On WebSphere the function getResource returns NOT "file:" but "classloader:"
!!!
Michael, who discovered a similar error, and I are working on it, to get a
fix.
If we have a good fix, we will post it.
Stephan
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://marc.theaimsgroup.com/?l=jetspeed>
Problems?: [EMAIL PROTECTED]
