Do I need to use locking model when use log4net from windsor logging facility and fileappender?
Or this issue is resolved by windsor itself?
Thanks.
After some research, I found out that using generated proxy class this is impossible. Pity.
Related
I am currently working on a EJB 3.1 based project running on GlassFish that uses a custom built framework to configure the functionality of any SessionBeans. Using this we can enable, disable and re-configure most of the services at run-time. Unfortunately we can't extend this to support conifguration of MDBs. I would like to set the selector a MDB is using based upon the configuration information and re-configure this if the settings change.
Unfortunately I could only come up with a SessionBean that creates MessageConsumers natively on the JMS Sessions based upon the configuration and to have the JMS messages handleb by MessageListeners, but I was told this way we would be loosing concurrency and the transaction handling of the EJB system, as we would no longer be using MDBs this way.
So is there any way to do what I'm looking for using MDBs? Someone told me there are some planned extensions in new EJB and JMS spec drafts, but I couln't find a pointer to that particular topic.
No, MDBs are configured by the Deployer at deploy-time.
Similar question answered here: Configuring MappedName annotation in Message Driven Bean dynamically
A newbie question : If I am not using Sagas or pub/sub model, do I need any persistence layer with NServiceBus?
The default persistence is RavenDB, I was wondering if I just use NSB without RavenDB or any persistence layer?
Side note:
Currently I have to run RavenDBServer.exe before I can even play around with NserviceBus, so if I do start using NServiceBus, I don't want to have a dependency on another app running in production. This could be a issue with my install.
NServiceBus only uses persistence for storing subscriptions for pub/sub and for saga state. If you aren't using those then you don't need RavenDB or any other implementation. I believe the NServiceBus.Core binary by default comes bundled with RavenDB DLLs, but it won't be needed in production in your case.
If I understand correctly, you could also use the NServiceBus.Lite profile which I believe uses in memory persistence. This is a great way to go as you are developing and trying to learn NServiceBus. However, I'm not sure you'd want to do so in production. It would be a better practice to have some persistence either in a database or file system to ensure reliability of your application in the case of errors or application restarts.
I have a .net 4.0 WCF application that uses the net.tcp binding and implements some service.
I would like to set a TCP socket option for that binding (ReuseAddress option. A related question explains why I want to do that).
If I was working with Raw Sockets I could use the Socket.SetSocketOption Method.
Is there a way to somehow extract the underlying Raw Socket from the net.tcp binding in order to change its options? Or some other way to set this option?
Amir, Thank you for your suggestion of adding ReuseAddress option. However, we need understand better what was your concrete scenario. In the related question (Changing Socket Options on WCF net.tcp binding) context, have you enable port sharing? Seems like porting sharing could result with similar symptom. Basically, we need concrete repro program and setup steps to understand better of the problem.
If anyone still runs into the problem or see the need of adding reuseAddress option, please report the bug at http://connect.microsoft.com/VisualStudio with repro program and repro steps. Thank you.
In article after article after article, any discussion of using an IOC Container (Unity, Windsor, etc.) with IIS involves the creation of a custom ServiceHostFactory and a custom ServiceHost.
The only reason I can see for that, is so that a custom service behavior, with an IInstanceProvider-related payload, can be applied to all services. So I'm trying to understand why the whole affair is not simplified by having an anonymous service configuration. Such configuration would allow a custom behavior to be applied to all services without using a custom ServiceHostFactory and custom Service Host.
That said, the only reason I can imagine a custom service host would be necessary is if the custom IInstanceProvider is recycled with each WCF instance or context instance. Certainly I would want IOC Container bindings to be established only once for each launch of my IIS ServiceHost rather than repeatedly or irregularly.
If my custom IInstanceProvider is indeed being recycled sporadically, then I could put my IOC Container into a custom service host - to insure that it will stick around as long as possible.
But again, if my custom IInstanceProvider will last as long as the in-built service host, then why not just skip the custom service host factory and custom service host?
In fact, taking this a bit further, if I were to put my IOC Container into a static member of my custom IInstanceProvider, then it wouldn't matter if the IInstanceProvider was being recycled irregularly. It comes full-circle: why do I need or want a custom ServiceHostFactory and custom ServiceHost to use an IOC Container with WCF?
Well. That's because most IoC/WCF integrations (like mine) does more than just creating your service (with it's dependencies).
Custom lifetimes / Disposal
Everything should get clean up properly when a request have ended. Your servcice and your IoC classes uses different lifetimes.
The end of a request can't be detected just with the help of an InstanceProvider.
IContractBehavior / IServiceBehavior
You can register behaviors in the container and automatically get them added to your WCF service.
Personally, i'm a fan of using a design where you don't need any ServiceHostFactory, ServiceHost, ServiceBehavior, and InstanceProvider combination and where you don't have to register the factory in your .svc file. I like my WCF service as just a really thin layer on top of a message passing architecture, and this saves you from using this WCF integration stuff. You can read more about such a design here.
Interesting question! The only reason I could think of for doing it this way is that you don't want to clutter up your app.config with items that are never going to change (i.e. the IoC container used by your WCF services). I try to restrict my use of the app.config to things that an end-user / developer might conceivably want to change without recompiling (in most cases, not much). This makes it more readable, and it is usually easier to specify configuration programmatically as there is better support for intellisense and compile-time checking within program code as opposed to configuration files.
However, this argument might not apply to the first article you linked to, because they're actually setting up their IoC container through the app.config. So it might be a double standard in this case. I've never really understood why people want to set up all their dependencies through external configuration files anyway. Storing static configuration in the app.config just seems like overkill to me in most cases.
I haven't used Apache Axis since my 1.x days so I am little rusty here. My question is this.... How do I go about using the #Autowired annotation in my Apache Axis2 service endpoint class? Is this possible? I did some google searching and have yet to find anything conclusive. I am using Apache Axis2 version 1.5.1 and Spring 3.0.3. I just want to autowire up a simple DAO into my Web Service endpoint. I wouldn't think that would be so hard. I have already configured my applicationContext.xml and tested my DAO in a simple DBunit JUnit test case so it works fine. I can also Autowire up my Spring bean in my JUnit test. In my WAR I have configured my web.xml to use the org.springframework.web.context.ContextLoaderListener. This works fine and I can see when I deploy the war that the applicationCOntext is loaded up. Now how do I wire this up so I can use #Autowired in my Apache Axis2 service endpoint class?
Thanks for any help in advance!
Kyle
Resolved my own issue. Jsst needed to have my Service Endpoint class simply extend the SpringBeanAutowiringSupport class.