Sorry about that, it was more of a question about the classloading than to
fix an issue. Anyway here is the error message...
D:\Annotation\felix>java -cp org.apache.log4j.jar;bin\felix.jar;.\conf
org.apache.felix.main.Main
Welcome to Felix.
=================
-> install file:org.apache.log4j.jar
Bundle ID: 4
-> install file:log4jdemo.jar
Bundle ID: 5
-> start 5
log4j:ERROR A "org.apache.log4j.ConsoleAppender" object is not assignable
to a "org.apache.log4j.Appender" variable.
log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
log4j:ERROR [4.0] whereas object of type
log4j:ERROR "org.apache.log4j.ConsoleAppender" was loaded by
[sun.misc.launcher$appclassloa...@11b86e7].
log4j:ERROR Could not instantiate appender named "default".
log4j:WARN No appenders could be found for logger (log4jdemo.Activator).
log4j:WARN Please initialize the log4j system properly.
-> ps
START LEVEL 1
ID State Level Name
[ 0] [Active ] [ 0] System Bundle (1.4.1)
[ 1] [Active ] [ 1] Apache Felix Shell Service (1.0.2)
[ 2] [Active ] [ 1] Apache Felix Shell TUI (1.0.2)
[ 3] [Active ] [ 1] Apache Felix Bundle Repository (1.2.1)
[ 4] [Resolved ] [ 1] Apache Jakarta log4j Plug-in
(1.2.13.v200706111418)
[ 5] [Active ] [ 1] Log4JDemo Plug-in (1.0.0)
->
The log4j.xml file is in the .\conf folder, that's why that is in the
classpath.
The Log4JDemo consists of...
package log4jdemo;
import org.apache.log4j.Logger;
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;
public class Activator implements BundleActivator {
public void start(BundleContext context) throws Exception {
Logger logger = Logger.getLogger(Activator.class);
logger.info("Info starting");
logger.warn("Warning starting");
logger.error("Error starting");
}
public void stop(BundleContext context) throws Exception {
Logger logger = Logger.getLogger(Activator.class);
logger.info("Info stopping");
logger.warn("Warning stopping");
logger.error("Error stopping");
}
}
Removing the log4j jar from the classpath removes the errors.
Thanks for all of your help..
-Pete
On Fri, 06 Mar 2009 00:25:24 -0800, Stuart McCulloch <[email protected]>
wrote:
2009/3/6 Stevens Gestin <[email protected]>
Hi,
without an hint on your error it's a bit difficult to help.
yes, seeing the actual error or exception trace would be useful
as well as your settings for system packages / bootdelegation
also note that while OSGi attempts to isolate bundles, because
it runs on top of the JVM it is still possible for code to get access
to other classloaders by techniques such as reflection, or simply
by calling getClassLoader() on a passed in type or instance.
complete isolation is only possible with low-level runtime support
Stevens
On Fri, Mar 6, 2009 at 7:07 AM, Pete Haidinyak <[email protected]> wrote:
> I am embedding Felix in an application I am porting and was playing
around
> with logging with Log4j. I wanted both the application and Felix to
use
> Log4j. I put the Log4j jar in the classpath and loaded a Log4j
bundle. I
was
> getting an error doing this.
> My question is I thought OSGi isolated the bundles from each other
and
the
> classpath unless you tell it other wise. Why would having log4j on the
> classpath cause a bundle to have problems?
>
> THanks
>
> -Pete
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
--
Le respect commence par celui de l'environnement
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
