| 
Database Engines/Servers
 » 
eXist
 » 
exist-open

catch errors for request:get-uploaded-file()

View: New views
8 Messages — Rating Filter:   Alert me  

catch errors for request:get-uploaded-file()

by ron.vandenbranden :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi,

I have a web application served through the eXist servlet via Cocoon,
that allows users to upload files using the
request:get-uploaded-file($upload-param-name as xs:string) function. I
wonder how I can warn users when their file exceeds the file size limit
(or when other things go wrong). Currently, the sole feedback in such
cases is a stack trace on STDOUT:
    "java.io.IOException: Multipart element '[...]' is too large ([...]
bytes) and was discarded.
     at
org.apache.cocoon.servlet.multipart.RejectedPart.getInputStream(RejectedPart.java:81)
     [...]"

Is there a way to catch this exception and use it to distill useful user
feedback from it (I've looked at the browse.xqm module in eXist's admin
webapp, but no clues there)? I tried to wrap the function in a
util:catch() function:
    util:catch("java.io.IOException",
            request:get-uploaded-file("upload"),
         $util:exception-message
         )

But this does not make the error message available to the XQuery. What
am I doing wrong (as a Java-illiterate, util:catch() seemed a plausible
approach to me)?

Thanks for any suggestions,

Ron Van den Branden

--
Ron Van den Branden
Wetenschappelijk Attaché
Centrum voor Teksteditie en Bronnenstudie (CTB)
Koninklijke Academie voor Nederlandse Taal- en Letterkunde (KANTL)
Koningstraat 18  B-9000 Gent
Tel: +32 9 265 93 53 / Fax: +32 9 265 93 49
E-mail : ron.vandenbranden@...
www.kantl.be/ctb


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Exist-open mailing list
Exist-open@...
https://lists.sourceforge.net/lists/listinfo/exist-open

Re: catch errors for request:get-uploaded-file()

by Adam Retter-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hmmm... I am wondering if this is more of a Cocoon issue than an
eXist/XQuery one. How are you limiting the size of your upload files?

Also can you post the full stack trace please?

2009/11/6 Ron Van den Branden <ron.vandenbranden@...>:

> Hi,
>
> I have a web application served through the eXist servlet via Cocoon,
> that allows users to upload files using the
> request:get-uploaded-file($upload-param-name as xs:string) function. I
> wonder how I can warn users when their file exceeds the file size limit
> (or when other things go wrong). Currently, the sole feedback in such
> cases is a stack trace on STDOUT:
>    "java.io.IOException: Multipart element '[...]' is too large ([...]
> bytes) and was discarded.
>     at
> org.apache.cocoon.servlet.multipart.RejectedPart.getInputStream(RejectedPart.java:81)
>     [...]"
>
> Is there a way to catch this exception and use it to distill useful user
> feedback from it (I've looked at the browse.xqm module in eXist's admin
> webapp, but no clues there)? I tried to wrap the function in a
> util:catch() function:
>    util:catch("java.io.IOException",
>            request:get-uploaded-file("upload"),
>         $util:exception-message
>         )
>
> But this does not make the error message available to the XQuery. What
> am I doing wrong (as a Java-illiterate, util:catch() seemed a plausible
> approach to me)?
>
> Thanks for any suggestions,
>
> Ron Van den Branden
>
> --
> Ron Van den Branden
> Wetenschappelijk Attaché
> Centrum voor Teksteditie en Bronnenstudie (CTB)
> Koninklijke Academie voor Nederlandse Taal- en Letterkunde (KANTL)
> Koningstraat 18  B-9000 Gent
> Tel: +32 9 265 93 53 / Fax: +32 9 265 93 49
> E-mail : ron.vandenbranden@...
> www.kantl.be/ctb
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Exist-open mailing list
> Exist-open@...
> https://lists.sourceforge.net/lists/listinfo/exist-open
>



--
Adam Retter

eXist Developer
{ United Kingdom }
adam@...
irc://irc.freenode.net/existdb

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Exist-open mailing list
Exist-open@...
https://lists.sourceforge.net/lists/listinfo/exist-open

Re: catch errors for request:get-uploaded-file()

by ron.vandenbranden :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi Adam,

For the record: the file upload limit is definitely a Cocoon issue: I've
found that the default Cocoon settings are very restrictive. The problem
itself can be solved by adapting these settings in web.xml:
    <!--
      Specify maximum allowed size of the upload. Defaults to 10 Mb.
      Set here to a very low 100 kb to allow samples to run.
    -->
    <init-param>
      <param-name>upload-max-size</param-name>
      <param-value>102400</param-value>
    </init-param>

When the uploaded file's size exceeds this limit, the attached error
(upload.trace) is printed to STDOUT (tried much to get it properly
logged, without success). The xquery itself
(request:get-uploaded-file("upload")) produces no error, however, but is
it possible to let it catch any exceptions or errors?

Thanks for your help!

Ron


Adam Retter schreef:
> Hmmm... I am wondering if this is more of a Cocoon issue than an
> eXist/XQuery one. How are you limiting the size of your upload files?
>
> Also can you post the full stack trace please?
>
> 2009/11/6 Ron Van den Branden <ron.vandenbranden@...>:
>  

--
Ron Van den Branden
Wetenschappelijk Attaché
Centrum voor Teksteditie en Bronnenstudie (CTB)
Koninklijke Academie voor Nederlandse Taal- en Letterkunde (KANTL)
Koningstraat 18  B-9000 Gent
Tel: +32 9 265 93 53 / Fax: +32 9 265 93 49
E-mail : ron.vandenbranden@...
www.kantl.be/ctb


java.io.IOException: Multipart element 'TBED02v00.xml' is too large (193549 bytes) and was discarded.
        at org.apache.cocoon.servlet.multipart.RejectedPart.getInputStream(RejectedPart.java:81)
        at org.exist.cocoon.CocoonRequestWrapper.getFileUploadParam(CocoonRequestWrapper.java:349)
        at org.exist.xquery.functions.request.GetUploadedFile.eval(GetUploadedFile.java:81)
        at org.exist.xquery.BasicFunction.eval(BasicFunction.java:68)
        at org.exist.xquery.InternalFunctionCall.eval(InternalFunctionCall.java:49)
        at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:59)
        at org.exist.xquery.PathExpr.eval(PathExpr.java:238)
        at org.exist.xquery.LetExpr.eval(LetExpr.java:150)
        at org.exist.xquery.LetExpr.eval(LetExpr.java:201)
        at org.exist.xquery.BindingExpression.eval(BindingExpression.java:144)
        at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:59)
        at org.exist.xquery.PathExpr.eval(PathExpr.java:238)
        at org.exist.xquery.ConditionalExpression.eval(ConditionalExpression.java:99)
        at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:59)
        at org.exist.xquery.PathExpr.eval(PathExpr.java:238)
        at org.exist.xquery.VariableDeclaration.eval(VariableDeclaration.java:111)
        at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:59)
        at org.exist.xquery.PathExpr.eval(PathExpr.java:238)
        at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:59)
        at org.exist.xquery.XQuery.execute(XQuery.java:217)
        at org.exist.xquery.XQuery.execute(XQuery.java:184)
        at org.exist.xmldb.LocalXPathQueryService.execute(LocalXPathQueryService.java:190)
        at org.exist.cocoon.XQueryGenerator.generate(XQueryGenerator.java:330)
        at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:579)
        at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:279)
        at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:481)
        at org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:121)
        at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:47)
        at org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:108)
        at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:69)
        at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:143)
        at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:69)
        at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:93)
        at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:235)
        at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:177)
        at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:253)
        at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:118)
        at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:47)
        at org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:108)
        at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:69)
        at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:143)
        at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:69)
        at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:93)
        at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:235)
        at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:177)
        at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:253)
        at org.apache.cocoon.Cocoon.process(Cocoon.java:699)
        at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1154)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
        at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358)
        at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294)
        at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567)
        at org.mortbay.http.HttpContext.handle(HttpContext.java:1807)
        at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:525)
        at org.mortbay.http.HttpContext.handle(HttpContext.java:1757)
        at org.mortbay.http.HttpServer.service(HttpServer.java:879)
        at org.mortbay.http.HttpConnection.service(HttpConnection.java:789)
        at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:960)
        at org.mortbay.http.HttpConnection.handle(HttpConnection.java:806)
        at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:218)
        at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:300)
        at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:511)


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Exist-open mailing list
Exist-open@...
https://lists.sourceforge.net/lists/listinfo/exist-open

Re: catch errors for request:get-uploaded-file()

by Adam Retter-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

You may be able to do something with the util method - util:catch()

Have a go at that and see if it helps.

If not (and perhaps anyways), we should add some refinement to the
request:get-uploaded-file() function...


2009/11/6 Ron Van den Branden <ron.vandenbranden@...>:

> Hi Adam,
>
> For the record: the file upload limit is definitely a Cocoon issue: I've
> found that the default Cocoon settings are very restrictive. The problem
> itself can be solved by adapting these settings in web.xml:
>   <!--
>     Specify maximum allowed size of the upload. Defaults to 10 Mb.
>     Set here to a very low 100 kb to allow samples to run.
>   -->
>   <init-param>
>     <param-name>upload-max-size</param-name>
>     <param-value>102400</param-value>
>   </init-param>
>
> When the uploaded file's size exceeds this limit, the attached error
> (upload.trace) is printed to STDOUT (tried much to get it properly logged,
> without success). The xquery itself (request:get-uploaded-file("upload"))
> produces no error, however, but is it possible to let it catch any
> exceptions or errors?
>
> Thanks for your help!
>
> Ron
>
>
> Adam Retter schreef:
>>
>> Hmmm... I am wondering if this is more of a Cocoon issue than an
>> eXist/XQuery one. How are you limiting the size of your upload files?
>>
>> Also can you post the full stack trace please?
>>
>> 2009/11/6 Ron Van den Branden <ron.vandenbranden@...>:
>>
>
> --
> Ron Van den Branden
> Wetenschappelijk Attaché
> Centrum voor Teksteditie en Bronnenstudie (CTB)
> Koninklijke Academie voor Nederlandse Taal- en Letterkunde (KANTL)
> Koningstraat 18  B-9000 Gent
> Tel: +32 9 265 93 53 / Fax: +32 9 265 93 49
> E-mail : ron.vandenbranden@...
> www.kantl.be/ctb
>
>
> java.io.IOException: Multipart element 'TBED02v00.xml' is too large (193549
> bytes) and was discarded.
>        at
> org.apache.cocoon.servlet.multipart.RejectedPart.getInputStream(RejectedPart.java:81)
>        at
> org.exist.cocoon.CocoonRequestWrapper.getFileUploadParam(CocoonRequestWrapper.java:349)
>        at
> org.exist.xquery.functions.request.GetUploadedFile.eval(GetUploadedFile.java:81)
>        at org.exist.xquery.BasicFunction.eval(BasicFunction.java:68)
>        at
> org.exist.xquery.InternalFunctionCall.eval(InternalFunctionCall.java:49)
>        at
> org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:59)
>        at org.exist.xquery.PathExpr.eval(PathExpr.java:238)
>        at org.exist.xquery.LetExpr.eval(LetExpr.java:150)
>        at org.exist.xquery.LetExpr.eval(LetExpr.java:201)
>        at
> org.exist.xquery.BindingExpression.eval(BindingExpression.java:144)
>        at
> org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:59)
>        at org.exist.xquery.PathExpr.eval(PathExpr.java:238)
>        at
> org.exist.xquery.ConditionalExpression.eval(ConditionalExpression.java:99)
>        at
> org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:59)
>        at org.exist.xquery.PathExpr.eval(PathExpr.java:238)
>        at
> org.exist.xquery.VariableDeclaration.eval(VariableDeclaration.java:111)
>        at
> org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:59)
>        at org.exist.xquery.PathExpr.eval(PathExpr.java:238)
>        at
> org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:59)
>        at org.exist.xquery.XQuery.execute(XQuery.java:217)
>        at org.exist.xquery.XQuery.execute(XQuery.java:184)
>        at
> org.exist.xmldb.LocalXPathQueryService.execute(LocalXPathQueryService.java:190)
>        at
> org.exist.cocoon.XQueryGenerator.generate(XQueryGenerator.java:330)
>        at
> org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:579)
>        at
> org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:279)
>        at
> org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:481)
>        at
> org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:121)
>        at
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:47)
>        at
> org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:108)
>        at
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:69)
>        at
> org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:143)
>        at
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:69)
>        at
> org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:93)
>        at
> org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:235)
>        at
> org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:177)
>        at
> org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:253)
>        at
> org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:118)
>        at
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:47)
>        at
> org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:108)
>        at
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:69)
>        at
> org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:143)
>        at
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:69)
>        at
> org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:93)
>        at
> org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:235)
>        at
> org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:177)
>        at
> org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:253)
>        at org.apache.cocoon.Cocoon.process(Cocoon.java:699)
>        at
> org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1154)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>        at
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358)
>        at
> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294)
>        at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567)
>        at org.mortbay.http.HttpContext.handle(HttpContext.java:1807)
>        at
> org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:525)
>        at org.mortbay.http.HttpContext.handle(HttpContext.java:1757)
>        at org.mortbay.http.HttpServer.service(HttpServer.java:879)
>        at org.mortbay.http.HttpConnection.service(HttpConnection.java:789)
>        at
> org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:960)
>        at org.mortbay.http.HttpConnection.handle(HttpConnection.java:806)
>        at
> org.mortbay.http.SocketListener.handleConnection(SocketListener.java:218)
>        at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:300)
>        at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:511)
>
>
>



--
Adam Retter

eXist Developer
{ United Kingdom }
adam@...
irc://irc.freenode.net/existdb

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Exist-open mailing list
Exist-open@...
https://lists.sourceforge.net/lists/listinfo/exist-open

Re: catch errors for request:get-uploaded-file()

by ron.vandenbranden :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi,

Adam Retter schreef:
> You may be able to do something with the util method - util:catch()
>
> Have a go at that and see if it helps.
>
>  
I don't think this works (unless I'm doing something wrong):

util:catch("java.io.IOException",
            request:get-uploaded-file("upload"),
         $util:exception-message
         )

...doesn't return any exception message, while it is flagged on STDOUT.
Even changing the first argument to "*" ("An entry of '*' will catch all
java exceptions.", according to the docs) doesn't catch anything.

Ron

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Exist-open mailing list
Exist-open@...
https://lists.sourceforge.net/lists/listinfo/exist-open

Re: catch errors for request:get-uploaded-file()

by Adam Retter-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Ah okay, I guess the exception is not passed up to eXist from Cocoon
then. This may be something that is beyond our control.

Have you considered implementing the file size checking in eXist as
opposed to Cocoon, or do you have to use Cocoon for this?

2009/11/6 Ron Van den Branden <ron.vandenbranden@...>:

> Hi,
>
> Adam Retter schreef:
>>
>> You may be able to do something with the util method - util:catch()
>>
>> Have a go at that and see if it helps.
>>
>>
>
> I don't think this works (unless I'm doing something wrong):
>
> util:catch("java.io.IOException",
>           request:get-uploaded-file("upload"),
>        $util:exception-message
>        )
>
> ...doesn't return any exception message, while it is flagged on STDOUT. Even
> changing the first argument to "*" ("An entry of '*' will catch all java
> exceptions.", according to the docs) doesn't catch anything.
>
> Ron
>



--
Adam Retter

eXist Developer
{ United Kingdom }
adam@...
irc://irc.freenode.net/existdb

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Exist-open mailing list
Exist-open@...
https://lists.sourceforge.net/lists/listinfo/exist-open

Re: catch errors for request:get-uploaded-file()

by ron.vandenbranden :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi,

Adam Retter schreef:
> Ah okay, I guess the exception is not passed up to eXist from Cocoon
> then. This may be something that is beyond our control.
>
>  
Ok,
> Have you considered implementing the file size checking in eXist as
> opposed to Cocoon, or do you have to use Cocoon for this?
>
>  
Do you mean: using the same code, but swapping Cocoon for using eXist's
own URLrewrite mechanism? Would that make such exceptions accessible to
eXist?

Currently, all our eXist applications are served with Cocoon, so it
would require some effort. Maybe this is an option in the longer term.
With my limited skills (XQuery/XSLT), I see eXist's
request:get-uploaded-file() function as my sole access point to uploaded
files. Maybe an empty result from that function could be used as
indication that 'something' went wrong along the way.

Ron

--
Ron Van den Branden
Wetenschappelijk Attaché
Centrum voor Teksteditie en Bronnenstudie (CTB)
Koninklijke Academie voor Nederlandse Taal- en Letterkunde (KANTL)
Koningstraat 18  B-9000 Gent
Tel: +32 9 265 93 53 / Fax: +32 9 265 93 49
E-mail : ron.vandenbranden@...
www.kantl.be/ctb


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Exist-open mailing list
Exist-open@...
https://lists.sourceforge.net/lists/listinfo/exist-open

Re: catch errors for request:get-uploaded-file()

by Adam Retter-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

>> Have you considered implementing the file size checking in eXist as
>> opposed to Cocoon, or do you have to use Cocoon for this?
>>
>>
>
> Do you mean: using the same code, but swapping Cocoon for using eXist's own
> URLrewrite mechanism? Would that make such exceptions accessible to eXist?

Not quite. I was thinking just remove the limit in Cocoon, use
request:get-uploaded-file() and then check the size of it in the
XQuery and then take action based on that.

> Currently, all our eXist applications are served with Cocoon, so it would
> require some effort. Maybe this is an option in the longer term. With my
> limited skills (XQuery/XSLT), I see eXist's request:get-uploaded-file()
> function as my sole access point to uploaded files. Maybe an empty result
> from that function could be used as indication that 'something' went wrong
> along the way.

If the XQuery is failing silently and not throwing the exception then
it is unlikely that Cocoon passes the exception to eXist, which means
we cant do anything about it.

> Ron
>
> --
> Ron Van den Branden
> Wetenschappelijk Attaché
> Centrum voor Teksteditie en Bronnenstudie (CTB)
> Koninklijke Academie voor Nederlandse Taal- en Letterkunde (KANTL)
> Koningstraat 18  B-9000 Gent
> Tel: +32 9 265 93 53 / Fax: +32 9 265 93 49
> E-mail : ron.vandenbranden@...
> www.kantl.be/ctb
>
>



--
Adam Retter

eXist Developer
{ United Kingdom }
adam@...
irc://irc.freenode.net/existdb

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Exist-open mailing list
Exist-open@...
https://lists.sourceforge.net/lists/listinfo/exist-open
Free embeddable forum powered by Nabble Forum Help