> So why having @requestScoped in your backend // let close the troll here for > that Because transaction scoped EM doesn’t work quite often because JPA sucks when it comes to lazy loading :)
LieGrue, strub > Am 05.03.2015 um 16:52 schrieb Romain Manni-Bucau <[email protected]>: > > > 2015-03-05 16:43 GMT+01:00 Mark Struberg <[email protected]>: > > > Am 05.03.2015 um 10:45 schrieb Romain Manni-Bucau <[email protected]>: > > Nothing technical, just real life. You tend to update the code to make it > > do what you expect right? so if you use a bean in a front layer you can add > > front stuff inside and then break your fully backend stuff. > > Well in MY projects all the backend jars are simply not allowed to import any > frontend specs like servlet and JSF. We even have checkstyle rules to forbid > the import of those ;) > > > So why having @requestScoped in your backend // let close the troll here for > that > > > > The JBatch spec doesnt deal with scopes at all. CDI spec doesnt deal with > > jbatch. Why CDI shouldnt be set up? Actually it is but not "web" scopes. As > > I said this choice is to be aligned with other threading model in EE. No > > technical constraint, just trying to ensure portability. > > If the batch artifacts are CDI beans then CDI rules apply. As simple as that. > This is perfectly portable because of that. > > > JBatch doesn't mention CDI at all...this is implementation specific: "An > example of an implementation-specific loader might be CDI or Spring DI." > > LieGrue, > strub >
