You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Pier Fumagalli <pi...@betaversion.org> on 2003/02/06 21:12:56 UTC

New CocoonServlet throws NullPointerException...

Vadim, your last changes to the cocoon servlet are throwing me a NPE...

java.lang.NullPointerException
        at 
org.apache.cocoon.components.notification.DefaultNotifyingBuilder.build(Defa
ultNotifyingBuilder.java:152)
        at 
org.apache.cocoon.components.notification.DefaultNotifyingBuilder.build(Defa
ultNotifyingBuilder.java:176)
        at 
org.apache.cocoon.servlet.CocoonServlet.manageException(CocoonServlet.java:1
189)
        at 
org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1092)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
        at 
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:360)
        at 
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandl
er.java:280)
        at 
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:553)
        at org.mortbay.http.HttpContext.handle(HttpContext.java:1717)
        at 
org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext
.java:549)
        at org.mortbay.http.HttpContext.handle(HttpContext.java:1667)
        at org.mortbay.http.HttpServer.service(HttpServer.java:862)
        at org.mortbay.http.HttpConnection.service(HttpConnection.java:759)
        at 
org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:923)
        at org.mortbay.http.HttpConnection.handle(HttpConnection.java:776)
        at 
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:202)
        at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:289)
        at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:455)

This is my sitemap, and of course, I don't have "index.xml" on the disk...

  <map:pipelines>
    <map:pipeline>
      <map:match pattern="">
        <map:redirect-to uri="index.xml"/>
      </map:match>

      <map:match pattern="*">
        <map:generate name="file" src="{1}"/>
        <map:serialize type="xml"/>
      </map:match>

    <map:handle-errors type="*">
      <map:serialize type="xml"/>
    </map:handle-errors>
      
    </map:pipeline>
  </map:pipelines>

Well, anyhow, this fixes it...

Index: org/apache/cocoon/servlet/CocoonServlet.java
===================================================================
RCS file: 
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/servlet/CocoonServlet.java,
v
retrieving revision 1.47
diff -u -3 -r1.47 CocoonServlet.java
--- org/apache/cocoon/servlet/CocoonServlet.java        2 Feb 2003 23:35:36
-0000       1.47
+++ org/apache/cocoon/servlet/CocoonServlet.java        6 Feb 2003 20:10:17
-0000
@@ -1175,7 +1175,6 @@
                 if (e != null) {
                     extraDescriptions.put(Notifying.EXTRA_CAUSE,
                   
DefaultNotifyingBuilder.getRootCause(e).getMessage());
-                    e = null;
                 }
             }
 
@@ -1183,7 +1182,6 @@
             if (!log.isInfoEnabled()) {
                 extraDescriptions.put(Notifying.EXTRA_CAUSE,
                   
DefaultNotifyingBuilder.getRootCause(e).getMessage());
-                e = null;
             }
 
             Notifying n = new DefaultNotifyingBuilder().build(this,


    Pier

Re: New CocoonServlet throws NullPointerException...

Posted by Vadim Gritsenko <va...@verizon.net>.
Pier Fumagalli wrote:

>Is there any sort of documentation on <map:handle-error/> somewhere?
>  
>

handle-error is a regular pipeline with couple of exceptions:
1.  As of today, generator is pre-set and can not be specified. It is on 
the TODO list to allow arbitrary generator in the handle-errors. Pre-set 
generator is "<notifier>" (org.apache.cocoon.sitemap.NotifyingGenerator).
2. Redirects are not allowed.

handle-error can have optional attribute @type with value of 404 
(ResourceNotFoundException) or 500 (all the other exceptions).

In handle-error you can create any error page you want (take a look at 
http://localhost:8888/samples/sub/does-not-exist), with or without 
stacktrace, you are in control of situation. Error handling code in 
Servlet though is just a fallback mechanism for the situations when 
handle-error pipeline is not present or double error occured, it can not 
be customized but can be turned off completely. Because customization is 
not possible, it is good idea to provide a way to hide a stacktrace 
(because if security reasons). I tied this to log level.

Vadim


>I'm going to get a headache soon :-( :-(
>
>    Pier
>  
>



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: New CocoonServlet throws NullPointerException...

Posted by Nicola Ken Barozzi <ni...@apache.org>.

Pier Fumagalli wrote, On 06/02/2003 22.01:
> "Vadim Gritsenko" <va...@verizon.net> wrote:
> 
>>Pier Fumagalli wrote:
>>
>>
>>>Well, anyhow, this fixes it...
>>
>>It does not fix the reason of NPE though, this is just a workaround.
>>Intention was not to log stacktrace in under certain conditions.
> 
> Yes... That's why I didn't commit it straight away.... I didn't quite figure
> out yet exactly what the NotificationManager does... :-)
> 
>>I committed the fix, could you please try it out?
> 
> It does work, but I still don't get how can I generate something like the
> default error page, when I start using the map:handle-error I have a
> completely different set of stuff coming out (like, still, the
> stacktrace)...

Who is the stupid guy that made that crap?!? <whistle> ;-P

> Is there any sort of documentation on <map:handle-error/> somewhere?

Ahem...

> I'm going to get a headache soon :-( :-(

Oh ooo...

Well, basically the stuff that does the notifying is in 
org.apache.cocoon.components.notification.*

Basically it's about using a Notifying object to create a notification.
A Notifying object must have these infos:


     /**
      * Gets the Type of the Notifying object
      */
     String getType();

     /**
      * Gets the Title of the Notifying object
      */
     String getTitle();

     /**
      * Gets the Source of the Notifying object
      */
     String getSource();

     /**
      * Gets the Sender of the Notifying object
      */
     String getSender();

     /**
      * Gets the Message of the Notifying object
      */
     String getMessage();

     /**
      * Gets the Description of the Notifying object
      */
     String getDescription();

     /**
      * Gets the ExtraDescriptions of the Notifying object
      */
     Map getExtraDescriptions();


The DefaultNotifyingBuilder is the default implementation of the 
notifier, that creates the messages in xml and html. The xml dtd is 
fixed, and the html mimics that.

As for handle-errors, it works like this: when an error in caught by the 
sitemap, a Notifying object is created from the error and added to the 
context. Then a new pipeline is setup, that is the handle-errors one, 
and the generator is the implicit NotifyingGenerator, that takes the 
Notifying stuff from the context and generates the sax events in the 
fixed DTD.

This passing stuff per context was done with the help of Peter Royal (hi 
Peter!) to make actions that work on the Notifying usable in handle-errors.

The implicit Generator should not remain implicit anymore. We have voted 
to make it specifiable in handle-errors. Just someone has to do it.

If you have other questions, and you surely will ;-) I'm here.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: New CocoonServlet throws NullPointerException...

Posted by Pier Fumagalli <pi...@betaversion.org>.
"Vadim Gritsenko" <va...@verizon.net> wrote:
> Pier Fumagalli wrote:
> 
>> Well, anyhow, this fixes it...
> 
> It does not fix the reason of NPE though, this is just a workaround.
> Intention was not to log stacktrace in under certain conditions.

Yes... That's why I didn't commit it straight away.... I didn't quite figure
out yet exactly what the NotificationManager does... :-)

> I committed the fix, could you please try it out?

It does work, but I still don't get how can I generate something like the
default error page, when I start using the map:handle-error I have a
completely different set of stuff coming out (like, still, the
stacktrace)...

Is there any sort of documentation on <map:handle-error/> somewhere?

I'm going to get a headache soon :-( :-(

    Pier


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: New CocoonServlet throws NullPointerException...

Posted by Vadim Gritsenko <va...@verizon.net>.
Pier Fumagalli wrote:

> Vadim, your last changes to the cocoon servlet are throwing me a NPE...
>
> java.lang.NullPointerException
>         at 
> org.apache.cocoon.components.notification.DefaultNotifyingBuilder.build(DefaultNotifyingBuilder.java:152)
>         at 
> org.apache.cocoon.components.notification.DefaultNotifyingBuilder.build(DefaultNotifyingBuilder.java:176)
>         at 
> org.apache.cocoon.servlet.CocoonServlet.manageException(CocoonServlet.java:1189)
>         at 
> org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1092)

...

> This is my sitemap, and of course, I don't have "index.xml" on the disk...
>
>   <map:pipelines>
>     <map:pipeline>
>       <map:match pattern="">
>         <map:redirect-to uri="index.xml"/>
>       </map:match>
>
>       <map:match pattern="*">
>         <map:generate name="file" src="{1}"/>
>         <map:serialize type="xml"/>
>       </map:match>
>
>     <map:handle-errors type="*">
>       <map:serialize type="xml"/>
>     </map:handle-errors>
>       
>     </map:pipeline>
>   </map:pipelines>
>
> Well, anyhow, this fixes it...


It does not fix the reason of NPE though, this is just a workaround. 
Intention was not to log stacktrace in under certain conditions.

I committed the fix, could you please try it out?


Vadim


> Index: org/apache/cocoon/servlet/CocoonServlet.java
> ===================================================================
> RCS file: 
> /home/cvs/xml-cocoon2/src/java/org/apache/cocoon/servlet/CocoonServlet.java,v
> retrieving revision 1.47
> diff -u -3 -r1.47 CocoonServlet.java
> --- org/apache/cocoon/servlet/CocoonServlet.java        2 Feb 2003 
> 23:35:36 -0000       1.47
> +++ org/apache/cocoon/servlet/CocoonServlet.java        6 Feb 2003 
> 20:10:17 -0000
> @@ -1175,7 +1175,6 @@
>                  if (e != null) {
>                      extraDescriptions.put(Notifying.EXTRA_CAUSE,
>                                            DefaultNotifyingBuilder.getRootCause(e).getMessage());
> -                    e = null;
>                  }
>              }
>  
> @@ -1183,7 +1182,6 @@
>              if (!log.isInfoEnabled()) {
>                  extraDescriptions.put(Notifying.EXTRA_CAUSE,
>                                        DefaultNotifyingBuilder.getRootCause(e).getMessage());
> -                e = null;
>              }
>  
>              Notifying n = new DefaultNotifyingBuilder().build(this,
>
>
>     Pier 




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org