You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Bill Lear <ra...@zopyra.com> on 2003/10/02 22:30:56 UTC
Tapestry exception report incomplete?
I have spent the last 45 minutes or more debugging something that should
have been simple to catch --- I am using HiveMind to provide services,
and I inadvertently used an old version of the HiveMind jar file,
and HiveMind was not able to parse the hivemodule.xml file at
runtime.
However, the exception report produced by Tapestry that shows up in my
browser nowhere indicates this. Instead, it indicates that a module
is not in the registry (true, but not the cause of the problem).
The Tapestry HTML report shows first
org.apache.tapestry.BindingException
...
then
ognl.OgnlException
...
then
org.apache.commons.hivemind.ApplicationRuntimeException
and this has the details:
Registry does not contain module 'com.foobar.eci.dao'.
Stack Trace:
org.apache.commons.hivemind.impl.RegistryImpl.getModule(RegistryImpl.java:115)
org.apache.commons.hivemind.impl.RegistryImpl.getService(RegistryImpl.java:125)
com.foobar.eci.services.Services.getService(Services.java:28)
However, if I look in the log file for my application, I see this, which
is really what I want:
<ERROR 2003-10-02 14:28:56,842 RegistryBuilder:162> Unable to parse module deployment descriptor file:/opt/jakarta/.jakarta-tomcat-4.1.18-LE-jdk14/webapps/rael_eci/WEB-INF/classes/META-INF/hivemodule.xml: Unable to read descriptor file:/opt/jakarta/.jakarta-tomcat-4.1.18-LE-jdk14/webapps/rael_eci/WEB-INF/classes/META-INF/hivemodule.xml: Unexpected element service-point within module (at file:/opt/jakarta/.jakarta-tomcat-4.1.18-LE-jdk14/webapps/rael_eci/WEB-INF/classes/META-INF/hivemodule.xml, line 5).
org.apache.commons.hivemind.ApplicationRuntimeException: Unable to read descriptor file:/opt/jakarta/.jakarta-tomcat-4.1.18-LE-jdk14/webapps/rael_eci/WEB-INF/classes/META-INF/hivemodule.xml: Unexpected element service-point within module (at file:/opt/jakarta/.jakarta-tomcat-4.1.18-LE-jdk14/webapps/rael_eci/WEB-INF/classes/META-INF/hivemodule.xml, line 5).
at org.apache.commons.hivemind.parse.DescriptorParser.parse(DescriptorParser.java:480)
at org.apache.commons.hivemind.impl.RegistryBuilder.processModuleResource(RegistryBuilder.java:245)
at org.apache.commons.hivemind.impl.RegistryBuilder.processModules(RegistryBuilder.java:212)
at com.foobar.eci.services.Services.getService(Services.java:24)
So, here, the actual error is from 4 lines earlier in my source code
than indicated in the HTML error report, and, of course, it includes
a description of what the problem was.
So, is there a reason this is not caught and reported by Tapestry?
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: [HiveMind] Re: Tapestry exception report incomplete?
Posted by Harish Krishnaswamy <hk...@comcast.net>.
May be we should classify errors into two types - the ones that can
proceed and the ones that should crash. Errors like unavailable service
implementation should probably proceed and those like the parsing errors
should probably crash?
-Harish
Bill Lear wrote:
>On Thursday, October 2, 2003 at 17:04:20 (-0400) Harish Krishnaswamy writes:
>
>
>>>...
>>>Why not just toss the thing and let the app catch it?
>>>
>>>
>>>
>>My understanding is, from a microkernel standpoint, it is not supposed
>>to crash just because one module or service had a problem, you know like
>>the containers, they just report the problem and move on. But the
>>containers have a console or a designated log file that one can take a
>>look at, but HiveMind does not have either, that will be a problem for
>>the uninformed, I think.
>>
>>
>
>Hmm, not sure I agree with this --- if someone mis-configures a
>microkernel, I'd rather have it crash and tell me about it than
>sputter on and die later, pointing me elsewhere by a subsequently
>thrown exception. I'll have to think and bring pursue discussion on
>the hivemind list.
>
>
>Bill
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>
Re: [HiveMind] Re: Tapestry exception report incomplete?
Posted by Bill Lear <ra...@zopyra.com>.
On Thursday, October 2, 2003 at 19:21:46 (-0400) Harish Krishnaswamy writes:
>That would work. I had another idea on my way home. What if the
>constructRegistry threw an exception if there was any problem in the
>construction, that is after the registry is built? That way the
>application can decide what to do. What do you think about that?
Not to mention that throwing a checked exception is not the same as
"crashing".
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [HiveMind] Re: Tapestry exception report incomplete?
Posted by Harish Krishnaswamy <hk...@comcast.net>.
That would work. I had another idea on my way home. What if the
constructRegistry threw an exception if there was any problem in the
construction, that is after the registry is built? That way the
application can decide what to do. What do you think about that?
-Harish
Howard M. Lewis Ship wrote:
>Perhaps we should put a check in RegistryBuilder:
>
>if (!LOG.isErrorEnabled())
> System.err.println("*** Logging not enabled for xxxx. Module parse and validation errors will not
>be visible. ***");
>
>In addition, an earlier version of the code had a brittle flag (that I used during testing). Turning
>the flag on would make some errors turn into thrown exceptions. I only used it for testing, and
>eventually discarded that and created a specialized Appended used to determine if certain messages
>had been logged. It could be ressurected and tied to a JVM system property.
>
>--
>Howard M. Lewis Ship
>Creator, Tapestry: Java Web Components
>http://jakarta.apache.org/tapestry
>http://jakarta.apache.org/commons/sandbox/hivemind/
>http://javatapestry.blogspot.com
>
>
>
>>-----Original Message-----
>>From: Bill Lear [mailto:rael@zopyra.com]
>>Sent: Thursday, October 02, 2003 5:11 PM
>>To: Tapestry users
>>Cc: commons-dev@jakarta.apache.org
>>Subject: Re: [HiveMind] Re: Tapestry exception report incomplete?
>>
>>
>>On Thursday, October 2, 2003 at 17:04:20 (-0400) Harish
>>Krishnaswamy writes:
>>
>>
>>>>...
>>>>Why not just toss the thing and let the app catch it?
>>>>
>>>>
>>>>
>>>My understanding is, from a microkernel standpoint, it is
>>>
>>>
>>not supposed
>>
>>
>>>to crash just because one module or service had a problem,
>>>
>>>
>>you know like
>>
>>
>>>the containers, they just report the problem and move on. But the
>>>containers have a console or a designated log file that one
>>>
>>>
>>can take a
>>
>>
>>>look at, but HiveMind does not have either, that will be a
>>>
>>>
>>problem for
>>
>>
>>>the uninformed, I think.
>>>
>>>
>>Hmm, not sure I agree with this --- if someone mis-configures
>>a microkernel, I'd rather have it crash and tell me about it
>>than sputter on and die later, pointing me elsewhere by a
>>subsequently thrown exception. I'll have to think and bring
>>pursue discussion on the hivemind list.
>>
>>
>>Bill
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>
RE: [HiveMind] Re: Tapestry exception report incomplete?
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
Perhaps we should put a check in RegistryBuilder:
if (!LOG.isErrorEnabled())
System.err.println("*** Logging not enabled for xxxx. Module parse and validation errors will not
be visible. ***");
In addition, an earlier version of the code had a brittle flag (that I used during testing). Turning
the flag on would make some errors turn into thrown exceptions. I only used it for testing, and
eventually discarded that and created a specialized Appended used to determine if certain messages
had been logged. It could be ressurected and tied to a JVM system property.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
> -----Original Message-----
> From: Bill Lear [mailto:rael@zopyra.com]
> Sent: Thursday, October 02, 2003 5:11 PM
> To: Tapestry users
> Cc: commons-dev@jakarta.apache.org
> Subject: Re: [HiveMind] Re: Tapestry exception report incomplete?
>
>
> On Thursday, October 2, 2003 at 17:04:20 (-0400) Harish
> Krishnaswamy writes:
> >>...
> >>Why not just toss the thing and let the app catch it?
> >>
> >My understanding is, from a microkernel standpoint, it is
> not supposed
> >to crash just because one module or service had a problem,
> you know like
> >the containers, they just report the problem and move on. But the
> >containers have a console or a designated log file that one
> can take a
> >look at, but HiveMind does not have either, that will be a
> problem for
> >the uninformed, I think.
>
> Hmm, not sure I agree with this --- if someone mis-configures
> a microkernel, I'd rather have it crash and tell me about it
> than sputter on and die later, pointing me elsewhere by a
> subsequently thrown exception. I'll have to think and bring
> pursue discussion on the hivemind list.
>
>
> Bill
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [HiveMind] Re: Tapestry exception report incomplete?
Posted by Bill Lear <ra...@zopyra.com>.
On Thursday, October 2, 2003 at 17:04:20 (-0400) Harish Krishnaswamy writes:
>>...
>>Why not just toss the thing and let the app catch it?
>>
>My understanding is, from a microkernel standpoint, it is not supposed
>to crash just because one module or service had a problem, you know like
>the containers, they just report the problem and move on. But the
>containers have a console or a designated log file that one can take a
>look at, but HiveMind does not have either, that will be a problem for
>the uninformed, I think.
Hmm, not sure I agree with this --- if someone mis-configures a
microkernel, I'd rather have it crash and tell me about it than
sputter on and die later, pointing me elsewhere by a subsequently
thrown exception. I'll have to think and bring pursue discussion on
the hivemind list.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [HiveMind] Re: Tapestry exception report incomplete?
Posted by Bill Lear <ra...@zopyra.com>.
On Thursday, October 2, 2003 at 17:04:20 (-0400) Harish Krishnaswamy writes:
>>...
>>Why not just toss the thing and let the app catch it?
>>
>My understanding is, from a microkernel standpoint, it is not supposed
>to crash just because one module or service had a problem, you know like
>the containers, they just report the problem and move on. But the
>containers have a console or a designated log file that one can take a
>look at, but HiveMind does not have either, that will be a problem for
>the uninformed, I think.
Hmm, not sure I agree with this --- if someone mis-configures a
microkernel, I'd rather have it crash and tell me about it than
sputter on and die later, pointing me elsewhere by a subsequently
thrown exception. I'll have to think and bring pursue discussion on
the hivemind list.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
[HiveMind] Re: Tapestry exception report incomplete?
Posted by Harish Krishnaswamy <hk...@comcast.net>.
Bill Lear wrote:
>On Thursday, October 2, 2003 at 16:41:38 (-0400) Harish Krishnaswamy writes:
>
>
>>Ha..ha.. I had the same problem this past weekend and I raised it in the
>>HiveMind list. The reason Tapestry cannot show the exception is because
>>it does not know. HiveMind, when it builds the registry, only *logs* the
>>errors, it does *not* throw an exception and crash. So the only way to
>>find this out would be to check the logs. I did not even have the logger
>>setup so I spent even more time stepping through the debugger and
>>figured the stupid typo problem :(
>>
>>
>
>So why does this appear in the log:
>
>
>
>>org.apache.commons.hivemind.ApplicationRuntimeException: Unable to read descriptor file:/opt/jakarta/.jakarta-tomcat-4.1.18-LE-jdk14/webapps/rael_eci/WEB-INF/classes/META-INF/hivemodule.xml: Unexpected element service-point within module (at file:/opt/jakarta/.jakarta-tomcat-4.1.18-LE-jdk14/webapps/rael_eci/WEB-INF/classes/META-INF/hivemodule.xml, line 5).
>>
>>
>
>Is Hivemind just catching this, reporting it, and moving on?
>
Yup.
>
>Why not just toss the thing and let the app catch it?
>
My understanding is, from a microkernel standpoint, it is not supposed
to crash just because one module or service had a problem, you know like
the containers, they just report the problem and move on. But the
containers have a console or a designated log file that one can take a
look at, but HiveMind does not have either, that will be a problem for
the uninformed, I think.
>
>
>Bill
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
>
Re: Tapestry exception report incomplete?
Posted by Drew Davidson <dr...@ognl.org>.
Bill Lear wrote:
>>org.apache.commons.hivemind.ApplicationRuntimeException: Unable to read descriptor file:/opt/jakarta/.jakarta-tomcat-4.1.18-LE-jdk14/webapps/rael_eci/WEB-INF/classes/META-INF/hivemodule.xml: Unexpected element service-point within module (at file:/opt/jakarta/.jakarta-tomcat-4.1.18-LE-jdk14/webapps/rael_eci/WEB-INF/classes/META-INF/hivemodule.xml, line 5).
>>
>>
>
>Is Hivemind just catching this, reporting it, and moving on?
>
>Why not just toss the thing and let the app catch it?
>
>
What's likely happening here (you didn't post the full stack trace so
it's difficult to tell) is that the initialization is done in the
servlet's init() method or in a static initializer. If either of these
is the case you would not see the exeception in the Tapestry exception
viewer because it would never be seen by that - it would be logged by
the servlet runner before any "request" came in for which Tapestry
manages a response (since Tapestry has to do it's work within the
context of the servlet's doGet() or doPost() methods).
I'm just guessing here based on the described behaviour, but when I see
stuff like this in my application logs the above two reasons are most
often the cause.
- Drew
--
+---------------------------------+
< Drew Davidson | OGNL Technology >
< Professional Open Source >
+---------------------------------+
| Email: drew@ognl.org /
| Web: http://www.ognl.org /
| Vox: (520) 531-1966 <
| Fax: (520) 531-1965 \
| Mobile: (520) 405-2967 \
+---------------------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
[HiveMind] Re: Tapestry exception report incomplete?
Posted by Harish Krishnaswamy <hk...@comcast.net>.
Bill Lear wrote:
>On Thursday, October 2, 2003 at 16:41:38 (-0400) Harish Krishnaswamy writes:
>
>
>>Ha..ha.. I had the same problem this past weekend and I raised it in the
>>HiveMind list. The reason Tapestry cannot show the exception is because
>>it does not know. HiveMind, when it builds the registry, only *logs* the
>>errors, it does *not* throw an exception and crash. So the only way to
>>find this out would be to check the logs. I did not even have the logger
>>setup so I spent even more time stepping through the debugger and
>>figured the stupid typo problem :(
>>
>>
>
>So why does this appear in the log:
>
>
>
>>org.apache.commons.hivemind.ApplicationRuntimeException: Unable to read descriptor file:/opt/jakarta/.jakarta-tomcat-4.1.18-LE-jdk14/webapps/rael_eci/WEB-INF/classes/META-INF/hivemodule.xml: Unexpected element service-point within module (at file:/opt/jakarta/.jakarta-tomcat-4.1.18-LE-jdk14/webapps/rael_eci/WEB-INF/classes/META-INF/hivemodule.xml, line 5).
>>
>>
>
>Is Hivemind just catching this, reporting it, and moving on?
>
Yup.
>
>Why not just toss the thing and let the app catch it?
>
My understanding is, from a microkernel standpoint, it is not supposed
to crash just because one module or service had a problem, you know like
the containers, they just report the problem and move on. But the
containers have a console or a designated log file that one can take a
look at, but HiveMind does not have either, that will be a problem for
the uninformed, I think.
>
>
>Bill
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
>
Re: [HiveMind] log exceptions or throw them?
Posted by Harish Krishnaswamy <hk...@comcast.net>.
I totally agree, I don't like the idea of crashing with every single
error. I would like to be able to see all the problems in one shot.
That's good, but there's nothing that forces the developer to set up the
loggers to catch the errors. Of course this is such a trivial thing that
you would expect everyone to already be using some kind of a logger but
it will become a standard newbie question nonetheless. And a lot of the
newbies will get frustrated and that's not good for HiveMind. Having
said that I am not sure what the solution is, like I said before may be
we just have to put a bold warning sign.
-Harish
Howard M. Lewis Ship wrote:
>I can see how this is frustrating; perhaps a change in HiveMind would be nice.
>
>I really want HiveMind to log errors and then continue on as best it can. I think (I may be wrong)
>that most users would be more frustrated with a "brittle" HiveMind that throws an exception for
>every error. In any kind of slightly chaotic team development environment, it would be likely that
>there would be incompatibilities in some module descriptors that would cause runtime errors. I'd
>hate for, say, the guy working on the ShoppingCart page to be dead in the water because he only got
>a partial update to the Registration module .... do you follow me; I want a highly dynamic system
>but I don't want it to be brittle in the face of conflicts.
>
>--
>Howard M. Lewis Ship
>Creator, Tapestry: Java Web Components
>http://jakarta.apache.org/tapestry
>http://jakarta.apache.org/commons/sandbox/hivemind/
>http://javatapestry.blogspot.com
>
>
>
>>-----Original Message-----
>>From: Bill Lear [mailto:rael@zopyra.com]
>>Sent: Thursday, October 02, 2003 4:53 PM
>>To: Tapestry users
>>Subject: Re: Tapestry exception report incomplete?
>>
>>
>>On Thursday, October 2, 2003 at 16:41:38 (-0400) Harish
>>Krishnaswamy writes:
>>
>>
>>>Ha..ha.. I had the same problem this past weekend and I raised it in
>>>the
>>>HiveMind list. The reason Tapestry cannot show the exception
>>>
>>>
>>is because
>>
>>
>>>it does not know. HiveMind, when it builds the registry,
>>>
>>>
>>only *logs* the
>>
>>
>>>errors, it does *not* throw an exception and crash. So the
>>>
>>>
>>only way to
>>
>>
>>>find this out would be to check the logs. I did not even
>>>
>>>
>>have the logger
>>
>>
>>>setup so I spent even more time stepping through the debugger and
>>>figured the stupid typo problem :(
>>>
>>>
>>So why does this appear in the log:
>>
>>
>>
>>>org.apache.commons.hivemind.ApplicationRuntimeException:
>>>
>>>
>>Unable to read
>>
>>
>>>descriptor
>>>file:/opt/jakarta/.jakarta-tomcat-4.1.18-LE-jdk14/webapps/rae
>>>
>>>
>l_eci/WEB-
>
>
>>INF/classes/META-INF/hivemodule.xml: Unexpected element service-point
>>within module (at
>>file:/opt/jakarta/.jakarta-tomcat-4.1.18-LE-jdk14/webapps/rael_eci/WEB-
>>INF/classes/META-INF/hivemodule.xml, line 5).
>>
>>
>
>Is Hivemind just catching this, reporting it, and moving on?
>
>Why not just toss the thing and let the app catch it?
>
>
>Bill
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>
[HiveMind] log exceptions or throw them?
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
I can see how this is frustrating; perhaps a change in HiveMind would be nice.
I really want HiveMind to log errors and then continue on as best it can. I think (I may be wrong)
that most users would be more frustrated with a "brittle" HiveMind that throws an exception for
every error. In any kind of slightly chaotic team development environment, it would be likely that
there would be incompatibilities in some module descriptors that would cause runtime errors. I'd
hate for, say, the guy working on the ShoppingCart page to be dead in the water because he only got
a partial update to the Registration module .... do you follow me; I want a highly dynamic system
but I don't want it to be brittle in the face of conflicts.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
> -----Original Message-----
> From: Bill Lear [mailto:rael@zopyra.com]
> Sent: Thursday, October 02, 2003 4:53 PM
> To: Tapestry users
> Subject: Re: Tapestry exception report incomplete?
>
>
> On Thursday, October 2, 2003 at 16:41:38 (-0400) Harish
> Krishnaswamy writes:
> >Ha..ha.. I had the same problem this past weekend and I raised it in
> >the
> >HiveMind list. The reason Tapestry cannot show the exception
> is because
> >it does not know. HiveMind, when it builds the registry,
> only *logs* the
> >errors, it does *not* throw an exception and crash. So the
> only way to
> >find this out would be to check the logs. I did not even
> have the logger
> >setup so I spent even more time stepping through the debugger and
> >figured the stupid typo problem :(
>
> So why does this appear in the log:
>
> >org.apache.commons.hivemind.ApplicationRuntimeException:
> Unable to read
> >descriptor
> >file:/opt/jakarta/.jakarta-tomcat-4.1.18-LE-jdk14/webapps/rae
l_eci/WEB-
>INF/classes/META-INF/hivemodule.xml: Unexpected element service-point
>within module (at
>file:/opt/jakarta/.jakarta-tomcat-4.1.18-LE-jdk14/webapps/rael_eci/WEB-
>INF/classes/META-INF/hivemodule.xml, line 5).
Is Hivemind just catching this, reporting it, and moving on?
Why not just toss the thing and let the app catch it?
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Tapestry exception report incomplete?
Posted by Bill Lear <ra...@zopyra.com>.
On Thursday, October 2, 2003 at 16:41:38 (-0400) Harish Krishnaswamy writes:
>Ha..ha.. I had the same problem this past weekend and I raised it in the
>HiveMind list. The reason Tapestry cannot show the exception is because
>it does not know. HiveMind, when it builds the registry, only *logs* the
>errors, it does *not* throw an exception and crash. So the only way to
>find this out would be to check the logs. I did not even have the logger
>setup so I spent even more time stepping through the debugger and
>figured the stupid typo problem :(
So why does this appear in the log:
>org.apache.commons.hivemind.ApplicationRuntimeException: Unable to read descriptor file:/opt/jakarta/.jakarta-tomcat-4.1.18-LE-jdk14/webapps/rael_eci/WEB-INF/classes/META-INF/hivemodule.xml: Unexpected element service-point within module (at file:/opt/jakarta/.jakarta-tomcat-4.1.18-LE-jdk14/webapps/rael_eci/WEB-INF/classes/META-INF/hivemodule.xml, line 5).
Is Hivemind just catching this, reporting it, and moving on?
Why not just toss the thing and let the app catch it?
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Tapestry exception report incomplete?
Posted by Harish Krishnaswamy <hk...@comcast.net>.
Ha..ha.. I had the same problem this past weekend and I raised it in the
HiveMind list. The reason Tapestry cannot show the exception is because
it does not know. HiveMind, when it builds the registry, only *logs* the
errors, it does *not* throw an exception and crash. So the only way to
find this out would be to check the logs. I did not even have the logger
setup so I spent even more time stepping through the debugger and
figured the stupid typo problem :(
-Harish
Bill Lear wrote:
>I have spent the last 45 minutes or more debugging something that should
>have been simple to catch --- I am using HiveMind to provide services,
>and I inadvertently used an old version of the HiveMind jar file,
>and HiveMind was not able to parse the hivemodule.xml file at
>runtime.
>
>However, the exception report produced by Tapestry that shows up in my
>browser nowhere indicates this. Instead, it indicates that a module
>is not in the registry (true, but not the cause of the problem).
>
>The Tapestry HTML report shows first
>
> org.apache.tapestry.BindingException
> ...
>
>then
>
> ognl.OgnlException
> ...
>
>then
>
> org.apache.commons.hivemind.ApplicationRuntimeException
>
>and this has the details:
>
>Registry does not contain module 'com.foobar.eci.dao'.
>Stack Trace:
>org.apache.commons.hivemind.impl.RegistryImpl.getModule(RegistryImpl.java:115)
>org.apache.commons.hivemind.impl.RegistryImpl.getService(RegistryImpl.java:125)
>com.foobar.eci.services.Services.getService(Services.java:28)
>
>However, if I look in the log file for my application, I see this, which
>is really what I want:
>
><ERROR 2003-10-02 14:28:56,842 RegistryBuilder:162> Unable to parse module deployment descriptor file:/opt/jakarta/.jakarta-tomcat-4.1.18-LE-jdk14/webapps/rael_eci/WEB-INF/classes/META-INF/hivemodule.xml: Unable to read descriptor file:/opt/jakarta/.jakarta-tomcat-4.1.18-LE-jdk14/webapps/rael_eci/WEB-INF/classes/META-INF/hivemodule.xml: Unexpected element service-point within module (at file:/opt/jakarta/.jakarta-tomcat-4.1.18-LE-jdk14/webapps/rael_eci/WEB-INF/classes/META-INF/hivemodule.xml, line 5).
>org.apache.commons.hivemind.ApplicationRuntimeException: Unable to read descriptor file:/opt/jakarta/.jakarta-tomcat-4.1.18-LE-jdk14/webapps/rael_eci/WEB-INF/classes/META-INF/hivemodule.xml: Unexpected element service-point within module (at file:/opt/jakarta/.jakarta-tomcat-4.1.18-LE-jdk14/webapps/rael_eci/WEB-INF/classes/META-INF/hivemodule.xml, line 5).
> at org.apache.commons.hivemind.parse.DescriptorParser.parse(DescriptorParser.java:480)
> at org.apache.commons.hivemind.impl.RegistryBuilder.processModuleResource(RegistryBuilder.java:245)
> at org.apache.commons.hivemind.impl.RegistryBuilder.processModules(RegistryBuilder.java:212)
> at com.foobar.eci.services.Services.getService(Services.java:24)
>
>So, here, the actual error is from 4 lines earlier in my source code
>than indicated in the HTML error report, and, of course, it includes
>a description of what the problem was.
>
>So, is there a reason this is not caught and reported by Tapestry?
>
>
>Bill
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org