Re: My exception handling is broken

[Ingo Düppe]

Hi,

ok now I add my own ViewRoot:

    component
     
component-typejavax.faces.ViewRoot/component-type
     
component-classorg.openuss.web.application.DefaultViewRoot/component-class
      /component

My DefaultViewRoot
class.

That do not set responseComplete if an exception occur. So my
ExceptionHandler can decide if it is an application exception occur 
just add an error message and if an unexpected exception occur add it
to the shale exception-list and redirect to the error page (with
responseComplete).

I'm not sure if this is the same as it is done by shale beside the
differentiation of application exceptions. 
So any comment are welcome.

Regards
Ingo



Veit Guna schrieb:

  Hi.

I encountered the same problem. I started development with
shale-1.0.4-SNAPHSOT a while ago and wrote my own ExceptionHandler, too.
 That worked so far. 3 weeks ago I upgraded to 1.0.4 and for example
acegi exceptions didn't get propagated anymore to its ExceptionFilter.
At this time I thought, it worked before because of a bug in the
SNAPSHOT release and that got fixed in the final 1.0.4. Something
changed in the way of handling exceptions I guess. I can't remember
exactly what I changed to get it running in 1.0.4 again, but it had
something todo with trowing exceptions.

In the past, I think the Shale Controller threw exceptions that were
queued up in the session under FacesConstants.EXCEPTIONS_LIST. Now this
isn't done anymore. I had to throw the exception explicitly in my shale
exception handler to get it propagated.

I would be also interested in what changed exactly and what's the right
way to handle exceptions in shale...

regards,
Veit




Ingo Düppe schrieb:
  
  
Hi,

I guess I missed some changes in shale 1.0.4. I override the
DefaultExceptionHandling so that my backing bean can throw to types of
exceptions one of my ApplicationExceptions and the unchecked
SystemExceptions. These two types were handled by the
DefaultExceptionHandler. For instance, the application exception just
ends up in an error message on the same view.

But now there is a responseComplete within the ShaleViewRoot (Is this
class new?) that prevents the rendering after exception handling.

So, do I need to introduce my own ViewRoot component or what is the
recommended way to handle my exceptions?

Regards
Ingo



  
  

  

[OT] Shale and Cat incompatibility [was Re: stack traces from shale-clay-usecases]

[Niall Pemberton]

On 2/3/07, Craig McClanahan [EMAIL PROTECTED] wrote:

Ignore the previous empty response -- that's what you get when you pet a cat
who is pawing your mouse at that moment :-).


LOL - my cat sometimes walks accross my keyboard, fortunately no
strange messages have resulted to date, but its going to happen one
day!

Niall


Craig

Re: stack traces from shale-clay-usecases

[Gary VanMatre]

On 2/2/07, Gary VanMatre [EMAIL PROTECTED] wrote:

 I was able to run the shale-clay-usecases in 10g (10.1.3.1.1) from
 JDeveloper Studio 10.1.3.2 but I had to make a few minor changes.

 For some reason, JDeveloper doesn't like that the shale-core and
 shale-validator jars have TLD files with the name taglib.tld? I renamed
 the TLD's and it was happy?

 I pulled down the trinidad maven plugin to build the JDeveloper project
 file and ran from the IDE.  I had to include the JSP Runtime libraries
 too.


 I'm not sure if that's what you are seeing? It's weird that taglib.tld
 trips it up?


Ignore the previous empty response -- that's what you get when you pet a cat
who is pawing your mouse at that moment :-).


That's one confused cat (wrong kind mouse).


It would definitely be wierd, but I can kind of sympathize with how someone
writing the server side could make a naive assumption that these resource
names are unique.  At any rate, I'd be fine with making all of our
META-INF/xxx.tld resource names unique.  After all, it won't affect any
users because they should not (can not?) make any direct references to these
things.



I did some more research and it turns out that it's a problem with the Trinidad 
JDeveloper maven plugin.  It has to copy the TLD's into the WEB-INF folder.  
Seems like this requirement is kind of old school but apparently necessary.

Even though my hit ratio on the myfaces patches isn't good, I went ahead and 
gave it a go [1].

[1]  https://issues.apache.org/jira/browse/ADFFACES-372
 



Gary


Craig


Gary