Stephan Hesmer wrote:
> ----- 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.
>
The first case depends on the jdk version, I think it is a bug in jdk1.3
The second would be interpreted as whatever file in server D:, whi is nonsense,
and gives errors like "unable to find host D".
>
> > 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:"
> !!!
I think classloader uses the classloader ot the class to get resources,
following the CLASSPATH. This allows for resources to be stored in jar files,
and be managed by applications, or similarly, executed from a "sealed" WAR file.
It will not do for external or writable resources, since they are out of our
environment, or else we cannotwrite to them.
In the servlet API documentation, they suggest that a container implementor
should implement their own private protocol to deal with resources. I am
thinking about that to end with these problems.
getResource would return a private protocol url, like jetspeed: , or jrm:
(jetspeed resource manager) and then the protocol handler would take care of
caching, expiration, security, etc. through configuration. This would be the
single entry point to the urlmanager and resource manager.
This would mean that, when you ask for a url for, let's say
/channel/MTV.rss, Jetpseed will ask the configured content manager for this
channel, as
jcm://contentserver:port/repository/channel/MTV.rss
The resource management service would wrap it as
jrm://resourceserver:port/resourcepool/jcm://contentserver:port/repository/channel/MTV.rss
The code would use these urls, and the container would return Writers, Readers,
Connections, etc. to these resources, in a transparent way. This would
completely substitute our current JetspeedDiskCacheEntry, which would turn, in
fact, to a JetspeedResourceURL class, handled through standard java.net.*
classes.
The resource manager would take care of synchronising/serializing access to
resources, and also of caching of responses, if advisable. Some of the resources
would point to local content managers, some other could point to remote content
managers or other places.
The content manager would take care of versioning, access rights, and locking of
the resources managed by it.
This is the direction I was taking when adding getReader and getWriter to the
JetspeedDiskCacheEntry, but it would require no changes in container or portlet
developer code.
What do you think about this approach?
>
> 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.
Thanks.
>
>
> 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]
--
--------------------------------------------------------------
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]
