java.lang.ClassNotFoundException: com.example.StreamLambdaHandler

[abidk]

Description:

When executing the spring-boot example:

mvn archetype:generate -DgroupId=my.service -DartifactId=my-service -Dversion=1.0-SNAPSHOT \
       -DarchetypeGroupId=com.amazonaws.serverless.archetypes \
       -DarchetypeArtifactId=aws-serverless-springboot-archetype \
       -DarchetypeVersion=1.1 

And running the project (via. sam local start-api --template sam.yaml --debug) results in the following error:

START RequestId: 9e5a7678-5dda-49a2-b244-1337d775ffa2 Version: $LATEST
java.lang.ClassNotFoundException: com.example.StreamLambdaHandler
	at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:348)

This seems to be an issue specifically with Ubuntu sam/docker (Possibly also with ubuntu version 18.04 specifically). Running the same sam-cli 0.3.0 and docker 18.03.1-ce on OSX works correctly and a response is returned as expected.

[sisiguo]

+1

I'm also running into a similar issue and have a ticket open on the aws-serverless-java-container project here too: aws/serverless-java-container#153

But I also encounter the same error when I do a deploy of the package to aws lambda via cloudFormation.

[abidk]

@sisiguo thanks for mentioning your ticket aswell. What operating system are you running it in?

[sisiguo]

I'm working off Ubuntu in a VMware box w/ this set-up:

• Ubuntu: 16.0.4
• Docker: 18.03.1-ce
• Sam: 0.3.0

[mhball]

+1 here too on:

Linux Mint 18.1 Cinnamon 64-bit
Sam 0.3.0
Docker 18.03.1-ce

This is really slowing down our Java development!

Seems to work okay for JavaScript though

[BoundInfinity]

+1 setup:

Ubuntu: 16.0.4
Docker: 18.03.1-ce
Sam: 0.3.0

It works for JS and fails for Java. Rolling back onto Sam 0.2.11 works for Java.

[fl3x1324]

I've created a pull request. Travis CI tests passed. Review needed. :)

[jfuss]

dupe of #389, which is being addressed in #464?

[fl3x1324]

@jfuss not really. The permissions for files inside the temp dir are preserved, but the dir itself is 700 which prevents docker from accessing the files inside. Setting the permissions to 755 or something similar eg. xx[4,5,6,7] works fine.

[fl3x1324]

@jfuss please note that this is not recursive chmod-ing, just the temp dir (tmpXXXXXX). Cheers!

[fl3x1324]

Problem is in the tempfile.mkdtemp() function where the dir is created with permissions 700, check this out, it's in the python2.7 source:
tempfile.py

def mkdtemp(suffix="", prefix=template, dir=None):
    """User-callable function to create and return a unique temporary
    directory.  The return value is the pathname of the directory.

    Arguments are as for mkstemp, except that the 'text' argument is
    not accepted.

    The directory is readable, writable, and searchable only by the
    creating user.

    Caller is responsible for deleting the directory when done with it.
    """

    if dir is None:
        dir = gettempdir()

    names = _get_candidate_names()

    for seq in xrange(TMP_MAX):
        name = names.next()
        file = _os.path.join(dir, prefix + name + suffix)
        try:
            _os.mkdir(file, 0700)
            return file
        except OSError, e:
            if e.errno == _errno.EEXIST:
                continue # try again
            if (_os.name == 'nt' and e.errno == _errno.EACCES and
                _os.path.isdir(dir) and _os.access(dir, _os.W_OK)):
                # On windows, when a directory with the chosen name already
                # exists, EACCES error code is returned instead of EEXIST.
                continue
            raise

    raise IOError, (_errno.EEXIST, "No usable temporary directory name found")

So what I did was just a workaround. This bug is not reproducible on Windows because the ntfs driver exposes all files with permissions 777 when accesed from linux host.

[sanathkr]

@fl3x1324 Looks like my PR won't solve this problem. Giving 755 permissions to the temp directory doesn't harm and probably helps with read/writability of the folder from within the Docker.

Reviewing your PR

[jfuss]

The fix for this that @fl3x1324 did was release in v0.4.0.

Closing this issue