Details
-
Type:
New Feature
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 1.0-beta-1
-
Component/s: None
-
Labels:None
-
Environment:windows
-
Number of attachments :
Description
Having hundreds of dependencies the windows shell script tries to create a huge environment variable, which overflows. You get a "line too long" when running.
A possible solution would be to load jars inside the shell script by using a classloader like Jakarta Commons Launcher http://jakarta.apache.org/commons/launcher/, Ant, Uberjar or perhaps Classworlds http://classworlds.codehaus.org/
This would also open a whole new range of possibilities : having jar directories with different priorities (say an empty "patches" directory), having a different class loading order then the usual alphanumeric order (for conflicting jars)
Thats not a bad idea (re ClassWorlds) but most launchers have a way of defining the classpath as a wildcard, for instance wrapper can define it as lib/* and it will add the jars it finds to the classpath.
On the other hand, using the classpath is actually not the best thing to do, or if you do you it in the startup scripts, you have to make sure you wipe out any existing classpath or you may end up importing something unintended (thats my developers don't use it).
I think using a bootstrapper like classworlds might be better anyway as it gives a good clean entry point to any application. My only concern is the overhead of loading jars that way. e.g. if I have a simple utility bundles with the app, I only need that one jar.