search

IQSS / dataverse

Open source research data repository software
http://dataverse.org
Other
875 stars 484 forks source link

Issue using S3 Direct Upload, NoSuchMethodError #7220

Open mderuijter opened 4 years ago

mderuijter commented 4 years ago

The following happens when I try to use S3 Direct Upload: Dataverse: v. 4.20 build develop-02601927b

awscli is installed, config and credentials have been setup correctly. has region = eu-central-1 in the config

I have configured the following JVM options: -Ddataverse.files.s3.type=s3 -Ddataverse.files.s3.label=s3 -Ddataverse.files.s3.bucket-name=dv-dev-bucket -Ddataverse.files.s3.download-redirect=true -Ddataverse.files.s3.upload-redirect=true

But as soon as i try to select S3 as the upload option for a dataverse or if i try to upload some files i get the following error: StandardWrapperValve[Faces Servlet]: Servlet.service() for servlet Faces Servlet threw exception java.lang.NoSuchMethodError: com.fasterxml.jackson.databind.ObjectMapper.enable([Lcom/fasterxml/jackson/core/JsonParser$Feature;)Lcom/fasterxml/jackson/databind/ObjectMapper

According to Stackoverflow this seems to be a dependency related issue:

Has anyone else experienced the same problem?

qqmyers commented 4 years ago

I haven't, and have had v4.20 successfully uploading to an S3 store. I'm not sure what to suggest. Any way you have different libraries installed than in the 4.20 release? (looks like jackson core and databind should be v2.9.6). Did you upgrade from a prior version and if so, did you delete the ./generated directory and restart glassfish?

I'm just guessing but the nature of the error and the fact that you see an issue when you change the s3 store for a dataverse suggest it really is a conflict and not something related to aws/s3 config. (The code to let you change the store for a dataverse doesn't make any connection to AWS underneath - it just queries to get the list of store names to present and writes your choice back to the db.)

mderuijter commented 4 years ago

@qqmyers Hi, I haven't changed any libraries in the pom.xml or added libraries manually either. I use Docker to automate my development environment to a certain degree, so I've tried starting with a fresh and configured dataverse a couple of times without success. So i'm not upgrading from an older version.

What is the ./generated directory you are referring to?

qqmyers commented 4 years ago

OK - I'm not familiar with what could go wrong with a Docker deployment in terms of how that might affect how libraries are found/ways you could see a conflict - hopefully others have some thoughts there. W.r.t. the ./generated directory - Glassfish (and Payara for 5.0 I assume) creates a generated subdirectory (under domains/domain1 if you use the default path) where I believe it compiles code for the .xhtml files. The install instructions usually include deleting it's contents. My thought in bringing it up is that it could be a place where information from an older version could get cached (and therefore give you a conflict). I don't have any specific reason to think that's the source of the problem beyond it potentially being a place where out-of-date info could exist. (FWIW - there is also an osgi-cache directory that some of the developer/debug info in the guides suggest deleting (with a glassfish restart). Another place out-of-date info might exist if you're changing versions/updating code.)

mderuijter commented 4 years ago

@qqmyers I'm afraid deleting those folders didn't help either (and restarting glassfish). I am still using glassfish 4.1, but that shouldn't be an issue. I'll try and see if I can get it to work on our development team's ansible/vagrant dataverse, if it works there I'll have to reevaluate my Docker setup :) Thanks for thinking with me on this. I'll let you know what happens.

mderuijter commented 4 years ago

@qqmyers alright, so the same config options DO work under the ansible/vagrant dataverse... The difference is that glassfish in my Docker runs as the root user, and the vagrant dataverse has a proper glassfish user setup. I don't know if that could lead to a situation like this, I'd have to try.

qqmyers commented 4 years ago

FWIW: I don't think the root versus glassfish account causes an issue directly, but perhaps there are path, JAVA_HOME, or other variables that are different when you run as root?

mderuijter commented 4 years ago

@qqmyers I agree running as root shouldn't cause this directly, and the Path setup just looks normal to me as well. I can't think of any reason right now why the Docker setup would behave differently than the Vagrant VM...

poikilotherm commented 4 years ago

Please see https://github.com/IQSS/dataverse/issues/5274#issuecomment-439844195 for a very similar error message.

Please keep in mind that in 4.20 the AWS SDK had been included in their full version. I remember they are shipping their own copies of Jackson rebundled. What precise version/commit are you using?

mderuijter commented 4 years ago

@poikilotherm Yes that is a very similar error message indeed. The AWS SDK version that's included in the pom.xml is 1.11.762 and the dataverse develop commit i'm on is v. 4.20 build develop-02601927b.

According to this comment https://github.com/IQSS/dataverse/issues/5274#issuecomment-439844195 the issue might be resolved if I upgrade to payara 5?

pdurbin commented 1 year ago

According to this comment #5274 (comment) the issue might be resolved if I upgrade to payara 5?

@mderuijter did you upgrad to Payara 5? Are you all set now? I hope so! 😄