11 May
2008
11 May
'08
1:16 a.m.
Vincent Massol wrote:
Well, I didn't want to blame anybody, but yeah...
Thanks,
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
On May 10, 2008, at 3:56 AM, Sergiu Dumitriu wrote:
Could be done, and I know exactly how. It is quite simple, but for the
automatic velocity API we have to be extra careful... I'll send a
proposal mail with the ideas in the next few days (if I don't, please
remind me, 'cause I tend to forget things).
About that flag, not so sure about it. If we want to globally
enable/disable this, we could just remove it from the chain of
uberspectors. And if we want to have that flag anyway, I'd make it the
other way around: by default don't let exceptions through. I'd put
something in the footer, [this page generated some exceptions], which
can be clicked to view the list of exception messages, and each message
can be clicked to display its stack trace.
Hm, or maybe the default should depend on what kind of build that is: a
release defaults to "don't let exceptions through" and a local build
does the other way around, for easier debugging.
WDYT?
Hi devs,
This week I introduced the support for chainable uberspectors, and
beside the SecureUberspector that was used before, now there's also a
DeprecatedCheckUberspector, that prints a warning in the logs
whenever a
deprecated method is called from velocity.
This is very cool. BTW one new uberspector that I'd like to add in the
future is an ExceptionCatchingUberspector which allows catching
exception from methods called and making them available in a velocity
context variable. By default the uberspector would let the exception
go through but a flag could be set to enable it. The general idea is
to have a single API, the java one and not a special API for Velocity
calls. Several things
I'd like to emphasize:
- These logs break the validity check done in the XmlRpc tests, so
this
allows us to detect (almost) any usage of the deprecated methods in
wiki
documents and update these documents
that's cool
- It also means that we can't make a product
release while there are
deprecated calls in the wiki pages
even better ;)
- "deprecated" means "having the
@Deprecated annotation". There's no
(simple) way of checking for the @deprecated doclet.
- whenever something gets deprecated, be sure to add this
annotation, as
otherwise the calls to the deprecated method won't be detected
- could someone help with cleaning the wiki source in order to fix the
builds on the 1.5-depending products? Just look at the continuum build
results (for example
http://continuum.xwiki.org/continuum/buildResult.action?buildId=20015&p…)
and look for messages like:
[WARNING] Deprecated usage of method
[com.xpn.xwiki.api.XWiki.parseInt]
in Main.Dashboard@14,25
and update the affected document (could be a GSoC student...)
I'll help.
- the logged document name is not always right,
as it doesn't reflect
inclusions and calls to $xwiki.parseText
I guess this is because of the trick we have of using the same
template name when we do includes... :(