I have worked in webapi 2 and resolved all the dependencies using unity.
All the dependencies in the application were placed in unity.config file and dependencies will be resolved with below piece of code.
using Microsoft.Practices.Unity;
using Microsoft.Practices.Unity.Configuration;
var section = (UnityConfigurationSection)ConfigurationManager.GetSection("unity");
container = new UnityContainer().LoadConfiguration(section);
Now i have similar requirement to be implemented using Azure V2 functions.
I know it can be implemented with default DI microsoft provides or any others dependency resolver like Autofac.
builder.Services.AddTransient<IEmployee, EmployeeProvider.Employee>();
However, My specific requirement is how the dependency can be resolved in azure V2 functions by placing dependencies in json or config files rather than normal way of resolving 'Services.AddTransient();'.
Any help is appreciated.
Yes, You can have whatever myFile.config.json as you want. All you need to do is just inject it from your Startup class.
var config = new ConfigurationBuilder()
..SetBasePath(Environment.CurrentDirectory)
.AddJsonFile("app.settings.json", optional: true, reloadOnChange: true)
.AddEnvironmentVariables()
.Build();
To access the values from the file you can use the IConfiguration class.
public MyService(IConfiguration configuration){
var emailConfig = configuration.GetSection("Email");
var userName = emailConfig["Username"];
}
Note : The .AddEnvironmentVariables() will deploy it to the portal's app settings automatically!
Related
Context:
Projen is an awesome tool to generate and manage (JSII-built) AWS CDK projects.
Background:
Previously I have managed CDK dependencies with RenovateBot's group:aws-cdkMonorepo preset. This will result in RenovateBot creating a single Github Pull Request for AWS CDK depedency updates.
Question:
With Projen, one controls the CDK version in .projenrc.js:
const { AwsCdkConstructLibrary } = require('projen');
const project = new AwsCdkConstructLibrary({
authorName: "Example",
authorAddress: "contact#example.com",
cdkVersion: "1.64.0",
name: "#example/project",
repository: "https://github.com/example/project.git",
});
project.synth();
So how can one manage that cdkVersion value with tooling such as DependaBot or RenovateBot?
Since keeping one's CDK constructs up-to-date with current CDK version is critial and with multiple CDK constructs doing it by hand will be painful.
The central version management depends on your requirement. If you are using a centralized construct library it is a must-have.
For managing the dependencies in centrally in a single configuration, you need to add the following snippet in the .projenrc.js
cdkDependecies:[
'#aws-cdk/core'
]
Now, whenever you run projen the cdk app would be managed centrally and use the latest version.
I just installed Grails 3.3.0 and I'd like to configure some custom repositories in the ${HOME}/user/.grails/settings.groovy file.
This is what I've done so far (Real URLs have been replaced for <someUrl1|2>):
grails {
profiles {
repositories {
repo1 {
url = "<someUrl1>"
snapshotsEnabled = true
}
repo2 {
url = "<someUrl2>"
snapshotsEnabled = true
}
}
}
}
Now, when I execute grails command on bash (Ubutu 16.04) it always tries to resolve the dependencies from the first repository (<someUrl1>)
Java: jdk8u141
Should this configuration be done like I did?
If not, How could I configure this file in order to use more than one repo for grails?
If having connectivity issues (or whatsoever), the first attempt to connect to the first repository fails, Does Grails tray to access the other ones declared?
Should this configuration be done like I did?
Yes, according to the documentation
Does Grails tray to access the other ones declared?
Yes, the list of repositories are passed into the constructor of this class.
https://github.com/grails/grails-core/blob/master/grails-shell/src/main/groovy/org/grails/cli/profile/repository/MavenProfileRepository.groovy#L48
This seems like a simple question to me:
I have a project where I automatically generate a Spring-WS WSDL, something like this:
<sws:dynamic-wsdl id="service"
portTypeName="Service"
locationUri="/Service/"
targetNamespace="http://location.com/Service/schemas/Mos">
<sws:xsd location="classpath:/META-INF/Service.xsd"/>
</sws:dynamic-wsdl>
Is there a way, on application context startup, to output the generated address of the wsdl, including context, location, etc? This would be handy if our integration tests start to fail, we can see if the location of the WSDL has changed.
As far as I know, you can find the WSDL at http://yourHost/yourServletContext/beanId.wsdl. In your case, beanId is 'service'.
Check out 3.7. Publishing the WSDL in the Spring-WS documentation for more information about this subject.
If you plan to expose your XSD's as well, the beanId.xsd (or, in my case the method name in the #Configuration class) format will be used. For instance:
private ClassPathResource exampleXsdResource = new ClassPathResource("example.xsd");
#Bean public SimpleXsdSchema example() {
return new SimpleXsdSchema(exampleXsdResource);
}
This exposes an XSD at http://yourHost/yourServletContext/example.xsd.
I have an interface like this:
#Remote
public interface ClientDataAccessRemote
And the EJB implements it:
#Stateless
public class ClientDataAccess implements ClientDataAccessRemote
And in the remote client I can access the EJB with this:
#EJB
private static ClientDataAccessRemote clientDataAccess;
This is everything I did and it works. The client and the EJB reside on the same server. Would it still work if they were separated? And how would the container find the EJB with that interface? I implemented this with Netbeans and I didnĀ“t have to specify any locations or anything like that. How does this work?
Unfortunatelly #EJB annotation works for local (single JVM) injections only. For separate hosts you need to fallback to plain JNDI lookup.
AFAIK there are some proprietary non-portable solutions to perform remote dependency injections, like for WebLogic server (here), but I wouldn't go that way.
JNDI lookup works but is overly complicated and quite ugly:
you need to know server vendor and add its client libraries to your app's dependencies,
you pollute application with:
cryptic vendor-specific URI formats
vendor-specific naming service port numer (often defaults to 1099, but who knows for sure...)
vendor-specific jndi-name pattern
Here is example lookup for bean hosted on remote JBoss 4.x instance:
Properties properties = new Properties();
properties.put(Context.INITIAL_CONTEXT_FACTORY,
"org.jnp.interfaces.NamingContextFactory");
properties.put(Context.URL_PKG_PREFIXES,
"org.jboss.naming:org.jnp.interfaces");
properties.setProperty(Context.PROVIDER_URL, "localhost:1099");
InitialContext context = null;
ClientDataAccessRemote cl = null;
try {
context = new InitialContext(properties);
cl = (ClientDataAccessRemote) context.lookup("ClientDataAccess/remote");
} catch (NamingException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
Given your EJB is part of EAR you need to prefix name of EJBean with name of EAR:
cl = (ClientDataAccessRemote) context.lookup("MyEAR/ClientDataAccess/remote");
Above example is JBoss specific, I'm not even sure if it will work with JBoss 5.x series without modifications.
Apparently EJB 3.1 specification brings some unification to jndi naming, but I haven't got pleasure to work with it yet.
If this example scared you a little, maybe a better solution would be exposing your EJB as web services (SOAP or REST style).
It brings problems of it's own, but is portable at least.
I'm trying to develop a stand-alone client app that uses web services in a Glassfish container (Metro). About all I have to work from is a wsdl for the wervices I'm trying to use. The wsdl is rife with all kinds of 'wsp:Policy' tags. Looks like IssuedToken, Trust13, ecryption are all utilized.
So I generated some code from netbeans and JAX-WS. Everything went well, but when trying to run the client I get:
'WST0029:STS location could not be obtained from either IssuedToken or from client configuration for accessing the service http://localhost:8080/ ....'
That's when it occured to me that I know nothing about WSS. It doesn't look like any code was generated to deal with security. So, I'll have to go from scratch.
So where to start? Books? Tutorials?
TIA
Metro applies the policy in runtime from either the WSDL or the wsit-client.xml config file. That's why no code is generated related to policies. According to this post it is not possible at the moment to do programatically.
This tutorial explains pretty well some of the things you can do with WSS, and though everything do probably not apply in this case it's still a good read.
The simplest way I've found of generating a client with WSS support is by using the wsimport script from Metro:
cd metro/bin/
mkdir src target
./wsimport.sh -s src -d target -extension -Xendorsed -verbose YourService.wsdl
Then install Metro into your application server (copy the libs to the correct places or run the ant script):
ant -f metro-on-glassfish.xml
Then put your local WSDL file in your classpath (e.g. your resource folder), so Metro can get it at runtime to apply the policies from your generated YourService class:
private final static URL YOURSERVICE_WSDL_LOCATION;
// This is enough, you don't need the wsdlLocation attribute
// on the #WebServiceClient annotation if you have this.
static {
YOURSERVICE_WSDL_LOCATION =
CustomerService.class.getClassLoader().getResource("YourService.wsdl");
}
public YourService() {
super(YOURSERVICE_WSDL_LOCATION,
new QName("http://tempuri.org/", "YourService"));
}
And if you want WS-Addressing you might need to add the feature manually to your binding method (Metro has never generated it for me, so I always have to add it myself).
#WebEndpoint(name = "WSHttpBinding_IYourService")
public IYourService getWSHttpBindingIYourService() {
WebServiceFeature wsAddressing = new AddressingFeature(true);
IYourService service =
super.getPort(new QName("http://xmlns.example.com/services/Your",
"WSHttpBinding_IYourService"), IYourService.class,
wsAddressing);
return service;
}