Create Sign up

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Get started Tell me more

4,551,723

Community Members

Community Events

184

Community Groups

Community
Products
Fisheye/Crucible
Questions
FishEye throws an exception when adding a built-in user

FishEye throws an exception when adding a built-in user

I have been unable to add a new built-in user to FishEye. An exception is thrown:

Your request was unable to be processed

java.lang.ExceptionInInitializerError -

Illegal character in path at index 16: file:/C:/Program Files/Atlassian/FishEye/fecru-3.3.0/content/WEB-INF/classes/

We have a Starter license, the current version is CR3.3.0 FE3.3.0 (20140210093606 2014-02-10). This problem also occurred before we upgraded from FE/CR3.2.4 to FE/CR3.3.0 and we run it on Windows Server 2008

Can anyone help with this?

2 answers

1 accepted

0 votes

Answer accepted

java.lang.NoClassDefFoundError: Could not initialize class com.opensymphony.xwork.validator.ValidatorFactory

implies there is something wrong with your FishEye installation.

Can you please unzip the FishEye zip again into a clean directory, stop the old instance and then start the new one ?

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

I did as suggested and reinstalled FishEye into a fresh directory. However, the exception was still thrown when I attempted to add either a built-in or crowd user.

I re-reviewed the documentation regarding sharing JIRA users with other Atlassian applications - such as FishEye - and eventually realised that there must be something in the FishEye user configuration that was incorrect.

I found that under FishEye | Administration | Users | Security | Authentication: JIRA/Crowd authentication - the Auto-add users into FishEye setting was false. Once changed to true, JIRA users are now able to log-in to FishEye.

This differs somewhat from the article at https://confluence.atlassian.com/display/JIRA/Allowing+Other+Applications+to+Connect+to+JIRA+for+User+Managementwhich uses Confluence as an example and guides the reader to User Directories administration. Nevertheless, the article was enough to point me in the right direction.

Thank you for your help.

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

0 votes

Can you please post the full stack-trace from the logs on the server?

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Thanks for your response. I performed the failed add user again and immediately took the attached extract from the end of the FishEye log.

Attachment seems to have failed so will paste the text here instead.

Hmmh - that exceeds the limit - trying attachment again...

It appears that I am unable to upload the extract from the log.

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Here's the first few lines of the stack trace from the log:

2014-02-19 13:36:52,052 WARN [qtp5321706-292 ] org.eclipse.jetty.servlet.ServletHandler ServletHandler-doHandle - Error for /admin/userAdd.do

java.lang.NoClassDefFoundError: Could not initialize class com.opensymphony.xwork.validator.ValidatorFactory

at com.opensymphony.xwork.validator.ValidatorFileParser.addValidatorConfigs(ValidatorFileParser.java:157)

at com.opensymphony.xwork.validator.ValidatorFileParser.parseActionValidatorConfigs(ValidatorFileParser.java:98)

at com.opensymphony.xwork.validator.DefaultActionValidatorManager.loadFile(DefaultActionValidatorManager.java:183)

at com.opensymphony.xwork.validator.DefaultActionValidatorManager.buildClassValidatorConfigs(DefaultActionValidatorManager.java:79)

at com.opensymphony.xwork.validator.DefaultActionValidatorManager.buildValidatorConfigs(DefaultActionValidatorManager.java:162)

at com.opensymphony.xwork.validator.DefaultActionValidatorManager.getValidators(DefaultActionValidatorManager.java:59)

at com.opensymphony.xwork.validator.AbstractActionValidatorManager.validate(AbstractActionValidatorManager.java:50)

at com.opensymphony.xwork.validator.AbstractActionValidatorManager.validate(AbstractActionValidatorManager.java:38)

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Found another exception in the log which might be a better match: