Singleton Design Pattern – Multiple Instances Allowed?

Your second option is a fine way to go -- it's a kind of dependency injection, which is the pattern used to share state across your program when you want to avoid singletons and global variables.

You can't get around the fact that something has to create your factory. If that something happens to be the application, so be it. The important point is that your factory shouldn't care what object created it, and the objects that receive the factory shouldn't depend on where the factory came from. Don't have your objects get a pointer to the application singleton and ask it for the factory; have your application create the factory and give it to those objects that will need it.

A singleton is a fancy kind of global state.

Your Urls isn't usefully a singleton, because it has no state. You may as well just not instantiate it in normal code.

public class Urls {
    public Urls() { }
    // static methods ...
}

context.put("urls", new Urls());