You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by "Iordanov, Borislav (GIC)" <bo...@miamidade.gov> on 2006/07/17 19:22:45 UTC
swalled exception
Hi guys,
I'm sure there is a way to configure logging so that this doesn't
happen, but by default I notice tons of swallowed exceptions in MyFaces.
The resulting behavior obviously is that something doesn't work and
there's no indication why. Regardless of logging the error and of my not
having spent a few hours figuring out how to configure MyFaces logs, I
think it is unacceptable behavior for the application to continue to run
after a fatal error. An example of a fatal error is an NPE thrown from a
property setter during the "update model values" request processing
phase. Such errors should be propagated to the servlet container so that
I can eventually see a stack trace on my browser - very convenient
during development.
Regards,
Bolerio
Re: swalled exception
Posted by Mike Kienenberger <mk...@gmail.com>.
In the future, as you all come across these, let's open some JIRA
issues so they can either be handled better (different logging level
or throw the exception)
On 8/16/06, L Frohman <lf...@gmail.com> wrote:
> I have had a similar problem, where the code
> catches an exception, then if the logging level
> was set to debug, it logs the exception, then the
> exception was rethrown. Yes this was frustrating
> to solve, until I set my logging level to debug.
> It was obviously written this way for a reason,
> but I don't know why.
>
> -----Original Message-----
> From: Mike Kienenberger [mailto:mkienenb@gmail.com]
> Sent: Wednesday, August 16, 2006 6:54 AM
> To: MyFaces Discussion
> Subject: Re: swalled exception
>
> Borislav,
>
> When you come across something like this, consider opening a JIRA
> issue and optionally attaching a patch to fix it. At minimum, you
> should include the stack trace or log message. Be aware that some behavior
> may be mandated by the JSF spec.
>
> In this particular case, there's not enough information to even comment on
> the specific problem.
>
> On 7/17/06, Iordanov, Borislav (GIC) <bo...@miamidade.gov> wrote:
> >
> >
> >
> >
> > Hi guys,
> >
> >
> >
> > I'm sure there is a way to configure logging so that this doesn't
> > happen, but by default I notice tons of swallowed exceptions in
> > MyFaces. The resulting behavior obviously is that something doesn't
> > work and there's no indication why. Regardless of logging the error
> > and of my not having spent a few hours figuring out how to configure
> > MyFaces logs, I think it is unacceptable behavior for the application
> > to continue to run after a fatal error. An example of a fatal error is
> > an NPE thrown from a property setter during the "update model values"
> > request processing phase. Such errors should be propagated to the
> > servlet container so that I can eventually see a stack trace on my browser
> - very convenient during development.
> >
> >
> >
> > Regards,
> >
> > Bolerio
>
>
RE: swalled exception
Posted by "Iordanov, Borislav (GIC)" <bo...@miamidade.gov>.
Hi,
Well, I guess it is sad then if so much thought has been put into the
spec. I don't understand why you take the RI as the ultimate R, it was
written by mere mortals after all ;)
Never heard of "faces-trace", but yes it's a good idea for a program to
stop executing after a fatal error instead of pretending it's not there.
regards
-----Original Message-----
From: Martin Marinschek [mailto:martin.marinschek@gmail.com]
Sent: Wednesday, August 16, 2006 11:19 AM
To: MyFaces Discussion; Cagatay Civici
Subject: Re: swalled exception
Hi Bolerio,
I can tell you that a lot of thought has been put into devising the
JSF-Spec - even more, sometimes I think that too much thought has
caused some of the problems of the spec....
However, please check what the RI does in the same case (and I think I
checked before and found out that it does) - If the same is done, this
would point away from a programming mistake.
My point remains - wouldn't this be a good addition to faces-trace?
Having an EL-resolver, and maybe DefaultActionListenerImpl with a
better error-handling?
regards,
Martin
On 8/16/06, Iordanov, Borislav (GIC) <bo...@miamidade.gov> wrote:
> Hi Martin,
>
> Mandated by the spec? Hmmm...don't know, I would agree that the JSF
could have been designed with a bit more thoughtfulness, but this
particular one looks just like a programming mistake.
>
> Best,
> Bolerio
>
>
> -----Original Message-----
> From: Martin Marinschek [mailto:martin.marinschek@gmail.com]
> Sent: Wed 8/16/2006 10:47 AM
> To: MyFaces Discussion
> Subject: Re: swalled exception
>
> Interestingly enough, the RI does the same as we in the case of an
> exception in the update model phase. I haven't checked with the spec
> if this is mandated, but the JavaDoc indicate something in this
> direction.
>
> I honestly don't like this myself. I wonder if faces-trace could be
> extended to show exceptions like this on the page during development?
>
> regards,
>
> Martin
>
> On 8/16/06, Iordanov, Borislav (GIC) <bo...@miamidade.gov> wrote:
> > As mentionned, time constraints prevented me from figuring out how
to turn on logging, let alone submit a patch or even open a JIRA
> >
> > I wasn't asking for comment, but making one, and I also indicated a
very specific case where the problem occurs, in the hope that it would
be helpful. If it's not, than too bad.
> >
> > regards
> >
> >
> > -----Original Message-----
> > From: Mike Kienenberger [mailto:mkienenb@gmail.com]
> > Sent: Wed 8/16/2006 9:53 AM
> > To: MyFaces Discussion
> > Subject: Re: swalled exception
> >
> > Borislav,
> >
> > When you come across something like this, consider opening a JIRA
> > issue and optionally attaching a patch to fix it. At minimum, you
> > should include the stack trace or log message. Be aware that some
> > behavior may be mandated by the JSF spec.
> >
> > In this particular case, there's not enough information to even
> > comment on the specific problem.
> >
> > On 7/17/06, Iordanov, Borislav (GIC) <bo...@miamidade.gov> wrote:
> > >
> > >
> > >
> > >
> > > Hi guys,
> > >
> > >
> > >
> > > I'm sure there is a way to configure logging so that this doesn't
happen,
> > > but by default I notice tons of swallowed exceptions in MyFaces.
The
> > > resulting behavior obviously is that something doesn't work and
there's no
> > > indication why. Regardless of logging the error and of my not
having spent a
> > > few hours figuring out how to configure MyFaces logs, I think it
is
> > > unacceptable behavior for the application to continue to run after
a fatal
> > > error. An example of a fatal error is an NPE thrown from a
property setter
> > > during the "update model values" request processing phase. Such
errors
> > > should be propagated to the servlet container so that I can
eventually see a
> > > stack trace on my browser - very convenient during development.
> > >
> > >
> > >
> > > Regards,
> > >
> > > Bolerio
> >
> >
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: swalled exception
Posted by Martin Marinschek <ma...@gmail.com>.
Hi Bolerio,
I can tell you that a lot of thought has been put into devising the
JSF-Spec - even more, sometimes I think that too much thought has
caused some of the problems of the spec....
However, please check what the RI does in the same case (and I think I
checked before and found out that it does) - If the same is done, this
would point away from a programming mistake.
My point remains - wouldn't this be a good addition to faces-trace?
Having an EL-resolver, and maybe DefaultActionListenerImpl with a
better error-handling?
regards,
Martin
On 8/16/06, Iordanov, Borislav (GIC) <bo...@miamidade.gov> wrote:
> Hi Martin,
>
> Mandated by the spec? Hmmm...don't know, I would agree that the JSF could have been designed with a bit more thoughtfulness, but this particular one looks just like a programming mistake.
>
> Best,
> Bolerio
>
>
> -----Original Message-----
> From: Martin Marinschek [mailto:martin.marinschek@gmail.com]
> Sent: Wed 8/16/2006 10:47 AM
> To: MyFaces Discussion
> Subject: Re: swalled exception
>
> Interestingly enough, the RI does the same as we in the case of an
> exception in the update model phase. I haven't checked with the spec
> if this is mandated, but the JavaDoc indicate something in this
> direction.
>
> I honestly don't like this myself. I wonder if faces-trace could be
> extended to show exceptions like this on the page during development?
>
> regards,
>
> Martin
>
> On 8/16/06, Iordanov, Borislav (GIC) <bo...@miamidade.gov> wrote:
> > As mentionned, time constraints prevented me from figuring out how to turn on logging, let alone submit a patch or even open a JIRA
> >
> > I wasn't asking for comment, but making one, and I also indicated a very specific case where the problem occurs, in the hope that it would be helpful. If it's not, than too bad.
> >
> > regards
> >
> >
> > -----Original Message-----
> > From: Mike Kienenberger [mailto:mkienenb@gmail.com]
> > Sent: Wed 8/16/2006 9:53 AM
> > To: MyFaces Discussion
> > Subject: Re: swalled exception
> >
> > Borislav,
> >
> > When you come across something like this, consider opening a JIRA
> > issue and optionally attaching a patch to fix it. At minimum, you
> > should include the stack trace or log message. Be aware that some
> > behavior may be mandated by the JSF spec.
> >
> > In this particular case, there's not enough information to even
> > comment on the specific problem.
> >
> > On 7/17/06, Iordanov, Borislav (GIC) <bo...@miamidade.gov> wrote:
> > >
> > >
> > >
> > >
> > > Hi guys,
> > >
> > >
> > >
> > > I'm sure there is a way to configure logging so that this doesn't happen,
> > > but by default I notice tons of swallowed exceptions in MyFaces. The
> > > resulting behavior obviously is that something doesn't work and there's no
> > > indication why. Regardless of logging the error and of my not having spent a
> > > few hours figuring out how to configure MyFaces logs, I think it is
> > > unacceptable behavior for the application to continue to run after a fatal
> > > error. An example of a fatal error is an NPE thrown from a property setter
> > > during the "update model values" request processing phase. Such errors
> > > should be propagated to the servlet container so that I can eventually see a
> > > stack trace on my browser - very convenient during development.
> > >
> > >
> > >
> > > Regards,
> > >
> > > Bolerio
> >
> >
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
RE: swalled exception
Posted by "Iordanov, Borislav (GIC)" <bo...@miamidade.gov>.
Hi Martin,
Mandated by the spec? Hmmm...don't know, I would agree that the JSF could have been designed with a bit more thoughtfulness, but this particular one looks just like a programming mistake.
Best,
Bolerio
-----Original Message-----
From: Martin Marinschek [mailto:martin.marinschek@gmail.com]
Sent: Wed 8/16/2006 10:47 AM
To: MyFaces Discussion
Subject: Re: swalled exception
Interestingly enough, the RI does the same as we in the case of an
exception in the update model phase. I haven't checked with the spec
if this is mandated, but the JavaDoc indicate something in this
direction.
I honestly don't like this myself. I wonder if faces-trace could be
extended to show exceptions like this on the page during development?
regards,
Martin
On 8/16/06, Iordanov, Borislav (GIC) <bo...@miamidade.gov> wrote:
> As mentionned, time constraints prevented me from figuring out how to turn on logging, let alone submit a patch or even open a JIRA
>
> I wasn't asking for comment, but making one, and I also indicated a very specific case where the problem occurs, in the hope that it would be helpful. If it's not, than too bad.
>
> regards
>
>
> -----Original Message-----
> From: Mike Kienenberger [mailto:mkienenb@gmail.com]
> Sent: Wed 8/16/2006 9:53 AM
> To: MyFaces Discussion
> Subject: Re: swalled exception
>
> Borislav,
>
> When you come across something like this, consider opening a JIRA
> issue and optionally attaching a patch to fix it. At minimum, you
> should include the stack trace or log message. Be aware that some
> behavior may be mandated by the JSF spec.
>
> In this particular case, there's not enough information to even
> comment on the specific problem.
>
> On 7/17/06, Iordanov, Borislav (GIC) <bo...@miamidade.gov> wrote:
> >
> >
> >
> >
> > Hi guys,
> >
> >
> >
> > I'm sure there is a way to configure logging so that this doesn't happen,
> > but by default I notice tons of swallowed exceptions in MyFaces. The
> > resulting behavior obviously is that something doesn't work and there's no
> > indication why. Regardless of logging the error and of my not having spent a
> > few hours figuring out how to configure MyFaces logs, I think it is
> > unacceptable behavior for the application to continue to run after a fatal
> > error. An example of a fatal error is an NPE thrown from a property setter
> > during the "update model values" request processing phase. Such errors
> > should be propagated to the servlet container so that I can eventually see a
> > stack trace on my browser - very convenient during development.
> >
> >
> >
> > Regards,
> >
> > Bolerio
>
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: swalled exception
Posted by Martin Marinschek <ma...@gmail.com>.
Interestingly enough, the RI does the same as we in the case of an
exception in the update model phase. I haven't checked with the spec
if this is mandated, but the JavaDoc indicate something in this
direction.
I honestly don't like this myself. I wonder if faces-trace could be
extended to show exceptions like this on the page during development?
regards,
Martin
On 8/16/06, Iordanov, Borislav (GIC) <bo...@miamidade.gov> wrote:
> As mentionned, time constraints prevented me from figuring out how to turn on logging, let alone submit a patch or even open a JIRA
>
> I wasn't asking for comment, but making one, and I also indicated a very specific case where the problem occurs, in the hope that it would be helpful. If it's not, than too bad.
>
> regards
>
>
> -----Original Message-----
> From: Mike Kienenberger [mailto:mkienenb@gmail.com]
> Sent: Wed 8/16/2006 9:53 AM
> To: MyFaces Discussion
> Subject: Re: swalled exception
>
> Borislav,
>
> When you come across something like this, consider opening a JIRA
> issue and optionally attaching a patch to fix it. At minimum, you
> should include the stack trace or log message. Be aware that some
> behavior may be mandated by the JSF spec.
>
> In this particular case, there's not enough information to even
> comment on the specific problem.
>
> On 7/17/06, Iordanov, Borislav (GIC) <bo...@miamidade.gov> wrote:
> >
> >
> >
> >
> > Hi guys,
> >
> >
> >
> > I'm sure there is a way to configure logging so that this doesn't happen,
> > but by default I notice tons of swallowed exceptions in MyFaces. The
> > resulting behavior obviously is that something doesn't work and there's no
> > indication why. Regardless of logging the error and of my not having spent a
> > few hours figuring out how to configure MyFaces logs, I think it is
> > unacceptable behavior for the application to continue to run after a fatal
> > error. An example of a fatal error is an NPE thrown from a property setter
> > during the "update model values" request processing phase. Such errors
> > should be propagated to the servlet container so that I can eventually see a
> > stack trace on my browser - very convenient during development.
> >
> >
> >
> > Regards,
> >
> > Bolerio
>
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
RE: swalled exception
Posted by "Iordanov, Borislav (GIC)" <bo...@miamidade.gov>.
As mentionned, time constraints prevented me from figuring out how to turn on logging, let alone submit a patch or even open a JIRA
I wasn't asking for comment, but making one, and I also indicated a very specific case where the problem occurs, in the hope that it would be helpful. If it's not, than too bad.
regards
-----Original Message-----
From: Mike Kienenberger [mailto:mkienenb@gmail.com]
Sent: Wed 8/16/2006 9:53 AM
To: MyFaces Discussion
Subject: Re: swalled exception
Borislav,
When you come across something like this, consider opening a JIRA
issue and optionally attaching a patch to fix it. At minimum, you
should include the stack trace or log message. Be aware that some
behavior may be mandated by the JSF spec.
In this particular case, there's not enough information to even
comment on the specific problem.
On 7/17/06, Iordanov, Borislav (GIC) <bo...@miamidade.gov> wrote:
>
>
>
>
> Hi guys,
>
>
>
> I'm sure there is a way to configure logging so that this doesn't happen,
> but by default I notice tons of swallowed exceptions in MyFaces. The
> resulting behavior obviously is that something doesn't work and there's no
> indication why. Regardless of logging the error and of my not having spent a
> few hours figuring out how to configure MyFaces logs, I think it is
> unacceptable behavior for the application to continue to run after a fatal
> error. An example of a fatal error is an NPE thrown from a property setter
> during the "update model values" request processing phase. Such errors
> should be propagated to the servlet container so that I can eventually see a
> stack trace on my browser - very convenient during development.
>
>
>
> Regards,
>
> Bolerio
RE: swalled exception
Posted by L Frohman <lf...@gmail.com>.
I have had a similar problem, where the code
catches an exception, then if the logging level
was set to debug, it logs the exception, then the
exception was rethrown. Yes this was frustrating
to solve, until I set my logging level to debug.
It was obviously written this way for a reason,
but I don't know why.
-----Original Message-----
From: Mike Kienenberger [mailto:mkienenb@gmail.com]
Sent: Wednesday, August 16, 2006 6:54 AM
To: MyFaces Discussion
Subject: Re: swalled exception
Borislav,
When you come across something like this, consider opening a JIRA
issue and optionally attaching a patch to fix it. At minimum, you
should include the stack trace or log message. Be aware that some behavior
may be mandated by the JSF spec.
In this particular case, there's not enough information to even comment on
the specific problem.
On 7/17/06, Iordanov, Borislav (GIC) <bo...@miamidade.gov> wrote:
>
>
>
>
> Hi guys,
>
>
>
> I'm sure there is a way to configure logging so that this doesn't
> happen, but by default I notice tons of swallowed exceptions in
> MyFaces. The resulting behavior obviously is that something doesn't
> work and there's no indication why. Regardless of logging the error
> and of my not having spent a few hours figuring out how to configure
> MyFaces logs, I think it is unacceptable behavior for the application
> to continue to run after a fatal error. An example of a fatal error is
> an NPE thrown from a property setter during the "update model values"
> request processing phase. Such errors should be propagated to the
> servlet container so that I can eventually see a stack trace on my browser
- very convenient during development.
>
>
>
> Regards,
>
> Bolerio
Re: swalled exception
Posted by Mike Kienenberger <mk...@gmail.com>.
Borislav,
When you come across something like this, consider opening a JIRA
issue and optionally attaching a patch to fix it. At minimum, you
should include the stack trace or log message. Be aware that some
behavior may be mandated by the JSF spec.
In this particular case, there's not enough information to even
comment on the specific problem.
On 7/17/06, Iordanov, Borislav (GIC) <bo...@miamidade.gov> wrote:
>
>
>
>
> Hi guys,
>
>
>
> I'm sure there is a way to configure logging so that this doesn't happen,
> but by default I notice tons of swallowed exceptions in MyFaces. The
> resulting behavior obviously is that something doesn't work and there's no
> indication why. Regardless of logging the error and of my not having spent a
> few hours figuring out how to configure MyFaces logs, I think it is
> unacceptable behavior for the application to continue to run after a fatal
> error. An example of a fatal error is an NPE thrown from a property setter
> during the "update model values" request processing phase. Such errors
> should be propagated to the servlet container so that I can eventually see a
> stack trace on my browser – very convenient during development.
>
>
>
> Regards,
>
> Bolerio
Re: tree2: update treeModel on the server
Posted by Andrew Robinson <an...@gmail.com>.
Now if we only understood why :-)
On 7/25/06, Jiang, Jane (NIH/NCI) [C] <ji...@mail.nih.gov> wrote:
> Thanks for the suggestion. It worked for me! I wish I understand more about it. Is there any documentation on it? I hope I am not losing anything by using the transient mode. I tried to trace my code in the debugging mode. The getTreeModel() still got called twice except both times returned the same treeState.
>
> Jane
>
> -----Original Message-----
> From: Andrew Robinson [mailto:andrew.rw.robinson@gmail.com]
> Sent: Tuesday, July 25, 2006 3:57 PM
> To: MyFaces Discussion
> Subject: Re: tree2: update treeModel on the server
>
>
> Stab in the dark (almost):
>
> Try setting the tree model's tree state to transient. I have seen some
> weird behaviors when the default (non-transient) is used. I don't
> fully understand it (didn't spend the time learning the source code
> for the control), but it has something to do with the tree model, tree
> state and/or tree nodes being cached when transient is false.
>
> -Andrew
>
> On 7/25/06, Jiang, Jane (NIH/NCI) [C] <ji...@mail.nih.gov> wrote:
> >
> >
> > Hi all,
> >
> > I am having problem updating the tree model. Here is my short code sample
> >
> > JSP
> > <h:commandLink value="Refresh tree" action="#{treeBacker.refreshTree}"/>
> > <br/><br/>
> >
> > <!-- Expand/Collapse Handled By Server -->
> > <t:tree2 id="serverTree" value="#{treeBacker.treeModel}" var="node"
> > varNodeToggler="t" clientSideToggle="false" binding="#{treeBacker.tree}">
> >
> > TreeBacker.java
> >
> > ... public String refreshTree() {
> > treeData.refreshTree();
> > _treeModel = new TreeModelBase(treeData.getTreeData());
> > return null;
> > }
> > public TreeModel getTreeModel() {
> > if (_treeModel == null) {
> > _treeModel = new TreeModelBase(treeData.getTreeData());
> > _treeModel.getTreeState().toggleExpanded("0");
> > }
> >
> > return _treeModel;
> > }
> >
> > I setup breakpoint to see what is going on. It seems like refreshTree() get
> > called, _treeModel is updated. Then getTreeModel() got called twice. The
> > first time it returned the updated one, then the second time it returned the
> > old one.
> >
> > My treeBacked is defined in the session scope as follow. So there should
> > not be two instances of treeBacker for the same session.
> >
> > <managed-bean>
> > <managed-bean-name>treeBacker</managed-bean-name>
> >
> > <managed-bean-class>gov.nih.nci.ncicb.cadsr.umlmodelbrowser.tree.TreeBacker</managed-bean-class>
> > <managed-bean-scope>session</managed-bean-scope>
> > </managed-bean>
> >
> > Any suggestions on how to get this to work or other ways to refresh the tree
> > would be grealy appreciated.
> >
> > Many thanks,
> >
> > Jane
>
RE: tree2: update treeModel on the server
Posted by "Jiang, Jane (NIH/NCI) [C]" <ji...@mail.nih.gov>.
Thanks for the suggestion. It worked for me! I wish I understand more about it. Is there any documentation on it? I hope I am not losing anything by using the transient mode. I tried to trace my code in the debugging mode. The getTreeModel() still got called twice except both times returned the same treeState.
Jane
-----Original Message-----
From: Andrew Robinson [mailto:andrew.rw.robinson@gmail.com]
Sent: Tuesday, July 25, 2006 3:57 PM
To: MyFaces Discussion
Subject: Re: tree2: update treeModel on the server
Stab in the dark (almost):
Try setting the tree model's tree state to transient. I have seen some
weird behaviors when the default (non-transient) is used. I don't
fully understand it (didn't spend the time learning the source code
for the control), but it has something to do with the tree model, tree
state and/or tree nodes being cached when transient is false.
-Andrew
On 7/25/06, Jiang, Jane (NIH/NCI) [C] <ji...@mail.nih.gov> wrote:
>
>
> Hi all,
>
> I am having problem updating the tree model. Here is my short code sample
>
> JSP
> <h:commandLink value="Refresh tree" action="#{treeBacker.refreshTree}"/>
> <br/><br/>
>
> <!-- Expand/Collapse Handled By Server -->
> <t:tree2 id="serverTree" value="#{treeBacker.treeModel}" var="node"
> varNodeToggler="t" clientSideToggle="false" binding="#{treeBacker.tree}">
>
> TreeBacker.java
>
> ... public String refreshTree() {
> treeData.refreshTree();
> _treeModel = new TreeModelBase(treeData.getTreeData());
> return null;
> }
> public TreeModel getTreeModel() {
> if (_treeModel == null) {
> _treeModel = new TreeModelBase(treeData.getTreeData());
> _treeModel.getTreeState().toggleExpanded("0");
> }
>
> return _treeModel;
> }
>
> I setup breakpoint to see what is going on. It seems like refreshTree() get
> called, _treeModel is updated. Then getTreeModel() got called twice. The
> first time it returned the updated one, then the second time it returned the
> old one.
>
> My treeBacked is defined in the session scope as follow. So there should
> not be two instances of treeBacker for the same session.
>
> <managed-bean>
> <managed-bean-name>treeBacker</managed-bean-name>
>
> <managed-bean-class>gov.nih.nci.ncicb.cadsr.umlmodelbrowser.tree.TreeBacker</managed-bean-class>
> <managed-bean-scope>session</managed-bean-scope>
> </managed-bean>
>
> Any suggestions on how to get this to work or other ways to refresh the tree
> would be grealy appreciated.
>
> Many thanks,
>
> Jane
Re: tree2: update treeModel on the server
Posted by Andrew Robinson <an...@gmail.com>.
Stab in the dark (almost):
Try setting the tree model's tree state to transient. I have seen some
weird behaviors when the default (non-transient) is used. I don't
fully understand it (didn't spend the time learning the source code
for the control), but it has something to do with the tree model, tree
state and/or tree nodes being cached when transient is false.
-Andrew
On 7/25/06, Jiang, Jane (NIH/NCI) [C] <ji...@mail.nih.gov> wrote:
>
>
> Hi all,
>
> I am having problem updating the tree model. Here is my short code sample
>
> JSP
> <h:commandLink value="Refresh tree" action="#{treeBacker.refreshTree}"/>
> <br/><br/>
>
> <!-- Expand/Collapse Handled By Server -->
> <t:tree2 id="serverTree" value="#{treeBacker.treeModel}" var="node"
> varNodeToggler="t" clientSideToggle="false" binding="#{treeBacker.tree}">
>
> TreeBacker.java
>
> ... public String refreshTree() {
> treeData.refreshTree();
> _treeModel = new TreeModelBase(treeData.getTreeData());
> return null;
> }
> public TreeModel getTreeModel() {
> if (_treeModel == null) {
> _treeModel = new TreeModelBase(treeData.getTreeData());
> _treeModel.getTreeState().toggleExpanded("0");
> }
>
> return _treeModel;
> }
>
> I setup breakpoint to see what is going on. It seems like refreshTree() get
> called, _treeModel is updated. Then getTreeModel() got called twice. The
> first time it returned the updated one, then the second time it returned the
> old one.
>
> My treeBacked is defined in the session scope as follow. So there should
> not be two instances of treeBacker for the same session.
>
> <managed-bean>
> <managed-bean-name>treeBacker</managed-bean-name>
>
> <managed-bean-class>gov.nih.nci.ncicb.cadsr.umlmodelbrowser.tree.TreeBacker</managed-bean-class>
> <managed-bean-scope>session</managed-bean-scope>
> </managed-bean>
>
> Any suggestions on how to get this to work or other ways to refresh the tree
> would be grealy appreciated.
>
> Many thanks,
>
> Jane
RE: swalled exception
Posted by "Iordanov, Borislav (GIC)" <bo...@miamidade.gov>.
Thanks for the tip, Adam.
Best,
Bolerio
________________________________
From: Adam Brod [mailto:ABrod@intralinks.com]
Sent: Tuesday, July 18, 2006 5:26 PM
To: MyFaces Discussion
Subject: Re: swalled exception
I agree. This was a huge problem for me. I lost many hours because
MyFaces was logging errors that I couldn't find. For what it's worth,
if you have log4j.jar in WEB-INF/lib and log4j.properties in
WEB-INF/classes with these values, you'll see the errors.
log4j.rootLogger=WARN, stdout
log4j.logger.org.apache.myfaces = INFO
log4j.logger.javax.faces = INFO
#***************************************
# Appender "stdout"
#***************************************
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d{ISO8601} %-5p %c -
%m%n
Adam Brod
Product Development Team
"Iordanov, Borislav \(GIC\)" <bo...@miamidade.gov>
07/17/2006 01:22 PM
Please respond to
"MyFaces Discussion" <us...@myfaces.apache.org>
To
"MyFaces Discussion" <us...@myfaces.apache.org>
cc
Subject
swalled exception
Hi guys,
I'm sure there is a way to configure logging so that this doesn't
happen, but by default I notice tons of swallowed exceptions in MyFaces.
The resulting behavior obviously is that something doesn't work and
there's no indication why. Regardless of logging the error and of my not
having spent a few hours figuring out how to configure MyFaces logs, I
think it is unacceptable behavior for the application to continue to run
after a fatal error. An example of a fatal error is an NPE thrown from a
property setter during the "update model values" request processing
phase. Such errors should be propagated to the servlet container so that
I can eventually see a stack trace on my browser - very convenient
during development.
Regards,
Bolerio
Disclaimer: This electronic mail and any attachments are confidential
and may be privileged. If you are not the intended recipient, please
notify the sender immediately by replying to this email, and destroy all
copies of this email and any attachments. Thank you.
Re: tree2: update treeModel on the server
Posted by Mr Arvind Pandey <ar...@yahoo.co.in>.
Hi Jiang,
Can you provide your jsp and java code in more
details? I have worked on tree2, may be i will be able
to give solution to your problem.
Regards...
Arvind
--- "Jiang, Jane (NIH/NCI) [C]" <ji...@mail.nih.gov>
wrote:
> Hi all,
>
> I am having problem updating the tree model. Here
> is my short code sample
>
> JSP
> <h:commandLink value="Refresh tree"
> action="#{treeBacker.refreshTree}"/>
> <br/><br/>
>
> <!-- Expand/Collapse Handled By Server -->
> <t:tree2 id="serverTree"
> value="#{treeBacker.treeModel}" var="node"
> varNodeToggler="t" clientSideToggle="false"
> binding="#{treeBacker.tree}">
>
> TreeBacker.java
>
> ... public String refreshTree() {
> treeData.refreshTree();
> _treeModel = new
> TreeModelBase(treeData.getTreeData());
> return null;
> }
> public TreeModel getTreeModel() {
> if (_treeModel == null) {
> _treeModel = new
> TreeModelBase(treeData.getTreeData());
>
> _treeModel.getTreeState().toggleExpanded("0");
> }
>
> return _treeModel;
> }
>
> I setup breakpoint to see what is going on. It
> seems like refreshTree() get called, _treeModel is
> updated. Then getTreeModel() got called twice. The
> first time it returned the updated one, then the
> second time it returned the old one.
>
> My treeBacked is defined in the session scope as
> follow. So there should not be two instances of
> treeBacker for the same session.
>
> <managed-bean>
>
> <managed-bean-name>treeBacker</managed-bean-name>
>
>
<managed-bean-class>gov.nih.nci.ncicb.cadsr.umlmodelbrowser.tree.TreeBacker</managed-bean-class>
>
> <managed-bean-scope>session</managed-bean-scope>
> </managed-bean>
>
> Any suggestions on how to get this to work or other
> ways to refresh the tree would be grealy
> appreciated.
>
> Many thanks,
>
> Jane
>
__________________________________________________________
Yahoo! India Answers: Share what you know. Learn something new
http://in.answers.yahoo.com/
tree2: update treeModel on the server
Posted by "Jiang, Jane (NIH/NCI) [C]" <ji...@mail.nih.gov>.
Hi all,
I am having problem updating the tree model. Here is my short code sample
JSP
<h:commandLink value="Refresh tree" action="#{treeBacker.refreshTree}"/>
<br/><br/>
<!-- Expand/Collapse Handled By Server -->
<t:tree2 id="serverTree" value="#{treeBacker.treeModel}" var="node" varNodeToggler="t" clientSideToggle="false" binding="#{treeBacker.tree}">
TreeBacker.java
... public String refreshTree() {
treeData.refreshTree();
_treeModel = new TreeModelBase(treeData.getTreeData());
return null;
}
public TreeModel getTreeModel() {
if (_treeModel == null) {
_treeModel = new TreeModelBase(treeData.getTreeData());
_treeModel.getTreeState().toggleExpanded("0");
}
return _treeModel;
}
I setup breakpoint to see what is going on. It seems like refreshTree() get called, _treeModel is updated. Then getTreeModel() got called twice. The first time it returned the updated one, then the second time it returned the old one.
My treeBacked is defined in the session scope as follow. So there should not be two instances of treeBacker for the same session.
<managed-bean>
<managed-bean-name>treeBacker</managed-bean-name>
<managed-bean-class>gov.nih.nci.ncicb.cadsr.umlmodelbrowser.tree.TreeBacker</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>
Any suggestions on how to get this to work or other ways to refresh the tree would be grealy appreciated.
Many thanks,
Jane
Re: swalled exception
Posted by Adam Brod <AB...@intralinks.com>.
I agree. This was a huge problem for me. I lost many hours because
MyFaces was logging errors that I couldn't find. For what it's worth, if
you have log4j.jar in WEB-INF/lib and log4j.properties in WEB-INF/classes
with these values, you'll see the errors.
log4j.rootLogger=WARN, stdout
log4j.logger.org.apache.myfaces = INFO
log4j.logger.javax.faces = INFO
#***************************************
# Appender "stdout"
#***************************************
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d{ISO8601} %-5p %c - %m%n
Adam Brod
Product Development Team
"Iordanov, Borislav \(GIC\)" <bo...@miamidade.gov>
07/17/2006 01:22 PM
Please respond to
"MyFaces Discussion" <us...@myfaces.apache.org>
To
"MyFaces Discussion" <us...@myfaces.apache.org>
cc
Subject
swalled exception
Hi guys,
I?m sure there is a way to configure logging so that this doesn?t happen,
but by default I notice tons of swallowed exceptions in MyFaces. The
resulting behavior obviously is that something doesn?t work and there?s no
indication why. Regardless of logging the error and of my not having spent
a few hours figuring out how to configure MyFaces logs, I think it is
unacceptable behavior for the application to continue to run after a fatal
error. An example of a fatal error is an NPE thrown from a property setter
during the ?update model values? request processing phase. Such errors
should be propagated to the servlet container so that I can eventually see
a stack trace on my browser ? very convenient during development.
Regards,
Bolerio
Disclaimer: This electronic mail and any attachments are confidential and may be privileged. If you are not the intended recipient, please notify the sender immediately by replying to this email, and destroy all copies of this email and any attachments. Thank you.