I have following configuration:
The EAR which contains different applications
Some component which has its own states
The request is how I am accessing the component from different applications, in the way that this component will keep his state (the state should be the same for all the applications).
Related
When a local client gets a reference to a LocalBean, does the container provide a direct reference to bean instance? If not, what is provided?
Pointers to specs and authentic sources would be highly appreciated.
The spec does not prescribe that explicitly as I see, but injected references to EJBs are normally interface-based proxies. That's necessary for providing container services, like transaction management and timeout control, picking an instance from the pool in case of SLSB, calling user interceptors if any, etc.
While the spec only tells something rather neutral:
The container is responsible for making the business interfaces and/or
home interfaces of its deployed enterprise beans available to the
client through dependency injection and/or through lookup in the JNDI
namespace.
You can easily check that BTW, for example with debugger.
We are using ejb 2.1 to expose as a webservice using apache axis2.I have read in codebranch website that both are serverside components where in ejb can be run in more than one server unlike servlets..but I didn't get clear picture of difference.
Let me quote this old (but good) comparison.
Enterprise JavaBeans are components meant to encapsulate business logic. They do not handle presentation and have a precise set of restrictions they must obey. An EJB may not manage threads, access files with the java.io package, have a GUI, accept socket connections, or load native libraries. These restrictions are imposed because EJBs execute inside an EJB container, roughly analogous to the way servlets execute in a servlet container. Where servlets can be used to perform many arbitrary tasks, including the generation of HTML pages, EJBs are used almost entirely as business objects. A session bean represents a client for a session or transaction and an entity bean represents a persistent business object that is usually stored in a database. Unlike servlets, a single session bean may exist per client. A single servlet may serve many clients. A session bean usually mediates client access to entity beans, shielding the client from the details of managing state.
I got exact answer Both are server side entities.EJB is designed by wrapping RMI API's.EJB is a service at Enterprise level.Main advantage that EJB can be a webservice which can deployed anywhere in the world.EJB is servicelayer enity which can even used by servlets.
We can have plain java in the service layer but differance that EJB has is it(EJB) can be alone deployed in any server unlike plain-java service layer.
Can anyone shade some light on the difference between ApplicationScope(JSF) and Singleton(Spring MVC). I have a application written in jsf in which one of the class uses application scope. And while converting to spring I used Singleton scope which I believe slightly equivalent to Application scope. But want to dig in deep to know what actually varies between both in areas such as performance etc.
Both are similar in the sense that, once started they will live on until the application ends (or the class is garbage collected, which you not happen in a typical Java EE application until you undeploy).
Both are shared instances and you should make sure that they are thread safe.
From Java EE 7 Tutorial
#ApplicationScoped Shared state across all users' interactions with a web application.
From Spring Documentation:
Spring's concept of a singleton bean differs from the Singleton pattern as defined in the Gang of Four (GoF) patterns book. The GoF Singleton hard-codes the scope of an object such that one and only one instance of a particular class is created per ClassLoader. The scope of the Spring singleton is best described as per container and per bean. This means that if you define one bean for a particular class in a single Spring container, then the Spring container creates one and only one instance of the class defined by that bean definition.
So unless you are, for example, using a back end singleton bean to serve multiple web applications (say in a EAR project with multiple web projects - in this case, the Singleton Bean may outlive the Application bean if you stop / undeploy the web-application but not the EAR) or destroy your Spring application context with your web application still running (in this case your Application Bean may outlive your Singleton Bean) both life cycles are very similar.
Anyway, I think that mixing Spring, JSF and DI xml / annotations is not a good idea. This article goes in detail about how to integrate the three (also, how to make it in a way that you can work with only one of the technology for the annotations).
So, #Named #ApplicationScoped + make sure that you get concurrency right = profit! :)
I am currently designing an application in Symfony2 and had a question around when services are instantiated. Basically, are all services instantiated when the container is configured in the application load cycle or at the point when the service is requested from the container?
I understand you can flag services to be lazy loaded through the proxy manager but I just wanted to know what happens by default.
To add some context, I want to create a factory method that returns different services and am unsure whether to define the services in the service config and fetch them from the container when requested or simply instantiate them in the factory itself.
If Symfony loads all the services when the container is loaded then that's a lot of excessive overheard for what I'm trying to do. Also I'd rather not define concrete classes in the factory method.
Thanks for your help.
I have 1 Site (MySite.com) / 1 Web Service (WebService.MySite.Com) and one Common Library (LibCommon)
The common Library Contains a Model e.g. UserModel = LibCommon.UserModel
The web service has a method 'Void CheckUser(LibCommon.UserModel model)'
However when I add the 'WebService' reference to 'MySite.com' the method changes so that it looks like 'Void CheckUser(WebService.MySite.Com.UserModel model)'
So I think fair enough I can just cast one object to the other as they are identical however .NET Says I cannot do this?
Is there a work around for this?
Cheers,
Note this is for WCF, and not ASMX web services:
You can't directly cast the original data class to the proxied class generated by the WCF service reference wizard. However, you can reuse the original data class in the client:
Add the library reference containing the transfer objects (i.e. LibCommon) as a reference to both the Service (WebService) and the Client (Mysite.com). When adding the service reference on the client, choose the advanced tab and then select Reuse types in referenced assemblies. This will then reuse the common data transfer classes, instead of duplicating the types with proxies.
Note however that by eliminating the proxied data class, you are introducing direct coupling between client and server - you should do this only if you have control over both client and server w.r.t. version control issues etc (e.g. able to deploy new versions of both client and server simultaneously)
As an aside, it is also possible to eliminate the shared service interface as well, by moving the server side Service contract interface into a separate, common assembly and then using a technique such as this or this.