I am using 3 webservices in my project and it was running correctly. But in these days it is crashing when creating it's client and I haven't changed anything.
How can I solve it, could you help me, please?
It's saying your service config file is not found. Are you referencing it correctly from the app.config?
It looks like you're using WPF or Silverlight so find your app.config file.
You cannot apply configSource= to since that is a config section group - not a simple config section, and the configSource attribute is only available on simple configuration sections.
You should however absolutely be able to apply the configSource attribute to any of the nodes inside - I do this all the time, in production systems - and it just works; for behaviors, services, clients, bindings, etc; each in a separate .config file.
.ClientConfig is also a bad extension. All configuration files should have .config extension.
In the worst case scenario that you can't configure the external config source for the settings, move them back tot he app.config file of the application!
Related
I'm very new to databases and I'm trying to find out what the best practise for what I'm trying to achieve.
I have the one repository which is a Django backend with a postgresql database attached. I'm working with this on my main pc but recently I've had to work on my laptop. My laptop has another postgresql database running on 5432, so I've had to change some of that info to be on port 54324. These changes I don't want pushed to the repository, but I would still like to track the settings.py file in the repository. So far I've just created a branch for each pc to maintain the separate settings, but I'm sure this is not a great way to do it. I've heard about setting up environment files, but I'm unsure about if this is the 'right way' to do it either.
I'm a little confused with the best way I can do this, hopefully I'm making sense. Any help would be appreciated greatly.
Thanks,
Darren
This is normally solved with a properties file that is ignored. What you keep is a sample file (that has a different name) and that you do track and change accordingly on git. Your python scripts read the properties file and everybody should be happy.
Besides eftshift0's answer, consider having a committed config.defaults.py file that set default configuration values that may be overridden by a per-site config.local.py file. If the default configuration works for you, you don't need to create the per-site config. If not, create the per-site config. Never commit (and do .gitignore) the per-site config.
The names of the configuration files might be located outside the repository proper, but the overall idea still applies. The distributed (and committed) configuration file is a sample and/or default and actual site settings are kept in some other file that is never committed.
If you already have a single config.py or settings.py, you can establish this configuration pattern by adding site.py (use whatever name you want for this per-site setting file) as an ignored file. Read the new file, if it exists, such that the site settings override the default settings from the existing tracked file, and you're good to go.
I followed this camunda tutorial on Youtube and created a simple, small, first project. I managed to generate a war file.
In the tutorial they are using the enterprise version and I'm using the community version. My camunda is running on a tomcat server instead of a wildfly like in the tutorial.
I found out that I've to put my .war file into the webapps folder.
After copying it I refreshed the processes tab in the Camunda Cockpit and I saw that it created a folder with the same name as my war file but the Process Definition is not listed. I still only see the default Invoice Receipt Process...
Any help on why my process definition is not showing up in the list is appreciated. I'm completely new to camunda and as there is no error message or so I've no idea about where to start looking.
If there's no error message, you've probably either:
Placed your process definition in the wrong location (it needs to be in the project's src/main/resources directory) or
Neglected to mark your process model/process definition as executable. (To mark it as executable, make sure you've checked that box on the "General" tab for the process definition itself.)
It's possible that you may have also mistakenly set something up incorrectly in your project. I'd recommend using one of the "Get Started" tutorials to ensure you have everything setup properly. This one is probably the best one for your situation: https://docs.camunda.org/get-started/spring/project-setup/.
I would like to restrict one of my web services running under Tomcat 7. That is, I have one instance of Tomcat 7 hosting several web services. Some of these web services need not be restricted to a specific IP-address, so this restriction must be per-app.
Initial search on the subject suggests that it is possible to do so via a Remote Address Filter by adding something like:
<Context>
<Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="10\.180\.156\.159"/>
<Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1"/>
</Context>
in "some" XML file that is part of the deployed WAR file.
My problem is that "some XML file" is very confusingly named. My understanding is that it is supposed to be the context XML but the context XML can be named anything... (it looks like the <param-name>contextConfigLocation</param-name> in <context-param> in web.xml that determines the name)
So, in the various sources providing the tips to implement this restriction, the references were to:
META-INF/context.xml (my WAR has no META-INF subfolder, only WEB-INF)
WEB-INF/web.xml (I do have that file, but it is the file that points to the context XML, not the context XML itself)
conf\Catalina\localhost\manager.xml (looks tomcat-wide, not per-app)
My context XML is named beans.xml and is located in the WEB-INF/classes subfolder...
Can someone please clarify this issue?
I am going to experiment now with my own guess, but an authoritative answer would be nice.
If you want to include the Valve for just one application, you would do this in a <Context/> block. As you have discovered, there are a few different places where you can configure the Context. Explanations of them below.
META-INF/context.xml (my WAR has no META-INF subfolder, only WEB-INF)
This is the only place where you can configure the context from your application. If you want to do this, simply create a META-INF folder in the root of your project (same location as WEB-INF directory). Inside META-INF, create a context.xml file and put your application specific configuration in there.
When your application is deployed to Tomcat, this context file will (if Tomcat is configured to do so, see copyXML), copy the file into $CATALINA_BASE/conf/Catalina/localhost/<app-name>.xml and add include it in the configuration.
conf\Catalina\localhost\manager.xml (looks tomcat-wide, not per-app)
The actual format of this should be $CATALINA_BASE/conf/[enginename]/[hostname]/[appname].xml where [enginename] defaults to 'Catalina' and [hostname] defaults to 'localhost'. Thus for the "manager" application, the path you listed would be correct. If your application is called "myapp" then you'd use conf/Catalina/localhost/myapp.xml or for the ROOT app, you'd use conf/Catalina/localhost/ROOT.xml.
This is the second location where you can put application specific Context configuration, and would be the one that I would recommend.
There are two other places where you can put Context configuration, one is conf/context.xml and the other is conf/server.xml. Do not use conf/context.xml in this case because it would apply server-wide (i.e. across all of your apps). The conf/server.xml is possible to use, but I would suggest against it. Use of conf/server.xml for configuration like this is discouraged mainly because it's inflexible and requires a complete server restart when you make changes.
In reference to...
WEB-INF/web.xml (I do have that file, but it is the file that points to the context XML, not the context XML itself)
This cannot be used for Context configuration, but you can use it to configure Servlet Filters and Tomcat ships with a RemoteAddressFilter, which does the same thing as the RemoteAddressValve.
It's generally recommended to use a Filter, when available, versus a Valve.
My context XML is named beans.xml and is located in the WEB-INF/classes subfolder...
You cannot use a custom name or location for your Context configuration. It needs to match one of the names and locations specified by Tomcat. For more details on this, see here.
We have a project setup here which uses Maven profiles quite extensively. We're using Spring, and although we mostly have an annotation-based configuration there are a few XML configuration files needed.
These Spring XML config files are pulled in with various different profiles, and in the actual web application they're all put in WEB-INF/spring and loaded up with classpath:spring/spring-*.xml. This works fine.
The problem is unit testing: I want to test a variety of different profiles, and Spring seems to have an issue with a wildcard specification like that when the files are spread over several directories.
The easiest solution I think would just be to specify each config file in the #ContextConfiguration test annotation, but unfortunately if one is missing Spring throws an exception, and there doesn't seem to be a way of turning this off.
The other thing I thought was potentially dumping all spring config files into one folder before running the tests, but that seems a bit of a kludge.
I was just wondering if anyone else had any experience of this problem and any workarounds.
It seems that the Spring guys have thought of this already.
You can use the syntax:
classpath*:spring/spring-*.xml
Which seems to work properly.
Trying out BizTalk with a web service call
The request/response is working fine on my own dev machine, but not on test ...
Exported the MSI over to my deployment test server (a seperate virtual), created the application with the Application/Import and then tested it to find it not working ...
checking the event log and it's shows an XLANG error with "Could not load file or assembly"
checked the GAC and the BizTalk assembly isn't there ...
so manually added it and that seemed to do the trick
Does the added web service reference mean the assembly has to be GAC'ed as part of a deployment?
And just to get me confused, tried deploying to the real test server, import the MSI, manual copy of the DLL to the GAC ... and it fails with the XLANG error in eventlog :-(
any idea what's going on here ?
What adapter are you using? I am assuming the SOAP adapter. If so you can look at your bindings. Look here near figure 6:
http://msdn.microsoft.com/en-us/magazine/cc163464.aspx
-Bryan
Just importing the MSI will by default not include the dll.You need to run it as well (like from windows explorer or the option given after install). This will physically move the file. This behavior is quite useful when scaling out. I don't think it have anything to do with the web reference specifically.