is it possible to override the deferred binding configuration of a inherit module?
Here is a example:
In the module, I want to use, a deferred binding is declared as follows moduleA.gwt.xml:
<replace-with class="A1Impl">
<when-type-is class="A"/>
</replace-with>
<replace-with class="A2Impl">
<when-type-is class="A"/>
<when-property-is name="p" value="1"/>
</replace-with>
The declaration says: Use A1Impl class as default and A2Impl class, if property p has the value 1.
Now, in my app I want to use that module and want P to be 1 (because this controls the above shown, but also a lot of other deferred binding configurations) mymodule.gwt.xml:
<inherits name='moduleA'/>
<set-property name="p" value="1" />
But additionally I want to override the deferred binding configuration of the inherit module to use my own implementation of A. I tried something like this in my module, but it didn't work:
<replace-with class="B1Impl">
<when-type-is class="A"/>
<when-property-is name="p" value="1"/>
</replace-with>
It should say something like this: Do not use A2Impl (declared in inherit module) if property p has the value 1 but use my own implementation B1Impl instead.
Is this possible?
Thanks in advance for any help.
In short, yes, you can redefine any rebind rules that have already been set. Simply inherit the module you are changing, then make your changes after that rebind rule.
<inherits name="package.to.ModuleA" />
<set-property name="p" value="1" />
With the code above, p is always 1, so setting specific rules about what p will be is a little bit silly. Unless p is ever able to be something other than 1, you really don't even need the when-property-is rule.
Your replace-with looks correct as long as it is listed after your inherits statements. For this reason, I always encourage developers to list all inherits rules first, and then go on to any replace-with and generate-with or set-property rules.
For more detail than that, you'll need to post something a little more concrete.
Related
I have a N-layer solution that works correctly in my dev environment. Apparently it works also on production environment, but sometime the execution fails. I do not understand why. I just know that nothing changes on database, no usefull error is visible and no log is written.
My supposition is a concurrency problem. I think that something fails when I try to do more than one select once the entity framework context has been initialized.
Here how my solution is structured
In the facade I inject the entity framework context. Here the configuration on my web.config of the service interface:
<containers>
<container>
<types>
<register type="it.MC.IContext.IDataContext, IContext"
mapTo="it.MC.EntityFrameworkContext.PublicAreaContext, EntityFrameworkContext">
<lifetime type="singleton" />
</register>
<register type="it.MC.IFacade.IPublicAreaFacade, IFacade"
mapTo="it.MC.Facade.PublicAreaFacade, Facade">
<interceptor type="TransparentProxyInterceptor" />
<lifetime type="singleton" />
<constructor>
<param name="context" type="it.MC.IContext.IDataContext, IContext"/>
</constructor>
</register>
</types>
</container>
</containers>
As you can see, my context and the facade are singleton. I think both are really wrong. I think that both Facade that the entity Framewrk context should be instanciate per request. I think this will solve the problem of the concurrency too.
Can anyone help me to correct my code please?
Thank you
I know that your question is:
Can anyone help me to correct my code please?
I read it like this:
Can anyone help me change this code so that IContext and IFacade will be re-initialized per request.
With that said... Yes, I also doubt that you want to keep your IContext as a singleton.
Why you shouldn't use singleton DataContexts in Entity Framework
Here's how you can change the lifetimemanager to PerRequestLifetimeManager, if that's what you want. Note that you probably need the Unity.Mvc NuGet-package.
<containers>
<container>
<types>
<register type="it.MC.IContext.IDataContext, IContext"
mapTo="it.MC.EntityFrameworkContext.PublicAreaContext, EntityFrameworkContext">
<lifetime type="Microsoft.Practices.Unity.PerRequestLifetimeManager, Microsoft.Practices.Unity.Mvc" />
</register>
<register type="it.MC.IFacade.IPublicAreaFacade, IFacade"
mapTo="it.MC.Facade.PublicAreaFacade, Facade">
<interceptor type="TransparentProxyInterceptor" />
<lifetime type="Microsoft.Practices.Unity.PerRequestLifetimeManager, Microsoft.Practices.Unity.Mvc" />
<constructor>
<param name="context" type="it.MC.IContext.IDataContext, IContext"/>
</constructor>
</register>
</types>
</container>
</containers>
Before moving to production I suggest you read this post about the PerRequestLifetimeManager.
Its purpose would be to only instantiate one instance per request,
which could (for example) prevent redundant operations and lookups
during the course of a single request.
The danger is if someone assumes that the object created is a good
place to store state during the request. The idea of dependency
injection is that a class receives a dependency (commonly an
interface) and doesn't "know" anything about it at all except that it
implements that interface.
Also, think about the Facade you got, and how it will work if it's re-initated every request. Does it perform any heavy operations at initialization? You might want to think about the lifetimemanager for that one.
UPDATE
Since you're using WebAPI you should be able to use HierarchicalLifetimeManager instead.
http://www.asp.net/web-api/overview/advanced/dependency-injection
The dependency resolver attached to the HttpConfiguration object has
global scope. When Web API creates a controller, it calls BeginScope.
This method returns an IDependencyScope that represents a child scope.
Web API then calls GetService on the child scope to create the
controller. When request is complete, Web API calls Dispose on the
child scope. Use the Dispose method to dispose of the controller’s
dependencies.
http://www.devtrends.co.uk/blog/introducing-the-unity.webapi-nuget-package
If you are registering any components that implement IDisposable such
as Entity Framework's DbContext, you will want to make sure that these
components get disposed of at the end of the request. This is achieved
by registering these components with a HierarchicalLifetimeManager.
I am using latest mybatis release i.e. mybatis3.2.2.
I have converted our old application which was on EJB CMP to mybatis, in which the newly converted mybatis code performance was much worse than the old code with EJB CMP.
Configuration settings of mybatis is as follows:
<settings>
<setting name="cacheEnabled" value="false"/>
<setting name="aggressiveLazyLoading" value="false" />
<setting name="lazyLoadingEnabled" value="true" />
<setting name="jdbcTypeForNull" value="VARCHAR"/>
<setting name="defaultExecutorType" value="REUSE"/>
<setting name="defaultStatementTimeout" value="25000"/>
</settings>
While analyzing performance issue through YJP profiler, I realized that HashTable.put(<mybatis returned Pojo>, <value>) methods were taking most of the time and seemed to be the only bottoleneck.
In the HashTable.put() method, we are putting Pojo returned from mybatis as a key. In which call, in turn it calls hashCode of that pojo, and from YJP I could see that in 'hashCode' method, it is calling 'org.apache.ibatis.executor.loader.CglibProxyFactory$EnhancedResultObjectProxyImpl.intercept(Object, Method, Object[], MethodProxy)', which is actually seemed like calling jdbc drivers and loading this pojo properties and those are the once taking all of the time.
Can any please help and guide me as in why mybatis is trying to load the Pojo while putting into HashTable in its hashCode method? Also, how can we improve its performance if at all we can.
Also, I tried to override 'hashCode' & 'equals' methods into my Pojo and used/compared only primary key properties, but it seems to have no effect, it is still calling 'executor.loader' of ibatis and doing same thing.
Ok, I have finally found the solution.
The 'lazyLoadTriggerMethods' setting configures the methods that trigger lazy loading.
By default it triggers lazy loading for 'equals,clone,hashCode,toString' methods.
I configured this property in SqlMapConfig.xml and removed 'equals,hashCode,toString' methods from it, as:
<settings>
<!-- below both entry required to achieve on-demand lazy loading -->
<setting name="aggressiveLazyLoading" value="false" />
<setting name="lazyLoadingEnabled" value="false" />
<setting name="jdbcTypeForNull" value="VARCHAR" />
<setting name="defaultExecutorType" value="REUSE"/>
<setting name="defaultStatementTimeout" value="25000"/>
<setting name="lazyLoadTriggerMethods" value="clone"/>
</settings>
Note: You should only do this when you are sure that the hashCode and equals implementation does not use lazy-loaded properties or uses the accessor methods for reading lazy-loaded properties.
It dramatically increased performance.
Thanks,
Parag
I'm looking to supply my own implementation of CanvasElement class. This class is instantiated in HTMLGraphicsCanvas class in the PlayN stack.
What is the ideal way of doing this? There are 2 ways that I've tried but failed:
A) Subclassing HTMLGraphics and HTMLPlatform? --this doesn't seem to be possible.
B) The GWT module mechanism seems to require that my custom implementation of a GWT-supplied class be of the same package. So take for example this XML snippet:
<replace-with class="com.google.gwt.dom.client.DOMImplOpera">
<when-type-is class="com.google.gwt.dom.client.DOMImpl"/>
<when-property-is name="user.agent" value="opera"/>
</replace-with>
If I do something like:
<replace-with class="com.domain.example.CustomCanvasElement">
<when-type-is class="com.google.gwt.dom.client.CanvasElement"/>
<when-property-is name="user.agent" value="opera"/>
</replace-with>
...it does not seem to work because the packages are different. At least that's what I think is happening.
Any other ideas? Much appreciated.
Ok so I can answer the B) part of my own question. Although I would really appreciate an answer to my overall question about how to supply my own implementation.
So my guess wasn't entirely correct. According to this section of Deferred Binding, basically you have to first create a superclass object that Browser-specific objects will subclass. So for instance:
GenericBrowserObject is the superclass and might have common implementations of certain methods between Browser-specific objects or might be your "catch-all" implementation for all other (non-specific) Browsers.
So for instance, let's say you only want to have specific implementations for IE and Gecko-based browsers.
GeckoBrowserObject extends GenericBrowserObject
IEBrowserObject extends GenericBrowserObject
Let's say that there is a common method called setStyle in GenericBrowserObject but they have differing implementations between GeckoBrowserObject and IEBrowserObject, then you would override setStyle in each of those classes and supply their own implementations.
The class that manipulates these objects needs to instantiate GenericBrowserObject superclass in this way:
GenericBrowserObject obj = GWT.create(GenericBrowserObject.class);
obj.setStyle("whatever");
Then in your module file (something.gwt.xml), you would have something like this:
<replace-with class="com.domain.blah.GenericBrowserObject">
<when-type-is class="com.domain.blah.GenericBrowserObject"/>
</replace-with>
<replace-with class="com.domain.blah.IEBrowserObject">
<when-type-is class="com.domain.blah.GenericBrowserObject"/>
<any>
<when-property-is name="user.agent" value="ie6"/>
<when-property-is name="user.agent" value="ie8"/>
</any>
</replace-with>
<replace-with class="com.domain.blah.GeckoBrowserObject">
<when-type-is class="com.domain.blah.GenericBrowserObject"/>
<any>
<when-property-is name="user.agent" value="gecko"/>
<when-property-is name="user.agent" value="gecko1_8"/>
</any>
</replace-with>
When GWT compiles this, it will generate the correct objects based on the user agent string via GWT.create.
Lets say I have EmailService which implments IEmailService. And EmailService has constructor dependency on ILoggingService. Now given that I have several implementations of ILoggingService, can achieve something like this:
<component service="IEmailService, MyInterfaces" type="EmailService, MyLib">
<parameters>
<parameter name="loggingService" value="LoggingService, MyLib" />
</parameters>
</component>
I have looked at giving names to registered types but so far couldn't find an example of how to use them from XML configuration.
In short I want to use XML configuration to specify which concrete logger implementation gets injection.
XML configuration in Autofac is targeted more toward the 80% use case rather than being a full implementation of Autofac's flexibility in XML form. Autofac instead recommends using its module mechanism for configuration. Modules, coupled with the XML configuration, can be a very powerful way to achieve what you're looking to accomplish and still have that flexibility to switch between dependencies as needed.
First, create an Autofac module that does the registration you want:
public class EmailModule
{
protected override void Load(ContainerBuilder builder)
{
// Register a named logging service so we can locate
// this specific one later.
builder.RegisterType<LoggingService>()
.Named<ILoggingService>("emailLogger");
// Create a ResolvedParameter we can use to force resolution
// of the constructor parameter to the named logger type.
var loggingServiceParameter = new ResolvedParameter(
(pi, ctx) => pi.Name == "loggingService",
(pi, ctx) => ctx.ResolveNamed<ILoggingService>("emailLogger"));
// Add the ResolvedParameter to the type registration so it
// knows to use it when resolving.
builder.RegisterType<EmailService>()
.As<IEmailService>()
.WithParameter(loggingServiceParameter);
}
}
Notice it's a little more complex of a registration because you're requiring a very specific resolution.
Now in XML configuration, register that module:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<section
name="autofac"
type="Autofac.Configuration.SectionHandler, Autofac.Configuration"/>
</configSections>
<autofac>
<modules>
<module type="EmailModule, MyAssembly" />
</modules>
</autofac>
</configuration>
When you want to switch configurations, register a different module rather than fiddling with specific component registries.
Code disclaimer: I'm writing the syntax from memory and I'm not a compiler, so you may have to do a little tweaking... but the premise holds. Isolate the complexity in a module, then register your module.
I've got the following config <when-property-is name="isExecute" value="true" />.
Am I able to set property isExecute for module A true and for module B false?
Am I able to change property value by Java?
Does GWT.create read property condition each call or only once (cache)?
What are you trying to achieve? Replacing implementations during runtime? You can use Generator to do this.