I have a project where the client (a Java stateful bean) will make a REST call to another bean (let's call it RequestBean) to perform a function and return a Response. Part of that function requires a call to a vendor's SOAP service. That service is a little slow to initialize in Java, but once initialized, then of course the calls are much faster.
I've been advised that I can move that service initialization to a separate ApplicationScoped bean (let's call it ServiceBean) so that it can initialize once and that's it. My question is about RequestBean. Should that be stateless, and how would it access the service that was initialized in ServiceBean?
I think I've figured this out. I added #Startup #Singleton to the service bean, as well as a method to pass the service reference to the request bean. This works. I'm not sure if this is really the proper way to do this, but for my immediate testing, it's sufficient.
Related
I have a rest endpoint which would start the scheduler of loading a XML to memory. Whenever I hit that rest endpoint, it loads the XML in memory and would return the XML after its ready (would take 10 - 15 seconds). When the same endpoint is accessed again, it would return the cached XML. Everything works fine but for now I have to manually hit the endpoint for the scheduler to start. Is there a way to hit the endpoint automatically via a simple code in startup? Or is there any other solution for this?
Normally, a component in the Nucleus is instantiated at first access, not at system start-up.
The way to have anything done at start-up in ATG is to create your component, and then to add its nucleus path to the list of initial services in the /Initial component (or from one of the many other Initial components changed off of it)
The component should be globally scoped. Because /Initial is instantiated at start-up, the services it references will also be instantiated as dependencies.
If your component is a POJO, then the no argument constructor will be invoked on component start-up, then the setX method will be called for each property with a value defined in its properties file.
If your component is extended from Generic Service, then additionally, beforeSet and afterSet methods will be called, before and after the set methods are invoked, if they exist, and finally doStartUp will be called.
This is all part of the fundamental lifecycle of components that the Nucleus manages.
This gives you a number of hooks with which to invoke your custom code.
Now, in your question, you ask how to call a REST endpoint at start-up. However, I believe what you actually want to ask is how to ensure that a particular piece of code gets executed at system start-up. A REST endpoint is how you are triggering it today, manually, from outside the Nucleus. But that does not mean that it must call a REST end point if it is to be automatically called at start up.
The easiest way to achieve what you want is
define a class that extends GenericService
override the doStartUp method
put the code you want to execute in this method, or invoke the code on another component from here
define a globally scoped component for the class
Add the component to the initialServices property of the Initial component
Restart the server and check that your code is being called at start-up. Put some debug statements in, and switch debug logging on in your layer.
Note, you may actually also want to think about whether you really need to invoke your code at system start-up. Anything in initial services adds to the start time of the server. Depending on your requirements, it may be better to do it on first access of your application service rather than at server start-up.
I am very new to Autofac dependency injection and I got these questions related to my project. I have gone through many articles but I am not getting a clear picture on some of the questions I have. Mine is a service application on .Net REST API. I am doing instance registration in App_Start module as shown below.
private static IContainer RegisterServices(ContainerBuilder builder)
{
builder.RegisterApiControllers(Assembly.GetExecutingAssembly());
builder.RegisterType<DCLMessengerContext>()
.As<DbContext>()
.ExternallyOwned()
.InstancePerLifetimeScope();
builder.RegisterType<DbFactory>()
.As<IDbFactory>()
.ExternallyOwned()
.InstancePerLifetimeScope();
builder.RegisterType<UnitOfWork>()
.As<IUnitOfWork>()
.InstancePerLifetimeScope();
builder.RegisterGeneric(typeof(EntityBaseRepository<>))
.As(typeof(IEntityBaseRepository<>))
.InstancePerLifetimeScope();
builder.RegisterType<PersonServiceClient>()
.As<IPerfService>()
.InstancePerLifetimeScope();
builder.RegisterType<PagingServiceContractClient>()
.As<PagingServiceContract>()
.InstancePerLifetimeScope();
builder.RegisterType<MessageService>()
.As<IMessageService>()
.InstancePerLifetimeScope();
Container = builder.Build();
return Container;
}
My service layer is "MessageService" and there I am performing all the DB and other integration operations and getting the instances through constructor injection. These are the questions I have around this implementation.
I am using InstancePerLifeTimeScope for all my registrations. Is this is the right approach? After the life cycle of each controller request (http request), will these instances will be automatically disposed?
Do we need to manually implement any Dispose operation on any of these instances? ( I don’t have any unmanaged objects in my code)
From the service method, I need to create a fire&forget thread as well using Task.Run(). What is the best approach to supply instances to this fire&forget thread? If I use InstancePerLifeTimeScope, I can see that new thread also getting the same instances that available through the service class so I am just confused when these instances will be disposed?
When you resolve the instance per lifetime scope component, you get a
single instance per nested scope
So if you are using them in controllers. You will have one object for per request and they will be disposed. But if you resolve them in a singleton object they wil live with this object.
Is this is the right approach?
It depends what you need. If you need singleton object, it's not. If you just want to use this service in request scope use instanceperrequest it's better.
Autofac automatically calls dispose for IDisposable objects. If you
need dispose method, implement it. It's not related with autofac.
If you use another thread resolve objects in this thread. Otherwise when request disposed your objects will be disposed and your thread will be fail. Check this.
Say I am using a service A which is imported in another service B. While B is running normally(ofcourse A is Active), what will happen is service A is uninstalled while service B is still running?
Service A -> Service B
What will be the different scenarios in case I am using ServiceReference, ServiceTracker & DS?
When a service is unpublished in OSGi, an event is sent to all bundles currently using that service to tell them that they should stop using it.
If you are using DS, your unbind method will be called. When it is called, you should make best efforts to stop using the service as soon as possible. But ultimately OSGi is a cooperative system, it cannot force you to release the service. However if you don't then you can cause problems, for example the service publisher will not be fully garbage-collected. You end up sabotaging the dynamics of the OSGi platform, possibly creating memory leaks and so on.
If you are using ServiceTracker then the removedService method will be called, and you need to respond in the same way. But didn't I tell you in the other question not to use ServiceTracker?? ;-)
If you are using ServiceReference then you need to explicitly register a ServiceListener in order to receive these events. This is why you really really shouldn't use this low-level API until you have gained a lot more experience (and once you do have that experience, you won't want to use it anyway!).
First of all: one of the advantages of OSGi is that the behaviour of the framework and standard services are clearly specified. Those specifications can be downloaded from the OSGi Alliance web site, or, if you don't like reading PDFs, ordered for print. The question you are asking is perfectly answered in those specifications.
That said, in summary: when a service is unregistered:
The ServiceReference object remains as it is. However, a call to ServiceReference.getService() will return null. Note that when using ServiceReferences you should release any references to the actual service object as retrieved via getService(), this normally requires some kind of tracking of the service.
For ServiceTracker ServiceTracker.remove is called. This normally results in a call to removedService() on the ServiceTracker or the defined ServiceTrackerCustomizer.
For DS, the defined unbind method for the referenced service is called (if specified). Furthermore, if the cardinality for the used service indicates that the service is mandatory, the using service may also be unregistered, even possibly deactivated or a new instance activated depending on the availability of alternative services and the policy defined for the service.
I am new to GWT and am able to work around with GWT RPC but have problem in understanding how the control flow takes place internally. How it gets translated to AJAX?
Can we use new() instead of GWT.create(someService.class) to make an RPC call?
Why does Google not just use Async version instead of creating 2 interfaces?
What happens internally when we use
TaskService Async = GWT.create(TaskService.class);
I have read that it chooses the browser specific hashname.js file but am not understanding the complete control flow. Also How is the Callback Object used.
Can someone explain the control flow by pointing out the essentials?
UPDATE : #Thomas Broyer, Everything I understood... Just confirming that in case GWT.create() there is a .rpc file in the client side which helps in the deferred(late/runtime) binding. Is that correct?
GWT.create() will in this case call a GWT generator; it'll generate a class implementing the Async interface (and that's why you only have to declare an interface and you never implement it yourself).
See RPC Plumbing Diagram.
Using a generator (or selecting a specific implementation, but in the case of GWT-RPC, a generator is used) is called deferred binding.
So, no, you cannot use new.
As to why there are 2 interfaces, this is so that GWT can check that your server-side code (synchronous) is consistent with your client-side code (async). The reason you call GWT.create on the synchronous interface and it returns an implementation of the async one is legacy. I bet they wouldn't do it that way, were they to re-implement GWT-RPC from scratch.
The generated class will be responsible of serializing the call (method name and arguments) and make an AJAX request (using a RequestBuilder); and then deserialize the response (either of the type declared, or an exception)
Because calls are asynchronous, the callback is used to, well, call your code back when the server responds, after deserialization takes place (so either calling onSuccess with the decoded object, or onFailure with the decoded exception).
See Getting Used to Asynchronous Calls
is it possible to get notified inside the bean (mdb in this case) that its deployment procedure has just finished?
I would say that when setMessageDrivenContext is called, that's your bean deployed - you know that the container has a context and has assigned it to your MDB.
The problem with your design is that MDBs are passive components, they're not supposed to do anything until a message gets delivered to them.
I'm pretty sure once the constructor is complete it's considered to be "deployed."
Okay, to address the downvote, from the Jave EE API documentation, you have two lifecycle methods available to you:
void ejbRemove()
A container invokes this method before it ends the life of the message-driven object.
void setMessageDrivenContext(MessageDrivenContext ctx)
Set the associated message-driven context.
Unfortunately, that's it.