I'm investigating the pros and cons of switching from Struts 2 to Spring MVC 3. I've gone the route of building test projects using annotation based controllers, but I'm struggling with how to set up my connection to my repository object. In XML it'd be this:
<bean name="/viewfood.htm"
class="hellospringmvc.controller.ViewFoodController"
p:foodRepository-ref="foodRepository"
p:viewName="viewfood" />
with the reference to the repository in the properties. How do I translate this into an annotation?
In the bean above you are referencing the foodRepository bean from the controller . To manage this with annotation ,
Use component scan to autodetect the #Repository , #Service annotation - It dosen't matter much if you use either of them but #Repository makes sense .
Mark your DAO class object with #Repository . See here for the reference
The beans are then autodetected and you will have a bean with the first letter of class name lower cased . or you can specify your own bean name using #Repository("foodRepository")
Related
Is there a way to create an IDbContext interface for DI (using AutoFac)?
i am using asp.net mvc 5 & EF 6.
and i would like to create an Interface for Dependency Injection.
There is some way to do it?
Currently i am register my Context class and it will work fine
builder.RegisterType<CustomContext>().SingleInstance().InstancePerLifeTimeScope();
DbContext's should be short-lived. A common pattern for working with EF Contexts is the Unit of Work pattern. There are a few out there for EF that can help manage the scope of a DbContext. At worst for ASP.Net you would want the DbContext lifetime set to the Request, no longer.
Option 1: (Recommended) Register a unit of work implementation (Such as Medhime's DbContextScope) and let that manage the DbContext scope. These follow the Interface/Concrete definitions to work well with DI.
Option 2: Register a DbContextFactory and use that to provide DbContexts. I.e.
using (var context = ContextFactory.Create())
{
// ....
}
Where ContextFactory is a defined DbContextFactory class implementing an IDbContextFactory interface.
Option 3: Register the DbContext itself as a PerRequest lifetime scope.
If your goal is to inject DbContexts to facilitate testing, I would highly recommend adopting a Repository pattern (Not a Generic Repository pattern I.e. Repository<TEntity>) and utilizing either Option 1 or Option 2. The advantage of a repository is that it serves as a boundary for the unit tests. Your "code under test" can then be served a Mocked repository class which in turn returns stubbed entities or IEnumerable<TEntity>/IQueryable<TEntity>. Mocking DbContexts and their DbSets is honestly a PITA. Repository methods can be tested if & as desired using integration-style tests talking to a real database.
I specified a String resource in an EJB with the #Resource annotation. The EJB is packaged within an EJB module. The ejb.jar has an ejb-jar.xml which specifies a default value for the String resource. The ejb.jar is packaged in an ear archive together with a web module.
When the ear is deployed to WebSphere, the Environment entries for EJB modules section shows three EJB entries:
The String resource I mapped for the ejb module;
The String resource I mapped for the ejb module, only this time it is called EJB_fully_qualified_name/resource_name;
The same fully qualified name of the resource but now mapped for the web module.
Unless I provide a default value for all the variants above the resource is not injected. If I add an ejb-jar.xml to the web module, WebSphere displays four entries (one simple name and one fully qualified name of the resource per module). Is this a WebSphere quirk or am I doing something wrong? I am using WebSphere 8.5.5.3 in a cluster environment.
Here is the bean:
#Singleton
#Startup
public class ConfigSingleton {
#Resource
private String serviceLookup;
}
Here is the ejb-jar.xml:
<ejb-jar>
<enterprise-beans>
<session>
<ejb-name>ConfigSingleton</ejb-name>
<env-entry>
<env-entry-name>serviceLookup</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>value</env-entry-value>
</env-entry>
</session>
</enterprise-beans>
</ejb-jar>
You have defined 2 completely different resources; either may be looked up.
Per the Java EE specifications, when you don't use the 'name' attribute of the #Resource annotation a default name is provided for you, which is the fully qualified class name where the annotation exists followed by the JavaBeans property name (which is basically either the name of the field, or the name of the method with 'set' removed and the next character in lowercase). The javadoc for the #Resource annotation is a little misleading as it just says the default is the field name; but does not clarify exactly what the field name is; it is in fact the class name followed by the field name, much like you would see if you printed out the java.lang.reflect.Field that would represent it.
When combining annotations and XML, the XML overrides the annotation only when the 'name' matches. In the sample provided, the names do not match, so you actually have 2 different resources.
If you want your <env-entry> in XML to override the #Resource annotation, so that you can inject a value, then you either need to change your annotation to look like this:
#Resource(name="serviceLookup")
Or change the <env-entry-name> to the fully qualified class name / serviceLookup.
Also, when the EJB module is included in a WAR modules things get a bit more complicated. Not the 'name' aspect, but where you can provide the value. In addition to providing a value in ejb-jar.xml, WebSphere also allows you to provide a value in ibm-ejb-jar-bnd.xml. However, when the EJB modules is in a WAR, then it may also be provided in ibm-web-bnd.xml... since all of the resources for all of the EJBs are visible in the java:comp/env name space for the entire WAR module. So, in the sample, you are getting two different names because of the defaults, and what appears to be two additional copies which are really just provided in case you want to override the values in ibm-web-bnd.xml.
I think what you're seeing here is the different JNDI namespaces:
https://docs.oracle.com/cd/E19798-01/821-1841/girgn/index.html
The resource value can be accessed from within the EJB module using the original name, but if it needs to be accessed from another module within the same application, it should give a JNDI path qualified by the module name, to ensure uniqueness (and traceability), and so on for other applications, and the global namespace.
I have the same EJB module with a bean inside an EAR that is server side and an EAR that is the client side.
Can I have this situation?
Because I'm getting this error http://justpaste.it/gfs3
without understand how to fix it.
You have answer in the stack trace:
The short-form default binding 'com.demo.view.RitornaPersonaRemote'
is ambiguous because multiple beans implement the interface :
[RitornaPersonaSenzaClientEAR#RitornaPersonaSenzaClient.jar#RitornaPersona,
RitornaPersonaWebSenzaClientEAR#RitornaPersonaSenzaClient.jar#RitornaPersona].
Provide an interface specific binding or use the long-form default binding on lookup.]
If you are asking whether you may have same EJB jar in multiple project - the answer is yes you can. However during deployment you have to use long-form JNDI, provide different JNDI name for beans in other module or disable short names. You cannot register two beans under same name.
Long name would be in the form RitornaPersonaSenzaClientEAR#RitornaPersonaSenzaClient.jar#com.demo.view.RitornaPersonaRemote
See detailed info here - EJB 3.0 and EJB 3.1 application bindings overview
UPDATE
To disable short names perform the following steps:
Go to Application servers > server1 > Process definition > Java Virtual Machine > Custom properties
Define new custom property com.ibm.websphere.ejbcontainer.disableShortDefaultBindings with value * to disable short bindings for all apps or AppName1|AppName2 to just disable short bindings in selected apps.
Example default bindings are shown in SystemOut.log:
The binding location is: ejblocal:JPADepEar/JPADepEJB.jar/TableTester#ejb.TableTester
The binding location is: ejblocal:ejb.TableTester
The binding location is: java:global/JPADepEar/JPADepEJB/TableTester!ejb.TableTester
And with disableShortDefaultBindings property set there is no short form:
The binding location is: ejblocal:JPADepEar/JPADepEJB.jar/TableTester#ejb.TableTester
The binding location is: java:global/JPADepEar/JPADepEJB/TableTester!ejb.TableTester
There is a bug in the documentation and the correct property is com.ibm.websphere.ejbcontainer.disableShortDefaultBindings not com.ibm.websphere.ejbcontainer.disableShortFormBinding
In my case:- i did install abc.ear and xyz.ear both ear was independent do dependency with each other.
I was calling abc.ear using client-lookup but that was giving me
com.ibm.websphere.naming.CannotInstantiateObjectException: Exception occurred while the JNDI NamingManager was processing a javax.naming.Reference object.
[Root exception is com.ibm.websphere.ejbcontainer.AmbiguousEJBReferenceException: The short-form default binding
'com.ejb.abc' is ambiguous because multiple beans implement the interface :
[xyz-ear#rabc-ejb-1.0.jar#abcInrerfaceImpl, rabc-ear#rabc-ejb-1.0.jar
abcInrerfaceImpl]. Provide an interface specific binding or use the long-form default binding on lookup.]
my Solution was:-
i removed the abc.jar that was inside another application(xyz.ear)
C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\wstemp\92668751\workspace\cells\mypc00Node01Cell\applications\xyz-ear.ear
'
Then solution client-lookup works fine.
To avoid this in future this is better practice to create separate node on your IBM-WAS server and install both application on different node.
So both application component will not mess up.
I am attempting to read the content of a file in Alfresco. I have seen examples that use
ContentService. Unforunately, when I try to use the example code, the ContentService
is not available.
I have added ContentService as a managed property of my managed bean in faces-config.xml
<managed-property>
<property-name>contentService</property-name>
<value>#{ContentService}</value>
</managed-property>
In my java code, I am using
ApplicationContext ctx = ApplicationContextHelper.getApplicationContext();
final ServiceRegistry serviceRegistry = (ServiceRegistry) ctx.getBean(ServiceRegistry.SERVICE_REGISTRY);
// contentService is an instance variable.
this.contentService = serviceRegistry.getContentService();
I am getting this Exception:
javax.faces.el.EvaluationException: Exception while invoking expression #{DeployAssetQADialog.start}
caused by:
javax.faces.el.PropertyNotFoundException: Bean: com.XXXXXXXXXX.CCCCCCCC.DeployAssetDialog, property: contentService
Can anyone tell me if there is something that I am missing? Thanks
PropertyNotFoundException sounds like your managed bean is missing a setter method.
How to expose spring managed beans to jsf may depend on the spring and/or jsf version you are using. Have a look at Spring beans injected into JSF Managed Beans for an example.
Finally, Make sure your Alfresco spring context is initialized before jsf kicks in.
Many issues in code
1) For each services which are injected you need to add getter setter method for them.
If you add getter setter for contentservice you can get rid of your error.
2) Other thing is you are trying to get conentservice though service registry in that case you need to inject service registry and add getter setter for that. Otherwise get contentservice instance directly as it is injected though faces-config and provided you have added getter setter for it you can directly use that instance of contentservice.
Is there a way to access the configuration parameters in config.yml from the model layer? From the controller I can use $this->container->getParameter('xyz'). But how can it be done from a class in the Model layer?
In symfony2 Entities are designed as POPOs, meaning that they shouldn't really have access to anything outside of their scope.
If you need some config option in one of your entities, consider passing it as a parameter from the controller like so:
$entityName->methodName($param1, $this->container->getParameter('xyz'));
This could (will) break DIC pattern, but you could use a singleton class to "globalize" what you need.
To feed your globals, use bootmethod from Bundle class (where you can access DIC stuff hence configuration).
Or more simple, add a static field to your Entity.
Quick & dirty solution, don't abuse it ;-)
You can use Dependency Injection and add your model to your services.yml file, and like every other service you make you can provide other services as constructor parameters. The only downside is you call $derp = $this->get("your_service_name"); instead of $derp = new Derp();.
For example:
# src/Derp/LolBundle/Resources/config/services.yml
services:
derp:
class: \Derp\LolBundle\Entity\Message
arguments: [#service_container]
#service_container is a service found using php app/console container:debug. It will function identically to $this->container in your controllers and it is provided to the constructor of your class. See here for more information on how to use service containers.
As previously mentioned they are POPOs (Plain Old PHP Objects) and the previous method of dependency injection is poor choice simply because you will have to remember to provide your model entity with the same object every time you use it (which is a hassle) and Symfony2 services are a way to mitigate that pain.