D
Divya Mali
Hi,
log4j-1.2.8 introduced an interface change from its previous version that
forces code to be modified (obviously). We have a situation where we will be
shipping a jar file that uses log4j-1.2.8 and our customers, who will be
using classes in our jar, may still be using the previous version of log4j.
Depending on the classpath, either our call to log4j-1.2.8 would fail or our
customers call to old log4j would fail. I was wondering if there was a way
to get around this problem. Would it possible to specify the classpath that
our jar should be using at runtime using a java method (so that the
classpath is not piucked from the environment variable CLASSPATH)?
Thanks,
Ganesh
log4j-1.2.8 introduced an interface change from its previous version that
forces code to be modified (obviously). We have a situation where we will be
shipping a jar file that uses log4j-1.2.8 and our customers, who will be
using classes in our jar, may still be using the previous version of log4j.
Depending on the classpath, either our call to log4j-1.2.8 would fail or our
customers call to old log4j would fail. I was wondering if there was a way
to get around this problem. Would it possible to specify the classpath that
our jar should be using at runtime using a java method (so that the
classpath is not piucked from the environment variable CLASSPATH)?
Thanks,
Ganesh