Thomas, I'm trying to use batoo-jpa now, but the dependencies include transaction JAR that may be 'ignored' by TomEE container. Everytime I start TomEE (or deploy to app from NetBeans 7.2), the following shows up in my server log:
Nov 20, 2012 11:44:43 AM org.apache.tomee.catalina.TomEEClassLoaderEnricher validateJarFile WARNING: jar 'C:\Users\Public\NetBeansProjects\mcms\build\web\WEB-INF\lib\transaction-api-1.1.jar' contains offending class: javax.transaction.Transaction. It will be ignored. Also, there are so many dependencies for batoo-jpa. Still trying... On Tue, Nov 20, 2012 at 10:43 AM, Thomas Andraschko < andraschko.tho...@gmail.com> wrote: > Sorry for the off topic, but if you think that your biggest bottleneck is > in your data-layer, you should give batoo jpa a try ;) > > 2012/11/20 Howard W. Smith, Jr. <smithh032...@gmail.com> > > > Well, you and others 'sold' me onto TomEE, so here I am. If I can get > this > > migration to TomEE and CDI complete, and my endusers are happy, then more > > than likely, I will remain TomEE (supporter and user) for life, and will > > not plan to return to Glassfish. :) > > > > In production, my (PrimeFaces 3.4.1) app is running so fast with > Glassfish > > 3.1.2.2 and MyFaces Core 2.1.9, and JUEL (on an old Windows Server 2003 > > Dell server), so I hope TomEE and CDI will beat out the performance I > > currently have in production, and I'm positive that it will...since > > OpenWebBeans is fast (like you said in one of your blogs/posts). :) > > > > Since I started using TomEE, it seems as though you all recommend HSQLDB; > > I'm currently using 'Apache' Derby and that's working great, but I saw > some > > benchmark tests that OpenJPA and HSQLDB performs much better than > > OpenJPA/Derby and EclipseLink/Derby. Right now, I'm using EclipseLink. I > > may look into migrating from Derby to HSQL when I have plenty of time to > do > > so, but I rather do more fun 'java' programming than SQL programming > right > > now. I'm sure you can understand that. I think the biggest bottleneck in > my > > app is the database and probably the machine it's running on. And trust > me, > > I've read how to tune Derby for performance and I think I did all I could > > to tune my Derby database. :) > > > > Wow, interesting. Thanks for sharing that about CDI events. It's funny > that > > you said that CDI events != messages. :) > > > > I need to study the CDI tutorials and blogs a bit, so I can learn how to > > use CDI events. I really would like to use it whereever > > possible/applicable. :) > > > > > > > > On Tue, Nov 20, 2012 at 10:18 AM, Mark Struberg <strub...@yahoo.de> > wrote: > > > > > Dropping OpenEJB as we are now back to core JSF and related. I don't > want > > > to spam them ;) > > > > > > 1.): each container has pros and cons. And each of them needs different > > > workarounds in edge cases :) > > > > > > > > > 2.) I'm not using NetBeans, but it's basically the same scenario. In my > > > project I opted for only using META-INF/beans.xml and completely > dropping > > > WEB-INF/beans.xml. This is perfectly fine as per the CDI spec [1]. > > > > > > > > > >What is a good example or use case for using CDI events? > > > > > > Oh there are plenty! You just need to understand that CDI events != > > > messages. CDI events are _always_ synchronous and only get delivered to > > > beans in currently active contexts. > > > > > > > > > E.g. if you fire a CDI event and have a public @SessionScoped class > User > > > then only the contextual instance 'User' from the current session will > > > receive the event. > > > > > > You can think about CDI events as a method invocation where you do not > > > know on which (and how many) instances you invoke it. > > > > > > > > > A practical use case. In our application we have a big fat menu. The > menu > > > content is depending on the language of the user and his privileges. > > Since > > > this can change on a language change or if the user logs in/out, etc > most > > > apps always re-calculate the whole MenuItem tree from the database. > > > > > > > > > What we did in our application is the following: Menu is a > @SessionScoped > > > cdi bean and we do NOT re-calculate the items for every request. > Instead > > we > > > fire a UserSettingsChangedEvent on each language change and > login/logout. > > > In the Menu bean (and a lot other places) we @Observes > > > UserSettingsChangedEvent and reload the menu in that case. > > > > > > > > > This performs vastly better and allows us to radically cache lots of > > > things. > > > > > > > > > > > > LieGrue, > > > strub > > > > > > [1] https://issues.jboss.org/browse/CDI-218 > > > > > > >________________________________ > > > > From: "Howard W. Smith, Jr." <smithh032...@gmail.com> > > > >To: MyFaces Discussion <users@myfaces.apache.org>; Mark Struberg < > > > strub...@yahoo.de> > > > >Cc: "us...@openejb.apache.org" <us...@openejb.apache.org> > > > >Sent: Tuesday, November 20, 2012 3:56 PM > > > >Subject: Re: Migrating to CDI: @Asynchronous > > > > > > > > > > > >Mark, > > > > > > > > > > > >Cool beans and agreed about @Asynchronous! Since I read about > > > @Asynchronous on Stackoverflow.com (a post by David Blevins), I decided > > to > > > give it a try, but I think I did read that 'asynchronous' (runnable, > > > etc...) tasks are not all that good in web application. > > > > > > > > > > > >So, while you were writing your reply, I was already commenting out > the > > > call to the @Asynchronous method, and I reverted to the synchronous > > version > > > of the method to update Google Calendar. After adding @Asynchronous, I > > > added some logic that works better than @Asynchronous, it will not do a > > > google calendar update on 'every' database update; I have some > strategic > > > processing in place that brought the # of google calendar requests down > > by > > > hundreds and even thousands on a daily average. > > > > > > > > > > > >You know what? I attempted to add to META-INF as well as WEB-INF (some > > > days ago), and I already reported (in an earlier post) that that didn't > > > allow my web app to start in TomEE (or Glassfish, if I was still using > > > Glassfish when I reported that earlier...smile). > > > > > > > > > > > >In response to Eclipse...hopefully, no offense will be taken, i'm not > a > > > user of eclipse, I've been a user of NetBeans ever since I started > > > developing JSF web application (since last summer, 2011), and I can be > > the > > > loyal type if something or someone treats me good. I was 'loyal' to > > > Mojarra, but then I heard about the Mojarra issues updating components > > via > > > AJAX, so I migrated to MyFaces Core (when I heard MyFaces Core 2.1.7+ > > > performs better than Mojarra), and then reading one of your posts, > Mark, > > > about OpenWebBeans performing fast, and JIRA's and many people > mentioning > > > that CDI is better than JSF managed beans, I decided to migrate to CDI, > > and > > > determined to use any/all features available that is offered by CDI, > like > > > events, SSE (server sent events), push (like Atmosphere), etc... > > > > > > > > > > > >Was having trouble using Atmosphere with Glassfish, so decided to give > > > TomEE a whirl, since you, Andy Bailey (a friend in PrimeFaces forum), > and > > > others recommended TomEE. I like all that Glassfish 'markets' (or tries > > to > > > sell) to JSF developers, but I'm liking what I see and hear about > TomEE, > > > OpenWebBeans, OpenEJB, etc... > > > > > > > > > > > >What is a good example or use case for using CDI events? > > > > > > > >Thanks, > > > >Howard > > > > > > > > > > > > > > > > > > > >On Tue, Nov 20, 2012 at 9:36 AM, Mark Struberg <strub...@yahoo.de> > > wrote: > > > > > > > >Hi! > > > >> > > > >>One of my first advice is to make sure that beans.xml is really there > > > for the container. > > > >>I've seen this pretty often if someone starts the webapp directly > from > > > Eclipse. In that case the CDI container sometimes cannot find > > > WEB-INF/beans.xml as eclipse doesn't set the classpath entries > correctly. > > > >> > > > >>Sometimes it helps to add a META-INF/beans.xml to the webapp > classpath. > > > This will end up in WEB-INF/classes/META-INF/beans.xml and is perfectly > > > fine from a spec perspective. > > > >> > > > >>There's a 30% chance that this is your problem ;) > > > >> > > > >>For the @Asynchronous: > > > >> > > > >>In general I do not really like @Asynchronous in webapps. It's really > > > very seldom useful as you need to wait for the result anyway. It also > > > doesn't get any Session, Request or Transaction information propagated > > over > > > and it's not guaranteed to succeed. Think about what happens if an > > > Exception gets hit in the asynchronous bean? > > > >> > > > >>This is really only useful in 2 cases: > > > >>* fire and forget. If you don't take care if the job succeeds or not, > > > then you might use it. > > > >> > > > >>* spawning off multiple jobs and waiting for all of them before > > > returning. > > > >> > > > >>Still you need to take a lot of care about error handling and similar > > > stuff. > > > >> > > > >> > > > >>In our big application where we really need asynchronous tasks to be > > > guaranteed to get executed we went the classic route which works on the > > > Host since the 60s: we just write the job into an own 'Tasks' table and > > > process it via an own Quartz job. On success, it updates the status. On > > > error it sets the task to a failure status and adds information about > the > > > cause. > > > >>That way we have a failure safe and restartable implementation. > > > >> > > > >>LieGrue, > > > >>strub > > > >> > > > >> > > > >> > > > >>----- Original Message ----- > > > >>> From: "Howard W. Smith, Jr." <smithh032...@gmail.com> > > > >>> To: us...@openejb.apache.org; MyFaces Discussion < > > > users@myfaces.apache.org> > > > >>> Cc: > > > >>> Sent: Tuesday, November 20, 2012 3:06 PM > > > >>> Subject: Re: Migrating to CDI: @Asynchronous > > > >>> > > > >>> MyFaces Users, > > > >>> > > > >>> Please read OP (or my original email below), and then read this > > email, > > > and > > > >>> advise. > > > >>> > > > >>> Romain, > > > >>> > > > >>> Yes, I have a code snippet; please continue reading beyond/below > > first > > > code > > > >>> snippet. > > > >>> > > > >>> > > > >>> Below is the code that is called by multiple beans as well as the > > bean > > > >>> where this method is defined. > > > >>> > > > >>> /* > > > >>> * Is it safe to start a new thread in a JSF managed bean? > > > >>> * Look at answers by BalusC and David Blevins > > > >>> * > > > >>> > > > > > > http://stackoverflow.com/questions/6149919/is-it-safe-to-start-a-new-thread-in-a-jsf-managed-bean > > > >>> * > > > >>> * Java EE 6 Tutorial Chapter 27 Using Asynchronous Method > > > Invocation > > > >>> in Session Beans > > > >>> * http://docs.oracle.com/javaee/6/tutorial/doc/gkkqg.html > > > >>> */ > > > >>> @Asynchronous > > > >>> public Future<Date> updateGoogleCalendarPostEditAsync(Date > > > >>> tripDateToBePlacedInQueue) { > > > >>> > > > >>> String log; > > > >>> > > > >>> Date tripDate = > > > >>> > > > > > > usersController.queueDateAndOrUpdateGoogleCalendar(tripDateToBePlacedInQueue); > > > >>> if (tripDate == null) { > > > >>> return new AsyncResult<>(tripDate); > > > >>> } > > > >>> > > > >>> performingGoogleCalendarMaintenace = true; > > > >>> > > > >>> try { > > > >>> > > > >>> if (usersController.googleCalendarHasEvents()) { > > > >>> usersController.deleteEvents(tripDate, tripDate); > > > >>> } > > > >>> > > > >>> String tripDateFrom = > > > displayUtil.getDateFromDateTime(tripDate, > > > >>> false); > > > >>> String tripDateTo = > > > displayUtil.getDateFromDateTime(tripDate, > > > >>> false); > > > >>> > > > >>> List<Orders> list = > > > getFacade().findAllConfirmed(tripDateFrom, > > > >>> tripDateTo, true); > > > >>> > > > >>> if (list != null) { > > > >>> for (Orders o : list) { > > > >>> > > > >>> usersController.addEventToCalendar(newGoogleCalendarEvent(o)); > > > >>> } > > > >>> } > > > >>> > > > >>> log = > > > "pf_OrdersController.updateGoogleCalendarPostEditAsync(): > > > >>> " + > > > >>> new DateTime(tripDate).toString("MM/dd/yyyy") + > > > >>> " processed successfully"; > > > >>> } catch (Exception e) { > > > >>> e.printStackTrace(); > > > >>> messages.addFormErrorMsg("Error updating Google > > Calendar", > > > >>> (e.getMessage() != null) ? e.getMessage() : ""); > > > >>> log = > > > "pf_OrdersController.updateGoogleCalendarPostEditAsync(): > > > >>> " + > > > >>> new DateTime(tripDate).toString("MM/dd/yyyy") + > > > >>> " processing failed due to exception"; > > > >>> } finally { > > > >>> performingGoogleCalendarMaintenace = false; > > > >>> } > > > >>> System.out.println(log); > > > >>> > > > >>> // Return our result > > > >>> return new AsyncResult<>(tripDate); > > > >>> } > > > >>> > > > >>> Below, is code where the @Asynchronous method is *called within the > > > same > > > >>> bean*, and is not the last piece of code in the calling method. > > > >> > > > >>> > > > >>> /* > > > >>> * 1. if tripDate changed, then update Google Calendar > > for > > > >>> original trip date > > > >>> * 2. update Google Calendar for current trip date > > > >>> */ > > > >>> if (new > > > >>> > DateTime(current.getReportDateTime()).toString("MM/dd/yyyy").equals( > > > >>> new > > > >>> DateTime(tripDateBeforeEdit).toString("MM/dd/yyyy")) > > > >>> == false) { > > > >>> > > updateGoogleCalendarPostEditAsync(tripDateBeforeEdit); > > > >>> } > > > >>> > > > updateGoogleCalendarPostEditAsync(current.getReportDateTime()); > > > >>> } > > > >>> if (invokePrepareEdit) > > > >>> return prepareEdit(); > > > >>> else > > > >>> return null; > > > >>> > > > >>> Below, is code that is at the very end of a calling method and > > *called > > > >>> within the same bean*, so there are no concerns here. > > > >> > > > >>> > > > >>> /* > > > >>> * update Google Calendar for current trip date > > > >>> */ > > > >>> > > > updateGoogleCalendarPostEditAsync(current.getReportDateTime()); > > > >>> return returnToBrowseOrView(); > > > >>> > > > >>> > > > >>> Below, is code that was *added to another bean*, that will call the > > > >>> *@Asynchronous > > > >>> method defined on the other bean* (ordersController). > > > >> > > > >>> > > > >>> public void updateGoogleCalendar() { > > > >>> if (relatedEntityName.equals("orders")) { > > > >>> Orders order = (Orders) relatedEntityObj; > > > >>> > > > >>> > > > > > > ordersController.updateGoogleCalendarPostEditAsync(order.getTripDateTime()); > > > >>> } > > > >>> } > > > >>> > > > >>> The method above, updateGoogleCalendar(), is called by code similar > > to > > > >>> below, which is not the last code executed in calling method. > > > >>> > > > >>> if (relatedEntityName.equals("orders")) { > > > >>> auditTrailDesc = "Updated ORDER: updated ORIGIN" + > > > >>> (originTx != null && > > originTx.length() > > > >>>> 0 > > > >>> ? "(" + originTx + ")" : ""); > > > >>> > > > >>> auditTrailController.createFromRelatedEntity(relatedEntityName, > > > >>> relatedEntityObj, auditTrailDesc); > > > >>> *// update Google Calendar* > > > >>> *updateGoogleCalendar();* > > > >> > > > >>> } > > > >>> else if (relatedEntityName.equals("orderDriver")) { > > > >>> OrderDriver od = (OrderDriver) relatedEntityObj; > > > >>> OrderCostDetails orderCostDetails = > > > >>> od.getOrderCostDetails(); > > > >>> Orders order = new > > > >>> ArrayList<>(orderCostDetails.getOrders()).get(0); > > > >>> auditTrailDesc = "updated ORIGIN" + > > > >>> > > > >>> > > > >>> > > > >>> Thanks, > > > >>> Howard > > > >>> > > > >>> > > > >>> On Tue, Nov 20, 2012 at 2:25 AM, Romain Manni-Bucau > > > >>> <rmannibu...@gmail.com>wrote: > > > >>> > > > >>>> Hi, > > > >>>> > > > >>>> can you share any snippet of code? > > > >>>> > > > >>>> *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* > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> 2012/11/20 Howard W. Smith, Jr. <smithh032...@gmail.com> > > > >>>> > > > >>>> > Prior to migrating from JSF managed to CDI (and currently in > > > >>> production), > > > >>>> > my web app is using @Asynchronous on @SessionScoped bean to > push > > > data > > > >>> to > > > >>>> > and keep Google Calendar updated with specific data from the > > > database. > > > >>>> > > > > >>>> > Honestly, I don't think I coded it correctly. What I mean by > > that, > > > >>> I > > > >>>> don't > > > >>>> > think I'm handling or capturing the return value of > @Asynchronous > > > >>>> methods, > > > >>>> > and honestly, I don't know where execution is ending after some > > or > > > >>> most > > > >>>> of > > > >>>> > the calls to @Asynchronous methods. > > > >>>> > > > > >>>> > Currently, in production, the @Asynchronous method calls seem > to > > be > > > >>>> working > > > >>>> > fine (production = MyFaces Core 2.1.9, JSF managed beans, > > Glassfish > > > >>>> > 3.1.2.2). Now that I'm migrating to TomEE/CDI, it seems as > though > > > >>>> > @Asynchronous is breaking my app; of course, I don't mind > > > >>> accepting > > > >>>> > responsibility and calling it a developer error. @Asynchronous > > > seems > > > >>> to > > > >>>> > result with the following error: > > > >>>> > > > > >>>> > Target Unreachable, identifier resolved to null > > > >>>> > > > > >>>> > I've read the following: > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > >>> > > > > > > http://www.andrejkoelewijn.com/wp/2010/03/05/jee-cdi-tip-target-unreachable-identifier-resolved-to-null/ > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > >>> > > > > > > http://stackoverflow.com/questions/4845041/target-unreachable-identifier-resolved-to-null > > > >>>> > > > > >>>> > but I have an empty beans.xml in WEB-INF and I have no JARs of > my > > > own > > > >>> (so > > > >>>> > no need to add beans.xml to META-INF, and please note, a lot of > > the > > > >>> xhtml > > > >>>> > pages in the app are working as designed. Also, I read > something > > > about > > > >>>> > cyclic references (below) > > > >>>> > > > > >>>> > "injection points in one bean deployment archive cannot be > > > >>> satisfied by a > > > >>>> > bean in a separate bean archive, even when they are from > > libraries > > > in > > > >>> the > > > >>>> > same module (web > > > >>>> > archive)"< > > > >>>> > > > > >>>> > > > >>> > > > > > > http://java.net/jira/browse/GLASSFISH-15721?focusedCommentId=301147&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_301147 > > > >>>> > > > > > >>>> > > > > >>>> > but I'm sure that is not the cause of the error that I'm > > > >>> experiencing. > > > >>>> > > > > >>>> > So, would you all recommend me to consider CDI Events instead > of > > > >>>> > @Asynchronous, both, or should I just fix @Asynchronous to work > > in > > > the > > > >>>> CDI > > > >>>> > app? > > > >>>> > > > > >>>> > Thanks, > > > >>>> > Howard > > > >>>> > > > > >>>> > > > >>> > > > >> > > > > > > > > > > > > > > > > > >
