Hi,
We are developing a plugin for the vsphere web client. Currently all the log messages from the plugin are written to vsphere_client_virgo.log through the java service (using apache logger, similar to the sample code).
Is there a way to configure from the plugin that the log messages would be written to a custom log file on the VC (instead of the vsphere_client_virgo.log)?
Thanks,
Ella
Hi Ella,
vSphere Web Client loggers are configured here:
.../server/configuration/serviceability.xml
You can try to programmatically configure a new log4j appender:
FileAppender fa = new FileAppender(); // You can also use ch.qos.logback.core.rolling.RollingFileAppender
fa.setName("FileLogger");
fa.setFile("mylog.log");
fa.setLayout(new PatternLayout("%d{yyyy-MM-dd'T'HH:mm:ss.SSSXXX}] [%-5level] %msg %ex%n")); // set your patterns here
fa.setThreshold(Level.DEBUG);
fa.setAppend(true);
fa.activateOptions();
Logger.getRootLogger().addAppender(fa)
I haven't tried this. Please let me know if this works for you.
Seems to work. Thanks Peter!
Something important about the PatternLayout(String) constructor.
A partner has reported the following error:
java.lang.NoSuchMethodError: org.apache.log4j.PatternLayout.<init>(Ljava/lang/String;)
Virgo server is using slf4j and not log4j. PatternLayout belongs to org.apace.log4j package that one needs to declare as import in his MANIFEST.MF file.
However "org.apache.log4j" package is exported by three jars (you can look them up in the server/repository):
1. com.springsource.org.apache.log4j-1.2.15.jar
Export-Package: org.apache.log4j;version="1.2.15"
This jar contains PatternLayout and it contains the required constructor .
2. log4j-over-slf4j-1.6.1.jar
Export-Package: org.apache.log4j;version=1.2.16
Does not contain PatternLayout at all
3. org.slf4j.log4j_1.7.2.v20130115-1340.jar
Export-Package: org.apache.log4j;version="1.2.17";
Contains PatternLayou class, but it doesn't have such constructor.
So in your MANIFEST.MF you should specify version 1.2.15. The tricky part here is that version="1.2.15" means minimal version, i.e. 1.2.16 and 1.2.17 will also satisfy the dependency.
Check here for more details on versioning: 2.2 OSGi Concepts
You can do the following:
Import-Package: org.apache.log4j;version="[1.2.15,1.2.15]"
This is one option and it will work.
However this will bind you to the exact version of the com.springsource.org.apache.log4j-1.2.15.jar. And it in future version of virgo this jar is changed, your plugin will stop working.
I've read in some blog that the same effect can be achieved by using Require-Bundle without specifying the version:
Require-Bundle: com.springsource.org.apache.log4j
I haven't tried it though
Hm, but aren't the plugins self contained? (i.e. potentially rely on different dependencies?) I am using an external-to-virgo log4j jar.
I have the following set up in the manifest:
Export-Package: com.moo.foo,
com.moo.bar,
org.apache.log4j
Bundle-ClassPath: .,
httpcore-4.3.jar,
httpclient-4.3.1.jar,
log4j-1.2.17.jar,
etc....
And then in the log4j.properties file:
log4j.rootLogger=ALL, file
log4j.appender.file=org.apache.log4j.RollingFileAppender
log4j.appender.file.File=mooBar.log
log4j.appender.file.MaxFileSize=10MB
log4j.appender.file.MaxBackupIndex=10
log4j.appender.file.layout=org.apache.log4j.PatternLayout
log4j.appender.file.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss.SSS} %-5p %c{1}:%L - %m%n
log4j.appender.file.append=true
log4j.logger.anotherLogger=ALL, anotherAppender
log4j.additivity.anotherLogger=false
log4j.appender.anotherAppender=org.apache.log4j.RollingFileAppender
log4j.appender.anotherAppender.File=mooFoo.log
log4j.appender.anotherAppender.MaxFileSize=10MB
log4j.appender.anotherAppender.MaxBackupIndex=10
log4j.appender.anotherAppender.layout=org.apache.log4j.PatternLayout
log4j.appender.anotherAppender.layout.ConversionPattern=%m%n
log4j.appender.anotherAppender.append=true
If you package your dependencies inside your bundle, then you are fine
What bothers me in your manifest is that you export or.apache.log4j:
Export-Package: com.moo.foo,
com.moo.bar,
org.apache.log4j
When you export it like that you make it visible to all other bundles in the OSGi environment. What makes it worse is that you don't specify a version when exporting it.
And as I've explained in my previous comments we already have 3 bundles that export that package. And if a bundle imports org.apache.log4j, then it becomes a mess.
Please try removing this package from Export-Package.
If it doesn't work, you can use Private-Package. Check this out: java - What does the private-package manifest header do? - Stack Overflow
Thanks for the feedback Peter, I appreciate it! I ended up moving log4j out of the export package and into the Require-Bundle and that seems to work.
Hi again Peter,
So we got the logging working on vSphere 5.5+. This seems to work fine because the vSphere user is "root" in group "root".
However, in vSphere 6.0, the web client user is "vsphere-client" in the group "users". Since most of the file structure is owned by root:root, the vsphere-client user does not have permissions to write to any folder. This includes the /etc/vmware-vpx/docRoot/diagnostics directory, which should be *the* place at least to which plugins should be able to write logs, no?
hi Ryan,
You're right. Starting with 6.0 the file system is under tighter security. Your plugin can write its logs in /storage/log/vmware/vsphere-client
The SDK 6.0 Release Notes mention the fact that plugins can use the env variable VMWARE_DATA_DIR for this storage directory location (on linux and windows)
We were hoping to be able to write or move logs to /etc/vmware-vpx/docRoot/diagnostics so as to be able to pick them up via http -- is writing to docRoot no longer a possibility as well? I thought that the docRoot/diagnostics was a place for putting this sort of thing -- should that be writable as well?
I guess the vCenter team closed all file access except in /storage.
Hi,
Please suggest how this can be done for vsphere 6.5 above.
What are the changes that needs to be done for custom log.
For vSphere Client 6.5 the virgo log can be configured in the same place that Peter mentioned at the top of this thread: /server/configuration/serviceability.xml