+1 on this topic, code shared, and the responses, so far!

Reinis, if I saw your code months/weeks ago, I would have used your code to
do something 'similar' in my app, but no longer a need for that, but I like
how you use 'producer' to instantiate a loggedIn user.

Definitely, something I 'wanted' to do for my asynchronous tasks that
updates google calendar. I used to 'note' in the tomcat7-stderr/catalina
log file that 'google calendar was updated by [userName]' and I used to do
the same (use websocket to send a msg to clients) in the UI.  That was the
'only' reason why i needed 'user', but also, I was a bit 'lazy' to write
software to extract data from the database, and (still somewhat lazy, since
I) leave it up for the user (or UI, as John calls it) to 'provide' the
'latest' (user-requested) data.

I have yet to use observer/producer/etc... definitely, want to find
applications within my app to use it, all i have to do is use it once, and
then I will have reusable code to refer to, and use it again-and-again.

Anyway, I have to agree with John. As a JavaEE/JSF developer that learned
javaEE via Netbeans 7.0 generated code, I would recommend the following
order of access to database layer:

UI (JSF/xhtml page) > @SessionScoped or @RequestScoped bean(s) > @Stateless
EJB > entity class and JPA (persistence unit)

My app design/implementation that I described above (related to google
calendar), what happens is this...

1. User request (user makes data change) via UI/JSF/xhtml page
2. @SessionScoped bean retrieves data (via @Stateless EJB, or member of
@SessionScoped bean that is annotated with @EJB) for the reservation 'date'
per user request, and populates custom class/object (with Date value and
List<GoogleCalendarEvent>)

3. custom class/object is added to List<> in a @Singleton bean (that
manages list of dates/data to be sent to google calendar)

4. @Singleton bean returns 'null' or custom class/object to @SessionScoped
bean; if != null, then asynchronous task is initiated with the custom
class/object as a parameter

5. asynchronous task is completed via JMS/ActiveMQ; google calendar updated

With this design/implementation, the user 'always' provides the latest
data, and google calendar will be updated with the latest data
provided-per-user-request.



On Mon, Apr 15, 2013 at 10:21 AM, John D. Ament <[email protected]>wrote:

> Problem is like Romain says, @SessionScoped objects are proxied instances.
>  Not real instances of the class you think they are.  To avoid this proxy,
> you need to reduce your scope or directly invoke the method.  Personally, I
> wouldn't share my data model with my UI (need cleaner separation, force the
> application of business logic, etc); but that's just me.
>
>
> On Mon, Apr 15, 2013 at 10:04 AM, <[email protected]> wrote:
>
> > Hi John,
> >
> > but i am using EJB already (User producer and async worker).
> >
> > Do you mean injecting producer directly and then calling
> > producerInstance.produceUser()? Yes I could do that, but the effect will
> be
> > same as omitting @SessionScoped, right?
> >
> > My motivation was to get jpa representation of currently logged in user,
> > to pack it once into session (to minimize jdbc although i just realized
> > that openjpa caches!) and to reuse it whenever i want to CRUD something
> > user-related in jpa.
> >
> > I heard (from Struberg?) that DeltaSpike is goin to offer a solution for
> > this?
> >
> > Br
> > Reinis
> >
> > -----Ursprüngliche Nachricht-----
> > Betreff: Re: Re[2]: JPA issue in combo with @SessionScoped
> > Von: "John D. Ament" <[email protected]>
> > An: [email protected]
> > Datum: 2013/04/15 15:18:50
> >
> > The alternative is to just inject the EJB and call the method directly
> > here.
> >
> >
> > On Mon, Apr 15, 2013 at 8:14 AM, <[email protected]> wrote:
> >
> > > Hi Romain,
> > >
> > > thanks, I already guessed something like this. But is there some
> pattern
> > > to avoid this or work around or something I could use to make it work?
> > >
> > > Basically it means I may not use any cdi on jpa entities whatsoever and
> > > that is quite a constraint :)
> > >
> > > kind regards
> > > Reinis
> > >
> > > -----Original-Nachricht-----
> > > > Von: "Romain Manni-Bucau" <[email protected]>
> > > > An: [email protected]
> > > > Datum: 15-04-2013 14:09
> > > > Betreff: Re: JPA issue in combo with @SessionScoped
> > > >
> > > > a conflict between cdi and jpa
> > > >
> > > >
> > > > proxying the jpa entity makes another class created and then the jpa
> > > > provider doesn't find back your entity
> > > >
> > > > *Romain Manni-Bucau*
> > > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > > > *Blog: **http://rmannibucau.wordpress.com/*<
> > > http://rmannibucau.wordpress.com/>
> > > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > > > *Github: https://github.com/rmannibucau*
> > > >
> > > >
> > > >
> > > > 2013/4/15 <[email protected]>
> > > >
> > > > > Hi,
> > > > > I have neither pure JPA nor CDI, nor EJB question, it's more of a
> > mix:
> > > > >
> > > > > I have following classes (reasonably simplified)
> > > > >
> > > > > @javax.ejb.Stateless
> > > > > public class UserProducer {
> > > > >
> > > > >  @PersistenceContext
> > > > >  EntityManager entityManager;
> > > > >
> > > > >  //Achtung, it produces a SessionScoped logged in user
> > > > >  @Produces @SessionScoped @my.own.LoggedIn
> > > > >  public User produceUser() {
> > > > >   return entityManager.createQuery(...,
> > User.class).getSingleResult();
> > > > >  }
> > > > > }
> > > > >
> > > > >
> > > > > @javax.ejb.Stateful
> > > > > public class AsyncWorker {
> > > > >
> > > > >  @PersistenceContext
> > > > >  EntityManager entityManager;
> > > > >
> > > > >  @Asynchronous
> > > > >  public void invokePersist(User user) {
> > > > >   schedulerEntityService.persist(user);
> > > > >  }
> > > > > }
> > > > >
> > > > > @RunWith(org.apache.openejb.junit.ApplicationComposer.class)
> > > > > class IntegrationTest {
> > > > >  @Inject @LoggedIn
> > > > >  User user;
> > > > >
> > > > >  @Inject
> > > > >  AsyncWorker asyncWorker;
> > > > >
> > > > >  @Test
> > > > >  public void testIt() {
> > > > >     asyncWorker.invokePersist(user); //<- No metadata was found for
> > > type
> > > > > "class my.own.User_$$_javassist_7". The class does not appear in
> the
> > > list
> > > > > of persistent types: [my.own.User, ...].
> > > > >  }
> > > > > }
> > > > >
> > > > > The OpenJPA throws an
> > org.apache.openjpa.persistence.ArgumentException
> > > No
> > > > > metadata was found for type "class my.own.User_$$_javassist_7". The
> > > class
> > > > > does not appear in the list of persistent types: [my.own.User,
> ...].
> > > > > FailedObject: my.own.User_$$_javassist_7-1 [java.lang.String]
> > > > >
> > > > > ONLY IF the producer method produceUser() is annotated as
> > > @SessionScoped.
> > > > > If I remove annotation, the test case works and User entity is
> being
> > > > > persisted.
> > > > >
> > > > > Can anyone imagine what it could be about?
> > > > >
> > > > > thank you for your ideas and kind regards
> > > > > Reinis
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>

Reply via email to