Seems to have been fixed in 6.2, not .3. Ref JDEV-25244.

Am I going crazy or does this seem to be fixed in jira 6.3?

BTW - I was saying that not being able to vote on resolved issues is BS, not necessarily this particular issue. For others... Jozef Kotlar has written a log4j filter that can help with this: https://answers.atlassian.com/questions/40838/how-to-avoid-invalidinputexception-stacktrace-in-log-using-custom-validators

I concur with Jamie, this is BS. Throwing a heavy weight exception is totally overkill for validators when a simple return true or false is all that is needed. I don't want to hear from some Atlassian architect that the framework dictates that an exception must always be thrown. Total overkill.

+1 from me. I would vote but it's not allowed on resolved-won't-fix issues, which in itself seems like kind of BS.

This should definitely be reconsidered. Or Atlassian should provide their own method to require a field or validate a field during a transition. This is because you want to have a lot of fields available to edit during the edit screen, but depending on the state the issue is in, certain "required" fields may not be necessary to have data or be known at that time. Then, during the course of the workflow, it may get to a step or transition where a field should be required to be filled out.

The alternative to using the JIRA Suite Utilities plugin is so set the field as required in the field configuration. However, then at the edit screen, the field will always be required no matter when the issue is edited. This would cause data quality issues where the field will be filled out with nothing, which then still satisfies a requirement during a transition at a later state.

This causes issue with the JIRA system logging since new log files are only created on restarts of JIRA, and the old log files are never cleaned up, which then could grow and keep growing to the point of running out of hard drive space and causing the system to crash theoretically halting all work. On top of that, as an administrator, you end up having to sift through all these legitimate stack traces to try to figure out if there is a real bug or problem occurring in your JIRA environment. Investigation into issues therefore takes exponentially more time than is necessary.

Please reconsider this or provide an alternative that solves all the problems that this stack traces causes.

My only problem is the printing of the whole stack trace of the error, which is totally unncesseary. Why not just log at Info or Warn-level so that the information is displayed in the log, but not the whole trace.

This DOES cause the users of 'JIRA Suite Utilities' a lot of pain.
Also for other customers of us, for who we developed custom validators, this is a problem.

Would be nice to reconsider. What I've looked through the JIRA source code, it should be no such big thing, to log InvalidInputException only at debug level (other WorkflowExceptions still at error level).

Anton,

I have the same request as Remy, but I have additionnal points:

The existing behavior is making the monitoring of our production server very difficult, as the logfile is constantly filled by abnormal and normal exceptions.
We need to have only abnormal errors to be dumped, so that we can really focus on fixing them.

The 'real solution' proposed here (JRA-5783) is not relevant for us, as our validation conditions depends on values of custom fields in issues, and not only the transition.

As an alternative to subclassing InvalidInputException, you could also introduce a sort of 'SilentException' interface that developers coudl chose to implement in their own Exceptions, when they want to avoid the dump of 'normal' exceptions.

Thank you,
JF

Thanks for the upddate and understanding!