URL serializer raises "Write Operation not supported" exceptions

Hi,

I am trying to use the URL Serializer with a 3.0 build taken from CVS this
afternoon and, even when I am using the oxf: protocol, I get a "Write
Operation not supported" exception...

The spec says that "The Filesystem  resource manager is the only Resource
Manager supporting write operations." but I am running the default
resource manager.

Thanks,

Eric

PS: also, most of the examples spit
org.orbeon.oxf.common.ValidationException "Warning: At least one 'include'
or 'fallback' element in the document is bound to the old
''http://www.w3.org/2001/XInclude'' namespace. This namespace is no longer
processed. The namespace ''http://www.w3.org/2003/XInclude'' must be used
for XInclude processing." when you try to view their source.




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

> Hi,
>
> I am trying to use the URL Serializer with a 3.0 build taken from CVS this
> afternoon and, even when I am using the oxf: protocol, I get a "Write
> Operation not supported" exception...
>
> The spec says that "The Filesystem  resource manager is the only Resource
> Manager supporting write operations." but I am running the default
> resource manager.

Hmmm... the stack trace suggests that the PriorityResourceManager is
involved:

org.orbeon.oxf.resources.WebAppResourceManagerImpl   getWriter
        WebAppResourceManagerImpl.java   131
org.orbeon.oxf.resources.ResourceManagerBase getWriteContentHandler
        ResourceManagerBase.java 295
org.orbeon.oxf.resources.PriorityResourceManagerImpl$12 run
        PriorityResourceManagerImpl.java 201
org.orbeon.oxf.resources.PriorityResourceManagerImpl delegate
        PriorityResourceManagerImpl.java 241
org.orbeon.oxf.resources.PriorityResourceManagerImpl
        getWriteContentHandler PriorityResourceManagerImpl.java 199
org.orbeon.oxf.processor.serializer.URLSerializer start
        URLSerializer.java 68

When it gets a write request, the PriorityResourceManager should be clever
enough to choose the first resource manager that supports a write
operation... Isn't it the case?

Eric





--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

>
> When it gets a write request, the PriorityResourceManager should be clever
> enough to choose the first resource manager that supports a write
> operation... Isn't it the case?

I had a look to the source and I think that there is a flaw in the design
of the canWrite() method of the ResourceManager interface:

    /**
     * Indicates if the resource manager implementation suports write
operations
     * @return true if write operations are allowed
     */
    public boolean canWrite();

For most of the resource managers, "canWrite" is independent of the URL
(except that it could also depend on permissions), but for the
PriorityResourceManager, this property should depend on the URL of the
resource since it should return the "canWrite" property of the resource
manager that will handle the URL.

I see two possible fixes for this issue:

1) a quick hack would be that the PriorityResourceManager, returns a "or"
of the "canWrite" properties of all its ResourceManagers. The effect would
be that an other exception would be risen later on if the actual
ResourceManager used for the actual resource can't write.
2) another solution would be to add a "URL" parameter to the canWrite
method so that a resource manager can check if it can write a specific
resource.

Now, this flaw isn't the reason why I am getting this exception since its
is raised in the getWriter method...

The stacktrace:

org.orbeon.oxf.resources.WebAppResourceManagerImpl          getWriter
        WebAppResourceManagerImpl.java          131
org.orbeon.oxf.resources.ResourceManagerBase         getWriteContentHandler
        ResourceManagerBase.java         295
org.orbeon.oxf.resources.PriorityResourceManagerImpl$12         run
        PriorityResourceManagerImpl.java         201
org.orbeon.oxf.resources.PriorityResourceManagerImpl         delegate
        PriorityResourceManagerImpl.java         241
org.orbeon.oxf.resources.PriorityResourceManagerImpl
        getWriteContentHandler         PriorityResourceManagerImpl.java  
     199
org.orbeon.oxf.processor.serializer.URLSerializer         start
        URLSerializer.java         68

shows that, for whatever reason, the PriorityResourceManager is selecting
the WebAppResourceManager to do this write operation...

When I update web.xml to use the FilesystemResourceManager instead of the
WebAppResourceManager this exception disapears.

The downside of the FilesystemResourceManager is that I have to give the
location of the orbeon WEBINF directory as the
oxf.resources.filesystem.sandbox-directory parameter.

Is there a way to use a relative path in this parameter?

Or couldn't the  WebAppResourceManager be able to support write operations
when the application isn't packaged in a war file?

Thanks,

Eric

Eric





--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Eric van der Vlist wrote:
> Hi,
>
> I am trying to use the URL Serializer with a 3.0 build taken from CVS this
> afternoon and, even when I am using the oxf: protocol, I get a "Write
> Operation not supported" exception...
>
> The spec says that "The Filesystem  resource manager is the only Resource
> Manager supporting write operations." but I am running the default
> resource manager.

By the default, you mean the WebApp resource manager? The Filesystem
resource manager doesn't appear in your web.xml? So the doc is correct,
you have to use the Filesystem resource manager at the moment for this
to work.

> PS: also, most of the examples spit
> org.orbeon.oxf.common.ValidationException "Warning: At least one 'include'
> or 'fallback' element in the document is bound to the old
> ''http://www.w3.org/2001/XInclude'' namespace. This namespace is no longer
> processed. The namespace ''http://www.w3.org/2003/XInclude'' must be used
> for XInclude processing." when you try to view their source.

Correct, I see that. Xerces is wrong: the "old" namespace is now the
correct one ;-) This said, our ErrorHandler should not throw an
exception upon a simple warning(). Fixing this. The Xerces warning will
disappear when we upgrade to the next version of Xerces or if/when we
decide to use our own XInclude processing all the way.

-Erik



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Le mardi 15 novembre 2005 à 00:12 +0100, Erik Bruchez a écrit : Yes, this is the one you get when you just unpack the war file...

> The Filesystem
> resource manager doesn't appear in your web.xml? So the doc is correct,
> you have to use the Filesystem resource manager at the moment for this
> to work.

The main downside is that (as far as I can see in my tests and in the
code) the oxf.resources.filesystem.sandbox-directory is expecting a file
path (and not an URI). This means that you can't easily ship a web.xml
with this parameter since it depends on the platform and installation
directory.

Would it be possible to allow to use URIs either in this parameter or as
an alternate parameter (oxf.resources.filesystem.sandbox-uri for
instance) and to accept the oxf: protocol?

Eric
--
Le premier annuaire des apiculteurs 100% XML!
                                                http://apiculteurs.info/
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
(ISO) RELAX NG   ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Eric van der Vlist wrote:

 > For most of the resource managers, "canWrite" is independent of the
 > URL (except that it could also depend on permissions), but for the
 > PriorityResourceManager, this property should depend on the URL of
 > the resource since it should return the "canWrite" property of the
 > resource manager that will handle the URL.

Resource managers in Orbeon PresentationServer are currently not
chosen depending on the URL. Either a unique resource manager is
specified in your web.xml, or the Priority resource manager goes
through one or more resource managers. But in theory yes, a resource
manager could decide to handle a path based on the value of that path.

In fact, canWrite() is currently never used in the code, but
getOutputStream() is used by the protocol handler for "oxf:", and
getWriter() is indirectly used by getWriteContentHandler() which is
used by the URL serializer (which uses the resource manager directly
and does not go through and URLConnection, probably for some
optimization reason). I found a few other funny thing in this URL
serializer, and I did some quick cleanup there.

 > I see two possible fixes for this issue:
 >
 > 1) a quick hack would be that the PriorityResourceManager, returns a
 > "or" of the "canWrite" properties of all its ResourceManagers. The
 > effect would be that an other exception would be risen later on if
 > the actual ResourceManager used for the actual resource can't write.

I fixed this behavior.

 > 2) another solution would be to add a "URL" parameter to the canWrite
 > method so that a resource manager can check if it can write a specific
 > resource.

I added the parameter, as I think it makes sense to have it.

 > Now, this flaw isn't the reason why I am getting this exception since its
 > is raised in the getWriter method...
 >
 > The stacktrace:

[...]

 > shows that, for whatever reason, the PriorityResourceManager is selecting
 > the WebAppResourceManager to do this write operation...

Yes, it first tries the first one, which doesn't support write
operations. It should not do this: it should try all of them and
choose the first one with canWrite() == true. I put this behavior in
place.

But this won't be enough to fix your problem, since you don't have a
Filesystem resource manager in place anyway.

 > When I update web.xml to use the FilesystemResourceManager instead of the
 > WebAppResourceManager this exception disapears.
 >
 > The downside of the FilesystemResourceManager is that I have to give the
 > location of the orbeon WEBINF directory as the
 > oxf.resources.filesystem.sandbox-directory parameter.
 >
 > Is there a way to use a relative path in this parameter?

No, the Filesystem resources manager really expects an absolute path
at this point. The question would be: to what would it be relative?

 > Or couldn't the  WebAppResourceManager be able to support write
operations
 > when the application isn't packaged in a war file?

I think this would be a better option. I tried to implement something
like this, but whether it will work will actually depend on how the
getRealPath() method of the servlet API is implemented, i.e. can you
use it with a path to something which does not yet exist?

I committed those changes, but I am not positive that they work at
this point ;-) Feel free to try them.

-Erik




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Eric van der Vlist wrote:

> The main downside is that (as far as I can see in my tests and in the
> code) the oxf.resources.filesystem.sandbox-directory is expecting a file
> path (and not an URI). This means that you can't easily ship a web.xml
> with this parameter since it depends on the platform and installation
> directory.
>
> Would it be possible to allow to use URIs either in this parameter or as
> an alternate parameter (oxf.resources.filesystem.sandbox-uri for
> instance) and to accept the oxf: protocol?

The problem is that the "oxf:" is implemented by... the resource
manager. So you could get into infinite loops here. I think that getting
the WebApp resource manager to support write operations is a better
strategy (if possible at all, see my other reply).

-Erik



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Le mardi 15 novembre 2005 à 01:08 +0100, Erik Bruchez a écrit : Great! Reading the code, I had the feeling its was maybe not as strong
as other classes :-) ...
Yes.
Same as oxf:/ ?

>  > Or couldn't the  WebAppResourceManager be able to support write
> operations
>  > when the application isn't packaged in a war file?
>
> I think this would be a better option. I tried to implement something
> like this, but whether it will work will actually depend on how the
> getRealPath() method of the servlet API is implemented, i.e. can you
> use it with a path to something which does not yet exist?

Yes, that can become touchy.

> I committed those changes, but I am not positive that they work at
> this point ;-) Feel free to try them.

They are working on my platform (Linux and -since yesterday's problems-
Tomcat) for the sandbox application that I had shipped as a repro case
yesterday (a save.xpl that writes the instance to file).

And that's working even if the file doesn't exist before being saved.

Thanks,

Eric

--
Carnet web :
           http://eric.van-der-vlist.com/blog?t=category&a=Fran%C3%A7ais
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
(ISO) RELAX NG   ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Eric van der Vlist wrote:

>>No, the Filesystem resources manager really expects an absolute path
>>at this point. The question would be: to what would it be relative?
>
>
> Same as oxf:/ ?

The Filesystem resource manager is just one possible implementation of
the "oxf:" protocol. "oxf:" is not really relative to anything.

When you use the WebApp resource manager, for example, you configure it
to say that you would like it to prepend some path (e.g.
"/WEB-INF/resources") to the path provided after "oxf:" (e.g.
"/config/properties.xml"). This is what tells the resource manager where
your resources sandbox is. Then the WebApp resource manager uses the
Servlet API to retrieve a resource called
"/WEB-INF/resources/config/properties.xml".

If you use the Filesystem resource manager, then you specify a base
directory on disk. Again in this case, this is what tells the resource
manager where the resources sandbox is. That directory has to be
absolute... or relative to what? You could implement a trick and say "I
would like the base directory of the Filesystem resource manager to be
the same directory as '/WEB-INF/resources', assuming you can find using
the Servlet API where that is located on disk". But that would be
far-fetched. Better then try to make the WebApp resource manager be able
to write whenever it can, which is what I have tried to implement.

> They are working on my platform (Linux and -since yesterday's problems-
> Tomcat) for the sandbox application that I had shipped as a repro case
> yesterday (a save.xpl that writes the instance to file).
>
> And that's working even if the file doesn't exist before being saved.

Great!

-Erik



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws