commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <ja...@carmanconsulting.com>
Subject RE: [proposal] Location utilities
Date Sun, 18 Sep 2005 13:09:18 GMT
Sylvain,

I like the idea.  I think the line-precise error reporting feature in
Tapestry/HiveMind is very helpful and other projects could benefit from it.
However, I would seriously doubt that we could get either project (Howard,
correct me if I'm wrong) to migrate over to using it because of the
reluctance to introduce another dependency.  This fear of "jar hell" (we
really need to come up with a formal name for that phobia) seems to limit
inter-project dependencies a lot here at Apache.  I doubt I'll ever even get
HiveMind to switch over to using commons-proxy as a core dependency, even
though I think it would make it tremendously more developer-friendly and
extensible.  

Just because we don't "eat our own dog food" doesn't mean that others might
not like a taste (my dogs seem to eat each others food almost exclusively)!
:-)  Has this code been developed entirely inside the Cocoon source
repository here at ASF (it has not "lived" anywhere else)?  If so, then it
shouldn't be too tough to get a commons-sandbox project started for this (no
software grant would be necessary from what I understand).  You have my +1
for starting a project in the sandbox for this code (not that I think it's
needed, but I just like to vote on random things).  I don't see any harm in
it.  If it never makes it out of the sandbox due to lack of community
interest, so be it.   If cocoon wants to migrate to using it, then that
would make it all the more likely that it would make it out of the sandbox,
though.

James


-----Original Message-----
From: news [mailto:news@sea.gmane.org] On Behalf Of Sylvain Wallez
Sent: Sunday, September 18, 2005 5:03 AM
To: commons-dev@jakarta.apache.org
Subject: Re: [proposal] Location utilities

Ping!

Only two people commented on this proposal. Does this mean there's no 
interest, or that I should elaborate more on it?

It seems to me that tracking the location of objects created from 
configuration files and reporting locations in exceptions is a very 
common need. Many projects have their own solution whereas other simply 
ignore this problem, which makes life very difficult to the user when it 
comes to correlating a Java exception with an error in a configuration file.

Having a common infrastructure (commons-location?) for this would allow 
to ease the task of tracking locations and would bring cross-project 
consistency in this area, just as commons already did in a number of 
other areas.

So, what do you think?

Sylvain


Sylvain Wallez wrote:

> Hi there,
>
> A large number of applications are dealing with configuration files 
> (server.xml, struts-actions.xml, cocoon.xconf, etc) and 
> semi-interpreted languages (Cocoon's sitemap, template languages in 
> Tapestry, Cocoon and Velocity, etc).
>
> A common problem with all these files is to report some meaningful 
> location information in the corresponding files when some problems 
> related to the information they contain occur (syntax error, invalid 
> class name, unkown component, etc). In such cases, the raw Java 
> exception is often of little use if it doesn't carry some location 
> information.
>
> Tapestry has for long had its nice "line precise error reporting" (see 
> [1], section 2.14), and we needed something similar for Cocoon. 
> However Cocoon needed more than this as request handling involves 
> several levels of semi-interpreted languages, such as the sitemap, 
> XSLT or JavaScript.
>
> So at Cocoon we have built a utility package that allow for location 
> stacktraces that complement regular Java stacktraces in exceptions. 
> The various levels of the Java call stack can also add their own 
> location information to the orginal exception without requiring 
> exception nesting, which leads to smaller, easier to understand 
> stracktraces.
>
> I would like to propose this utility package for inclusion in Jakarta 
> Commons. This would allow for other projects to provide more easily 
> some meaningfull error reports, and, if successful, would make error 
> reporting globally more consistent when different products are used 
> together.
>
> You can see this utility in action at [2], and browse the source code 
> in Cocoon's SVN [3]. It has no dependency except commons-lang where 
> IMHO it would fit nicely.
>
> What do you think? Is it of interest to the commons project?
>
> Thanks,
> Sylvain
>
> [1] http://jakarta.apache.org/tapestry/3.0.3/faq.html
> [2] http://www.anyware-tech.com/blogs/sylvain/archives/000210.html
> [3] 
>
http://svn.apache.org/repos/asf/cocoon/trunk/src/java/org/apache/cocoon/util
/location/ 
>
>
-- 
Sylvain Wallez                        Anyware Technologies
http://people.apache.org/~sylvain     http://www.anyware-tech.com
Apache Software Foundation Member     Research & Technology Director


---------------------------------------------------------------------
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


Mime
View raw message