Closed GoogleCodeExporter closed 9 years ago
Hi,
I got a similar error when I was writing a web application using encog
dependencies. It looks like a classloader issue. When I deploy war in tomcat
and the web app tries to load an EG file, the "Unknown activation function"
error is thrown. The following line of code would need to be fixed:
org.encog.util.obj.ModuleHandler.createModuleList(final String... packages)
here the line:
for (final Class< ? > c : ModuleHandler.findClasses(ClassLoader
.getSystemClassLoader(), pkgfilter, null, false, null))
uses system class loader. I think when running under tomcat the expected
classes would not show.
Just a hunch ;-)
Would be glad to see this problem fixed ASAP
Original comment by iyerk0@gmail.com
on 9 Nov 2010 at 8:27
This problem was fixed for me in the later release without changing anything.
Download the latest build at :
http://build.heatonresearch.com/cruisecontrol/buildresults/java-encog-core
Original comment by androw95...@gmail.com
on 9 Nov 2010 at 9:23
Please see attached file for fix to this issue. This works on both standalone
and web application setups. The issue is with using system classloader. I have
replaced it with current classloader and I got the expected results.
Hurray !
Please check attached file for fix.
Thanks
k
Original comment by iyerk0@gmail.com
on 9 Nov 2010 at 10:27
Attachments:
Hi androw95220,
Thanks for letting me know. If this has been fixed, then please mark this bug
as closed.
One more thing can't i update to the latest core codebase from google code?
Thanks,
k
Original comment by iyerk0@gmail.com
on 10 Nov 2010 at 5:53
[deleted comment]
One more thing...
Despite my changes to the classloader, the following cast fails when running in
JUnit through an ant task
classPaths = ((java.net.URLClassLoader) classLoader).getURLs();
I suspect this will be the same issue with the existing classloader in
modduleHandler.
I get the following cast exception
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask$SplitLoader cannot be
cast to java.net.URLClassLoader
Note that the JUnit runs fine if I execute it from eclipse IDE directly.
FYI...
Original comment by iyerk0@gmail.com
on 10 Nov 2010 at 6:19
I did make a change to address this. For a long time Encog has resolved
classes simply from a very long text file, that had lines like:
org.encog.engine.network.activation.ActivationSigmoid
From this text file I am able to look for the last part of the line, delimited
by the final period. And then use the rest of the line to resolve the line.
There were two problems with this. First, I had to update the text file(that
is included in the Encog JAR) each time a class is added or removed. Second,
if Encog attempted to persist a user class, it did not work. Because the user
class was not in the text file/
A user contributed the class loader, it read the JAR and dynamically built the
class list. This seemed good, as it solved both of the previously mentioned
two problems.
But I was getting reports of Encog not finding the activation function. I
reimplemented the classpath text file, with the module loader as a "fall back".
So, if you are using an Encog standard activation function, then Encog SHOULD
find it in the class file, without the need to use the module loader. However,
if the class is not in Encog's built in class list, then the module loader is
used.
I will take a look.
Original comment by heatonre...@gmail.com
on 11 Nov 2010 at 1:09
Original comment by heatonre...@gmail.com
on 18 Nov 2010 at 2:52
Original issue reported on code.google.com by
androw95...@gmail.com
on 5 Nov 2010 at 4:37