When we declare persistence units in Seam's components.xml, there's almost always a <persistence:entity-manager-factory> and a <persistence:managed-persistence-context>. Those two elements can have a scope attribute. What's the default scope of those two components? It's not stated in the xsd.
From documentation
<persistence:managed-persistence-context name="bookingDatabase"
auto-create="true"
persistence-unit-jndi-name="java:/EntityManagerFactories/bookingData"/>
This configuration creates a conversation-scoped Seam component named bookingDatabase
and according to api of EntityManagerFactory this component is in application scope
#Scope(value=APPLICATION)
#BypassInterceptors
#Startup
Related
I have a spring-mvc application that is using java configuration, not xml. There are #Configuration annotations sprinkled through several files. In particular, there is a #PropertySources annotation in one file in a class that implements WebMvcConfigurerAdapter. There are two classes which contain an #Autowired Environment variable. One of these classes is itself a #Configuration class, and I would like it to have access to the fully-loaded Environment at the time it runs.
This isn't happening. When this code executes, the Environment is still null. I've tried reordering the #ComponentScan packages, tried moving the #PropertySources annotation, and nothing has helped me load the property sources in time.
I want this to happen first, before any other configuration.
What must I do to make it so?
UPDATE: After trying many things, including the Order annotation, I find the problem seems to be not so much that the #PropertySources are being loaded too late as that a class I have that is derived from org.springframework.security.web.context.AbstractSecurityWebApplicationInitializer is being loaded too soon. Nothing in my code even references this class but Spring is somehow deciding that this, above all other classes, must be initialized first. No amount of messing around with #Order seems to change this. This in spite of the javadocs, which indicate that the behavior I want is the default:
Caveats
Subclasses of AbstractDispatcherServletInitializer will register their
filters before any other Filter. This means that you will typically
want to ensure subclasses of AbstractDispatcherServletInitializer are
invoked first. This can be done by ensuring the Order or Ordered of
AbstractDispatcherServletInitializer are sooner than subclasses of
AbstractSecurityWebApplicationInitializer.
You can use ContextInitializer, catch the moment when Boot prepared its environment and "inject" your property source programmatically as you want.
If you have a ConfigurableApplicationContext then it provides a ConfigurableEnvironment, which contains the propertySources as a list. If you want your PropertySource to rule all above the others than add it as first. If you want to place it to a special position then you can add it before an other, identified by its "name".
public class ConfigInitializer implements ApplicationContextInitializer<ConfigurableApplicationContext> {
#Override
public void initialize(ConfigurableApplicationContext ctx) {
// rule over all the others:
ctx.getEnvironment().getPropertySources().
addFirst(new ResourcePropertySource("file:/etc/conf/your_custom.properties"));
// rule over application.properties but not argument or systemproperties etc
ctx.getEnvironment().getPropertySources().
addBefore("applicationConfig: [classpath:/application.properties]",
new ResourcePropertySource("classpath:your_custom.properties"));
// names can be discovered by placing a breakpoint somewhere here and watch
// ctx.getEnvironment().getPropertySources().propertySourceList members,
// each has a name ...
}
}
You can bring into play this class by:
registering it in the application.properties :
context.initializer.classes=a.b.c.ConfigInitializer
or from application start :
new SpringApplicationBuilder(YourApplication.class).
initializers(new ConfigInitializer()).
run(args);
By the way this is a proper way to inject more of your custom properties, like properties coming from a database or a different host etc...
Not that I am an expert in Java config but maybe:
Spring 4 utilizes this feature in its #PropertySource annotation. To
remind you, #PropertySource annotation provides a mechanism for adding
a source of name/value property pairs to Spring's Environment and it
is used in conjunction with #Configuration classes.
Taken from: http://blog.codeleak.pl/2013/11/how-to-propertysource-annotations-in.html
Are you using #PropertySource or #PropertySources?
Have You tried 'order' property for spring bean initialisation?
I am using simpleInjector 2.8.0.0 I would like to construct just one instance of a dbContext during a lifetime scope.
(My dependency chain has 2 dependencies on IDatabaseContext/DbContext)
I have a scope decorator which implements the lifetime scope (The scope decorator is being injected into a SignalRHub):
using (ServiceHost.Container.BeginLifetimeScope())
{
var commandHandler = ServiceHost.Container.GetInstance<ICommandHandler<TCommand>>();
//constructs 2 DbContexts.
commandHandler.Handle(command);
}
I have a lifetime scope registration for the IDatabaseContext:
container.RegisterLifetimeScope<IDatabaseContext, DatabaseContext>();
However, I can see (from a Guid) that I am creating 2 instances of the IDatabaseContext/DbContext within the scope.
Are you sure this is the same scope? Either you are nesting scopes, or you what you see is two actual request being handled. In the debugger, you might be able to view request information, for instance by inspecting the HttpContext.Current.Request.Url property.
We're using Moq and I was wondering what the current role of virtual methods were in it-- in the post below dated 2008 it's clear you had to mark your methods as virtual in order for Moq to work (or inherit from an interface.)
Moq discussion
However, is this still the case in .Net 4.5, that you're required to use virutal methods in the class you want to mock? And does this also hold true when you create a wrapper class around a static method-- the wrapper class either inherits from an interface or the method in question needs to be marked virtual?
This hasn't changed in .NET 4 or 4.5. As the link you provided explains, Moq uses Castle Windsor Dynamic Proxy to generate a type derived from the type you wish to mock. Therefore, the standard rules of inheritance apply. The derived type generated by Moq can only intercept calls to methods that any normal derived class can override.
How can i access a variable or change the state of an element(like tabNavigator) from one mxml to another mxml in FLEX 4.6??
Each separate MXML file should be viewed as a class, since that is what they are.
In the theory of encapsulation; two classes should not directly access / change each others variables or state. They should use an API provided by the developer of the MXML Class.
If MXML 1 is the parent of MXML 2; then MXML1 can pass data to MXML2 by setting public properties or calling public methods.
MXML2 can pass data to MXML1 by dispatching events.
If MXML1 and MXML2 are not in a parent child relationship; (AKA Both children of the same component as one example) they they should not communicate with each other directly. They should dispatch events which the mutual parent should handle and use to set values or execute methods on it's own children.
From an encapsulation standpoint, that is how it should be done using the built in facilities of ActionScript / Flex.
What a lot of people do as part of building applications is to make use of dependency injection. That was values that are "global to the application" can be shared among multiple components. Another approach to doing this is to use a Singleton. A third approach might be to make use of static values on a class; which can be accessed without accessing an instance of a class.
Is it possible to make unity try all defined constructors starting with the one with most arguments down to the least specific one (the default constructor)?
Edit
What I mean:
foreach (var constructor in concrete.GetConstructorsOrderByParameterCount())
{
if(CanFulfilDependencies(constructor))
{
UseConstructor(constructor);
break;
}
}
I don't want Unity to only try the constructor with most parameters. I want it to continue trying until it finds a suitable constructor. If Unity doesn't provide this behavior by default, is it possible to create an extension or something to be able to do this?
Edit 2
I got a class with two constructors:
public class MyConcrete : ISomeInterface
{
public MyConcrete (IDepend1 dep, IDepend2 dep2)
{}
public MyConcrete(IDepend1 dep)
{}
}
The class exists in a library which is used by multiple projects. In this project I want to use second constructor. But Unity stops since it can't fulfill the dependencies by the first constructor. And I do not want to change the class since the first constructor is used by DI in other projects.
Hence the need for Unity to try resolving all constructors.
Unity will choose the constructor with the most parameters unless you explicitly tag a constructor with the [InjectionConstructor] attribute which would then define the constructor for Unity to use.
When you state a suitable constructor; that is somewhat contingent on the environment. If for instance you always want to guarantee that a certain constructor is used when making use of Unity use the attribute mentioned previously, otherwise explicitly call the constructor you want to use.
What would be the point of Unity "trying" all constructors? It's purpose is to provide an instance of a type in a decoupled manner. Why would it iterate through the constructors if any constructor will create an instance of the type?
EDIT:
You could allow the constructor with the most params to be used within the project that does not have a reference to that type within its container by making use of a child container. This will not force the use of the constructor with a single param but it will allow the constructor with 2 params to work across the projects now.
You could also switch to using the single constructor across the board and force the other interface in via another form of DI (Property Injection), not Constructor Injection...therefore the base is applicable across the projects which would make more sense.