I tried to debug of beans creation and understood that it is random order. What is the order of bean creation in Weld? Is there a graph of beans?
It won't be "Random". Generally everything will be "lazy" instantiated, but when demand for a bean occurs, it will reach to the bottom of the bean dependency graph and recursively instantiate dependencies. If two nodes occur at the same depth, order of instantiation may be undefined, but most certainly won't be randomized.
Related
I'm wondering how to use CDI to build multiple independent objects trees representing the same type of data. Here is an example:
I have a Car, in which I want to inject GearShift and Engine.
I also want to inject Engine in GearShift
This Car + GearShift + Engine is my tree.
If I want to have several cars at the same time, what would be the best way to do this using CDI?
I would expect to be able to define a kind of scope or a qualifier for each tree.
But CDI scopes and qualifiers are defined statically, while the number of cars is dynamic.
As an additional requirement, I would like to inject another dependency that would be shared between cars.
For example, all cars would share the same Road for their whole lifetime (couldn't find something else that makes more sense).
Thanks in advance
I am no sure if I understand you properly, but I think you can, at least, use Session Scope, because you could create several Sessions with different Ids. For every Session you will have own Session Map.
In that way you can manage separate set of Cars Objects.
If you use Weld as CDI your implementation, you can use a BoundSessionContext which can be bound to any Map. The context is automatically attached to the map on activation, and detached when invalidate() is called.
I've been reading about the conversation scope in Java EE 6 (and therefore CDI 1.0), and how it can isolate data from different tabs in a browser, and preserve data across many requests of a particular workflow of pages. I've no issues there.
In my reading, I've read that many of its ideas came from Seam. Often I see caveats such as 'but CDI's conversationscope does not do "nested" conversations'. I'm not sure what exactly a "nested" conversation is?
I've read this good link also http://www.andygibson.net/blog/article/understanding-nested-conversations/
but I think I'm missing something fundamental.. I'm just not fully getting what a "nested" conversation is in this context. Can anyone help dumb it down for me?
From the Seam 2 documentation:
A nested conversation has its own conversation context, but can read values from the outer conversation's context. The outer conversation's context is read-only within a nested conversation, but because objects are obtained by reference, changes to the objects themselves will be reflected in the outer context.
So with nested conversations you have the chance to split a given parent conversation into several child conversations, each with both their context and access to the parent's context.
Although CDI was heavily influenced by Seam, it is so to say only a common denominator of several influences, so it does not contain everything which Seam had. The idea was, that by creating CDI extensions, such as Seam 3 was about and what now should be done by Apache Deltaspike, more features commonly used could be provided above the CDI standard.
Unfortunately, I am very disappointed with what Deltaspike provides and allthough JavaEE 6 and thus CDI is so long in existence, there is still a gap between what I was used to with my Seam 2 projects. I mean honestly, just have a look at the Deltaspike Homepage which starts with the words "Some logos ideas" which in turn ends my confidence in it...
This question already has answers here:
Backing beans (#ManagedBean) or CDI Beans (#Named)?
(5 answers)
Closed 6 years ago.
Okay, so I have a JSF backing bean that needs a reference to another (#NoneScoped) bean.
Should I #Inject it or use #ManagedProperty to obtain an instance reference from the container?
Why use one and not the other, in my mind the two approaches achieve the same thing.
#ManagedProperty and #NoneScoped comes from the JSF 2.0 spec whilst #Inject comes from the CDI spec.
If you are just working on a servlet application that doesn't make any use of any of the others JavaEE 6 features, then go for #ManagedProperty. That annotation has also an advantage against #Inject: you can use EL (expression language) with it (although there are workarounds to get that in CDI).
Both annotations/containers seem to achieve "the same thing" but in very different ways and they work with different containers. Beans managed by CDI will be available to JSF but not viceversa. If you are annotating your beans with JSF specific annotations then forget about using custom qualifiers, interceptors, producer methods, etc. I usually prefer the approach with CDI because, at the end, it is more sophisticated but the choice will depend on your actual needs.
Wrapping it up, as it seems that you are just using JSF features then stick to the #ManagedProperty (CDI can't understand #NoneScoped annotations, in CDI all beans are under the #Default scope if none specified). Switching to CDI in your project might mean to replace not just the #ManagedProperty for an #Inject one, but all your #RequestScoped (and so on) for the CDI-specific ones.
I would favour CDI over managed beans whenever possible. CDI is richer in deploy-time dependency checking and its proxy support prevents scope leak. This makes it easier to verify the correctness of your model. Producers can generally be used to provide glue code where necessary.
CDI spec
Blog post on CDI and EL
Let's say If I have an application where I have been keeping all my XPages, most not necessarily related to each other. If I define several beans in the faces-config file for some of these XPages, what is the effect on memory and performance in the other XPages that do not use any of these managed beans? Aren't they instantiated and kept in memory (even if empty) for all the XPages in this application?
If so, then would it be best practice to keep the related XPages that will use a managed bean (and maybe share them) in their own NSF vs. having a single store for all the XPages for a site?
Howard
Managed bean is constructed only if referenced in EL/SSJS. Its scope defines, when it is discarded.
So from performance standpoint it does not matter (sort of) how many beans are defined in faces-config.
What you must take into account, though, is performance of methods. Especially setters/getters, which are called usually more times per request. Also avoid any excessive code in constructor of request scoped beans. Applies to memory demands too - try not to keep vast amount of data (arrays, maps...) in beans.
I would recommend to split XPages into more databases. Reason is different from beans performance - application logic. It is better to keep related functions together (into single NSF) and separated from others (don't mix them all at the same place).
That realy depends on the scope you are using to keep them in memory, what you are using them for etc etc..
I am writing a JSF 2.0 form to edit a JPA #Entity object. I have a backing bean that has a get method for the Entity, which it fetches from the EntityManager. So far so good.
The question is does the Entity object that is being edited by the user get accessed by other parts of the application? In other words if someone else calls up that record, do they see the field changes before I merge the record back into the data base via the EntityManager? Or do they get a different instance.
The reason this is important is that the user can enter all sorts of bad data. The validation phase done by the backing bean will not call merge() all the errors are cleared, but what about before then?
If this is a common instance, how do I avoid this problem?
The question is does the Entity object that is being edited by the user get accessed by other parts of the application? In other words if someone else calls up that record, do they see the field changes before I merge the record back into the data base via the EntityManager? Or do they get a different instance.
The entity instance used by JSF will be a detached entity instance. It is not one that belongs to the persistence context. Each client/user will also receive it's own instance of the detached entity.
The reason this is important is that the user can enter all sorts of bad data. The validation phase done by the backing bean will not call merge() all the errors are cleared, but what about before then?
The merging of any invalid data will occur on when you invoke EntityManager.merge to merge the contents of the detached entity with the persistence context. If you never invoked merge, then the modified contents of the Entity will never make it to the persistence context.
If this is a common instance, how do I avoid this problem?
You can always avoid this by validating the state of the entity before merging it with the persistence context. You could employ bean validation in both JSF and JPA, to prevent this scenario, although you will typically do this only in one layer, to prevent redundant checks. However, if you have specified validation groups for your bean validation constraints to distinguish between presentation and persistence constraints, then you ought be employing bean validation in both the layers. Do keep in mind, that once the contents of the bean have been merged successfully with the persistence context, there isn't a lot you can do to undo this change, except for a transaction rollback, or a refresh/clear of the persistence context.
Adding to the correct answer of Vineet:
You could possibly have an attached entity returned by your backing bean, for instance if you used a stateful session bean (EJB) with the extended persistence context.
In this case however you would still not risk concurrency issues, since every instance of a persistence context returns unique instances of attached entities (unique: instance not shared with other existing persistence contexts).
Furthermore, JSF will not push changes into the model (the attached JPA entity in this case) if any kind of validation error occurs. So as long as you have your validation set up correctly (bean validation or regular JSF validation), there will be no risk of 'tainting' the entity.
Additionally, note that for the attached case you would not have to call merge(), as this will automatically happen when the context closes, so instead you 'close' the stateful bean.
That said, the common case is the one Vineet describes where you get a detached entity.