I'm using Logback library (more precisely log4s -- a Scala wrapper over it) for logging in a dynamically loaded JVM class. When the class is loaded for the first time, everything is logged fine. For all subsequent loadings of that class no more logs are produced. Have someone encountered a similar problem? In documentation to Slf4j (https://www.slf4j.org/faq.html#declared_static) it is said that static loggers are IOC-friendly. Is the same problem implied here?
Related
My question is about the possibility of customizing the logging/tracing done by CAF - viz. does the C++ CAF framework allow an application linking with it to customize the logging & tracing done within CAF?
For e.g., CAF writes its logs to log file if logging is enabled during compilation. But if an application wished to integrate the logs/traces generated by CAF with its own logging mechanism(syslog etc), is there any hook provided by CAF to do that?
I went through the CAF logger class, but could not see any such mechanism - the CAF logger class is not derivable, and the set_current_logger() method takes a logger* as input, etc.
Any pointers on how to achieve the above requirement would be appreciated.
Thanks.
is there any hook provided by CAF to do that?
Currently not.
The set_current_logger function merely sets a thread-local pointer to the actor system logger. However, CAF is very modular and allowing custom logger implementations is actually quite straightforward. I've created a feature request for this on the official GitHub repository. Stay tuned.
I was looking at source from the Flask Extension Registry. I probably looked at about 6 or 7 projects and couldn't find any of them logging output.
My question is: is it OK to do so? If so, should I use app.logger or my own logger?
Yes, you should log - no, you should not use the application logger since the user will not the be able to configure your extension's logging verbosity separately from their own.
Instead, create your own logger using Python's built-in logging module. Add a NullHandler (Python 3 has one, create your own NullHandler for Python2) so that by default your library will not log anything. Add a documentation section explaining how the user can access your logger to setup handlers (and explicitly configure levels, should they so desire).
As is often the case, there is some very good advice on this subject in Python's documentation:
Configuring Logging for a Library
When developing a library which uses logging, you should take care to document how the library uses logging - for example, the names of loggers used. Some consideration also needs to be given to its logging configuration. If the using application does not use logging, and library code makes logging calls, then (as described in the previous section) events of severity WARNING and greater will be printed to sys.stderr. This is regarded as the best default behaviour.
If for some reason you don’t want these messages printed in the absence of any logging configuration, you can attach a do-nothing handler to the top-level logger for your library. This avoids the message being printed, since a handler will be always be found for the library’s events: it just doesn’t produce any output. If the library user configures logging for application use, presumably that configuration will add some handlers, and if levels are suitably configured then logging calls made in library code will send output to those handlers, as normal.
I am currently writing an application and I want to make it as extensive as possible for me -> every component should be considered as an extension except core functionality.
Basically I provide abstract class which needs to be implemented (header file) and a static library. Also I provide .py file with abstract class and example of .component file which is basically .ini file - there user should declare what's the class_name, python_class_name and etc.
So in the end user need to create DLL, python script, .ini file. Then zip into an archive with extension package. Well that's the plan.
My application is supposed to look for .package file, unzip it, get from there .component file, read it, load class from DLL by name, create object and store it in global object register inside application. Then I create c++ and python bridge (knowing what interface is implemented by python class helps a lot) which allows to invoke python methods by name. That python script should be store into zip too.
I've got basically two questions:
1. Is it possible to load DLL from `.zip` in runtime? I believe its hardly possible without creating temporary unzipped file and then deleting it.
2. Is there other to load DLL except basic approach with `windows.h` header? I use `boost` library there and there, maybe there is some way to do it?
For zipping as far as I know there no better solution then using zlib so I am planning to use that.
It is possible to load DLL from zip/memory. Actually many exe packers/virus do load the dll manually.
It is actually the same question of the first question.
What LoadLibrary does?
Mapping or loading the DLL into memory.
Relocating offsets in the DLL using the relocating table of the DLL (if present).
Resolving the dependencies of the DLL, loading other DLLs needed by this DLL and resolving the offset of the needed functions.
Calling its entrypoint (if present) with the DLL_PROCESS_ATTACH parameter.
You could write your own code to load the library manually. However, if you do not load the dll the same way as LoadLibrary does, there could be some limitations.
refer: http://www.codeproject.com/Tips/430684/Loading-Win-DLLs-manually-without-LoadLibrary
You can load .dll library from memory, at least with trivial .dll without more dependency.
What you do is to emulate what LoadLibrary do. Parse the PE executable yourself, call VirtualAlloc, setup proper page attributes, copy the payload, do relocations, and lookup the symbols.
A quick search reveal a detail yet simple tutorial here.
Note that this may also upset certain virus scanner.
I am calling some C++ code that tries to load a Java class, e.g.
JNIEnv *jenv = ...
jclass cls = jenv->FindClass("org/some/bundle/SomeClass");
Now, the problem is that this class resides in an OSGi bundle, and the code above cannot find my class.
This problem only arise when running unit tests (Tycho-surefire headless tests). Is there a simple way to force the OSGi framework to find my class from JNI? On the Java side, I suspect something like Dynamic-ImportPackage could have fixed my problem. I am unwilling to change the third party C++ library just to get it working with the test framework, so I prefer a solution on the Java test setup / configuration side, if possible.
The FindClass method of JNIEnv only searches the contents of the system ClassLoader as defined by the global application classpath. Since OSGi does not use the global classpath, it is no surprise that this doesn't work.
In general whenever loading a class, you need to specify not just the class name but also the classloader that should load it. This is an inevitable requirement of modularity. So your code needs to be able to find the bundle that you expect to contain the class, and then call its loadClass method. You can do this directly in C++ code, but it may be easier to write a Java utility method to do it and then just call that method from C++.
Well, I am not 100% sure that your case is like mine.
In my RCP I used to get the exception:
ClassNotFoundException: com.tool.packageA.IWantToLoadThisClass cannot be found by com.tool.packageB_1.0.0.qualifier
A simple solution was to:
Add com.tool.packageA to com.tool.packageB MANIFEST.MF Require-Bundle.
I though wanted to avoid that solution, because I was able to load other classes found in other packages normally com.tool.packageC, com.tool.packageD (This wasn't done by me though so I didn't know how it worked).
Searching around I came to find the other solution which I ended up using to keep things similar to the current working packages (com.tool.packageC, com.tool.packageD).
The solution was:
Using Eclipse-BuddyPolicy and Eclipse-RegisterBuddy see here for detailed info
This is how to get it to work:
Add Eclipse-BuddyPolicy: registered to com.tool.packageB MANIFEST.MF
Add Eclipse-RegisterBuddy: com.tool.packageB to com.tool.packageA MANIFEST.MF
Add Require-Bundle: com.tool.packageB to com.tool.packageA MANIFEST.MF
Now com.tool.packageA.IWantToLoadThisClass will be visible from com.tool.packageB and you will be able to find it when jenv->FindClass("com/tool/packageA/IWantToLoadThisClass");.
I hope this helps.
I have a parent SWF file that defines a Widget base class.
I then load an external SWF into the parent. The external SWF's document class derives from the Widget base class -- let's call it DerivedWidget for example.
The problem is that when I load the external SWF, I cannot cast the Loader.content (shows in debugger as having the DerivedWidget type) to the Widget type. I use the "as" operator to cast the content as a Widget in the parent SWF once the load completes, but the cast results in "null".
This behavior is not expected, because the external SWF is loaded into the parent's application domain, and the Loader's content shows up in the debugger as DerivedWidget, which I know derives from Widget, but the cast to the base Widget class is failing.
Can anyone explain this unexpected behavior and offer a solution?
[Edit: looking back at an earlier code snapshot... this was working before, but now it isn't... and the loading and casting code hasn't changed]
[Edit2: actually, it seems to be failing when debugging in the Flash IDE. When run normally, everything loads into the correct ApplicationDomain (sameDomain=true); this is obviously a huge bug]
There are some bugs in the way that DocumentClass does inheritance.
http://bugs.adobe.com/jira/browse/FP-2999 (need to log in to adobe's bug tracker)
My recommendation is to take it off the stage and export it through the library instead, it will work from there. In fact my rule of thumb is "never use document classes."
I have experienced the similar problem. The solution are two fold.
Use DerivedWidget(mc), instead of mc as DerivedWidget. There are some articles addressing this problem, you need to find it out.
make sure the class DerivedWidget is accessible in both compilation environment. If you use Module or invovle different Flash domain, be more careful.