I have log4cxx implementation in utility.dll. This dll is used by application1.dll and application2.dll
Application1 defines log file name as "c:\application1\applog.log"; Application2 defines log file name as "c:\application2\applog.log".
If I run both the applications seperately, logs are created in the corresponding files properly. If I try to run both the applications simultaneously the logs are created in latest opened application's log file.
I have opened application1 first logs are created in "application1\applog.log" file. At same time I opened Application2. Now both application's logs are appended in "application2\applog.log"
Note: Both of my applications are dlls acting like a drivers) Both are acting as a seperate application I need logs to be in different output files. Both dlls will run under same exe.
How to make the the same log4cxx implementation to log in different log files per application?
I had a similar situation where my app and dll were logging to the same file. This is just an educated guess, but try changing the name of the logger in the dlls and app.
// in application1.dll
const log4cxx::LoggerPtr logger1 log4cxx::Logger::getLogger("ABC"));
log4cxx::PropertyConfigurator::configure("./application1.config");
// in application2.dll
const log4cxx::LoggerPtr logger2 log4cxx::Logger::getLogger("ABC"));
log4cxx::PropertyConfigurator::configure("./application2.config");
Assuming you are using a canned configuration. applicagtion1.config and application2.config could be identical except for the log4j.appender.File.File= line
in application1.config
log4j.appender.File.File=logs/application1.logs
and in application2.config
log4j.appender.File.File=logs/application2.logs
Related
I'm trying to modify an application that was deployed with JNLP onto my PC. However, when I try to replace the existing application's JAR with my new jar, it fails to lookup javax.jnlp.SingleInstanceService and javax.jnlp.BasicService.
I've already signed the main JAR file with my own key pair (not the original one), but it still does not work.
The following two lines throw UnavailableServiceException (uninitialised).
BasicService lookup = (BasicService)ServiceManager.lookup("javax.jnlp.BasicService");
SingleInstanceService singleInstanceService = (SingleInstanceService)ServiceManager.lookup("javax.jnlp.SingleInstanceService");
On the unmodified JAR (which is run with java.exe -cp SomeJar.jar), no exceptions are thrown. I am certain that this is a signature issue, as even a resigned file with no other modifications still has this issue.
Is there any way I can replicate this on my modified JAR (perhaps by adding it's keystore certificate to some file)?
The problem is not in jar signing. To use JNLP API you should start your jar via jnlp file.
Syntax for running jnlp file is: javaws your_jnlp_file
Your jar should be registered in resources container inside your jnlp file, and your jar should be deployed as part of your web aplication.
You are starting your jar as standard jar.
The reason why the old jar did not result in error, most possibly because it had simply handled UnavailableServiceException.
The question is a follow up to this one: Generate Web.Debug config which could be debugged](Generate Web.Debug.config which could be debugged)
I have defined a transformation for web.debug.config. During compilation I see the following:
Transformed Web.config using C:\data\Main\WebRole\Web.Debug.config into
C:\data\Main\obj\obj\x64\Debug\WebRole.csproj\TransformWebConfig\ [...]
transformed\Web.config.
Checked Web.config in the specified location - it is correct (transformation succeeded)
But when I start the service in the azure emulator I get an alert that
Why does it happen? Looks that incorrect web.config is taken. Where should I specify the location of correct (transformed) file?
The key thing to realise with web.config Transforms (and is mentioned in the answer to your linked question) is that they are only part of the story.
When you build your sources, the transformed web.config file is built into the /obj/ folder, ready for deployment.
It is only the act of deploying your solution somewhere that puts the transformed config file into use - as noted in the docs:
When you deploy the Web application by using the selected build configuration and by using either a deployment package or one-click publish, the Web.config file is transformed according to your specifications.
How are you running the application after you build it? You need to publish or deploy it using one of the built in mechanisms that support web transforms to see those changes on your site.
If you are running the emulator against the original source files, they won't see the transformed web.config file - which is why typically the debug build doesn't have any transforms and you then turn off debugging with your Release build which is then deployed to production.
As you're trying to test this in the emulator you should be able to do the following:
In the Solution Explorer, ensure you've selected a file within the project that runs in the emulator.
From the Build menu, select "Publish [Project Name".
In the Publish Wizard, create a new "Profile" using the "Custom" publish target.
In the "Connection" pane select "File System" as the publish method, and give it a suitable target location.
In the "Settings" pane choose the appropriate configuration (in your case probably "Debug"), and set any other options that you'd like.
Then press "Publish", and the project should be built, and then deployed to the new file location.
You should then be able to start the emulator from this newly published location, which will be using your transformed web.config.
I have found this solution and it works perfectly
https://translate.google.co.il/translate?hl=en&sl=de&tl=en&u=http%3A%2F%2Fwww.sascha-dittmann.de%2Fpost%2FWebConfig-Transformation-im-Windows-Azure-Compute-Emulator.aspx&anno=2
I have an ASP.NET web application written in C# 4.0. The application references a class library that comes with its own configuration file. At runtime, the class library uses similar to the following code to load this specific configuration:
var exeConfigPath = this.GetType().Assembly.Location;
var config = ConfigurationManager.OpenExeConfiguration(exeConfigPath);
This is done because the library has to load its bundled configuration rather than the application configuration. The application configuration should not be concerned of the library's settings and should not be able to alter them.
Now, there are a few other things that need to be done for this concept to work. I have to set the library's configuration file build operation as Content in the properties window and the Copy to be Copy Always or Copy If Newer. So far so good - the file gets automatically both into the class library's bin directory, and the web applications's bin directory, and is correctly renamed from App.config to CustomLibrary.dll.config (as supposed, the library's dll is CustomLibrary.dll).
Now I am facing two issues.
1) When I publish the web application to a filesystem location (mapped in IIS), the CustomLibrary.dll.config appears back as App.config in the bin folder of the published app. OK - I will rename it in the class library project to match the expected convention - and problem solved.
2) Even when published, the IIS compiles the application again and stores it in the ASP.NET Temporary Files. There is a fancy directory structure with a folder dedicated for each assembly referenced. The folder corresponding to the CustomLibrary.dll does not contain the config file in it. Since this.GetType().Assembly.Location will return the path to the temp folder, the application fails to load the configuration and crashes as it should.
I need to preserve the pattern of having the configuration in the class library, and be able to make it work in the web application. When manually copying the .config to the temp folder, the app works, but see, I really hate manual copying to randomly-named folders.
Is there a way to either prevent IIS from using the temp folders, or to make it copy along the config files? I believe the problem I am facing is configuration-related rather than conceptual since the application works as expected when the config file is in place. I'd prefer not to mess with using hard-coded physical paths to the config file either.
Edit:
To make it clearer, I will point out what and why I want to achieve. The idea is that the library and the web project will be developed as separate products - there will be no user or application specific information in the configuration of the library, so it will not change for different use scenarios. It is also rather specific to the class library functionality rather than the end application. It makes sense for me to keep the library's configuration information bundled within it (similar to Java, where a spring context xml file, or a properties file, get bundled with the jar of the library). I'd like to avoid having to copy the configuration in each app/web config of the consumer application. There will be cases where the consumer application is developed by third parties, and I do not want to rely on them doing their configuration right for my stuff to work. Again, the only issue here is not having the config file copied to the right place.
If those are static, internal settings that nobody should see or change, wouldn't you be better off having a file with the configuration included within the class library as an embedded resource? Either that or just a static class with the settings.
That way you'd be certain that nobody alters it, which in your scenario seems to be a plus.
I have come along a way to work arround the described issue, still not a very pleasant one to my requirements.
The solution is to take advantage of the application configuration (web.config in web apps, or app.config) which is always available. I have added as settings the absolute paths to the config file for each library. So I ended up with:
<!--
THIS IS IN THE WEB.CONFIG FILE
-->
<appSettings>
<add key ="ClassLibrary_ConfigPath"
value ="{My Publish Output Folder}\ClassLibrary.dll.config"/>
</appSettings>
and the class library now uses the following code to load its configuration:
Configuration config = null;
try
{
var exeConfigPath = this.GetType().Assembly.Location;
config = ConfigurationManager.OpenExeConfiguration(exeConfigPath);
}
catch (Exception e)
{
if (!IsConfigurationNotFoundError(e))
{
// IsConfigurationNotFoundError logic skipped for brevity
var exeConfigPath =
ConfigurationManager.AppSettings["ClassLibrary_ConfigPath"];
if (exeConfigPath != null)
{
config = ConfigurationManager.OpenExeConfiguration(exeConfigPath);
}
}
else
{
throw;
}
}
While this works, I will wait for a better solution if possible. Still, I do not have to copy the entire ClassLibrary.dll.config into the web.config file, but now I must manage filesystem locations and be aware of app-setting names. What I really want is the consumer app of the ClassLibrary.dll not to deal with its configuration in any way. If it were a desktop app, I have this covered, as Visual Studio copies the ClassLibary.dll.config appropriately. I hope there is a way to make it work smoothly for web apps.
The short answer is: you can't. You have to merge both configuration sections and place all settings in the main configuration file of your application. In case of the web application it would be the web.config. Read this
I understand that the WebRole module inside my Web Role web app project runs inside WAIISHost.exe and the rest of the app runs inside W3WP.EXE. Therefore web.config settings cannot be read from the WebRole app domain.
This can be solved by creating a special "waiishost.exe.config" in the web project file and set the "Copy to Output Directory" property to "Copy Always".
That's fine. However, now, I have config settings in ServiceConfiguration AND web.config AND "waiishost.exe.config". This is only a minor but annoying issue though. The biggest problem is that when I publish my Azure project, ServiceConfiguration and web.config get automatically transformed into the production values whereas waiishost.exe.config does not get transformed, so I end up with development config going into the production environment. (the production env is not live yet, so not a major issue yet)
Can anyone think of any ideas as to how I can also have the Publish process transform waiishost.exe.config? Maybe I could run some kind of startup process which could simply copy and rename the web.config file to be waiishost.exe.config before waiishost.exe starts.
BTW, I cannot simply move config to the ServiceConfiguration file as I have whole config sections and connection strings which are used by third party components, like the ServiceBusConfiguration section.
Many thanks
Yes, there is.
A little manual, but is "one-time-setup" per project. Check out this and that blog posts I've made a while ago (even before you could have ServiceConfiguration files). These blog posts will give you a great idea on how to achieve your desire.
Background: I have a DLL I created that includes 2 c files. These c files reference a third c file which defines a user defined type (we'll call it class_pointer), which is a pointer of type class.
E.g.
typedef class pointer_class *class_pointer;
then defines the class:
typedef class pointer_class {..}
pointer_class has various variables and functions associated with it that the original 2 c files make use of through class_pointer.
I am using this DLL in an ASP.NET C# web application. I am using PInvoke to import the functions into the dll. However, when I go to call on these functions that involve the class_pointer, the website running on IIS hangs. This does not happen in the VS debugger. If I comment out said class_pointers, everything runs smoothly -- I have access to the DLL and everything.
I have tried changing the permissions on all the DLLs included in my bin directory (just to be safe) for NETWORK SERVICE to have read/execute permissions. The dll will work without the class_pointers, so I don't think it is an issue of permissions. Does anyone have any advice on what might be causing IIS to hang when these class_pointers are involved?
I finally was able to figure this out with the help of Microsoft's debugging tools.
The class_pointers were written by another developer that has since left the place I work. In the pointer_class, there was a function to get the current application path. When running on the web, this was set to the inetsrv directory in SYSWOW64 (The machine I was running on was a 64bit machine). To solve the issue, we set the application path to the website when we are running the web, rather than where the .exe application was running from (SYSWOW64/inetsrv).
Because the application path was wrong, the native dll was unable to load some files in and was putting up popup warning messages. These pop up messages were waiting for a user response and since we couldn't get one on the web, the application hanged!
Hope this helps someone else out there!