[2.1.0 Regression] Dev-Mode ClassLoader does not contain app classes about playframework HOT 20 CLOSED

@jroper , you're so helpful ;-)

I wouldn't ask it here if I could find the solution somewhere else; on the stackfoverflow this question was already answered (see http://stackoverflow.com/questions/20210574/play-fails-to-load-custom-log-back-appender), but I don't like the idea to compile logback stuff and manually put it to jar file at /lib directory. Shouldn't playframework do our lifes easier?

Another related question in the mailing (see https://groups.google.com/forum/#!topic/play-framework/MgLHlBOldeE) has no answer.

So, sorry me, but in this case I have no other place to ask play-devs on how to make things right except here. We'll be very grateful if you can confirm that the suggested solution at stackoverflow is the only valid or enlighten us with proper way to extend logback in playframework.

Thanks.

from playframework.

@ssokolenko The mailing list and stack overflow are good places to ask questions, not the issue tracker.

from playframework.

Hi @jroper ,

is there any way to run custom logback's converters/filters/layout in dev mode?

from playframework.

I have the same issue with other framework like hazelcast https://groups.google.com/forum/?fromgroups=#!topic/play-framework/0p7MtKMmKRg

from playframework.

Hello,
Is there a plan for this ticket? We need DEV and PROD mode behaves the same way, we lose hugely time.
Thank you

from playframework.

We got an (propably) similar issue here: Deserializing a instance of a app-definied class (using commons-langs SerializationUtils) falis with ClassNotFoundException. Root cause (as far a i can track this down) is that

private static native ClassLoader latestUserDefinedLoader() 

from ObjectInputStream returns the classloader from PlayCommands: SBT/Play shared ClassLoader, with: WrappedArray([...]) whereas Thread.currentThread().getContextClassLoader() returns the PlayReloader one: ReloadableClassLoader(v1) {[...]}.

I'm not sure about the behaviour of latestUserDefinedLoader() so i could not find a solution to this...

A Workaround (for me) is:
instead of using

SerializationUtils.deserialize(inputStream); 

i did define

    /**
     * copy of SerializationUtils.deserialize to change ObjectInputStream Implementation
     *
     * @param inputStream
     * @return
     */
    private static Object deserialize(InputStream inputStream) {
        if (inputStream == null) {
            throw new IllegalArgumentException("The InputStream must not be null");
        }
        ObjectInputStream in = null;
        try {
            // stream closed in the finally
            in = new ClassLoaderObjectInputStream(inputStream);
            return in.readObject();

        } catch (ClassNotFoundException ex) {
            throw new SerializationException(ex);
        } catch (IOException ex) {
            throw new SerializationException(ex);
        } finally {
            try {
                if (in != null) {
                    in.close();
                }
            } catch (IOException ex) {
                // ignore close exception
            }
        }
    }

    /**
     * Use the implemenation for Play2.1, because latestUserDefinedLoader()
     * of original implementation does return classloader incorrectly
     * (PlayCommands instead of PlayReloader).
     */
    private static class ClassLoaderObjectInputStream extends ObjectInputStream{

        public ClassLoaderObjectInputStream(InputStream in) throws IOException {
            super(in);
        }

        @Override
        protected Class<?> resolveClass(ObjectStreamClass desc) throws IOException, ClassNotFoundException{

            try {
                String name = desc.getName();
                ClassLoader ccl = Thread.currentThread().getContextClassLoader();
                Class<?> clazz = ccl.loadClass(name);
                return clazz;
            } catch(ClassNotFoundException e) {
                return super.resolveClass(desc);
            }
        }
    }

    }

from playframework.

I ran into a very similar problem with Akka.

Instead of initializing Akka with

    AkkaSystem("name")

I used

    ActorSystem("name", 
      ConfigFactory.load(), 
      Play.classloader(Play.current))

My inspiration came from here:
http://grokbase.com/t/gg/play-framework/133bamw7n6/play-2-1-0-akka-remoting-classnotfoundexception-after-upgrading-from-2-0-4

It is probably easier to adjust this to hazelcast than to logback.

Maybe you can do something similar with logback provided you load the logging configuration after application startup?

from playframework.

We had the similar issue. Our case is caused by "SBT/Play shared ClassLoader" which includes only the jar files in "dependencyClasspath in Compile", e.g., HBase library classes. And our customized HBase filter in app classes is in "ReloadableClassLoader(v?)", who is the child of "SBT/Play shared ClassLoader". When we use the filter to build a HBase scan, HBase library uses "SBT/Play shared ClassLoader" when calling "Class.forName" and the filter is invisible, then we got "ClassNotFoundException".

I have a blog for this issue: http://ben-tech.blogspot.com/2013/05/play-run-in-dev-mode-and.html.

I'm wondering if this is possible to create a classloader that loads the classes like HBase filter and is parent of "SBT/Play shared ClassLoader", and reloads the classes during reloading.

from playframework.

Possibly related to #851.

from playframework.

+1 I would like to see that DEV & PROD Classloaders work the same, too. I have run across this problem twice now.

from playframework.

Having probably this same problem with postgresql jdbc's "datatype.type=MyClass" option, which ends up calling Class.forName. When MyClass is part of the project (or a sub-project), a runtime ClassNotFoundException results in "play run", but not after dist, or when putting the jar manually in lib. Is there any workaround or fix?

from playframework.

+1 on prod and dev classloaders to work the same.
I got an issue which I think is related to this.

from playframework.

Most of the comments here are not related to this issue.

In order to dynamically reload your classes, Play must use a dynamic classloader in dev mode. We can't avoid that. But there is no need for the complexity of a dynamic classloader in prod mode, so we don't use one. In future we might. But if your code is broken in dev mode but not in prod mode, it probably means that at some point your code is calling Class.forName, or is not passing the Play classloader to somewhere where it should. That's a problem with your code (or the library you're using), there's nothing Play can do about that, unless we decide not to use a dynamic classloader, in which case you'll have to restart Play every time you make a change to your code.

from playframework.

Many standard libraries call Class.forName (in my case, postgresql-jdbc, inside the jdbc api-specified connection constructor). Are you saying all these libraries (and apis) need to be fixed somehow to be passed a classloader?

from playframework.

Many standard libraries use the context classloader as the way to load classes, precisely because of these issues with dynamic classloaders, since most Java code these days run in a dynamic classloader (eg, tomcat and other servlet containers provide a dynamic classloader). Any the library that doesn't do this is broken.

As for the postgresql-jdbc specifically, I don't know about it, I haven't seen any other reports of there being problems with postgres, and it's not uncommon for people to use postgres with Play. If you've found a reporducable issue for it, please raise a separate bug, with stack traces etc.

from playframework.

We stumbled across a similar (same?) issue when upgrading a 2.0.4 based app to 2.1.1. We use a custom router for one of our actors. Usage is similar to this:

 val actor = Akka.system.actorOf(Props[SomeActor].withRouter(FromConfig()), name = "someActor")

Configuration looks like this:

play {
    akka {
      actor {
        deployment {
          /someActor {
            router = "controllers.SomeRouter"
            nr-of-instances = 4
          }
        }
      }
    }
}

In development mode (and with logger.application=TRACE in the config) the app fails to run with the following exception:

[trace] application - Exception caught in Netty
java.lang.ExceptionInInitializerError: null
  at play.api.libs.concurrent.Execution$Implicits$.defaultContext$lzycompute(Execution.scala:8) ~[play_2.10.jar:2.1.1]
  at play.api.libs.concurrent.Execution$Implicits$.defaultContext(Execution.scala:7) ~[play_2.10.jar:2.1.1]
  at play.api.libs.concurrent.Execution$.<init>(Execution.scala:11) ~[play_2.10.jar:2.1.1]
  at play.api.libs.concurrent.Execution$.<clinit>(Execution.scala) ~[play_2.10.jar:2.1.1]
  at play.core.server.netty.PlayDefaultUpstreamHandler.handleAction$1(PlayDefaultUpstreamHandler.scala:359) ~[play_2.10.jar:2.1.1]
  at play.core.server.netty.PlayDefaultUpstreamHandler.messageReceived(PlayDefaultUpstreamHandler.scala:329) ~[play_2.10.jar:2.1.1]
Caused by: java.lang.IllegalArgumentException: Cannot instantiate router [controllers.SomeRouter], defined in [/someActor], make sure it extends [akka.routing.RouterConfig] and has constructor with [com.typesafe.config.Config] parameter
  at akka.actor.Deployer$$anonfun$1.applyOrElse(Deployer.scala:165) ~[akka-actor_2.10.jar:na]
  at akka.actor.Deployer$$anonfun$1.applyOrElse(Deployer.scala:164) ~[akka-actor_2.10.jar:na]
  at scala.runtime.AbstractPartialFunction.apply(AbstractPartialFunction.scala:33) ~[scala-library.jar:na]
  at scala.util.Failure$$anonfun$recover$1.apply(Try.scala:185) ~[scala-library.jar:na]
  at scala.util.Try$.apply(Try.scala:161) ~[scala-library.jar:na]
  at scala.util.Failure.recover(Try.scala:185) ~[scala-library.jar:na]
Caused by: java.lang.ClassNotFoundException: controllers.SomeRouter
  at java.net.URLClassLoader$1.run(URLClassLoader.java:202) ~[na:1.6.0_45]
  at java.security.AccessController.doPrivileged(Native Method) ~[na:1.6.0_45]
  at java.net.URLClassLoader.findClass(URLClassLoader.java:190) ~[na:1.6.0_45]
  at java.lang.ClassLoader.loadClass(ClassLoader.java:306) ~[na:1.6.0_45]
  at java.lang.ClassLoader.loadClass(ClassLoader.java:247) ~[na:1.6.0_45]
  at sbt.PlayCommands$$anonfun$53$$anonfun$55$$anon$2.loadClass(PlayCommands.scala:535) ~[na:na]    

However, it works in production mode.

from playframework.

jroper,
buildin ehcache in play 2.1.1 does not use dynamic classloader. in case of memory usage after any changes I get empty cache, if I try disk usage I get ClassNotFoundException :(

from playframework.

Hi, jroper.
i encounter the same problem when using openjpa. is there a way to get the dynamic classloader, so i can fix the problem via recompiling openjpa ?

from playframework.

actually some of 3rd lib using OSGi, is there any OSGi configure for play?

from playframework.

There are too many separate issues involved in this bug report to be useful, some have been fixed (for example, Akka using the right classloader), and some have nothing to do with Play.

If you're having classloader issues, first ask for help on the mailing list, and if it seems apparent that there is something concrete that Play is doing wrong, then raise a bug, or something concrete that Play could do better, then submit a pull request.

from playframework.